From owner-ips@ece.cmu.edu Sat Jun 1 02:06:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17909 for ; Sat, 1 Jun 2002 02:06:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g515K0I05463 for ips-outgoing; Sat, 1 Jun 2002 01:20:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.pwebtech.com ([64.21.143.152]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g515Jtw05451 for ; Sat, 1 Jun 2002 01:19:55 -0400 (EDT) Received: (qmail 23928 invoked from network); 1 Jun 2002 05:19:49 -0000 Received: from unknown (HELO workstation03) (12.81.30.242) by rt1.pwebtech.com with SMTP; 1 Jun 2002 05:19:49 -0000 Message-ID: <015301c2092c$241a2760$0100a8c0@workstation03> From: "Charles Lambka" To: Subject: remove Date: Fri, 31 May 2002 21:51:04 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0146_01C208ED.430A8730" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0146_01C208ED.430A8730 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable remove ------=_NextPart_000_0146_01C208ED.430A8730 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
remove
------=_NextPart_000_0146_01C208ED.430A8730-- From owner-ips@ece.cmu.edu Sat Jun 1 03:04:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22340 for ; Sat, 1 Jun 2002 03:04:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g516Eju07894 for ips-outgoing; Sat, 1 Jun 2002 02:14:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g516Ehw07889 for ; Sat, 1 Jun 2002 02:14:43 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g516EWrd026706 for ; Sat, 1 Jun 2002 08:14:32 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g516EVF118444 for ; Sat, 1 Jun 2002 08:14:31 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: keys/parameter dependence X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 1 Jun 2002 09:14:25 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 01/06/2002 09:14:31, Serialize complete at 01/06/2002 09:14:31 Content-Type: multipart/alternative; boundary="=_alternative 00212157C2256BCB_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00212157C2256BCB_= Content-Type: text/plain; charset="us-ascii" I think we can leave it to individual keys and say only that dependencies and how to handle them are specified with keys. Julo pat_thaler@agilent.com Sent by: owner-ips@ece.cmu.edu 06/01/2002 03:02 AM Please respond to pat_thaler To: John Hufferd/San Jose/IBM@IBMUS, mkrikis@yahoo.com cc: Mike.Donohoe@quantum.com, ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence John, The part that might cause interoperability problems is different interpretations of which parameters action or acceptance is dependent on others. For instance, does the sentence mean that InitialR2T should be sent before FirstBurstSize and that FirstBurstSize doesn't need a response when the response to InitialR2T was Yes? If the sentence is left in, then it should be clarified by adding something such as: "The definition of a key specifies whether the key is dependent on any other keys." and if any of our current keys are dependent, add to those keys "This key is dependent on ." If none are currently dependent, it would be reasonable to add to 11 "Currently, no Login/Text Operational keys are dependent." Pat -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Friday, May 31, 2002 2:38 PM To: Martins Krikis Cc: Mike Donohoe; 'ips@ece.cmu.edu' Subject: Re: iSCSI: keys/parameter dependence I do not see a problem with the Text, the previous key=value pairs are ones that were in previous PDUs or key=value pairs that were scanned previous to the current pair being scanned. It is not clear that we have to write any thing else to help people understand the concept of previous. I think we are straining at a nat here, and it is not worth the effort. I do not see the problem. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Martins Krikis @ece.cmu.edu on 05/31/2002 01:15:26 PM Sent by: owner-ips@ece.cmu.edu To: Mike Donohoe , "'ips@ece.cmu.edu'" cc: Subject: Re: iSCSI: keys/parameter dependence --- Mike Donohoe wrote: > From 12-95 4.3.3 pg 80 (and also in 4.4 pg 83): > > Whenever parameter action or acceptance are > dependent on other parameters, > the dependent parameters MUST be sent after the > parameters on > which they depend. If they are sent within the same > command, a > response for a parameter might imply responses for > others. I've been ignoring this paraghaph having been convinced that there are no dependencies among the operational parameters (those allowed to be used in the operational stage of login), and that any dependencies for security parameters would be naturally observed by security protocols (i.e., first send me this, I'll send you that, now send this, etc.). However, I think you raised some good questions. I think this paragraph should be removed. Here are the reasons: "(sent) after" isn't defined. It is unclear whether "in higher numbered bytes within the same PDU" qualifies as "after" or whether only "in a PDU sent at a later time" would. It's probably irrelevant, since due to the introduction of the C-bit, parameters can be accumulated and processed one "batch" at a time, without any specific order within the "batch" and they will quite likely not be processed PDU by PDU. Therefore, the text about them being sent in "the same command" is likely irrelevant, too, since many implementation simply won't check that. But what's really dangerous here is that an implementation that perceives some parameters as dependent may take the "might imply" text as an endorsement for sending back less key=value pairs than was received, which could make the other side never commit due to missing responses. We certainly don't want to allow for such a non-interoperability in the specification. So, could we please get rid of this whole paragraph? Thanks, Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com --=_alternative 00212157C2256BCB_= Content-Type: text/html; charset="us-ascii"

I think we can leave it to individual keys and say only that dependencies and how to handle them are specified with keys.

Julo


pat_thaler@agilent.com
Sent by: owner-ips@ece.cmu.edu

06/01/2002 03:02 AM
Please respond to pat_thaler

       
        To:        John Hufferd/San Jose/IBM@IBMUS, mkrikis@yahoo.com
        cc:        Mike.Donohoe@quantum.com, ips@ece.cmu.edu
        Subject:        RE: iSCSI: keys/parameter dependence

       


John,

The part that might cause interoperability problems is different
interpretations of which parameters action or acceptance is dependent on
others. For instance, does the sentence mean that InitialR2T should be sent
before FirstBurstSize and that FirstBurstSize doesn't need a response when
the response to InitialR2T was Yes?

If the sentence is left in, then it should be clarified by adding something
such as:
"The definition of a key specifies whether the key is dependent on any other
keys."
and if any of our current keys are dependent, add to those keys
"This key is dependent on <key names>."
If none are currently dependent, it would be reasonable to add to 11 "Currently,
no Login/Text Operational keys are dependent."

Pat

-----Original Message-----
From: John Hufferd [mailto:hufferd@us.ibm.com]
Sent: Friday, May 31, 2002 2:38 PM
To: Martins Krikis
Cc: Mike Donohoe; 'ips@ece.cmu.edu'
Subject: Re: iSCSI: keys/parameter dependence



I do not see a problem with the Text, the previous key=value pairs are ones
that were in previous PDUs or key=value pairs that were scanned previous to
the current pair being scanned.  It is not clear that we have to write any
thing else to help people understand the concept of previous.  I think we
are straining at a nat here, and it is not worth the effort.

I do not see the problem.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com


Martins Krikis <mkrikis@yahoo.com>@ece.cmu.edu on 05/31/2002 01:15:26 PM

Sent by:    owner-ips@ece.cmu.edu


To:    Mike Donohoe <Mike.Donohoe@quantum.com>, "'ips@ece.cmu.edu'"
      <ips@ece.cmu.edu>
cc:
Subject:    Re: iSCSI: keys/parameter dependence



--- Mike Donohoe <Mike.Donohoe@quantum.com> wrote:

> From 12-95 4.3.3 pg 80 (and also in 4.4 pg 83):
>
> Whenever parameter action or acceptance are
> dependent on other parameters,
> the dependent parameters MUST be sent after the
> parameters on
> which they depend. If they are sent within the same
> command, a
> response for a parameter might imply responses for
> others.

I've been ignoring this paraghaph having been
convinced that there are no dependencies among
the operational parameters (those allowed to be
used in the operational stage of login), and that
any dependencies for security parameters would
be naturally observed by security protocols (i.e.,
first send me this, I'll send you that, now
send this, etc.).

However, I think you raised some good questions.
I think this paragraph should be removed.
Here are the reasons:

"(sent) after" isn't defined. It is unclear
whether "in higher numbered bytes within the
same PDU" qualifies as "after" or whether only
"in a PDU sent at a later time" would. It's
probably irrelevant, since due to the introduction
of the C-bit, parameters can be accumulated and
processed one "batch" at a time, without any
specific order within the "batch" and they will
quite likely not be processed PDU by PDU.
Therefore, the text about them being sent in
"the same command" is likely irrelevant, too,
since many implementation simply won't check that.

But what's really dangerous here is that an
implementation that perceives some parameters
as dependent may take the "might imply" text
as an endorsement for sending back less key=value
pairs than was received, which could make the
other side never commit due to missing responses.
We certainly don't want to allow for such a
non-interoperability in the specification.

So, could we please get rid of this whole
paragraph?

Thanks,

Martins Krikis, Intel Corp.

Disclaimer: these opinions are mine and may not
           be those of my employer.


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com



--=_alternative 00212157C2256BCB_=-- From owner-ips@ece.cmu.edu Sat Jun 1 08:56:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22361 for ; Sat, 1 Jun 2002 08:56:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g51CBsQ03206 for ips-outgoing; Sat, 1 Jun 2002 08:11:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4VLBbw10728 for ; Fri, 31 May 2002 17:11:37 -0400 (EDT) Received: from pacman.cisco.com (pacman.cisco.com [171.71.161.106]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4VLBUHt005208; Fri, 31 May 2002 14:11:30 -0700 (PDT) Date: Fri, 31 May 2002 14:11:30 -0700 (PDT) From: Arvind Prabhudev To: Keith McCloghrie , cc: ips@ece.cmu.edu, , , , , Mickey Spiegel Subject: Re: FC Mgmt mib In-Reply-To: <200205241613.JAA07884@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Hello Keith, Very sorry for the delay. Your suggested 3 changes will meet our needs. My initial hesitancy to consider us as the 'bridge' port was because we are not a B-port as in FC-BB-2. We transport FC over GigE. Our port is a wire extender. So if we expand the description of 'bridge' to explicitly state that it could be a wire-extender port too, we could forgo the need for 'tunnel' code point. We do need the draft FC mib to allow us to report BB-credit and data field size info. And probably generalising fcmEPortTable is not a bad idea if we are sure that B-ports and E-ports share a common set of parameters and nothing will be added to one which will not be applicable to another. thanks, Arvind >>>>> Date: Wed, 29 May 2002 15:38:47 -0700 From: charissa.willard@sanvalley.com For FC over IP a port can be either a B_port or an E_port. A B_port supports Class F frames and thus could at least use the Class F BB_Credit object that you specified in fcmEPortTable. The MIB defines the FcUnitFunction type of 'bridge' as "encapsulates FC frames within another protocol". Doesn't this imply "tunneling"? Since a B_port is transparent to the Fabric, just providing a table for B_Ports may provide a solution for other devices/ports that are transparent to the Fabric and need an object for BB_Credit. <<<<< On Fri, 24 May 2002, Keith McCloghrie wrote: > Arvind, > > (Sorry for the delay in responding.) It seems to me that you are > requesting the following three changes: > > 1. a new code point for FcUnitFunctions > > - I think this is fine, except how about calling it 'tunnel' ?? > > 2. Changing the fcmLinkTable from mandatory to optional > > - I think this is fine. > > 3. A new table for 'tunnel' ports > > - I'd rather not add a new table unless it's absolutely necessary. > How about I just broaden the scope of the fcmEPortTable so that > it applies not only to E_Ports but also to 'tunnel' ports ?? > > The MIB will also need a new group for devices supporting 'tunnel' > functionality, which will contain just fcmEPortClassFCredit > and fcmEPortClassFDataFieldSize, right ?? > > If you agree to the above (and nobody else objects), then I'll go > ahead and update the MIB. > > The only other pending changes are an alignment of the meanings of bits > of the FcUnitFunctions TC with the latest update to the meanings in the > GS-4 specification (note that FcUnitFunctions's SYNTAX is unchanged), > and some other typos. > > In fact, if anyone else has any changes that they would like to propose > before Last Call, can I request that they raise them now. > > Thanks, > Keith. > > > From: Arvind Prabhudev > > Message-ID: > > Date: Mon, 29 Apr 2002 21:06:40 -0700 (PDT) > > To: ips@ece.umn.edu > > Subject: FC Mgmt mib > > > > (This is regarding draft-ietf-ips-fcmgmt-mib-01) > > > > Hello, > > > > I am writing on behalf of a group at Cisco which is developing an optical > > box. One of our linecards is aimed at providing Fibre Channel aggregation > > while simultaneously extending fibrechannel connectivity to much larger > > distances. Fibre channel frames are encapsulated into ethernet frames, > > tagged with a flow identifier and these frames are packet multiplexed > > over the trunk interface (which operates at the ITU grid frequency). > > > > -------+ +---------+ +---------+ +------- > > Regular| FC |Our box 1| GigE |Our box 2| FC |Regular > > FC port+---------+ X Tx+-----------+Ty Y +---------+FC Port > > A | | | | | | B > > -------+ +---------+ +---------+ +------- > > > > In figure above, FC streams from multiple X & Y ports are ethernet > > encapsulated and multiplexed over Tx & Ty ports respectively. > > > > We were considering supporting the draft-ietf-ips-fcmgmt-mib-01 for > > providing fibre channel management of our box. We had a few requests in > > this regard. > > > > As described above, we do not terminate fibrechannel at the FC-2 level. > > We handle only upto FC-1 level. We remain transparent to the fibre channel > > connectivity. We feel that there is no appropriate value in the > > FcUnitFunctions type that would describe the nature of our box. We > > would like to propose a new code point 'transport'. > > > > Secondly, we wanted a means to report the BB Credit on our (X & Y) ports. > > There are FcBbCredit objects in fcmFxPortTable & fcmEPortTable through > > which we can report this value. But, we are neither an F nor E port. So > > would it possible to consider our ports as a new category of 'transport' > > ports which do SAN extension and have a separate table for it which has BB > > credit object? > > > > The last issue is regarding the fcmLinkTable. It is currently mandatory. > > We would prefer that the table was made optional. Ofcourse, the table in > > its current form does not preclude not populating it, if nothing was > > learnt. Any information about the ID of the source port & node that we are > > connected to, which we might discover by potentially snooping the frames, > > we would like to report via the PTOPO-MIB (rfc2922). > > > > I hope our inputs could be incorporated into the proposed FC mgmt MIB draft. > > Please let us know what you think. > > > > best regards, > > Arvind > > > From owner-ips@ece.cmu.edu Sat Jun 1 14:08:28 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25910 for ; Sat, 1 Jun 2002 14:08:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g51Hiwb18314 for ips-outgoing; Sat, 1 Jun 2002 13:44:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g51Hiuw18308 for ; Sat, 1 Jun 2002 13:44:56 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g51Hioj2016484 for ; Sat, 1 Jun 2002 19:44:50 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g51Hio264336 for ; Sat, 1 Jun 2002 19:44:50 +0200 To: ips@ece.cmu.edu Importance: High MIME-Version: 1.0 Subject: iSCSI 12-96 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 1 Jun 2002 20:44:48 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 01/06/2002 20:44:50, Serialize complete at 01/06/2002 20:44:50 Content-Type: multipart/alternative; boundary="=_alternative 0061201FC2256BCB_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0061201FC2256BCB_= Content-Type: text/plain; charset="us-ascii" is out - julo --=_alternative 0061201FC2256BCB_= Content-Type: text/html; charset="us-ascii"
is out - julo --=_alternative 0061201FC2256BCB_=-- From owner-ips@ece.cmu.edu Sat Jun 1 14:08:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25923 for ; Sat, 1 Jun 2002 14:08:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g51HOrw17240 for ips-outgoing; Sat, 1 Jun 2002 13:24:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web14205.mail.yahoo.com (web14205.mail.yahoo.com [216.136.172.151]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g51HOpw17236 for ; Sat, 1 Jun 2002 13:24:52 -0400 (EDT) Message-ID: <20020601172451.41273.qmail@web14205.mail.yahoo.com> Received: from [12.232.113.21] by web14205.mail.yahoo.com via HTTP; Sat, 01 Jun 2002 10:24:51 PDT Date: Sat, 1 Jun 2002 10:24:51 -0700 (PDT) From: surya prakash varanasi Subject: remove To: ips@ece.cmu.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk remove __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Sat Jun 1 14:11:13 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25964 for ; Sat, 1 Jun 2002 14:10:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g51HK3e16992 for ips-outgoing; Sat, 1 Jun 2002 13:20:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g51HK1w16987 for ; Sat, 1 Jun 2002 13:20:01 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g51HJtj2011426 for ; Sat, 1 Jun 2002 19:19:55 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g51HJsF23474 for ; Sat, 1 Jun 2002 19:19:54 +0200 Importance: High Subject: RE: iSCSI-12-95 To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Sat, 1 Jun 2002 18:43:09 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 01/06/2002 20:19:54 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk How about the following text: If CHAP is used with a secret that has less than 96 random bits then IPsec encryption (according to the implementation requirements in Section 7.3.2 Confidentiality) MUST be used to protect the connec-tion. Moreover, in this case IKE authentication with group pre-shared keys MUST NOT be used unless it is not essential to protect group members against off-line dictionary attacks of other members. When CHAP is used with secret shorter than 96 bits, a compliant implemen-tation MUST NOT continue with the login unless it can verify that IPsec encryption is being used to protect the connection. Julo ----- Forwarded by Julian Satran/Haifa/IBM on 06/01/2002 06:41 PM ----- Julian Satran To: "THALER,PAT (A-Roseville,ex1)" 05/31/2002 07:18 cc: ips@ece.cmu.edu AM From: Julian Satran/Haifa/IBM@IBMIL Subject: RE: iSCSI-12-95(Document link: Julian Satran - Mail) Pat, Comments in text. Julo "THALER,PAT (A-Roseville,ex1) To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu " cc: 05/31/2002 12:52 AM Please respond to "THALER,PAT (A-Roseville,ex1) " Julian, I am having two problems with the second MUST in the following paragraph from iSCSI-12-95 7.2.1: If CHAP is used with a secret that has less than 96 random bits then IPsec encryption (according to the implementation requirements in Section 7.3.2 Confidentiality) MUST be used to protect the connection. Moreover, in this case IKE authentication with group pre-shared keys MUST NOT be used. When CHAP is used with secret shorter than 96 bits, a compliant implementation MUST NOT continue with the login unless it can verify that IPsec encryption is being used to protect the connection. Who or what does the requirement apply to? Is the iSCSI implementation expected to check whether IKE is using pre-shared keys or is this a requirement on the person setting up the security? It isn't clear to me that an iSCSI implementation has access to that information. +++ the requirement about checking length is an implementation requirement (if you can't check that you have IPsec then you must fail login). The requirement about IKE is for the administrator/manager at least.+++ Secondly, it isn't clear to me why it is required. I'm assuming the concern is that a member of a group with preshared keys could use an off-line dictionary attack to crack the CHAP secret of another member of the group but it seems to me that there are situations where this is not a threat. For instance, one could have a group that was a host and multiple equally secure disk arrays. If one isn't concerned about one of the arrays trying to impersonate another there isn't a danger in allowing them to authenticate with CHAP protected by IPsec enryption with a group pre-shared key. Could the MUST be made a SHOULD with a statement that ignoring the SHOULD means that one member of the group could crack the CHAP secret of another member? +++ this is a fair assessment of the situation and I think that your suggestion makes sense +++ Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, May 29, 2002 3:02 PM To: ips@ece.cmu.edu Subject: iSCSI-12-95 12-95 is out. It has the latest wording on security and text negotiation (including the spanning). Still to go - text fixes in chapter 11. Julo From owner-ips@ece.cmu.edu Sun Jun 2 09:46:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14638 for ; Sun, 2 Jun 2002 09:46:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g52D0op20433 for ips-outgoing; Sun, 2 Jun 2002 09:00:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (io.iol.unh.edu [132.177.123.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g529Rqw11459 for ; Sun, 2 Jun 2002 05:27:52 -0400 (EDT) Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.3/8.12.3) with ESMTP id g529Ri4F012706 for ; Sun, 2 Jun 2002 05:27:45 -0400 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.3/8.12.3/Submit) with ESMTP id g529RiwH012703 for ; Sun, 2 Jun 2002 05:27:44 -0400 Date: Sun, 2 Jun 2002 05:27:44 -0400 (EDT) From: "Robert D. Russell" To: ips@ece.cmu.edu Subject: Re: iSCSI: keys/parameter dependence Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian: The following paragraph from an e-mail from Martins Krikis made me realize that the definition of the new C bit is not correct, because it goes much further than is necessary to solve the "split key" problem, and as a result, it opens up a whole new set of problems, complicates what was previously a simple situation, and breaks a lot of already running and tested code. > "(sent) after" isn't defined. It is unclear > whether "in higher numbered bytes within the > same PDU" qualifies as "after" or whether only > "in a PDU sent at a later time" would. It's > probably irrelevant, since due to the introduction > of the C-bit, parameters can be accumulated and > processed one "batch" at a time, without any > specific order within the "batch" and they will > quite likely not be processed PDU by PDU. > Therefore, the text about them being sent in > "the same command" is likely irrelevant, too, > since many implementation simply won't check that. > I don't believe the intention of the recent discussion that led to the introduction of the C bit was, in fact, to allow "batching" or to throw out "ordering" of the sending of keys. However, the definition in Draft 12-95 sections 9.10.2 and 9.11.2 seems to now allow batching: (I agree with John Huffered that Martins' comments about "ordering" are not correct in any case.) Section 9.10.2 C (Complete) Bit: "When set to 1, indicates that the text (set of key=value pairs) in this Text Request is not complete (it will be continued on a subsequent Text Request); otherwise, it indicates that this Text Request ends a set of key=value pairs." (Section 9.11.2 is the same, but with Response substituted for Request.) The problem I see with this definition of the C bit is that the sending side can force the receiving NOT to process a PDU containing key=value pairs, even if all those key=value pairs are complete within the PDU. Therefore, the receiver is forced to save this PDU (and any number of following PDUs) until the sender finally sends C = 0. In the worst case, the sender could send one key=value pair per PDU with the C bit set to 0 and the receiver could not reply to any of these until it got one with C bit set to 1. As the e-mail from Martins indicates, some people are already taking this to mean that parameter negotiations will "normally" be batched. Up until the introduction of the C bit, PDUs and keys in them were always processed as received, and most code already does this, since it is the most logical and efficient way to do it. We should still encourage this as the "normal" way of negotiating. I believe the problem we were trying to solve by introducing the C bit was the one where a key was split over a PDU boundary -- we were not trying to redesign the negotiation mechanism, which was discussed on the mailing list long ago and has been working in a lot of running code for the past two plugfests. Could we therefore please change the definition of the C bit in section 9.10.2 to read: "When set to 1, indicates that the text in this Text Request contains a single key=value pair, and that pair is incomplete within this PDU." (Section 9.11.2 should have the same change, but with Response instead of Request) I believe this corresponds more closely with the description in section 4.2 Text Mode Negotiation, where the C bit (flag) is clearly tied to the idea of split keys only: "Key=value" pairs may span PDU boundaries. An initiator or target having sent partial key=value text within a PDU indicates that more text follows by setting the C flag bit in the Text Request or Text Response to 1." Perhaps an additional sentence could also be added to this: "The following PDUs should only contain text that completes the partial key=value text until after a PDU with C set to 1 has been sent, at which time new key=value pairs can be sent in the next PDU." I'm not happy about seeing such a major change (C flag bit) introduced so late in the process to solve an "almost" non-existant problem (split keys). It is "almost" non-existand because of the following considerations (some of which were already mentioned on the list and are just summarized here): During the login process, the PDU size is 8192 bytes. Therefore, except for the long keys during negotiation that follows a chosen AuthMethod, there is never a need to split keys across pdu boundaries during login -- even if you negotiate every possible login key (except those special keys that occur in security protocols) to its maximum length, you do not reach the total of 8192 bytes. It is not even close! Therefore, there is no need for any implication that the C bit should appear during this process. When those long security keys are needed, the negotiation process is in a 1 key over, 1 key back exchange mode, so there is no "batching" possible and the split key should in fact be the only key in the pdu. Finally, during text exchanges, there only 6 keys that can be legally sent (plus the X-extension key): SendTargets, TargetName, TargetAlias, TargetAddress, InitiatorAlias, and MaxRecvPDULength. None of these can legally have a value greater than 255 bytes, which is well less than the minimum PDU size (512 bytes). So there is no need to split keys over boundaries during text negotiation, except perhaps for the X-extension keys. My proposed definition of the C bit as applying only to split keys therefore only applies to X-extension keys during text negotiation. Since we have had no experience with X- keys, and cannot forsee their use, anything we introduce only for them should be the minimum possible. In summary, I would like to see as little disruption as possible to the key negotiation scheme which has been stable for a long time, especially since anything we introduce will be needed only in very limited circumstances. I believe my modification to the definition of the C flag accomplishes that, without introducing any new, false perceptions about "batching" and "ordering". Thank you for your consideration. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Sun Jun 2 14:00:12 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17723 for ; Sun, 2 Jun 2002 14:00:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g52GxGk00634 for ips-outgoing; Sun, 2 Jun 2002 12:59:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g52GxEw00629 for ; Sun, 2 Jun 2002 12:59:15 -0400 (EDT) Received: from twestrelay04.boulder.ibm.com (twestrelay04.boulder.ibm.com [9.17.194.55]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g52GxD29030100; Sun, 2 Jun 2002 12:59:13 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by twestrelay04.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g52GxCM165990; Sun, 2 Jun 2002 10:59:12 -0600 Importance: Normal Subject: Re: iSCSI: keys/parameter dependence To: "Robert D. Russell" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Sun, 2 Jun 2002 09:57:25 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 06/02/2002 10:59:12 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I think Robert makes a good point here. But let me also use this as a platform to again warn about last minute changes to any spec that has been worked over for a long time with long forgotten reasons for why decisions were made, even why compromises were reached. Changes made at this point should be the absolute minimum, and avoided if at all possible. The probability of unforeseen impacts are the greatest for any changes made at the end of a design process. And what we are doing here is not an exception to this rule. For us to have gone this far for this corner case, at this late stage, demonstrates that many of us are permitting last minute flaps to push us into acquiescence in order to get to last call. We of course need to make changes to things that are broken, but sometimes, if it only fails when someone does unnatural acts, then perhaps we should not care to fix that in this go around, and instead let the vendors that do that suffer from the consequences of pushing the envelope. Any such thoughts like this are contrary to the way engineers like us think, however, we constantly live with this as our products get close to ship time. I am NOT advocating this as a blanket position, just a thought rigor that we should each factor in. I think we should also be thinking about what we should put into the next revision of the spec., and perhaps start accumulating various thoughts that might be approprate for that, and then as we think of changes ask ourselves, if the new thoughts need to be in this spec or in a follow on draft. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Robert D. Russell" @ece.cmu.edu on 06/02/2002 02:27:44 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: iSCSI: keys/parameter dependence Julian: The following paragraph from an e-mail from Martins Krikis made me realize that the definition of the new C bit is not correct, because it goes much further than is necessary to solve the "split key" problem, and as a result, it opens up a whole new set of problems, complicates what was previously a simple situation, and breaks a lot of already running and tested code. > "(sent) after" isn't defined. It is unclear > whether "in higher numbered bytes within the > same PDU" qualifies as "after" or whether only > "in a PDU sent at a later time" would. It's > probably irrelevant, since due to the introduction > of the C-bit, parameters can be accumulated and > processed one "batch" at a time, without any > specific order within the "batch" and they will > quite likely not be processed PDU by PDU. > Therefore, the text about them being sent in > "the same command" is likely irrelevant, too, > since many implementation simply won't check that. > I don't believe the intention of the recent discussion that led to the introduction of the C bit was, in fact, to allow "batching" or to throw out "ordering" of the sending of keys. However, the definition in Draft 12-95 sections 9.10.2 and 9.11.2 seems to now allow batching: (I agree with John Huffered that Martins' comments about "ordering" are not correct in any case.) Section 9.10.2 C (Complete) Bit: "When set to 1, indicates that the text (set of key=value pairs) in this Text Request is not complete (it will be continued on a subsequent Text Request); otherwise, it indicates that this Text Request ends a set of key=value pairs." (Section 9.11.2 is the same, but with Response substituted for Request.) The problem I see with this definition of the C bit is that the sending side can force the receiving NOT to process a PDU containing key=value pairs, even if all those key=value pairs are complete within the PDU. Therefore, the receiver is forced to save this PDU (and any number of following PDUs) until the sender finally sends C = 0. In the worst case, the sender could send one key=value pair per PDU with the C bit set to 0 and the receiver could not reply to any of these until it got one with C bit set to 1. As the e-mail from Martins indicates, some people are already taking this to mean that parameter negotiations will "normally" be batched. Up until the introduction of the C bit, PDUs and keys in them were always processed as received, and most code already does this, since it is the most logical and efficient way to do it. We should still encourage this as the "normal" way of negotiating. I believe the problem we were trying to solve by introducing the C bit was the one where a key was split over a PDU boundary -- we were not trying to redesign the negotiation mechanism, which was discussed on the mailing list long ago and has been working in a lot of running code for the past two plugfests. Could we therefore please change the definition of the C bit in section 9.10.2 to read: "When set to 1, indicates that the text in this Text Request contains a single key=value pair, and that pair is incomplete within this PDU." (Section 9.11.2 should have the same change, but with Response instead of Request) I believe this corresponds more closely with the description in section 4.2 Text Mode Negotiation, where the C bit (flag) is clearly tied to the idea of split keys only: "Key=value" pairs may span PDU boundaries. An initiator or target having sent partial key=value text within a PDU indicates that more text follows by setting the C flag bit in the Text Request or Text Response to 1." Perhaps an additional sentence could also be added to this: "The following PDUs should only contain text that completes the partial key=value text until after a PDU with C set to 1 has been sent, at which time new key=value pairs can be sent in the next PDU." I'm not happy about seeing such a major change (C flag bit) introduced so late in the process to solve an "almost" non-existant problem (split keys). It is "almost" non-existand because of the following considerations (some of which were already mentioned on the list and are just summarized here): During the login process, the PDU size is 8192 bytes. Therefore, except for the long keys during negotiation that follows a chosen AuthMethod, there is never a need to split keys across pdu boundaries during login -- even if you negotiate every possible login key (except those special keys that occur in security protocols) to its maximum length, you do not reach the total of 8192 bytes. It is not even close! Therefore, there is no need for any implication that the C bit should appear during this process. When those long security keys are needed, the negotiation process is in a 1 key over, 1 key back exchange mode, so there is no "batching" possible and the split key should in fact be the only key in the pdu. Finally, during text exchanges, there only 6 keys that can be legally sent (plus the X-extension key): SendTargets, TargetName, TargetAlias, TargetAddress, InitiatorAlias, and MaxRecvPDULength. None of these can legally have a value greater than 255 bytes, which is well less than the minimum PDU size (512 bytes). So there is no need to split keys over boundaries during text negotiation, except perhaps for the X-extension keys. My proposed definition of the C bit as applying only to split keys therefore only applies to X-extension keys during text negotiation. Since we have had no experience with X- keys, and cannot forsee their use, anything we introduce only for them should be the minimum possible. In summary, I would like to see as little disruption as possible to the key negotiation scheme which has been stable for a long time, especially since anything we introduce will be needed only in very limited circumstances. I believe my modification to the definition of the C flag accomplishes that, without introducing any new, false perceptions about "batching" and "ordering". Thank you for your consideration. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Sun Jun 2 16:30:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18960 for ; Sun, 2 Jun 2002 16:30:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g52JnYl08573 for ips-outgoing; Sun, 2 Jun 2002 15:49:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (io.iol.unh.edu [132.177.123.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g52JCGw06749 for ; Sun, 2 Jun 2002 15:12:16 -0400 (EDT) Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.3/8.12.3) with ESMTP id g52JC84F016215 for ; Sun, 2 Jun 2002 15:12:08 -0400 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.3/8.12.3/Submit) with ESMTP id g52JC8TY016212 for ; Sun, 2 Jun 2002 15:12:08 -0400 Date: Sun, 2 Jun 2002 15:12:08 -0400 (EDT) From: "Robert D. Russell" To: ips@ece.cmu.edu Subject: Re: iSCSI: keys/parameter dependence Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Pat: Comments in text below. > The part that might cause interoperability problems is different > interpretations of which parameters action or acceptance is dependent on > others. I agree -- see below. > For instance, does the sentence mean that InitialR2T should be sent > before FirstBurstSize and that FirstBurstSize doesn't need a response when > the response to InitialR2T was Yes? See my responses to Mike Donahoe and Martins Krikis. In particular, an offered key ALWAYs requires a response (unless this happens during login, in which case the responder can also just close the connection). The response can be Reject or NotUnderstood or Irrelevant in certain defined circumstances, but there must always be a response. > If the sentence is left in, then it should be clarified by adding something > such as: > "The definition of a key specifies whether the key is dependent on any other > keys." I believe the sentence should be left in and its intent remain unchanged. However, clarification would certainly be desirable, and would probably remove a lot of the current uncertainty. > and if any of our current keys are dependent, add to those keys > "This key is dependent on ." > If none are currently dependent, it would be reasonable to add to 11 > "Currently, > no Login/Text Operational keys are dependent." There are dependencies, so such a statement cannot be added to section 11. The existence of a dependency between FirstBurstSize and MaxBurstSize is already clear from the statement in section 11.15: "FirstBurstSize MUST NOT exceed MaxBurstSize." My earlier e-mail to Mike Donahoe details this dependency. The existence of a dependency between OFMarker and OFMarkInt, and between IFMarker and IFMarkInt, is implied by the statements in section A.3.2: "When the interval is unacceptable the responder answers with "Reject". Reject is resetting the marker function in the spcified direction (Output or Input) to No." This last sentence should probably be reworded to say: "A response value of "Reject" to an OFMarkInt (IFMarkInt) key resets the corresponding OFMarker (IFMarker) key value to "No"." Besides these two dependencies just mentioned, I am aware of two other dependencies, and it would certainly would not hurt to have all these made explicit in the appropriate sections of the standard. If anyone else has other dependencies to add, we should all know about these now! :) 1. The table in section 11.12 describes the action taken on the four combinations of InitialR2T = Yes/No and ImmediateData = Yes/No. The combination InitialR2T=Yes and ImmediateData=No means "Unsolicited data disallowed". Therefore, FirstBurstSize becomes "Irrelevant" for this combination. This means that if FirstBurstSize is offered after an offer of ImmediateData=No which is accepted, and either an explicit offer of InitialR2T=Yes which is accepted or no explicit offer of InitialR2T (in which case the applicable default value is Yes), then a reply of FirstBurstSize=Irrelevant MAY be returned (alternatively, a valid value can also be given in the reply). 2. Since the default value of OFMarker (IFMarker) is No, an offer of OFMarkInt (IFMarkInt) without a previous explicit offer of OFMarker=Yes (IFMarker=Yes) MAY generate the reply OFMarkInt=Irrelevant (IFMarkInt=Irrelevant) -- it can, of course, also reply with a valid value or with "Reject", as specified in section A.3.2. A similar reply of OFMarkInt=Irrelevant (IFMarkInt=Irrelevant) MAY also be generated if the previous explicit offer of OFMarker=Yes (IFMarker=YES) was refused by a reply of OFMarker=No (IFMarker=NO). Best, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Sun Jun 2 16:30:12 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18989 for ; Sun, 2 Jun 2002 16:30:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g52JnNU08546 for ips-outgoing; Sun, 2 Jun 2002 15:49:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (io.iol.unh.edu [132.177.123.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g52J7ew06528 for ; Sun, 2 Jun 2002 15:07:40 -0400 (EDT) Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.3/8.12.3) with ESMTP id g52J7W4F016153 for ; Sun, 2 Jun 2002 15:07:32 -0400 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.3/8.12.3/Submit) with ESMTP id g52J7Wto016150 for ; Sun, 2 Jun 2002 15:07:32 -0400 Date: Sun, 2 Jun 2002 15:07:32 -0400 (EDT) From: "Robert D. Russell" To: ips@ece.cmu.edu Subject: Re: iSCSI: keys/parameter dependence Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Mike: Comments in text below: > >From 12-95 4.3.3 pg 80 (and also in 4.4 pg 83): > > Whenever parameter action or acceptance are dependent on other parameters, > the dependent parameters MUST be sent after the parameters on > which they depend. If they are sent within the same command, a > response for a parameter might imply responses for others. > > > Is an example of this FirstBurstSize being dependent on MaxBurstSize (or > vis-versa)? yes > So MaxBurstSize MUST come before FirstBurstSize? Not necessarily, since it says "Whenever parameter action or acceptance are dependent on other parameters, ...". If you want to offer a value of FirstBurstSize (say 524288) that is greater than the default value 262144 of MaxBurstSize then a value of MaxBurstSize at least as large as 524288 must be offered first -- otherwise the offered value of 262144 for FirstBurstSize could not be accepted, since that would violate the requirement in section 11.14 that "FirstBurstSize MUST NOT exceed MaxBurstSize." (and the (default) value for MaxBurstSize would be exceeded if the offered value were accepted at that point in the negotiations.) On the other hand, if you want to offer a value of MaxBurstSize (say 32768) that is smaller than the default value 65536 of FirstBurstSize then a value of FirstBurstSize no larger than 32768 must be offered first -- otherwise the offered value of 32768 for MaxBurstSize cannot be accepted, since that would violate the same requirement at that point in the negotiations. > I don't see any definition of operational parameters. Just in section 11 > keys that are not "declarative" are "operational keys". In draft 12-95, Chapter 11 is entitled "Login/Text Operational Keys", and the fourth paragraph in this chapter says: "Keys marked as "declarative" may appear also in the SecurityNegotiation stage while all other keys described in this chaper are operational keys." Doesn't that pretty clearly define operational keys? > Also, the spec goes back and forth between the terms "keys"/"parameters" and > "operational keys"/"operational parameters"/"operational negotiation > parameter keys". Is this something that should be cleaned up? It would certainly help to use consistent terminology throughout. Best, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Sun Jun 2 16:30:30 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19005 for ; Sun, 2 Jun 2002 16:30:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g52JnUA08558 for ips-outgoing; Sun, 2 Jun 2002 15:49:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (io.iol.unh.edu [132.177.123.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g52JAJw06636 for ; Sun, 2 Jun 2002 15:10:19 -0400 (EDT) Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.3/8.12.3) with ESMTP id g52JAB4F016186 for ; Sun, 2 Jun 2002 15:10:11 -0400 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.3/8.12.3/Submit) with ESMTP id g52JABYA016183 for ; Sun, 2 Jun 2002 15:10:11 -0400 Date: Sun, 2 Jun 2002 15:10:11 -0400 (EDT) From: "Robert D. Russell" To: ips@ece.cmu.edu Subject: Re: iSCSI: keys/parameter dependence Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Martins: Comments in text below: > > From 12-95 4.3.3 pg 80 (and also in 4.4 pg 83): > > > > Whenever parameter action or acceptance are > > dependent on other parameters, > > the dependent parameters MUST be sent after the > > parameters on > > which they depend. If they are sent within the same > > command, a > > response for a parameter might imply responses for > > others. > > I've been ignoring this paraghaph having been > convinced that there are no dependencies among > the operational parameters (those allowed to be > used in the operational stage of login), and that > any dependencies for security parameters would > be naturally observed by security protocols (i.e., > first send me this, I'll send you that, now > send this, etc.). However, there ARE dependencies between operational parameters that cannot be ignored, such as the one Mike mentioned -- FirstBurstSize and MaxBurstSize are dependent because of the requirement in section 11.15: "FirstBurstSize MUST NOT exceed MaxBurstSize." See my e-mail response to Mike for details on that dependence. I am also sending a following e-mail that details 3 other dependencies. > However, I think you raised some good questions. > I think this paragraph should be removed. > Here are the reasons: > > "(sent) after" isn't defined. It is unclear > whether "in higher numbered bytes within the > same PDU" qualifies as "after" or whether only > "in a PDU sent at a later time" would. I don't see this, and I agree with John Hufferd's response to this that "previous" is obviously "previous", whether in the previous PDUs (because the current PDU was delivered after them) or in the same PDU (because key=value pairs are naturally scanned from the beginning of a PDU's data segment, and if nothing else, pairs had to be put into the data segment in that order, and delivered on the wire in that order). This is a non-issue. > It's > probably irrelevant, since due to the introduction > of the C-bit, parameters can be accumulated and > processed one "batch" at a time, without any > specific order within the "batch" and they will > quite likely not be processed PDU by PDU. I don't see this either. Nowhere does the newly added text describing the C-bit say anything about doing away with the specific order of the key=value pairs within the "batch". Why should it -- even if you don't process PDU by PDU you still have to process batch by batch, a batch still has to be scanned to find key=value pairs, and the natural way to scan is from the beginning of the batch, since the next key starts after the delimiter of the previous key in the batch. This is also a non-issue. > Therefore, the text about them being sent in > "the same command" is likely irrelevant, too, > since many implementation simply won't check that. "command" should simply be replaced by "batch" or, to be more consistent with the rest of the wording in the standard, with "set of key=value pairs". However, see my earlier e-mail to Julian stating my concerns over the use of the C-bit for "batching". > But what's really dangerous here is that an > implementation that perceives some parameters > as dependent may take the "might imply" text > as an endorsement for sending back less key=value > pairs than was received, which could make the > other side never commit due to missing responses. > We certainly don't want to allow for such a > non-interoperability in the specification. Certainly not, and nowhere can I find anything in the standard that implies responses can ever be omitted. On the contrary, there are several places where it says you MUST always respond. For example, in section 4.2 on Text Mode Negotiation it says: "A key not understood by the responder may be ignored by the responder without affecting the basic function. However, the Text Response for a key not understood MUST be Key=NotUnderstood." And in section 4.2.2 for simple-value negotiations it says "For simple-value negotiations, the responding party MUST respond with the same key." The only time responses are optional are the 2 special-case Boolean negotiations detailed at the end of section 4.2. At no other time can responses be omitted. This is also a non-issue. > So, could we please get rid of this whole > paragraph? I do not see how we can get rid of this paragraph. However, perhaps it could be worded better to make it clearer without changing its intent. Best, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Sun Jun 2 23:24:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23512 for ; Sun, 2 Jun 2002 23:24:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g532kQr27661 for ips-outgoing; Sun, 2 Jun 2002 22:46:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from yamuna.siri.co.in ([164.164.82.134]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g532kIw27639 for ; Sun, 2 Jun 2002 22:46:20 -0400 (EDT) Subject: remove To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: mahesh.revuri@siritech.com Date: Mon, 3 Jun 2002 08:25:45 +0530 X-MIMETrack: Serialize by Router on Yamuna/Siri(Release 5.0.5 |September 22, 2000) at 06/03/2002 08:25:56 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk remove From owner-ips@ece.cmu.edu Mon Jun 3 04:10:42 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05865 for ; Mon, 3 Jun 2002 04:10:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g537JYG10249 for ips-outgoing; Mon, 3 Jun 2002 03:19:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g537JWw10244 for ; Mon, 3 Jun 2002 03:19:32 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g537JO9D090644; Mon, 3 Jun 2002 09:19:25 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g537JOD53070; Mon, 3 Jun 2002 09:19:24 +0200 To: "Robert D. Russell" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: keys/parameter dependence X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Mon, 3 Jun 2002 10:19:22 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 03/06/2002 10:19:24, Serialize complete at 03/06/2002 10:19:24 Content-Type: multipart/alternative; boundary="=_alternative 00276C3AC2256BCD_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00276C3AC2256BCD_= Content-Type: text/plain; charset="us-ascii" Robert, First I would like to correct an error that appeared (not intentionally I assume) in your note - a PDU C bit set to 0 terminates a sequence even if it stands alone. As for the batching of keys neither the new text nor the old said anything for or against it. The new text says only that the receiver should not process text untill it does not receive the complete sequence (whether it is batched or not that is an implementation issue). The only point that we added and we made it for simplicity is stating that the while a sequence is incomplete the answers should be empty. We could as well reverse to the previous - "do not originate new keys" without breaking logic but we found this new rule simpler. As for dependencies I agree that the argument about not having defined before is lightweight but then the statement about dependencies was too general to be of any use and we replaced it with a key specific statement. Overall the C bit change is lightweight and for reasons you have mentioned is not bound to break code. I simplifies parsing as those boundary cases that where the old scheme was hard. I would be grateful if you could point out those dependencies that are mandatory to check (some dependencies are benign and not worth checking - e..g., R2T is mandated and FirstBurstSize is also negotiated) so that we can specifically state them (as we do for security). Regards, Julo "Robert D. Russell" 06/02/2002 12:23 PM Please respond to "Robert D. Russell" To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: iSCSI: keys/parameter dependence Julian: The following paragraph from an e-mail from Martins Krikis made me realize that the definition of the new C bit is not correct, because it goes much further than is necessary to solve the "split key" problem, and as a result, it opens up a whole new set of problems, complicates what was previously a simple situation, and breaks a lot of already running and tested code. > "(sent) after" isn't defined. It is unclear > whether "in higher numbered bytes within the > same PDU" qualifies as "after" or whether only > "in a PDU sent at a later time" would. It's > probably irrelevant, since due to the introduction > of the C-bit, parameters can be accumulated and > processed one "batch" at a time, without any > specific order within the "batch" and they will > quite likely not be processed PDU by PDU. > Therefore, the text about them being sent in > "the same command" is likely irrelevant, too, > since many implementation simply won't check that. > I don't believe the intention of the recent discussion that led to the introduction of the C bit was, in fact, to allow "batching" or to throw out "ordering" of the sending of keys. However, the definition in Draft 12-95 sections 9.10.2 and 9.11.2 seems to now allow batching: (I agree with John Huffered that Martins' comments about "ordering" are not correct in any case.) Section 9.10.2 C (Complete) Bit: "When set to 1, indicates that the text (set of key=value pairs) in this Text Request is not complete (it will be continued on a subsequent Text Request); otherwise, it indicates that this Text Request ends a set of key=value pairs." (Section 9.11.2 is the same, but with Response substituted for Request.) The problem I see with this definition of the C bit is that the sending side can force the receiving NOT to process a PDU containing key=value pairs, even if all those key=value pairs are complete within the PDU. Therefore, the receiver is forced to save this PDU (and any number of following PDUs) until the sender finally sends C = 0. In the worst case, the sender could send one key=value pair per PDU with the C bit set to 0 and the receiver could not reply to any of these until it got one with C bit set to 1. As the e-mail from Martins indicates, some people are already taking this to mean that parameter negotiations will "normally" be batched. Up until the introduction of the C bit, PDUs and keys in them were always processed as received, and most code already does this, since it is the most logical and efficient way to do it. We should still encourage this as the "normal" way of negotiating. I believe the problem we were trying to solve by introducing the C bit was the one where a key was split over a PDU boundary -- we were not trying to redesign the negotiation mechanism, which was discussed on the mailing list long ago and has been working in a lot of running code for the past two plugfests. Could we therefore please change the definition of the C bit in section 9.10.2 to read: "When set to 1, indicates that the text in this Text Request contains a single key=value pair, and that pair is incomplete within this PDU." (Section 9.11.2 should have the same change, but with Response instead of Request) I believe this corresponds more closely with the description in section 4.2 Text Mode Negotiation, where the C bit (flag) is clearly tied to the idea of split keys only: "Key=value" pairs may span PDU boundaries. An initiator or target having sent partial key=value text within a PDU indicates that more text follows by setting the C flag bit in the Text Request or Text Response to 1." Perhaps an additional sentence could also be added to this: "The following PDUs should only contain text that completes the partial key=value text until after a PDU with C set to 1 has been sent, at which time new key=value pairs can be sent in the next PDU." I'm not happy about seeing such a major change (C flag bit) introduced so late in the process to solve an "almost" non-existant problem (split keys). It is "almost" non-existand because of the following considerations (some of which were already mentioned on the list and are just summarized here): During the login process, the PDU size is 8192 bytes. Therefore, except for the long keys during negotiation that follows a chosen AuthMethod, there is never a need to split keys across pdu boundaries during login -- even if you negotiate every possible login key (except those special keys that occur in security protocols) to its maximum length, you do not reach the total of 8192 bytes. It is not even close! Therefore, there is no need for any implication that the C bit should appear during this process. When those long security keys are needed, the negotiation process is in a 1 key over, 1 key back exchange mode, so there is no "batching" possible and the split key should in fact be the only key in the pdu. Finally, during text exchanges, there only 6 keys that can be legally sent (plus the X-extension key): SendTargets, TargetName, TargetAlias, TargetAddress, InitiatorAlias, and MaxRecvPDULength. None of these can legally have a value greater than 255 bytes, which is well less than the minimum PDU size (512 bytes). So there is no need to split keys over boundaries during text negotiation, except perhaps for the X-extension keys. My proposed definition of the C bit as applying only to split keys therefore only applies to X-extension keys during text negotiation. Since we have had no experience with X- keys, and cannot forsee their use, anything we introduce only for them should be the minimum possible. In summary, I would like to see as little disruption as possible to the key negotiation scheme which has been stable for a long time, especially since anything we introduce will be needed only in very limited circumstances. I believe my modification to the definition of the C flag accomplishes that, without introducing any new, false perceptions about "batching" and "ordering". Thank you for your consideration. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 --=_alternative 00276C3AC2256BCD_= Content-Type: text/html; charset="us-ascii"
Robert,

First I would like to correct an error that appeared (not intentionally I assume) in your note - a PDU  C bit set to 0 terminates a sequence even if it stands alone.

As for the batching of keys neither the new text nor the old said anything for or against it.

The new text says only that the receiver should not process text untill it does not receive the complete sequence (whether it is batched or not that is an implementation issue).

The only point that we added and we made it for simplicity is stating that the while a sequence is incomplete the answers should be empty.

We could as well reverse to the previous - "do not originate new keys" without breaking logic but we found this new rule simpler.

As for dependencies I agree that the argument about not having defined before is lightweight  but then the statement about dependencies was too general to be of any use and we replaced it with a key specific statement.

Overall the C bit change is lightweight and for reasons you have mentioned is not bound to break code.

I simplifies parsing as those boundary cases that where the old scheme was hard.

I would be grateful if you could point out those dependencies that are mandatory to check (some dependencies are benign and not worth checking - e..g., R2T is mandated and FirstBurstSize is also negotiated) so that we can specifically state them (as we do for security).

Regards,
Julo


"Robert D. Russell" <rdr@io.iol.unh.edu>

06/02/2002 12:23 PM
Please respond to "Robert D. Russell"

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        
        Subject:        RE: iSCSI: keys/parameter dependence

       


Julian:

The following paragraph from an e-mail from Martins Krikis
made me realize that the definition of the new C bit
is not correct, because it goes much further
than is necessary to solve the "split key" problem,
and as a result, it opens up a whole new set of problems,
complicates what was previously a simple situation, and
breaks a lot of already running and tested code.


> "(sent) after" isn't defined. It is unclear
> whether "in higher numbered bytes within the
> same PDU" qualifies as "after" or whether only
> "in a PDU sent at a later time" would. It's
> probably irrelevant, since due to the introduction
> of the C-bit, parameters can be accumulated and
> processed one "batch" at a time, without any
> specific order within the "batch" and they will
> quite likely not be processed PDU by PDU.
> Therefore, the text about them being sent in
> "the same command" is likely irrelevant, too,
> since many implementation simply won't check that.
>

I don't believe the intention of the recent discussion
that led to the introduction of the C bit was, in fact,
to allow "batching" or to throw out "ordering" of the
sending of keys.  However, the definition in Draft 12-95
sections 9.10.2  and 9.11.2 seems to now allow batching:
(I agree with John Huffered that Martins' comments about
"ordering" are not correct in any case.)

Section 9.10.2 C (Complete) Bit:
"When set to 1, indicates that the text (set of key=value pairs) in
this Text Request is not complete (it will be continued on a
subsequent Text Request); otherwise, it indicates that this
Text Request ends a set of key=value pairs."

(Section 9.11.2 is the same, but with Response substituted for Request.)

The problem I see with this definition of the C bit is that
the sending side can force the receiving NOT to process
a PDU containing key=value pairs, even if all those key=value
pairs are complete within the PDU.  Therefore, the receiver
is forced to save this PDU (and any number of following PDUs)
until the sender finally sends C = 0.  In the worst case, the
sender could send one key=value pair per PDU with the C bit set
to 0 and the receiver could not reply to any of these until it
got one with C bit set to 1.
As the e-mail from Martins indicates, some people are already
taking this to mean that parameter negotiations will "normally"
be batched.  Up until the introduction of the C bit, PDUs and keys
in them were always processed as received, and most code already does
this, since it is the most logical and efficient way to do it.
We should still encourage this as the "normal" way of negotiating.

I believe the problem we were trying to solve by introducing
the C bit was the one where a key was split over a PDU boundary
-- we were not trying to redesign the negotiation mechanism,
which was discussed on the mailing list long ago and has been
working in a lot of running code for the past two plugfests.

Could we therefore please change the definition of the C bit in
section 9.10.2 to read:
"When set to 1, indicates that the text in this Text Request
contains a single key=value pair, and that pair is incomplete
within this PDU."

(Section 9.11.2 should have the same change, but with Response
instead of Request)

I believe this corresponds more closely with the description
in section 4.2 Text Mode Negotiation, where the C bit (flag) is
clearly tied to the idea of split keys only:
"Key=value" pairs may span PDU boundaries.  An initiator or target
having sent partial key=value text within a PDU indicates that more
text follows by setting the C flag bit in the Text Request or
Text Response to 1."

Perhaps an additional sentence could also be added to this:
"The following PDUs should only contain text that completes
the partial key=value text until after a PDU with C set to 1
has been sent, at which time new key=value pairs can be sent
in the next PDU."

I'm not happy about seeing such a major change (C flag bit)
introduced so late in the process to solve an "almost" non-existant
problem (split keys).  It is "almost" non-existand because of
the following considerations (some of which were already
mentioned on the list and are just summarized here):
During the login process, the PDU size is 8192 bytes.
Therefore, except for the long keys during negotiation
that follows a chosen AuthMethod, there is never a need to split
keys across pdu boundaries during login --
even if you negotiate every possible login key
(except those special keys that occur in security protocols)
to its maximum length, you do not reach the total of 8192 bytes.
It is not even close!  Therefore, there is no need for any
implication that the C bit should appear during this process.
When those long security keys are needed, the negotiation process is
in a 1 key over, 1 key back exchange mode, so there is no "batching"
possible and the split key should in fact be the only key in the pdu.
Finally, during text exchanges, there only 6 keys that can be
legally sent (plus the X-extension key): SendTargets, TargetName,
TargetAlias, TargetAddress, InitiatorAlias, and MaxRecvPDULength.
None of these can legally have a value greater than 255 bytes,
which is well less than the minimum PDU size (512 bytes).
So there is no need to split keys over boundaries during text
negotiation, except perhaps for the X-extension keys.
My proposed definition of the C bit as applying only to split keys
therefore only applies to X-extension keys during text negotiation.
Since we have had no experience with X- keys, and cannot forsee their
use, anything we introduce only for them should be the minimum possible.

In summary, I would like to see as little disruption as possible
to the key negotiation scheme which has been stable for a long time,
especially since anything we introduce will be needed only in very
limited circumstances.  I believe my modification to the definition of
the C flag accomplishes that, without introducing any new, false
perceptions about "batching" and "ordering".

Thank you for your consideration.

Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774

--=_alternative 00276C3AC2256BCD_=-- From owner-ips@ece.cmu.edu Mon Jun 3 09:54:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13540 for ; Mon, 3 Jun 2002 09:54:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g53D8b206557 for ips-outgoing; Mon, 3 Jun 2002 09:08:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g53BcNw01825 for ; Mon, 3 Jun 2002 07:38:29 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08359; Mon, 3 Jun 2002 07:37:54 -0400 (EDT) Message-Id: <200206031137.HAA08359@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-ifcp-11.txt,.pdf Date: Mon, 03 Jun 2002 07:37:53 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : iFCP - A Protocol for Internet Fibre Channel Storage Networking Author(s) : C. Monia et al. Filename : draft-ietf-ips-ifcp-11.txt,.pdf Pages : 103 Date : 31-May-02 This document specifies an architecture and gateway-to-gateway protocol for the implementation of fibre channel fabric functionality over an IP network. This functionality is provided through TCP protocols for fibre channel frame transport and the distributed fabric services specified by the fibre channel standards. The architecture enables internetworking of fibre channel devices through gateway-accessed regions having the fault isolation properties of autonomous systems and the scalability of the IP network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-ifcp-11.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-ifcp-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-ifcp-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020531131622.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-ifcp-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-ifcp-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020531131622.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Mon Jun 3 11:45:06 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19513 for ; Mon, 3 Jun 2002 11:45:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g53Ev2I13749 for ips-outgoing; Mon, 3 Jun 2002 10:57:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g53Ev0w13744 for ; Mon, 3 Jun 2002 10:57:00 -0400 (EDT) Received: from hq-ex-c3.brocade.com (hq-ex-c3 [192.168.126.211]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id HAA19141; Mon, 3 Jun 2002 07:56:51 -0700 (PDT) Received: by hq-ex-c3.brocade.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Jun 2002 07:57:18 -0700 Message-ID: <2F37CED150E21640A9C6E75B8BE6AF830A4C8A@hq-ex-4> From: Robert Snively To: "'Robert D. Russell'" , ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence Date: Mon, 3 Jun 2002 07:56:43 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk Picking up on this in the middle of a thread, I find the following reply from Bob Russell interesting: > > It's > > probably irrelevant, since due to the introduction > > of the C-bit, parameters can be accumulated and > > processed one "batch" at a time, without any > > specific order within the "batch" and they will > > quite likely not be processed PDU by PDU. > > I don't see this either. Nowhere does the newly added text > describing the C-bit say anything about doing away with the > specific order of the key=value pairs within the "batch". > Why should it -- even if you don't process PDU by PDU you still > have to process batch by batch, a batch still has to be scanned > to find key=value pairs, and the natural way to scan is from the > beginning of the batch, since the next key starts after the > delimiter of the previous key in the batch. > This is also a non-issue. Skimming over rev 12, I have not found the word "order" applied in the context of processing a string of key=value pairs. While they must clearly be parsed linearly, it is perfectly reasonable to process the parsed values in any order, or even in a vendor-specific order than makes sense to a particular target. That is why key=value pairs are used in the first place, so that one does not have to worry about ordering. In this context, batching would be normal behavior and out of order processing within a batch would also be normal behavior. If you want to order processing, you would have to send them one at a time without the C bit set. From owner-ips@ece.cmu.edu Mon Jun 3 13:17:27 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24494 for ; Mon, 3 Jun 2002 13:17:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g53GlKL22084 for ips-outgoing; Mon, 3 Jun 2002 12:47:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g53GlIw22079 for ; Mon, 3 Jun 2002 12:47:18 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 0DCA0114E; Mon, 3 Jun 2002 10:47:11 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 739501EE; Mon, 3 Jun 2002 10:47:10 -0600 (MDT) Received: from 130.29.152.143 by axcsbh1.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 03 Jun 2002 10:47:09 -0600 Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Jun 2002 10:47:09 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C353C25@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: minor conflict introduced by C bit Date: Mon, 3 Jun 2002 10:47:01 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-ae6a76db-7708-11d6-bae3-009027404a4a" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-ae6a76db-7708-11d6-bae3-009027404a4a Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20B1E.48ABFAB0" ------_=_NextPart_001_01C20B1E.48ABFAB0 Content-Type: text/plain; charset="iso-8859-1" Julian, I have noticed a minor conflict of the C bit with existing text. 11.4 and 11.9 require the target to return TargetName and TargetPortal group in the first Login Response PDU but the new text on the C bit in 4.2 requires the target to return an empty response if the C bit is set. Therefore, if the C bit is set on the first Login Request PDU, the target will have conflicting requirements on it. One could resolve this by: 1) Specify that the C bit MUST NOT be set in the first Login Request PDU; or 2) Allow declarations to be sent in PDUs when the other side has the C bit set; or 3) Change the requirement in 11.4 and 11.9 to be the response to the first Login Request PDU with the C bit set to zero. Regards, Pat ------_=_NextPart_001_01C20B1E.48ABFAB0 Content-Type: text/html; charset="iso-8859-1"
Julian,
 
I have noticed a minor conflict of the C bit with existing text.
 
11.4 and 11.9 require the target to return TargetName and TargetPortal group in the first Login Response PDU but the new text on the C bit in 4.2 requires the target to return an empty response if the C bit is set. Therefore, if the C bit is set on the first Login Request PDU, the target will have conflicting requirements on it.
 
One could resolve this by:
1) Specify that the C bit MUST NOT be set in the first Login Request PDU; or
2) Allow declarations to be sent in PDUs when the other side has the C bit set; or
3) Change the requirement in 11.4 and 11.9 to be the response to the first Login Request PDU with the C bit set to zero.
 
Regards,
Pat
------_=_NextPart_001_01C20B1E.48ABFAB0-- ------=_NextPartTM-000-ae6a76db-7708-11d6-bae3-009027404a4a-- From owner-ips@ece.cmu.edu Mon Jun 3 13:20:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24636 for ; Mon, 3 Jun 2002 13:20:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g53GvB022768 for ips-outgoing; Mon, 3 Jun 2002 12:57:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from emailO.iomega.com (email.iomega.com [147.178.1.2]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g53Gv8w22759 for ; Mon, 3 Jun 2002 12:57:08 -0400 (EDT) Received: from ROYNTEX01.iomega.com by emailO.iomega.com via smtpd (for ECE.CMU.EDU [128.2.136.200]) with SMTP; 3 Jun 2002 16:57:08 UT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C20B1F.B1A23689" Subject: remove Date: Mon, 3 Jun 2002 10:57:07 -0600 Message-ID: X-MS-Has-Attach: yes Thread-Topic: remove Thread-Index: AcILH7GXUl2j10ikQMazU1UuB6VQyw== From: "Mark Johnson" To: Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C20B1F.B1A23689 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C20B1F.B1A23689" ------_=_NextPart_002_01C20B1F.B1A23689 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable remove =20 =20 ------_=_NextPart_002_01C20B1F.B1A23689 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
remove
 
 
=00 ------_=_NextPart_002_01C20B1F.B1A23689-- ------_=_NextPart_001_01C20B1F.B1A23689 Content-Type: image/jpeg; name="Notebook.jpg" Content-Transfer-Encoding: base64 Content-ID: <549125616@03062002-089E> Content-Description: Notebook.jpg Content-Location: Notebook.jpg Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgEASABIAAD/7QSyUGhvdG9zaG9wIDMuMAA4QklNA+kAAAAAAHgAAwAAAEgA SAAAAAADBgJS//f/9wMPAlsDRwUoA/wAAgAAAEgASAAAAAAC2AIoAAEAAABkAAAAAQADAwMAAAAB Jw8AAQABAAAAAAAAAAAAAAAAYAgAGQGQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4 QklNA+0AAAAAABAASAAAAAEAAQBIAAAAAQABOEJJTQPzAAAAAAAIAAAAAAAAAAA4QklNBAoAAAAA AAEAADhCSU0nEAAAAAAACgABAAAAAAAAAAI4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEA L2ZmAAEAoZmaAAYAAAAAAAEAMgAAAAEAWgAAAAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklN A/gAAAAAAHAAAP////////////////////////////8D6AAAAAD///////////////////////// ////A+gAAAAA/////////////////////////////wPoAAAAAP////////////////////////// //8D6AAAOEJJTQQAAAAAAAACAAA4QklNBAIAAAAAAAIAADhCSU0ECAAAAAAAEAAAAAEAAAJAAAAC QAAAAAA4QklNBAkAAAAAAqIAAAABAAAAgAAAAAIAAAGAAAADAAAAAoYAGAAB/9j/4AAQSkZJRgAB AgEASABIAAD//gAnRmlsZSB3cml0dGVuIGJ5IEFkb2JlIFBob3Rvc2hvcKggNC4wAP/uAA5BZG9i ZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwR DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIAAIAgAMBIgACEQEDEQH/3QAEAAj/xAE/ AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkK CxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWS U/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpam tsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGx QiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSV xNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APROif0Kv6X81T9L j+ar/m/5K0F8rJJIfqlJfKySKn6pSXyskkp+qUl8rJJKfqlJfKySSn6pSXyskkp+qUl8rJJKfqlJ fKySSn//2ThCSU0EBgAAAAAABwABAAAAAQEA//4AJ0ZpbGUgd3JpdHRlbiBieSBBZG9iZSBQaG90 b3Nob3CoIDQuMAD/7gAOQWRvYmUAZIAAAAAB/9sAhAAMCAgNCQ0VDAwVGhQQFBogGxoaGyAiFxcX FxciEQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAQ0NDREOERsRERsUDg4OFBQO Dg4OFBEMDAwMDBERDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAAYBaAD ASIAAhEBAxEB/90ABABa/8QBPwAAAQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEB AQAAAAAAAAABAAIDBAUGBwgJCgsQAAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYU kaGxQiMkFVLBYjM0coLRQwclklPw4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5Sk hbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQAC EQMhMRIEQVFhcSITBTKBkRShsUIjwVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RF VTZ0ZeLys4TD03Xj80aUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMB AAIRAxEAPwCv0T+n4/8AxrP+qavW15J0U/r+P/xrP+qavWg8eKElsWSHZfXWYe4A+ZUMjIFTJBE/ Fc1kXbg63mJP+amk0uesGqdc19Sup2ZrLmWGQxwLR4B35v8A0V0qKlJJJIqUkkkkpSSSSSlJJJJK UkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSS SSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJ KUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpS SSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJ JKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkp SSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJ JJKUkkkkpSSSSSn/0J9G6oKn04zKKXOdYA6x7d1kOP8Ag/3Hs/MXY/sOl/0hYfCT/wCQavnZJArQ /S1HTXVN21+weYa7/vqzcroeQ+Q3XcYOn/mbF89pIaJfpboXRK+k1uDQPUsILyONPotZ/JatRfKq SSX6qSXyqkip+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJ KfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp +qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6 qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqp JfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl 8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXy qkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKq SSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJ KfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp +qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6 qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn/2Q== ------_=_NextPart_001_01C20B1F.B1A23689-- From owner-ips@ece.cmu.edu Mon Jun 3 13:38:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25091 for ; Mon, 3 Jun 2002 13:38:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g53GTnn20768 for ips-outgoing; Mon, 3 Jun 2002 12:29:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g53GTlw20764 for ; Mon, 3 Jun 2002 12:29:47 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id BD97E1211; Mon, 3 Jun 2002 10:29:46 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 99BD94A2; Mon, 3 Jun 2002 10:29:46 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 03 Jun 2002 10:29:45 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Jun 2002 10:29:44 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C353C0D@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: rdr@io.iol.unh.edu, ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence Date: Mon, 3 Jun 2002 10:29:34 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Robert, The text: "When set to 1, indicates that the text (set of key=value pairs) in this Text Request is not complete (it will be continued on a subsequent Text Requests); otherwise, it indicates that this Text Request ends a set of key=value pairs." says anything that implies the keys are batch processed. The draft is explicit that one must reply with empty PDUs while the C bit is set, but it doesn't say anything about processing. One could be building a buffer of responses to those keys while receiving them. If one was only going to allow long security keys to be split, then one wouldn't need the C bit at all. One can tell that the complete key hasn't arrived yet. If we made the changes you suggest, we wouldn't need the C bit at all. The C bit was introduced because people wanted to build a buffer of keys to send without having to check whether they would all fit into one PDU. Concensus of those who responded was very much in favor of this direction. (The discussion period was short though intense. Perhaps more time should be allowed for people to see the discussion and respond before changing the draft.) Regards, Pat -----Original Message----- From: Robert D. Russell [mailto:rdr@io.iol.unh.edu] Sent: Sunday, June 02, 2002 2:28 AM To: ips@ece.cmu.edu Subject: Re: iSCSI: keys/parameter dependence Julian: The following paragraph from an e-mail from Martins Krikis made me realize that the definition of the new C bit is not correct, because it goes much further than is necessary to solve the "split key" problem, and as a result, it opens up a whole new set of problems, complicates what was previously a simple situation, and breaks a lot of already running and tested code. > "(sent) after" isn't defined. It is unclear > whether "in higher numbered bytes within the > same PDU" qualifies as "after" or whether only > "in a PDU sent at a later time" would. It's > probably irrelevant, since due to the introduction > of the C-bit, parameters can be accumulated and > processed one "batch" at a time, without any > specific order within the "batch" and they will > quite likely not be processed PDU by PDU. > Therefore, the text about them being sent in > "the same command" is likely irrelevant, too, > since many implementation simply won't check that. > I don't believe the intention of the recent discussion that led to the introduction of the C bit was, in fact, to allow "batching" or to throw out "ordering" of the sending of keys. However, the definition in Draft 12-95 sections 9.10.2 and 9.11.2 seems to now allow batching: (I agree with John Huffered that Martins' comments about "ordering" are not correct in any case.) Section 9.10.2 C (Complete) Bit: "When set to 1, indicates that the text (set of key=value pairs) in this Text Request is not complete (it will be continued on a subsequent Text Request); otherwise, it indicates that this Text Request ends a set of key=value pairs." (Section 9.11.2 is the same, but with Response substituted for Request.) The problem I see with this definition of the C bit is that the sending side can force the receiving NOT to process a PDU containing key=value pairs, even if all those key=value pairs are complete within the PDU. Therefore, the receiver is forced to save this PDU (and any number of following PDUs) until the sender finally sends C = 0. In the worst case, the sender could send one key=value pair per PDU with the C bit set to 0 and the receiver could not reply to any of these until it got one with C bit set to 1. As the e-mail from Martins indicates, some people are already taking this to mean that parameter negotiations will "normally" be batched. Up until the introduction of the C bit, PDUs and keys in them were always processed as received, and most code already does this, since it is the most logical and efficient way to do it. We should still encourage this as the "normal" way of negotiating. I believe the problem we were trying to solve by introducing the C bit was the one where a key was split over a PDU boundary -- we were not trying to redesign the negotiation mechanism, which was discussed on the mailing list long ago and has been working in a lot of running code for the past two plugfests. Could we therefore please change the definition of the C bit in section 9.10.2 to read: "When set to 1, indicates that the text in this Text Request contains a single key=value pair, and that pair is incomplete within this PDU." (Section 9.11.2 should have the same change, but with Response instead of Request) I believe this corresponds more closely with the description in section 4.2 Text Mode Negotiation, where the C bit (flag) is clearly tied to the idea of split keys only: "Key=value" pairs may span PDU boundaries. An initiator or target having sent partial key=value text within a PDU indicates that more text follows by setting the C flag bit in the Text Request or Text Response to 1." Perhaps an additional sentence could also be added to this: "The following PDUs should only contain text that completes the partial key=value text until after a PDU with C set to 1 has been sent, at which time new key=value pairs can be sent in the next PDU." I'm not happy about seeing such a major change (C flag bit) introduced so late in the process to solve an "almost" non-existant problem (split keys). It is "almost" non-existand because of the following considerations (some of which were already mentioned on the list and are just summarized here): During the login process, the PDU size is 8192 bytes. Therefore, except for the long keys during negotiation that follows a chosen AuthMethod, there is never a need to split keys across pdu boundaries during login -- even if you negotiate every possible login key (except those special keys that occur in security protocols) to its maximum length, you do not reach the total of 8192 bytes. It is not even close! Therefore, there is no need for any implication that the C bit should appear during this process. When those long security keys are needed, the negotiation process is in a 1 key over, 1 key back exchange mode, so there is no "batching" possible and the split key should in fact be the only key in the pdu. Finally, during text exchanges, there only 6 keys that can be legally sent (plus the X-extension key): SendTargets, TargetName, TargetAlias, TargetAddress, InitiatorAlias, and MaxRecvPDULength. None of these can legally have a value greater than 255 bytes, which is well less than the minimum PDU size (512 bytes). So there is no need to split keys over boundaries during text negotiation, except perhaps for the X-extension keys. My proposed definition of the C bit as applying only to split keys therefore only applies to X-extension keys during text negotiation. Since we have had no experience with X- keys, and cannot forsee their use, anything we introduce only for them should be the minimum possible. In summary, I would like to see as little disruption as possible to the key negotiation scheme which has been stable for a long time, especially since anything we introduce will be needed only in very limited circumstances. I believe my modification to the definition of the C flag accomplishes that, without introducing any new, false perceptions about "batching" and "ordering". Thank you for your consideration. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Mon Jun 3 14:16:51 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26122 for ; Mon, 3 Jun 2002 14:16:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g53HJ4Q24317 for ips-outgoing; Mon, 3 Jun 2002 13:19:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g53HJ2w24309 for ; Mon, 3 Jun 2002 13:19:02 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 8439A9C6C; Mon, 3 Jun 2002 11:19:01 -0600 (MDT) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 499DC1EE; Mon, 3 Jun 2002 11:19:01 -0600 (MDT) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 03 Jun 2002 11:19:00 -0600 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Jun 2002 11:19:00 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C353C51@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: "Robert D. Russell" , ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence Date: Mon, 3 Jun 2002 11:18:54 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk My comments are inserted with my initials. Pat -----Original Message----- From: Robert D. Russell [mailto:rdr@io.iol.unh.edu] Sent: Sunday, June 02, 2002 12:10 PM To: ips@ece.cmu.edu Subject: Re: iSCSI: keys/parameter dependence However, there ARE dependencies between operational parameters that cannot be ignored, such as the one Mike mentioned -- FirstBurstSize and MaxBurstSize are dependent because of the requirement in section 11.15: "FirstBurstSize MUST NOT exceed MaxBurstSize." See my e-mail response to Mike for details on that dependence. I am also sending a following e-mail that details 3 other dependencies. This is an excellent example of why it is necessary to state explicitly where (if anywhere) one is required to send parameters in a specific order. Requiring that x not exceed y is equivalent to requiring y to be greater than or equal to x. It doesn't imply the order. In any case, as long as each side independently ensures that the maximum value it will accept for FirstBurstSize does not exceed the maximum value it will accept for MaxBurstSize, it doesn't matter which is negotiated first. The relationship between these two values does not imply an order and if we want to force an order it will need to be done explicitly. > But what's really dangerous here is that an > implementation that perceives some parameters > as dependent may take the "might imply" text > as an endorsement for sending back less key=value > pairs than was received, which could make the > other side never commit due to missing responses. > We certainly don't want to allow for such a > non-interoperability in the specification. Certainly not, and nowhere can I find anything in the standard that implies responses can ever be omitted. On the contrary, there are several places where it says you MUST always respond. For example, in section 4.2 on Text Mode Negotiation it says: "A key not understood by the responder may be ignored by the responder without affecting the basic function. However, the Text Response for a key not understood MUST be Key=NotUnderstood." And in section 4.2.2 for simple-value negotiations it says "For simple-value negotiations, the responding party MUST respond with the same key." The only time responses are optional are the 2 special-case Boolean negotiations detailed at the end of section 4.2. At no other time can responses be omitted. This is also a non-issue. Then the sentence: "If they are sent within the same command, a response for a parameter might imply responses for others." should be altered. "A response for a parameter might imply responses for others" appears to some readers to say that those responses may be omitted since they are already implied though to other readers it just means that the earlier response limits the response to the later key. > So, could we please get rid of this whole > paragraph? I do not see how we can get rid of this paragraph. However, perhaps it could be worded better to make it clearer without changing its intent. If the first sentence of the paragaph is to stay, then one needs to explicitly list the parameter ordering requirements because dependency order is not clear. The second sentence should be deleted as it doesn't say anything useful. It is clear that the response to earlier parameters limits the range of responses to later parameters regardless of whether they are in the same PDU or not. Regards, Pat From owner-ips@ece.cmu.edu Mon Jun 3 16:39:58 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00319 for ; Mon, 3 Jun 2002 16:39:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g53K5Qb08011 for ips-outgoing; Mon, 3 Jun 2002 16:05:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtp3.electric.net (smtp3.electric.net [216.129.90.16]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g53K5Ow08004 for ; Mon, 3 Jun 2002 16:05:24 -0400 (EDT) Received: from hm1.electric.net ([216.129.90.33]) by smtp3.electric.net with smtp (Exim 4.04) id 17Ey4v-00099N-03 for ips@ece.cmu.edu; Mon, 03 Jun 2002 13:05:21 -0700 Received: from osmtp1.electric.net ([216.129.90.29]) by hm1.electric.net (NAVGW 2.5.2.9) with SMTP id M2002060313052029006 for ; Mon, 03 Jun 2002 13:05:20 -0700 Received: from [216.192.238.30] (helo=EGRodriguez) by osmtp1.electric.net with esmtp (Exim 3.22 #1) id 17Ey4t-0005KX-04 for ips@ece.cmu.edu; Mon, 03 Jun 2002 13:05:20 -0700 From: "Elizabeth G. Rodriguez" To: Subject: IPS All: Last Call updates Date: Mon, 3 Jun 2002 15:03:18 -0600 Message-ID: <00c901c20b42$17ca82d0$1eeec0d8@EGRodriguez> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CA_01C20B0F.CD3012D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00CA_01C20B0F.CD3012D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, The IPS WG has just announced last call on two drafts: FCIP and iFCP. The FC Common Encapsulation draft has completed last call, and will be forwarded on to the ADs as soon as at least on of the above drafts has completed last call as well. Please submit any comments against these drafts as soon as possible. Reason for this is two fold. First, we would like to get the last call process completed for these drafts completed prior to Yokohoma. Second, we hope to start last call on other drafts (e.g. iSCSI, Security, and FC Mgmt MIB) soon, so that we can hopefully get those drafts through at least first last call comment resolution prior to Yokohoma. Thanks, Elizabeth Rodriguez IPS co-chair ------=_NextPart_000_00CA_01C20B0F.CD3012D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

The IPS WG has just announced last call on two = drafts:  FCIP and iFCP.

The FC Common Encapsulation draft has completed last = call, and will be forwarded on to the ADs as soon as at least on of the above = drafts has completed last call as well.

 

Please submit any comments against these drafts as = soon as possible.

Reason for this is two fold. 

First, we would like to get the last call process = completed for these drafts completed prior to Yokohoma.

Second, we hope to start last call on other drafts = (e.g. iSCSI, Security, and FC Mgmt MIB) soon, so that we can hopefully get = those drafts through at least first last call comment resolution prior to = Yokohoma.

 

Thanks,

 

Elizabeth Rodriguez

IPS co-chair

 

------=_NextPart_000_00CA_01C20B0F.CD3012D0-- From owner-ips@ece.cmu.edu Mon Jun 3 16:42:35 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00369 for ; Mon, 3 Jun 2002 16:42:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g53Jn6j06665 for ips-outgoing; Mon, 3 Jun 2002 15:49:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtp2.electricmail.net (smtp2.electric.net [216.129.90.15]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g53Jn2w06653 for ; Mon, 3 Jun 2002 15:49:03 -0400 (EDT) Received: from hm1.electric.net ([216.129.90.33]) by smtp2.electricmail.net with smtp (Exim 4.04) id 17Exp7-00086p-4A for ips@ece.cmu.edu; Mon, 03 Jun 2002 12:49:01 -0700 Received: from osmtp3.electric.net ([216.129.90.30]) by hm1.electric.net (NAVGW 2.5.2.9) with SMTP id M2002060312490121940 for ; Mon, 03 Jun 2002 12:49:01 -0700 Received: from [216.192.238.30] (helo=EGRodriguez) by osmtp3.electric.net with esmtp (Exim 3.22 #1) id 17Exp4-0005wz-04 for ips@ece.cmu.edu; Mon, 03 Jun 2002 12:48:59 -0700 From: "Elizabeth G. Rodriguez" To: Subject: iFCP: IPS WG Last Call for iFCP Date: Mon, 3 Jun 2002 14:46:57 -0600 Message-ID: <00bd01c20b3f$cebc3040$1eeec0d8@EGRodriguez> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BE_01C20B0D.8421C040" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00BE_01C20B0D.8421C040 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, All issues brought up in the first wg last call for iFCP have now been addressed. Resolution to those comments may be found at http://search.ietf.org/internet-drafts/draft-ietf-ips-ifcp-wglcc-00.txt A new iFCP draft has been made available, and the IPS working group is announcing a new last call on this draft. The draft is available at http://search.ietf.org/internet-drafts/draft-ietf-ips-ifcp-11.txt The comment period for this draft will conclude at 5pm EST on Monday, June 17. Comments of an editorial nature should be addressed directly to the draft editor, Charles Monia (cmonia@NishanSystems.com), technical coordinator Franco Travostino (travos@nortelnetworks.com), as well as the IPS co-chairs Elizabeth Rodriguez (ElizabethRodriguez@ieee.org) and David Black (black_david@emc.com) Comments of a technical nature need to be addressed on the IPS WG mailing list directly. Please submit comments on this draft as soon as possible. Thank you, Elizabeth Rodriguez & David Black, IPS WG co-chairs ------=_NextPart_000_00BE_01C20B0D.8421C040 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

All issues brought up in the first wg last call for = iFCP have now been addressed.

Resolution to those comments may be found at = http://search.ietf.org/internet-drafts/draft-ietf-ips-ifcp-wglcc-= 00.txt

 

A new iFCP draft has been made available, and the IPS = working group is announcing a new last call on this draft.

The draft is available at http://search.ietf.org/internet-drafts/draft-ietf-ips-ifcp-11.txt

The comment period for this draft will conclude at = 5pm EST on Monday, June 17.

 

Comments of an editorial nature should be addressed = directly to the draft editor, Charles Monia (cmonia@NishanSystems.com), technical coordinator Franco Travostino (travos@nortelnetworks.com),= as well as the IPS co-chairs Elizabeth Rodriguez (ElizabethRodriguez@ieee.org) = and David Black (black_david@emc.com)

 

Comments of a technical nature need to be addressed = on the IPS WG mailing list directly.

 

Please submit comments on this draft as soon as = possible.

 

Thank you,

 

Elizabeth Rodriguez & David Black, =

IPS WG co-chairs

 

------=_NextPart_000_00BE_01C20B0D.8421C040-- From owner-ips@ece.cmu.edu Mon Jun 3 16:43:35 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00388 for ; Mon, 3 Jun 2002 16:43:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g53Js5807051 for ips-outgoing; Mon, 3 Jun 2002 15:54:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtp2.electricmail.net (smtp2.electric.net [216.129.90.15]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g53Js2w07038 for ; Mon, 3 Jun 2002 15:54:02 -0400 (EDT) Received: from [216.129.90.84] (helo=deckard.electric.net) by smtp2.electricmail.net with smtp (Exim 4.04) id 17Extx-000EkI-02 for ips@ece.cmu.edu; Mon, 03 Jun 2002 12:54:01 -0700 Received: from osmtp3.electric.net ([216.129.90.30]) by deckard.electric.net (NAVGW 2.5.2.9) with SMTP id M2002060312272101129 for ; Mon, 03 Jun 2002 12:27:21 -0700 Received: from [216.192.238.30] (helo=EGRodriguez) by osmtp3.electric.net with esmtp (Exim 3.22 #1) id 17Extv-0006wV-04 for ips@ece.cmu.edu; Mon, 03 Jun 2002 12:54:00 -0700 From: "Elizabeth G. Rodriguez" To: Subject: FCIP: IPS WG last call for FCIP Date: Mon, 3 Jun 2002 14:51:58 -0600 Message-ID: <00c401c20b40$824a38f0$1eeec0d8@EGRodriguez> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C5_01C20B0E.37AFC8F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00C5_01C20B0E.37AFC8F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, All issues brought up for the first WG last call for FCIP have now been addressed. Resolution to those comments may be found at http://search.ietf.org/internet-drafts/draft-ietf-ips-fcip-wglc-02.txt A new FCIP draft has been made available, and the IPS working group is announcing a new last call on this draft. The draft is available at http://search.ietf.org/internet-drafts/draft-ietf-ips-fcovertcpip-10.txt The comment period for this draft will conclude at 5pm EST on Monday, June 17. Comments of an editorial nature should be addressed directly to the draft editor, Ralph Weber(ralphoweber@compuserve.com), technical coordinator Murali Rajagopal (muralir@cox.net), as well as the IPS co-chairs Elizabeth Rodriguez (ElizabethRodriguez@ieee.org) and David Black (black_david@emc.com) Comments of a technical nature need to be addressed on the IPS WG mailing list directly. Please submit comments on this draft as soon as possible. Thank you, Elizabeth Rodriguez & David Black, IPS WG co-chairs ------=_NextPart_000_00C5_01C20B0E.37AFC8F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

All issues brought up for the first WG last call for = FCIP have now been addressed.

Resolution to those comments may be found at http://search.ietf.org/internet-drafts/draft-ietf-ips-fcip-wglc-02= .txt

 

A new FCIP draft has been made available, and the IPS working group is announcing a new last call on this = draft.

The draft is available at http://search.ietf.org/internet-drafts/draft-ietf-ips-fcovertcpi= p-10.txt

The comment period for this draft will conclude at = 5pm EST on Monday, June 17.

 

Comments of an editorial nature should be addressed = directly to the draft editor, Ralph Weber(ralphoweber@compuserve.com), technical coordinator Murali Rajagopal (muralir@cox.net), as well as the IPS = co-chairs Elizabeth Rodriguez (ElizabethRodriguez@ieee.org) and David Black (black_david@emc.com)

 

Comments of a technical nature need to be addressed = on the IPS WG mailing list directly.

 

Please submit comments on this draft as soon as = possible.

 

Thank you,

 

Elizabeth Rodriguez & David Black, =

IPS WG co-chairs

 

 

------=_NextPart_000_00C5_01C20B0E.37AFC8F0-- From owner-ips@ece.cmu.edu Mon Jun 3 16:51:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00563 for ; Mon, 3 Jun 2002 16:50:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g53KUAH10005 for ips-outgoing; Mon, 3 Jun 2002 16:30:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13702.mail.yahoo.com (web13702.mail.yahoo.com [216.136.175.135]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g53KU6w09991 for ; Mon, 3 Jun 2002 16:30:06 -0400 (EDT) Message-ID: <20020603203005.55596.qmail@web13702.mail.yahoo.com> Received: from [192.55.52.2] by web13702.mail.yahoo.com via HTTP; Mon, 03 Jun 2002 13:30:05 PDT Date: Mon, 3 Jun 2002 13:30:05 -0700 (PDT) From: Martins Krikis Subject: Re: iSCSI: keys/parameter dependence To: "Robert D. Russell" Cc: ips@ece.cmu.edu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk (I've thrown some text out to keep it shorter) --- "Robert D. Russell" wrote: > The following paragraph from an e-mail from Martins > Krikis > made me realize that the definition of the new C bit > is not correct, because it goes much further > than is necessary to solve the "split key" problem, > and as a result, it opens up a whole new set of > problems, > complicates what was previously a simple situation, > and > breaks a lot of already running and tested code. The C-bit actually simplifies a previously very complicated situation. As to "running and tested", I don't think many people have encountered split PDUs in operational stage or FFP Text negotiations yet. > I don't believe the intention of the recent > discussion > that led to the introduction of the C bit was, in > fact, > to allow "batching" or to throw out "ordering" of > the > sending of keys. However, the definition in Draft > 12-95 > sections 9.10.2 and 9.11.2 seems to now allow > batching: Those, who prefer the "batch-processing" approach fought for the C-bit, so I would say that it was introduced in order to allow it. Regarding ordering, however, it had never been defined, and I would hate to see it introduced. In my opinion, it is best to treat all operational parameters as independent and negotiate them as such. Just before the commit (i.e., turning on the T or F bit), one can do an all-encompassing consistency check and reset the negotiations if the values violate the laws imposed on them, or offer some more keys to solve any such problems, if this is still possible. I could even imagine negotiations succeeding but laws (e.g. FirstBurstSize <= MaxBurstSize) not being broken when sending data... OK, the last thing might technically be forbidden at the moment but it is not that unreasonable. It would be something like FirstBursSize = min(FirstBurstSize, MaxBurstSize) done after the negotiation end, and then you can forget about dependencies.I think it is way easier than worrying about key ordering every time something is sent or received. > (I agree with John Huffered that Martins' comments > about > "ordering" are not correct in any case.) I'd have to know which particular ones are we talking about in order to clarify my position. > The problem I see with this definition of the C bit > is that > the sending side can force the receiving NOT to > process > a PDU containing key=value pairs, even if all those > key=value > pairs are complete within the PDU. Therefore, the > receiver > is forced to save this PDU (and any number of > following PDUs) > until the sender finally sends C = 0. "You may process, just please don't send anything back yet, because I'm not finished sending stuff to you. The small PDU size wrt the abnormally large data amounts that I have to send (all very important and urgent) are making it hard for me to fit it all in a single PDU." > In the worst > case, the > sender could send one key=value pair per PDU with > the C bit set > to 0 and the receiver could not reply to any of > these until it > got one with C bit set to 1. If this is really a problem, I'm happy to retreat my position to one of the other schemes, going as far as allowing the responding side to send responses and originate key declarations, but not to originate keys that are not declarations. I am really fond of doing batch-processing of the keys and I would hate to have it broken again. > As the e-mail from Martins indicates, some people > are already > taking this to mean that parameter negotiations will > "normally" > be batched. I'm planning to batch my parameters. But I don't care how the other side processes them, as long as it sticks to the (new) protocol and doesn't interrupt me when I have the C-bit still set. > Up until the introduction of the C bit, > PDUs and keys > in them were always processed as received, and most > code already does > this, since it is the most logical and efficient way > to do it. > We should still encourage this as the "normal" way > of negotiating. How could you possibly know what "most code" does? I would even conjecture that most code isn't out there open for examination or experimentation with. Most code that I've seen does batch-processing. I must admit, the batch is typically one PDU and the code can break if keys are getting split. The C-bit allows a trivial update of that code to deal with split keys as well. > I believe the problem we were trying to solve by > introducing > the C bit was the one where a key was split over a > PDU boundary sure > -- we were not trying to redesign the negotiation > mechanism, and we didn't really. It's still essentially the same, one side sends some pairs, the other side answers. But PDU boundaries no longer mess up this simple scheme. > which was discussed on the mailing list long ago and > has been > working in a lot of running code for the past two > plugfests. Did you see split-keys outside of security stage? What happened, if so? > Could we therefore please change the definition of > the C bit in > section 9.10.2 to read: > "When set to 1, indicates that the text in this Text > Request > contains a single key=value pair, and that pair is > incomplete > within this PDU." I could see it anyway when I find no terminating '\0'. But how would this change help with the original split-key problem (both sides feeling like originators)? Do you propose to send complete pairs separated from split-pairs? And the sender to check for each key=value whether it will fit entirely or not? If so, please see the very lengthy discussion which got us to the C-bit. > I'm not happy about seeing such a major change (C > flag bit) > introduced so late in the process to solve an > "almost" non-existant > problem (split keys). Yes it is "almost" non-existant. That's why I asked above, have you seen split-keys outside security stage or not? > It is "almost" non-existand > because of > the following considerations (some of which were > already > mentioned on the list and are just summarized here): > During the login process, the PDU size is 8192 > bytes. > Therefore, except for the long keys during > negotiation > that follows a chosen AuthMethod, there is never a > need to split > keys across pdu boundaries during login -- > even if you negotiate every possible login key > (except those special keys that occur in security > protocols) > to its maximum length, you do not reach the total of > 8192 bytes. > It is not even close! Therefore, there is no need > for any > implication that the C bit should appear during this > process. OK, disallow it completely. Just don't let some split-keys make both sides feel like originators, nor ask me to check each key=value pair I'm preparing for fitting or not fitting. > When those long security keys are needed, the > negotiation process is > in a 1 key over, 1 key back exchange mode, so there > is no "batching" > possible and the split key should in fact be the > only key in the pdu. Sure, although nothing prevents me from declaring that my 1 key=value is my "whole batch" and apply batch-processing to this pair. > Finally, during text exchanges, there only 6 keys > that can be > legally sent (plus the X-extension key): > SendTargets, TargetName, > TargetAlias, TargetAddress, InitiatorAlias, and > MaxRecvPDULength. > None of these can legally have a value greater than > 255 bytes, > which is well less than the minimum PDU size (512 > bytes). And how many instances of TargetName and TargetAddress can the SendTargets command provoke from the other side? I think it can easily overflow the 8192 bytes. > So there is no need to split keys over boundaries > during text > negotiation, except perhaps for the X-extension > keys. One could get away without splitting keys ever (but not necessarily without splitting values). However, a scheme like that means that the sender has to check whether a newly prepared pair fits or doesn't (definition of "fits" varies depending on whether the key may be split or not). Again, the lengthy previous discussions were all about why this would be a bad requirement to have. > In summary, I would like to see as little disruption > as possible > to the key negotiation scheme which has been stable > for a long time, I think the C-bit just achieved that. A "batch" is a "virtual PDU" (no length restrictions). Once you get a "batch", you're welcome to send the response batch, just as previously done with PDUs. Except that nobody has to worry about split keys anymore. > I believe my modification to > the definition of > the C flag accomplishes that, without introducing > any new, false > perceptions about "batching" and "ordering". It's nice that batching is now possible. Having any ordering (within a "batch") is entirely unnecessary, however, IMO. Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my emplyer __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Mon Jun 3 17:21:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01486 for ; Mon, 3 Jun 2002 17:21:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g53Kg1u10813 for ips-outgoing; Mon, 3 Jun 2002 16:42:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13703.mail.yahoo.com (web13703.mail.yahoo.com [216.136.175.136]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g53Kfww10807 for ; Mon, 3 Jun 2002 16:41:58 -0400 (EDT) Message-ID: <20020603204158.96478.qmail@web13703.mail.yahoo.com> Received: from [192.55.52.4] by web13703.mail.yahoo.com via HTTP; Mon, 03 Jun 2002 13:41:58 PDT Date: Mon, 3 Jun 2002 13:41:58 -0700 (PDT) From: Martins Krikis Subject: Re: iSCSI: keys/parameter dependence To: ips@ece.cmu.edu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- "Robert D. Russell" wrote: > > So MaxBurstSize MUST come before FirstBurstSize? > > Not necessarily, since it says "Whenever parameter > action or acceptance > are dependent on other parameters, ...". If you > want to offer a value of > FirstBurstSize (say 524288) that is greater than the > default value 262144 > of MaxBurstSize then a value of MaxBurstSize at > least as large as 524288 > must be offered first -- otherwise the offered value > of 262144 for > FirstBurstSize could not be accepted, since that > would violate the > requirement in section 11.14 that "FirstBurstSize > MUST NOT exceed > MaxBurstSize." (and the (default) value for > MaxBurstSize would be > exceeded if the offered value were accepted at that > point in the > negotiations.) > > On the other hand, if you want to offer a value of > MaxBurstSize (say 32768) > that is smaller than the default value 65536 of > FirstBurstSize then a value > of FirstBurstSize no larger than 32768 must be > offered first -- otherwise > the offered value of 32768 for MaxBurstSize cannot > be accepted, since that > would violate the same requirement at that point in > the negotiations. So, are you really proposing a requirement that we must look at the values in order to figure out in which order to send keys? That is so UGLY, it is hard to believe that this is happening. Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Mon Jun 3 18:06:08 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02645 for ; Mon, 3 Jun 2002 18:06:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g53LiXN15491 for ips-outgoing; Mon, 3 Jun 2002 17:44:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13709.mail.yahoo.com (web13709.mail.yahoo.com [216.136.175.251]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g53LiUw15486 for ; Mon, 3 Jun 2002 17:44:30 -0400 (EDT) Message-ID: <20020603214429.8076.qmail@web13709.mail.yahoo.com> Received: from [192.55.52.3] by web13709.mail.yahoo.com via HTTP; Mon, 03 Jun 2002 14:44:29 PDT Date: Mon, 3 Jun 2002 14:44:29 -0700 (PDT) From: Martins Krikis Subject: Re: iSCSI: keys/parameter dependence To: "Robert D. Russell" Cc: ips@ece.cmu.edu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- "Robert D. Russell" wrote: > The existence of a dependency between FirstBurstSize > and > MaxBurstSize is already clear from the statement in > section 11.15: > "FirstBurstSize MUST NOT exceed MaxBurstSize." My > earlier e-mail to Mike > Donahoe details this dependency. I've already said that looking at values to determine the order is very, very ugly. I don't think we need order at all. Check for consistency before commit, that's when you have to look at all keys anyways, to see which ones are lacking responses or haven't been negotiated, etc. Let's not put extra burden of checking dependencies at key processing time. It's simplest to be able to decide on the value of each key without having to look at the others. (I'm not talking about security stage though.) > The existence of a dependency between OFMarker and > OFMarkInt, and between > IFMarker and IFMarkInt, is implied by the statements > in section A.3.2: > "When the interval is unacceptable the responder > answers with > "Reject". Reject is resetting the marker function > in the spcified > direction (Output or Input) to No." No it isn't. IMO, it is resetting the marker interval to its previous value, which is likely the default value. I believe it's perfectly legal to negotiate the marker interval but to not turn on marker use, or to turn on the use but stay with current (default) values for the interval. If one side can't tolerate the other's Reject (i.e., can't live with the default value), it is welcome to bail and try next time w/o markers. BTW, we could use 0 here as a special value, meaning that markers are not in use, then we wouldn't need the boolean keys for markers. > This last sentence should probably be reworded to > say: > "A response value of "Reject" to an OFMarkInt > (IFMarkInt) key resets the > corresponding OFMarker (IFMarker) key value to > "No"." No, thank you. I would prefer if Reject meant the same as with the other keys, i.e., negotiation failed for this key, let's stick with the old value, or bail if we must. > 1. The table in section 11.12 describes the action > taken on the four > combinations of InitialR2T = Yes/No and > ImmediateData = Yes/No. > The combination InitialR2T=Yes and ImmediateData=No > means "Unsolicited > data disallowed". Therefore, FirstBurstSize becomes > "Irrelevant" for > this combination. This means that if FirstBurstSize > is offered after > an offer of ImmediateData=No which is accepted, and > either an explicit > offer of InitialR2T=Yes which is accepted or no > explicit offer of > InitialR2T (in which case the applicable default > value is Yes), > then a reply of FirstBurstSize=Irrelevant MAY be > returned > (alternatively, a valid value can also be given in > the reply). OK, a dependency. Not of the simplest kind, of course. Does it impose order? What's the harm if I send FirstBurstSize before those other two keys? Isn't it simpler to negotiate a variable that ends up unused than to worry about whether it should or should not be sent after some other keys? Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Mon Jun 3 18:06:12 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02646 for ; Mon, 3 Jun 2002 18:06:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g53LN1h13956 for ips-outgoing; Mon, 3 Jun 2002 17:23:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13705.mail.yahoo.com (web13705.mail.yahoo.com [216.136.175.138]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g53LMww13943 for ; Mon, 3 Jun 2002 17:22:58 -0400 (EDT) Message-ID: <20020603212257.17233.qmail@web13705.mail.yahoo.com> Received: from [192.55.52.4] by web13705.mail.yahoo.com via HTTP; Mon, 03 Jun 2002 14:22:57 PDT Date: Mon, 3 Jun 2002 14:22:57 -0700 (PDT) From: Martins Krikis Subject: Re: iSCSI: keys/parameter dependence To: "Robert D. Russell" Cc: ips@ece.cmu.edu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- "Robert D. Russell" wrote: > However, there ARE dependencies between operational > parameters that cannot be ignored, such as the one > Mike mentioned I should have been more precise. I meant "order imposing dependencies". You might say "is there any other kind?", and I would say "yes" and be very sorry for not CC-ing you on my previous post sent to the list. I'm sorry already. > -- FirstBurstSize and MaxBurstSize are dependent > because of the > requirement in section 11.15: "FirstBurstSize MUST > NOT exceed > MaxBurstSize." See my e-mail response to Mike for > details > on that dependence. I saw it. I consider it unbelievably ugly to have to look at the values in order to figure out ordering requirements. I prefer ignoring ordering completely and check for overall consistency before commit. > > "(sent) after" isn't defined. It is unclear > > whether "in higher numbered bytes within the > > same PDU" qualifies as "after" or whether only > > "in a PDU sent at a later time" would. > > I don't see this, and I agree with John Hufferd's > response > to this that "previous" is obviously "previous", > whether in > the previous PDUs (because the current PDU was > delivered > after them) or in the same PDU Just because your interpretation matches John's doesn't mean that it has been unambiguously defined and that everybody will see it that way. The suspicion that may be, just may be, "after" meant "in a later PDU" was made stronger by the sentence that talked about keys sent in the same "command" (i.e., PDU). > (because key=value > pairs > are naturally scanned from the beginning of a PDU's > data segment, Not if we don't have a C-bit and have to start from the end to see if the last pair is split or full. And natural to one might be unnatural to another. > and if nothing else, pairs had to be put into the > data segment > in that order, What order? Previous coming before after? That order only appears once I've put something in the data-segment, and I could put pairs in there in any way I want... > This is a non-issue. It's a good thing we got it clear what "after" means, now I'll just ask why is it important... > I don't see this either. Nowhere does the newly > added text > describing the C-bit say anything about doing away > with the > specific order of the key=value pairs within the > "batch". Nowhere does it say anything about the order. I may prefer to process all booleans first, for example. I may even find each pair going backwards in the PDU... > Why should it -- even if you don't process PDU by > PDU you still > have to process batch by batch, batch by batch, yes, absolutely. > a batch still has to > be scanned > to find key=value pairs, and the natural way to scan > is from the > beginning of the batch, not necessarily. > since the next key starts > after the > delimiter of the previous key in the batch. or the previous value (or pair) ends before the delimiter of the next key... > This is also a non-issue. As long as somebody doesn't impose processing order on my implementation. > > Therefore, the text about them being sent in > > "the same command" is likely irrelevant, too, > > since many implementation simply won't check that. > > "command" should simply be replaced by "batch" or, > to be more consistent with the rest of the wording > in the > standard, with "set of key=value pairs". Why does it even matter whether a key has been sent in the same "batch" or even the same PDU as another one? Either the value of one may imply the value of another, or not. But why does this sentence single out keys sent in the same "command" ("batch", whatever)? > However, see my earlier e-mail to Julian stating my > concerns over the use of the C-bit for "batching". I've seen it and still think that batching of keys is a great way to simplify their processing. > > But what's really dangerous here is that an > > implementation that perceives some parameters > > as dependent may take the "might imply" text > > as an endorsement for sending back less key=value > > pairs than was received, which could make the > > other side never commit due to missing responses. > > We certainly don't want to allow for such a > > non-interoperability in the specification. > > > Certainly not, and nowhere can I find anything in > the standard > that implies responses can ever be omitted. Alright. Then let's just get rid of this sentence because it does make it sound like may be, just may be, responses can be omitted when they are already implied. > This is also a non-issue. I hope so, but the sentence worries me. > I do not see how we can get rid of this paragraph. > However, perhaps it could be worded better to make > it clearer > without changing its intent. But what is the intent? That ordering of keys matters? I don't see it as a good feature, if so. Or that the values of some keys "imply" the values of others? They may be putting restrictions on them, but why only if in the same "command" ("batch", whatever)? Why not always? Why have this observation here and in the form that makes one doubt whether responses are always mandatory? Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Mon Jun 3 18:19:36 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02860 for ; Mon, 3 Jun 2002 18:19:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g53Lp8C15924 for ips-outgoing; Mon, 3 Jun 2002 17:51:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13704.mail.yahoo.com (web13704.mail.yahoo.com [216.136.175.137]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g53Lp5w15916 for ; Mon, 3 Jun 2002 17:51:05 -0400 (EDT) Message-ID: <20020603215104.5843.qmail@web13704.mail.yahoo.com> Received: from [192.55.52.3] by web13704.mail.yahoo.com via HTTP; Mon, 03 Jun 2002 14:51:04 PDT Date: Mon, 3 Jun 2002 14:51:04 -0700 (PDT) From: Martins Krikis Subject: RE: iSCSI: minor conflict introduced by C bit To: ips@ece.cmu.edu In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00C353C25@axcs04.cos.agilent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk > One could resolve this by: > 1) Specify that the C bit MUST NOT be set in the > first Login Request PDU; or > 2) Allow declarations to be sent in PDUs when the > other side has the C bit set; or > 3) Change the requirement in 11.4 and 11.9 to be the > response to the first Login Request PDU with the C > bit set to zero. I think 3 is the most natural way for the current meaning of C-bit. I can live with 2 as well (even responses could be sent, just no new originations of non-declarations). 1 would take us back to square-1, i.e., strictly speaking, the sender will be forced to check whether things fit or not. Martins Krikis, Intel Corp. Disclaimer: my opinions, not necessarily Intel's. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Mon Jun 3 19:50:12 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04468 for ; Mon, 3 Jun 2002 19:50:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g53ND1O20913 for ips-outgoing; Mon, 3 Jun 2002 19:13:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g53NCxw20907 for ; Mon, 3 Jun 2002 19:12:59 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 0EE1130706; Mon, 3 Jun 2002 19:12:59 -0400 (EDT) Date: Mon, 3 Jun 2002 16:11:00 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Martins Krikis Cc: Subject: RE: iSCSI: minor conflict introduced by C bit In-Reply-To: <20020603215104.5843.qmail@web13704.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Sorry, meant to answer earlier but deleted too fast. On Mon, 3 Jun 2002, Martins Krikis wrote: > > > One could resolve this by: > > 1) Specify that the C bit MUST NOT be set in the > > first Login Request PDU; or > > 2) Allow declarations to be sent in PDUs when the > > other side has the C bit set; or > > 3) Change the requirement in 11.4 and 11.9 to be the > > response to the first Login Request PDU with the C > > bit set to zero. > > I think 3 is the most natural way for the current > meaning of C-bit. I can live with 2 as well (even > responses could be sent, just no new originations > of non-declarations). 1 would take us back to > square-1, i.e., strictly speaking, the sender will > be forced to check whether things fit or not. I think that 3) is the most natural. It captures what I think is the intent of the working group and adapts it for the case where the initial offer won't fit in one PDU. Take care, Bill From owner-ips@ece.cmu.edu Tue Jun 4 00:40:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10026 for ; Tue, 4 Jun 2002 00:40:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g543sPY05989 for ips-outgoing; Mon, 3 Jun 2002 23:54:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g543sNw05984 for ; Mon, 3 Jun 2002 23:54:24 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g543s6j2032282; Tue, 4 Jun 2002 05:54:06 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g543s5i38460; Tue, 4 Jun 2002 05:54:05 +0200 To: "THALER,PAT (A-Roseville,ex1)" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: minor conflict introduced by C bit X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 4 Jun 2002 06:54:01 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 04/06/2002 06:54:05, Serialize complete at 04/06/2002 06:54:05 Content-Type: multipart/alternative; boundary="=_alternative 005F63E3C2256BCD_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005F63E3C2256BCD_= Content-Type: text/plain; charset="us-ascii" Thanks Pat - I think that 3 is acceptable and keeps current semantics unchanged. Julo "THALER,PAT (A-Roseville,ex1)" 06/03/2002 07:47 PM Please respond to "THALER,PAT (A-Roseville,ex1)" To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: minor conflict introduced by C bit Julian, I have noticed a minor conflict of the C bit with existing text. 11.4 and 11.9 require the target to return TargetName and TargetPortal group in the first Login Response PDU but the new text on the C bit in 4.2 requires the target to return an empty response if the C bit is set. Therefore, if the C bit is set on the first Login Request PDU, the target will have conflicting requirements on it. One could resolve this by: 1) Specify that the C bit MUST NOT be set in the first Login Request PDU; or 2) Allow declarations to be sent in PDUs when the other side has the C bit set; or 3) Change the requirement in 11.4 and 11.9 to be the response to the first Login Request PDU with the C bit set to zero. Regards, Pat --=_alternative 005F63E3C2256BCD_= Content-Type: text/html; charset="us-ascii"
Thanks Pat - I think that 3 is acceptable and keeps current semantics unchanged.

Julo


"THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>

06/03/2002 07:47 PM
Please respond to "THALER,PAT (A-Roseville,ex1)"

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: minor conflict introduced by C bit

       


Julian,
 
I have noticed a minor conflict of the C bit with existing text.
 
11.4 and 11.9 require the target to return TargetName and TargetPortal group in the first Login Response PDU but the new text on the C bit in 4.2 requires the target to return an empty response if the C bit is set. Therefore, if the C bit is set on the first Login Request PDU, the target will have conflicting requirements on it.
 
One could resolve this by:
1) Specify that the C bit MUST NOT be set in the first Login Request PDU; or
2) Allow declarations to be sent in PDUs when the other side has the C bit set; or
3) Change the requirement in 11.4 and 11.9 to be the response to the first Login Request PDU with the C bit set to zero.
 
Regards,
Pat

--=_alternative 005F63E3C2256BCD_=-- From owner-ips@ece.cmu.edu Tue Jun 4 01:48:28 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10710 for ; Tue, 4 Jun 2002 01:48:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5459YH09928 for ips-outgoing; Tue, 4 Jun 2002 01:09:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5459Xw09924 for ; Tue, 4 Jun 2002 01:09:33 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5459Q42012778 for ; Tue, 4 Jun 2002 07:09:26 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5459Qs42990 for ; Tue, 4 Jun 2002 07:09:26 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSI 12-96 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 4 Jun 2002 08:09:22 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 04/06/2002 08:09:25, Serialize complete at 04/06/2002 08:09:25 Content-Type: multipart/alternative; boundary="=_alternative 001B9250C2256BCE_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001B9250C2256BCE_= Content-Type: text/plain; charset="us-ascii" For all those that complained about errors on 12-96 - I have uploaded a fresh copy - 2 pages where in error and I don't know how (checksum did probably not reveal an error on the uplink - it happened before). Julo --=_alternative 001B9250C2256BCE_= Content-Type: text/html; charset="us-ascii"
For all those that complained about errors on 12-96 - I have uploaded a fresh copy - 2 pages where in error and I don't know how (checksum did probably not reveal an error on the uplink - it happened before).

Julo --=_alternative 001B9250C2256BCE_=-- From owner-ips@ece.cmu.edu Tue Jun 4 09:46:20 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28445 for ; Tue, 4 Jun 2002 09:46:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g54D7hx14563 for ips-outgoing; Tue, 4 Jun 2002 09:07:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g54D7ew14551 for ; Tue, 4 Jun 2002 09:07:40 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g54D7WAW021442; Tue, 4 Jun 2002 15:07:32 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g54D7Vs100362; Tue, 4 Jun 2002 15:07:31 +0200 To: "Robert D. Russell" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: null termination of keys X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 4 Jun 2002 16:07:29 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 04/06/2002 16:07:31, Serialize complete at 04/06/2002 16:07:31 Content-Type: multipart/alternative; boundary="=_alternative 00474CF0C2256BCE_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00474CF0C2256BCE_= Content-Type: text/plain; charset="us-ascii" Bob, The reason it was put in is to to enable "parsing" without the C bit. With key spanning PDUs before having the C bit the sender had to avoid sending a 0 if this was the last byte of the PDU as he had no other means of signaling continuation. A 0 at the end of a PDU meant end-of-LTDS. Now that we have the C bit we can live with or without having a 0 at the end of the last PDU. Let's hear some more voices. Regards, Julo "Robert D. Russell" 06/04/2002 09:48 AM Please respond to "Robert D. Russell" To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: null termination of keys Julian: Draft 12-96, section 4.1 defines an LTDS and then says: "Every key=value pair, excluding the last or only pair in a LTDS, MUST be followed by one null (0x00) delimiter; the last or only pair in a LTDS ends at the LTDS end." This brings us back to where we were in draft 6 -- that key=value pairs are separated by nulls, not terminated by nulls. If I remember correctly, one of the primary reasons that this was changed going to draft 7 is that implementations prefer to treat each key=value pair as one string, and in C and C++, strings are null terminated. I do not believe this change is in any way necessary for the LTDS or C-bit mechanism, and would request that it be put back to the way it has been from draft 7 through draft 12-94: "Every key=value pair, including the last or only pair in a LTDS, MUST be followed by one null (0x00) delimiter." Thanks Bob Russell --=_alternative 00474CF0C2256BCE_= Content-Type: text/html; charset="us-ascii"
Bob,

The reason it was put in is to to enable "parsing" without the C bit.
With key spanning PDUs before having the C bit the sender had to avoid sending a 0 if this was the last byte of the PDU as he had no other means of signaling continuation. A 0 at the end of a PDU meant end-of-LTDS.

Now that we have the C bit we can live with or without having a 0 at the end of the last PDU.
Let's hear some more voices.

Regards,
Julo


"Robert D. Russell" <rdr@io.iol.unh.edu>

06/04/2002 09:48 AM
Please respond to "Robert D. Russell"

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        Re: null termination of keys

       


Julian:

Draft 12-96, section 4.1 defines an LTDS and then says:

"Every key=value pair, excluding the last or only pair in a LTDS,
MUST be followed by one null (0x00) delimiter; the last or only pair
in a LTDS ends at the LTDS end."

This brings us back to where we were in draft 6 -- that key=value pairs
are separated by nulls, not terminated by nulls.  If I remember
correctly, one of the primary reasons that this was changed going to draft
7 is that implementations prefer to treat each key=value pair as one string,
and in C and C++, strings are null terminated.

I do not believe this change is in any way necessary for the LTDS or
C-bit mechanism, and would request that it be put back to the way it has
been from draft 7 through draft 12-94:

"Every key=value pair, including the last or only pair in a LTDS,
MUST be followed by one null (0x00) delimiter."

Thanks

Bob Russell

--=_alternative 00474CF0C2256BCE_=-- From owner-ips@ece.cmu.edu Tue Jun 4 11:02:06 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01710 for ; Tue, 4 Jun 2002 11:02:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g54EZgA20860 for ips-outgoing; Tue, 4 Jun 2002 10:35:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (io.iol.unh.edu [132.177.123.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g546mtw14908 for ; Tue, 4 Jun 2002 02:48:55 -0400 (EDT) Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.3/8.12.3) with ESMTP id g546mh6U024167; Tue, 4 Jun 2002 02:48:43 -0400 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.3/8.12.3/Submit) with ESMTP id g546mhTh024164; Tue, 4 Jun 2002 02:48:43 -0400 Date: Tue, 4 Jun 2002 02:48:43 -0400 (EDT) From: "Robert D. Russell" To: Julian Satran cc: ips@ece.cmu.edu Subject: Re: null termination of keys In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian: Draft 12-96, section 4.1 defines an LTDS and then says: "Every key=value pair, excluding the last or only pair in a LTDS, MUST be followed by one null (0x00) delimiter; the last or only pair in a LTDS ends at the LTDS end." This brings us back to where we were in draft 6 -- that key=value pairs are separated by nulls, not terminated by nulls. If I remember correctly, one of the primary reasons that this was changed going to draft 7 is that implementations prefer to treat each key=value pair as one string, and in C and C++, strings are null terminated. I do not believe this change is in any way necessary for the LTDS or C-bit mechanism, and would request that it be put back to the way it has been from draft 7 through draft 12-94: "Every key=value pair, including the last or only pair in a LTDS, MUST be followed by one null (0x00) delimiter." Thanks Bob Russell From owner-ips@ece.cmu.edu Tue Jun 4 11:03:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01762 for ; Tue, 4 Jun 2002 11:03:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g54EZoW20878 for ips-outgoing; Tue, 4 Jun 2002 10:35:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (io.iol.unh.edu [132.177.123.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g548Dqw18995 for ; Tue, 4 Jun 2002 04:13:52 -0400 (EDT) Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.3/8.12.3) with ESMTP id g548De6U025072; Tue, 4 Jun 2002 04:13:40 -0400 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.3/8.12.3/Submit) with ESMTP id g548DeKO025069; Tue, 4 Jun 2002 04:13:40 -0400 Date: Tue, 4 Jun 2002 04:13:40 -0400 (EDT) From: "Robert D. Russell" To: Julian Satran cc: ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian: I have found the following dependencies between keys in draft 12-96, and would ask other people on the mailing list to contribute others they have found so we can all be aware of the complete set. There seem to be very few dependencies, which I believe is a credit to a clean, orthogonal design. With a bit of work, we could probably get rid of all the dependencies between the OFMarkInt (IFMarkInt) and OFMarker (IFMarker) keys, perhaps, as suggested by Martins Krikis, by eliminating the OFMarker (IFMarker) key and substituting a default (and response) value of 0 for the OFMarkInt (IFMarkInt) to mean "no markers in that direction". This would also eliminate the need for a "Reject" reply to an OFMarkInt (IFMarkInt) offer. "Meaningful" dependencies (i.e., those that cannot be ignored because they effect operation): 1. Between FirstBurstSize and MaxBurstSize Section 11.15: "FirstBurstSize MUST NOT exceed MaxBurstSize." 2. Between OFMarkInt (IFMarkInt) and OFMarker (IFMarker) Section A.3.2: "When the interval (in an OFMarkInt (IFMarkInt) offer) is unacceptable the responder answers with "Reject". Reject is resetting the marker function (i.e., OFMarker (IFMarker)) in the specified direction (Output or Input) to No." 3. Between SessionType and MaxConnections Section 11.22: "The discovery session implies MaxConnections = 1 and overrides both the default and an explicit setting." "Trivial" dependencies (i.e., those that only allow the option of replying with "Irrelevant" instead of a normally selected value, and therefore can be ignored). 1. Between FirstBurstSize, InitialR2T, and ImmediateData The table in section 11.12 implies that the combination InitialR2T=Yes and ImmediateData=No allows the response FirstBurstSize=Irrelevant. 2. Between OFMarker (IFMarker) and OFMarkInt (IFMarkInt). Sections A.3.1 and A.3.2 imply that OFMarker=No (IFMarker=No) allows the response OFMarkInt=Irrelevant (IFMarkInt=Irrelevant). Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Tue Jun 4 11:03:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01785 for ; Tue, 4 Jun 2002 11:03:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g54ELfD19749 for ips-outgoing; Tue, 4 Jun 2002 10:21:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g54ELcw19741 for ; Tue, 4 Jun 2002 10:21:38 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Jun 2002 10:21:22 -0400 Message-ID: From: Eddy Quicksall To: "ips@ece. cmu. edu (E-mail)" Subject: release projection Date: Tue, 4 Jun 2002 10:21:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20BD3.19AFC5B0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C20BD3.19AFC5B0 Content-Type: text/plain; charset="iso-8859-1" What's the new target date for the completion of the iSCSI standard? mailto: Eddy_Quicksall@iVivity.com ------_=_NextPart_001_01C20BD3.19AFC5B0 Content-Type: text/html; charset="iso-8859-1"

What's the new target date for the completion of the iSCSI standard?

 
 
------_=_NextPart_001_01C20BD3.19AFC5B0-- From owner-ips@ece.cmu.edu Tue Jun 4 11:05:44 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01847 for ; Tue, 4 Jun 2002 11:05:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g54Ek6s21748 for ips-outgoing; Tue, 4 Jun 2002 10:46:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f20.pav2.hotmail.com [64.4.37.20]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g54Ek0w21720 for ; Tue, 4 Jun 2002 10:46:00 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 4 Jun 2002 07:45:54 -0700 Received: from 64.38.134.101 by pv2fd.pav2.hotmail.msn.com with HTTP; Tue, 04 Jun 2002 14:45:54 GMT X-Originating-IP: [64.38.134.101] From: "Bernard Aboba" To: ips@ece.cmu.edu Subject: Security -13 draft Date: Tue, 04 Jun 2002 07:45:54 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Jun 2002 14:45:54.0822 (UTC) FILETIME=[87C02A60:01C20BD6] Sender: owner-ips@ece.cmu.edu Precedence: bulk A -13 version of the security draft is available for your examination at: http://www.drizzle.com/~aboba/IPS/draft-ietf-ips-security-13.txt Since this is potentially the version that will go to WG last call, a careful reading is encouraged. _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From owner-ips@ece.cmu.edu Tue Jun 4 11:08:26 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02016 for ; Tue, 4 Jun 2002 11:08:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g54EZXP20838 for ips-outgoing; Tue, 4 Jun 2002 10:35:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (io.iol.unh.edu [132.177.123.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g546kKw14748 for ; Tue, 4 Jun 2002 02:46:20 -0400 (EDT) Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.3/8.12.3) with ESMTP id g546k36U024123; Tue, 4 Jun 2002 02:46:03 -0400 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.3/8.12.3/Submit) with ESMTP id g546k3nZ024120; Tue, 4 Jun 2002 02:46:03 -0400 Date: Tue, 4 Jun 2002 02:46:03 -0400 (EDT) From: "Robert D. Russell" To: pat_thaler@agilent.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00C353C0D@axcs04.cos.agilent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Pat: Replies to all your e-mails in this one response. > The draft > is explicit that one must reply with empty PDUs while the C bit is > set, but it doesn't say anything about processing. One could be > building a buffer of responses to those keys while receiving them. You are, of course, correct -- the draft does not say anything about processing, and I was mistaken to imply that it did. This does, however, bring up another question. When the C bit is 0, the receiver of that PDU does not seem to be required to send replies to the keys it has received up to that point -- it could send another empty PDU, or more likely, it could send new offers of its own. It seems to me that there is nothing in the draft that says when replies to keys should be sent, only that they MUST be sent. > However, there ARE dependencies between operational > parameters that cannot be ignored, such as the one Mike mentioned > -- FirstBurstSize and MaxBurstSize are dependent because of the > requirement in section 11.15: "FirstBurstSize MUST NOT exceed > MaxBurstSize." See my e-mail response to Mike for details > on that dependence. I am also sending a following e-mail > that details 3 other dependencies. > > This is an excellent example of why it is necessary > to state explicitly where (if anywhere) one is required > to send parameters in a specific order. Requiring that > x not exceed y is equivalent to requiring y to be greater > than or equal to x. It doesn't imply the order. In any case, > as long as each side independently ensures that the maximum > value it will accept for FirstBurstSize does not exceed > the maximum value it will accept for MaxBurstSize, it doesn't > matter which is negotiated first. The relationship between > these two values does not imply an order and if we want to > force an order it will need to be done explicitly. You are correct, it does not force an order and I was mistaken to imply that it did. I also believe we do not need or want to force an order. > I don't think there are currently > any cases where order of negotiation is required. You are correct, the dependencies I mentioned exist, but they do not require imposition of any ordering on the negotiation -- my mistake. Bob Russell From owner-ips@ece.cmu.edu Tue Jun 4 11:08:39 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02035 for ; Tue, 4 Jun 2002 11:08:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g54EZaP20846 for ips-outgoing; Tue, 4 Jun 2002 10:35:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (io.iol.unh.edu [132.177.123.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g546kww14791 for ; Tue, 4 Jun 2002 02:46:58 -0400 (EDT) Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.3/8.12.3) with ESMTP id g546kk6U024137; Tue, 4 Jun 2002 02:46:46 -0400 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.3/8.12.3/Submit) with ESMTP id g546kk3S024134; Tue, 4 Jun 2002 02:46:46 -0400 Date: Tue, 4 Jun 2002 02:46:46 -0400 (EDT) From: "Robert D. Russell" To: Martins Krikis cc: ips@ece.cmu.edu Subject: Re: iSCSI: keys/parameter dependence In-Reply-To: <20020603203005.55596.qmail@web13702.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Martins: Comments below on all your e-mails in this one reply. > As to "running and tested", > I don't think many people have encountered split > PDUs in operational stage or FFP Text negotiations > yet. Agreed. > Those, who prefer the "batch-processing" approach > fought for the C-bit, so I would say that it was > introduced in order to allow it. I missed that point earlier. > Regarding ordering, however, it had never been > defined, and I would hate to see it introduced. It was defined before draft 8, but was taken out when that draft came in. Unfortunately, I did not take it out of my memory. I agree that it should not be reintroduced. > In my opinion, it is best to treat all operational > parameters as independent and negotiate them as > such. Agreed. > Just before the commit > (i.e., turning on the T or F bit), one can do an > all-encompassing consistency check and reset > the negotiations if the values violate the laws > imposed on them, or offer some more keys to solve > any such problems, if this is still possible. What you are saying seems to imply that C=0 does NOT require the receiver to reply to keys received up to that point -- it could send another empty PDU, or more likely, it could send new offers of its own. I agree that there is nothing in the draft that says when replies to keys should be sent, only that they MUST be sent (sometime). For example, consider a login negotiation of operational parameters in which the initiator sends a login pdu containing key=value offers and the C bit 0. The target responds with a login response pdu containing key=value offers of its own (offering different keys) but no replies to any of the offers it received in the login. The initiator can then reply to the target's new offers, or it can decide not to reply, and instead send additional new offers or even an empty pdu, (C bit 0 in both alternatives). And now the target could do as it did before, not replying to any offers but either sending back new offers or sending back an empty login response pdu (again C bit 0 in both alternatives). This could go on indefinitely. It would seem that the initiator might try to force replies by setting T=1 to force an end-of-stage transition. However, the target can refuse to make the transition and can reply with T=0 and still no replies to the keys it was offered. This is admittedly a rather far-out example, because presumably both initiator and target want to end the negotiations as soon as possible. My point only is that I do not see anything in the draft that says when the replies to keys have to be sent, only several references that there MUST be a reply to every key offered (eventually). Thoughts, comments? > I could even imagine negotiations > succeeding but laws > (e.g. FirstBurstSize <= MaxBurstSize) not being > broken when sending data... OK, the last thing > might technically be forbidden at the moment > but it is not that unreasonable. It would be > something like > FirstBursSize = min(FirstBurstSize, MaxBurstSize) > done after the negotiation end, and then you can > forget about dependencies. I think it is way > easier than worrying about key ordering every > time something is sent or received. The dependency can be accounted for when generating the reply. For example, reply.FirstBurstSize = min(offer.FirstBurstSize, reply.MaxBurstSize) That way nothing is broken when sending data. > And how many instances of TargetName and TargetAddress > can the SendTargets command provoke from the other > side? I think it can easily overflow the 8192 bytes. Yes it can, but there was already a mechanism in place to deal with this. In fact, this brings up an interesting point. Presumably the C bit has to be used with replies sent to SendTargets (or any other offer that might generate a long reply), since the C bit is in the Text Response PDU used to send these replies. Refering to sections 9.10.2 and 9.10.4: If the target generating a long reply has more text to send than will fit in one PDU, then it should indicate this by setting C = 1. Setting C = 1 also forces F=0, and this in turn forces the Target Transfer Tag to be something other than 0xffffffff. When there is no more text to send, the target sets C = 0 and F = 1 and TTT=0xffffffff in the last text response pdu it sends to the initiator. There is no situation in which C = 1 and F = 1 can occur (since this is explicitly stated in 9.10.2 as being an error), nor is there a situation in which C = 0 and F = 0 should occur (because C = 0 means "I'm done sending stuff" and F = 0 means "I'm not done sending stuff"). Is this the way you interpret the merging of the C bit with the long text reply mechanism? If there is a consensus on this, perhaps the wording in the draft in section 9.10.4 should include the (required) settings of the C bit whenever it mentions the corresponding settings of the F bit and TTT field. > > -- FirstBurstSize and MaxBurstSize are dependent > > because of the > > requirement in section 11.15: "FirstBurstSize MUST > > NOT exceed > > MaxBurstSize." See my e-mail response to Mike for > > details > > on that dependence. > > I saw it. I consider it unbelievably ugly to have to > look at the values in order to figure out ordering > requirements. I prefer ignoring ordering completely > and check for overall consistency before commit. You are correct, the values can be figured out without resorting to an ordering -- my mistake. > Nowhere does it say anything about the order. Agreed. > So, are you really proposing a requirement that > we must look at the values in order to figure out in > which order to send keys? That is so UGLY, it is > hard to believe that this is happening. Please forget I even suggested it. > > The existence of a dependency between OFMarker and > > OFMarkInt, and between > > IFMarker and IFMarkInt, is implied by the statements > > in section A.3.2: > > "When the interval is unacceptable the responder > > answers with > > "Reject". Reject is resetting the marker function > > in the spcified > > direction (Output or Input) to No." > > No it isn't. IMO, it is resetting the marker interval > to its previous value, which is likely the default > value. I believe it's perfectly legal to negotiate > the marker interval but to not turn on marker use, > or to turn on the use but stay with current (default) > values for the interval. If one side can't tolerate > the other's Reject (i.e., can't live with the > default value), it is welcome to bail and try next > time w/o markers. BTW, we could use 0 here as a > special value, meaning that markers are not in use, > then we wouldn't need the boolean keys for > markers. > > > This last sentence should probably be reworded to > > say: > > "A response value of "Reject" to an OFMarkInt > > (IFMarkInt) key resets the > > corresponding OFMarker (IFMarker) key value to > > "No"." > > No, thank you. I would prefer if Reject meant the > same as with the other keys, i.e., negotiation > failed for this key, let's stick with the old > value, or bail if we must. Either the sentence needs to be reworded so it is proper English or it should be taken out of the draft. I take it you are advocating its removal? Bob Russell From owner-ips@ece.cmu.edu Tue Jun 4 11:10:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02118 for ; Tue, 4 Jun 2002 11:10:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g54EV0S20466 for ips-outgoing; Tue, 4 Jun 2002 10:31:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (io.iol.unh.edu [132.177.123.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g546jfw14684 for ; Tue, 4 Jun 2002 02:45:41 -0400 (EDT) Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.3/8.12.3) with ESMTP id g546jS6U024103; Tue, 4 Jun 2002 02:45:28 -0400 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.3/8.12.3/Submit) with ESMTP id g546jS2r024100; Tue, 4 Jun 2002 02:45:28 -0400 Date: Tue, 4 Jun 2002 02:45:28 -0400 (EDT) From: "Robert D. Russell" To: Robert Snively cc: ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence In-Reply-To: <2F37CED150E21640A9C6E75B8BE6AF830A4C8A@hq-ex-4> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Robert: You are, of course, absolutely correct. There is no mention in the current drafts of "order" applied to the processing of keys -- there used to be such an "order" requirement, but that went out when draft 8 came in, and is now ancient history. My apologies to the entire list for mistakenly bringing it back. I do, however, have a question about one small point in what you said: > If you want to order processing, you would > have to send them one at a time without the C bit set. Is this true? When the C bit is not set, there appears to be no requirement in the standard that the receiver is forced to reply to the keys it has received at that time -- it MUST reply to every key eventually, but just having the C bit = 0 does not seem to require it to reply then -- it could send an empty reply PDU, or could offer new keys of its own at that time and delay responding to anything until "everything is on the table". Comments/corrections please. Thanks Bob Russell > Picking up on this in the middle of a thread, I > find the following reply from Bob Russell > interesting: > > > > It's > > > probably irrelevant, since due to the introduction > > > of the C-bit, parameters can be accumulated and > > > processed one "batch" at a time, without any > > > specific order within the "batch" and they will > > > quite likely not be processed PDU by PDU. > > > > I don't see this either. Nowhere does the newly added text > > describing the C-bit say anything about doing away with the > > specific order of the key=value pairs within the "batch". > > Why should it -- even if you don't process PDU by PDU you still > > have to process batch by batch, a batch still has to be scanned > > to find key=value pairs, and the natural way to scan is from the > > beginning of the batch, since the next key starts after the > > delimiter of the previous key in the batch. > > This is also a non-issue. > > Skimming over rev 12, I have not found the word "order" > applied in the context of processing a string of > key=value pairs. While they > must clearly be parsed linearly, it is perfectly reasonable > to process the parsed values in any order, or even in > a vendor-specific order than makes sense to a particular > target. That is why key=value pairs are used in the > first place, so that one does not have to worry about > ordering. In this context, batching would be normal behavior > and out of order processing within a batch would also be > normal behavior. If you want to order processing, you would > have to send them one at a time without the C bit set. From owner-ips@ece.cmu.edu Tue Jun 4 11:12:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02176 for ; Tue, 4 Jun 2002 11:11:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g54EgAl21427 for ips-outgoing; Tue, 4 Jun 2002 10:42:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g54Eg8w21422 for ; Tue, 4 Jun 2002 10:42:08 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id B6E911461; Tue, 4 Jun 2002 08:42:07 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 4A350EE; Tue, 4 Jun 2002 08:42:07 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 04 Jun 2002 08:42:05 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Jun 2002 08:42:05 -0600 Message-ID: <9F8400020EC5D311AF62009027C396160902C427@axcs09.cos.agilent.com> From: kevin_lemay@agilent.com To: rdr@io.iol.unh.edu, Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence Date: Tue, 4 Jun 2002 08:42:03 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Also, Since discovery sessions cannot do IO... then should Initial_R2T, BidiInitialR2T, ImmediateData, MaxOustandingR2T, DataPDUInOrder, DataSequenceInOrder only be valid for normal sessions. Kevin Lemay -----Original Message----- From: Robert D. Russell [mailto:rdr@io.iol.unh.edu] Sent: Tuesday, June 04, 2002 1:14 AM To: Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence Julian: I have found the following dependencies between keys in draft 12-96, and would ask other people on the mailing list to contribute others they have found so we can all be aware of the complete set. There seem to be very few dependencies, which I believe is a credit to a clean, orthogonal design. With a bit of work, we could probably get rid of all the dependencies between the OFMarkInt (IFMarkInt) and OFMarker (IFMarker) keys, perhaps, as suggested by Martins Krikis, by eliminating the OFMarker (IFMarker) key and substituting a default (and response) value of 0 for the OFMarkInt (IFMarkInt) to mean "no markers in that direction". This would also eliminate the need for a "Reject" reply to an OFMarkInt (IFMarkInt) offer. "Meaningful" dependencies (i.e., those that cannot be ignored because they effect operation): 1. Between FirstBurstSize and MaxBurstSize Section 11.15: "FirstBurstSize MUST NOT exceed MaxBurstSize." 2. Between OFMarkInt (IFMarkInt) and OFMarker (IFMarker) Section A.3.2: "When the interval (in an OFMarkInt (IFMarkInt) offer) is unacceptable the responder answers with "Reject". Reject is resetting the marker function (i.e., OFMarker (IFMarker)) in the specified direction (Output or Input) to No." 3. Between SessionType and MaxConnections Section 11.22: "The discovery session implies MaxConnections = 1 and overrides both the default and an explicit setting." "Trivial" dependencies (i.e., those that only allow the option of replying with "Irrelevant" instead of a normally selected value, and therefore can be ignored). 1. Between FirstBurstSize, InitialR2T, and ImmediateData The table in section 11.12 implies that the combination InitialR2T=Yes and ImmediateData=No allows the response FirstBurstSize=Irrelevant. 2. Between OFMarker (IFMarker) and OFMarkInt (IFMarkInt). Sections A.3.1 and A.3.2 imply that OFMarker=No (IFMarker=No) allows the response OFMarkInt=Irrelevant (IFMarkInt=Irrelevant). Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Tue Jun 4 12:19:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04536 for ; Tue, 4 Jun 2002 12:19:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g54G89o28600 for ips-outgoing; Tue, 4 Jun 2002 12:08:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g54G86w28594 for ; Tue, 4 Jun 2002 12:08:06 -0400 (EDT) Received: from hq-ex-c3.brocade.com (hq-ex-c3 [192.168.126.211]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id JAA16137; Tue, 4 Jun 2002 09:07:43 -0700 (PDT) Received: by hq-ex-c3.brocade.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Jun 2002 09:08:10 -0700 Message-ID: <2F37CED150E21640A9C6E75B8BE6AF830A4C94@hq-ex-4> From: Robert Snively To: "'Robert D. Russell'" , Robert Snively Cc: ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence Date: Tue, 4 Jun 2002 09:07:37 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk I stand corrected. If you want to order batches, you must not only transmit the keys that you want to batch, but you must also not transmit another batch of keys until you have received the replies for the outstanding batch. You must also do this in a manner consistent with the stage of login or post-login operation that is being performed, as specified in 4.3. I haven't studied all aspects of this carefully, but I would expect that the processing must proceed on a batch by batch basis, since it is never clear when the Final-Response exchange will be requested and the target must have completed whatever negotiation is going on with respect to previous batch exchanges. I would not expect the target to be allowed to hang around doing nothing until Final-Response exchanges were requested. This seems to be what section 4.4 says, at least for post-login activities. I was a little surprised to see that post-login negotiations of a parameter a second time without an intervening reset constitute a protocol error. Some of the values, notably those duplicating MODE SENSE/SELECT parameters, have traditionally been renegotiable as desired by the SCSI device without an intervening reset, and I would expect that capability to have been mapped into the key=value negotations. Bob > > Is this true? When the C bit is not set, there appears to be > no requirement in the standard that the receiver is forced to > reply to the keys it has received at that time -- it MUST reply > to every key eventually, but just having the C bit = 0 does > not seem to require it to reply then -- it could send an empty > reply PDU, or could offer new keys of its own at that time > and delay responding to anything until "everything is on the > table". Comments/corrections please. From owner-ips@ece.cmu.edu Tue Jun 4 12:20:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04553 for ; Tue, 4 Jun 2002 12:20:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g54FdD726166 for ips-outgoing; Tue, 4 Jun 2002 11:39:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g54Fd9w26153 for ; Tue, 4 Jun 2002 11:39:10 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g54EbSu28828; Tue, 4 Jun 2002 10:37:28 -0400 Message-ID: <3CFCDF0A.43B880C@splentec.com> Date: Tue, 04 Jun 2002 11:38:50 -0400 From: Luben Tuikov Reply-To: iSCSI , Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Julian Satran CC: "Robert D. Russell" , ips@ece.cmu.edu Subject: Re: null termination of keys References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, I agree with Robert. Robert's point of view (as any academic in the computer/math sciences) is CONSISTENCY. Which is, btw, a _good_ thing! The reason is simple: a key=value pair is an entity starting with non-NUL char (cf. def. of key) and ending with NUL (0x0) char. With such a simple definition, parsing the keys is a walk in the park. In the draft we are lacking clear-cut, precise definition of concepts, objects, their interactions and algorithmic steps. If we have those set, then finishing and/or changing iSCSI will be extremely easy. Take for example the concepts of ``immediate data'' and ``unsolicied data'' and their interactions -- what a spaghetti. If we define those properly, then we can express many constraints simply, such as ``A + B <= FirstBurstSize'' where A is blah-blah, and B is blah-blah; ``TargetQueueSize=Max... - blah + 1'' and so on. Many of us, I'm sure, are reading the draft and re-writing it, in terms of definitions like the above, in order to clearly understand it... and you know what happens then... _inconsistencies_ are found. This is why, for example, very recently it was decided that 4.1 should contain definitions in it... even though it was prompted for a while back. BTW, I'm surprised that only _one_ person objected to such a _BIG_ change(s) in the draft. Considering from personal experience and scaling properly, we should've seen at least 100 people complaining... -- Luben P.S. The above definition of a key=value pair would also solve by default the problem with more than one NUL char, rather than you explicitly having to put more text in the draft. Of course putting more than one NUL char would be frowned upon but a proper parser following the above rule would have no problem with it... But I digress... Julian Satran wrote: > > Bob, > > The reason it was put in is to to enable "parsing" without the C bit. > With key spanning PDUs before having the C bit the sender had to avoid sending a 0 if this was the > last byte of the PDU as he had no other means of signaling continuation. A 0 at the end of a PDU > meant end-of-LTDS. > > Now that we have the C bit we can live with or without having a 0 at the end of the last PDU. > Let's hear some more voices. > > Regards, > Julo > > "Robert D. Russell" > To: Julian Satran/Haifa/IBM@IBMIL > 06/04/2002 09:48 AM cc: ips@ece.cmu.edu > Please respond to "Robert D. Russell" Subject: Re: null termination of keys > > > > Julian: > > Draft 12-96, section 4.1 defines an LTDS and then says: > > "Every key=value pair, excluding the last or only pair in a LTDS, > MUST be followed by one null (0x00) delimiter; the last or only pair > in a LTDS ends at the LTDS end." > > This brings us back to where we were in draft 6 -- that key=value pairs > are separated by nulls, not terminated by nulls. If I remember > correctly, one of the primary reasons that this was changed going to draft > 7 is that implementations prefer to treat each key=value pair as one string, > and in C and C++, strings are null terminated. > > I do not believe this change is in any way necessary for the LTDS or > C-bit mechanism, and would request that it be put back to the way it has > been from draft 7 through draft 12-94: > > "Every key=value pair, including the last or only pair in a LTDS, > MUST be followed by one null (0x00) delimiter." > > Thanks > > Bob Russell From owner-ips@ece.cmu.edu Tue Jun 4 13:31:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06977 for ; Tue, 4 Jun 2002 13:31:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g54Gq0S02124 for ips-outgoing; Tue, 4 Jun 2002 12:52:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g54Gpsw02113 for ; Tue, 4 Jun 2002 12:51:54 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id BEB5930706; Tue, 4 Jun 2002 12:51:53 -0400 (EDT) Date: Tue, 4 Jun 2002 09:49:52 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Julian Satran Cc: "Robert D. Russell" , Subject: Re: null termination of keys In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 4 Jun 2002, Julian Satran wrote: > Bob, > > The reason it was put in is to to enable "parsing" without the C bit. > With key spanning PDUs before having the C bit the sender had to avoid > sending a 0 if this was the last byte of the PDU as he had no other means > of signaling continuation. A 0 at the end of a PDU meant end-of-LTDS. > > Now that we have the C bit we can live with or without having a 0 at the > end of the last PDU. > Let's hear some more voices. As a C/C++ programmer, I really like the idea of having 0s at the end of a key/value pair. I agree with Bob that having key/value pairs terminated by NULs is easier. Take care, Bill From owner-ips@ece.cmu.edu Tue Jun 4 13:32:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06990 for ; Tue, 4 Jun 2002 13:32:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g54H78n03291 for ips-outgoing; Tue, 4 Jun 2002 13:07:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g54H74w03278 for ; Tue, 4 Jun 2002 13:07:04 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g54H6vvk024200; Tue, 4 Jun 2002 19:06:57 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g54H6uN31228; Tue, 4 Jun 2002 19:06:56 +0200 To: "Robert D. Russell" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: keys/parameter dependence X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 4 Jun 2002 20:06:55 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 04/06/2002 20:06:56, Serialize complete at 04/06/2002 20:06:56 Content-Type: multipart/alternative; boundary="=_alternative 005D5E07C2256BCE_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005D5E07C2256BCE_= Content-Type: text/plain; charset="us-ascii" Bob, Thanks. That matches my list although I have a somewhat different approach to some of them. 1. FirstBurstSize - MaxburstSize is not exactly a dependency as it means only that the negotiated values have to relate to each other at commit time or you have negotiation failure (login failure) 2 & 3 as above. I think tact we may want to say somewhere that value consistency to the rules is to be determined a the end of the negotiation. Thanks, Julo "Robert D. Russell" 06/04/2002 11:13 AM Please respond to "Robert D. Russell" To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence Julian: I have found the following dependencies between keys in draft 12-96, and would ask other people on the mailing list to contribute others they have found so we can all be aware of the complete set. There seem to be very few dependencies, which I believe is a credit to a clean, orthogonal design. With a bit of work, we could probably get rid of all the dependencies between the OFMarkInt (IFMarkInt) and OFMarker (IFMarker) keys, perhaps, as suggested by Martins Krikis, by eliminating the OFMarker (IFMarker) key and substituting a default (and response) value of 0 for the OFMarkInt (IFMarkInt) to mean "no markers in that direction". This would also eliminate the need for a "Reject" reply to an OFMarkInt (IFMarkInt) offer. "Meaningful" dependencies (i.e., those that cannot be ignored because they effect operation): 1. Between FirstBurstSize and MaxBurstSize Section 11.15: "FirstBurstSize MUST NOT exceed MaxBurstSize." 2. Between OFMarkInt (IFMarkInt) and OFMarker (IFMarker) Section A.3.2: "When the interval (in an OFMarkInt (IFMarkInt) offer) is unacceptable the responder answers with "Reject". Reject is resetting the marker function (i.e., OFMarker (IFMarker)) in the specified direction (Output or Input) to No." 3. Between SessionType and MaxConnections Section 11.22: "The discovery session implies MaxConnections = 1 and overrides both the default and an explicit setting." "Trivial" dependencies (i.e., those that only allow the option of replying with "Irrelevant" instead of a normally selected value, and therefore can be ignored). 1. Between FirstBurstSize, InitialR2T, and ImmediateData The table in section 11.12 implies that the combination InitialR2T=Yes and ImmediateData=No allows the response FirstBurstSize=Irrelevant. 2. Between OFMarker (IFMarker) and OFMarkInt (IFMarkInt). Sections A.3.1 and A.3.2 imply that OFMarker=No (IFMarker=No) allows the response OFMarkInt=Irrelevant (IFMarkInt=Irrelevant). Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 --=_alternative 005D5E07C2256BCE_= Content-Type: text/html; charset="us-ascii"
Bob,

Thanks.  That matches my list although I have a somewhat different approach to some of them.

1. FirstBurstSize - MaxburstSize is not exactly a dependency as it means only that the negotiated values have to relate to each other
at commit time or you have negotiation failure (login failure)

2 & 3 as above.

I think tact we may want to say somewhere that value consistency to the rules is to be determined a the end of the negotiation.

Thanks,
Julo



"Robert D. Russell" <rdr@io.iol.unh.edu>

06/04/2002 11:13 AM
Please respond to "Robert D. Russell"

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: keys/parameter dependence

       


Julian:

I have found the following dependencies between keys in draft 12-96,
and would ask other people on the mailing list to contribute others
they have found so we can all be aware of the complete set.

There seem to be very few dependencies, which I believe is a credit
to a clean, orthogonal design.

With a bit of work, we could probably get rid of all the dependencies
between the OFMarkInt (IFMarkInt) and OFMarker (IFMarker) keys, perhaps,
as suggested by Martins Krikis, by eliminating the OFMarker (IFMarker)
key and substituting a default (and response) value of 0 for the
OFMarkInt (IFMarkInt) to mean "no markers in that direction".

This would also eliminate the need for a "Reject" reply to an OFMarkInt
(IFMarkInt) offer.


"Meaningful" dependencies (i.e., those that cannot be ignored because
they effect operation):

1.  Between FirstBurstSize and MaxBurstSize
     Section 11.15: "FirstBurstSize MUST NOT exceed MaxBurstSize."

2.  Between OFMarkInt (IFMarkInt) and OFMarker (IFMarker)
     Section A.3.2: "When the interval (in an OFMarkInt (IFMarkInt)
     offer) is unacceptable the responder answers with "Reject".
     Reject is resetting the marker function (i.e., OFMarker
     (IFMarker)) in the specified direction (Output or Input) to No."

3.  Between SessionType and MaxConnections
     Section 11.22: "The discovery session implies MaxConnections = 1
     and overrides both the default and an explicit setting."


"Trivial" dependencies (i.e., those that only allow the option of
replying with "Irrelevant" instead of a normally selected value, and
therefore can be ignored).

1.  Between FirstBurstSize, InitialR2T, and ImmediateData
     The table in section 11.12 implies that the combination
     InitialR2T=Yes and ImmediateData=No allows the response
     FirstBurstSize=Irrelevant.

2.  Between OFMarker (IFMarker) and OFMarkInt (IFMarkInt).
     Sections A.3.1 and A.3.2 imply that OFMarker=No (IFMarker=No)
     allows the response OFMarkInt=Irrelevant (IFMarkInt=Irrelevant).



Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774

--=_alternative 005D5E07C2256BCE_=-- From owner-ips@ece.cmu.edu Tue Jun 4 13:32:29 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07004 for ; Tue, 4 Jun 2002 13:32:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g54HJYo04392 for ips-outgoing; Tue, 4 Jun 2002 13:19:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g54HJSw04373 for ; Tue, 4 Jun 2002 13:19:28 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g54HJKvk054148; Tue, 4 Jun 2002 19:19:20 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g54HJJs20734; Tue, 4 Jun 2002 19:19:20 +0200 To: kevin_lemay@agilent.com Cc: ips@ece.cmu.edu, rdr@io.iol.unh.edu MIME-Version: 1.0 Subject: RE: iSCSI: keys/parameter dependence X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 4 Jun 2002 20:19:18 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 04/06/2002 20:19:20, Serialize complete at 04/06/2002 20:19:20 Content-Type: multipart/alternative; boundary="=_alternative 005ECB04C2256BCE_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005ECB04C2256BCE_= Content-Type: text/plain; charset="us-ascii" Probably - but if you are tolerant you can answer them with Irrelevant. Julo kevin_lemay@agilent.com 06/04/2002 05:42 PM Please respond to kevin_lemay To: rdr@io.iol.unh.edu, Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence Also, Since discovery sessions cannot do IO... then should Initial_R2T, BidiInitialR2T, ImmediateData, MaxOustandingR2T, DataPDUInOrder, DataSequenceInOrder only be valid for normal sessions. Kevin Lemay -----Original Message----- From: Robert D. Russell [mailto:rdr@io.iol.unh.edu] Sent: Tuesday, June 04, 2002 1:14 AM To: Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence Julian: I have found the following dependencies between keys in draft 12-96, and would ask other people on the mailing list to contribute others they have found so we can all be aware of the complete set. There seem to be very few dependencies, which I believe is a credit to a clean, orthogonal design. With a bit of work, we could probably get rid of all the dependencies between the OFMarkInt (IFMarkInt) and OFMarker (IFMarker) keys, perhaps, as suggested by Martins Krikis, by eliminating the OFMarker (IFMarker) key and substituting a default (and response) value of 0 for the OFMarkInt (IFMarkInt) to mean "no markers in that direction". This would also eliminate the need for a "Reject" reply to an OFMarkInt (IFMarkInt) offer. "Meaningful" dependencies (i.e., those that cannot be ignored because they effect operation): 1. Between FirstBurstSize and MaxBurstSize Section 11.15: "FirstBurstSize MUST NOT exceed MaxBurstSize." 2. Between OFMarkInt (IFMarkInt) and OFMarker (IFMarker) Section A.3.2: "When the interval (in an OFMarkInt (IFMarkInt) offer) is unacceptable the responder answers with "Reject". Reject is resetting the marker function (i.e., OFMarker (IFMarker)) in the specified direction (Output or Input) to No." 3. Between SessionType and MaxConnections Section 11.22: "The discovery session implies MaxConnections = 1 and overrides both the default and an explicit setting." "Trivial" dependencies (i.e., those that only allow the option of replying with "Irrelevant" instead of a normally selected value, and therefore can be ignored). 1. Between FirstBurstSize, InitialR2T, and ImmediateData The table in section 11.12 implies that the combination InitialR2T=Yes and ImmediateData=No allows the response FirstBurstSize=Irrelevant. 2. Between OFMarker (IFMarker) and OFMarkInt (IFMarkInt). Sections A.3.1 and A.3.2 imply that OFMarker=No (IFMarker=No) allows the response OFMarkInt=Irrelevant (IFMarkInt=Irrelevant). Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 --=_alternative 005ECB04C2256BCE_= Content-Type: text/html; charset="us-ascii"
Probably - but if you are tolerant you can answer them with Irrelevant.

Julo


kevin_lemay@agilent.com

06/04/2002 05:42 PM
Please respond to kevin_lemay

       
        To:        rdr@io.iol.unh.edu, Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: keys/parameter dependence

       


Also,

Since discovery sessions cannot do IO... then should Initial_R2T,
BidiInitialR2T, ImmediateData, MaxOustandingR2T, DataPDUInOrder,
DataSequenceInOrder only be valid for normal sessions.

Kevin Lemay

-----Original Message-----
From: Robert D. Russell [mailto:rdr@io.iol.unh.edu]
Sent: Tuesday, June 04, 2002 1:14 AM
To: Julian Satran
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: keys/parameter dependence


Julian:

I have found the following dependencies between keys in draft 12-96,
and would ask other people on the mailing list to contribute others
they have found so we can all be aware of the complete set.

There seem to be very few dependencies, which I believe is a credit
to a clean, orthogonal design.

With a bit of work, we could probably get rid of all the dependencies
between the OFMarkInt (IFMarkInt) and OFMarker (IFMarker) keys, perhaps,
as suggested by Martins Krikis, by eliminating the OFMarker (IFMarker)
key and substituting a default (and response) value of 0 for the
OFMarkInt (IFMarkInt) to mean "no markers in that direction".

This would also eliminate the need for a "Reject" reply to an OFMarkInt
(IFMarkInt) offer.


"Meaningful" dependencies (i.e., those that cannot be ignored because
they effect operation):

1.  Between FirstBurstSize and MaxBurstSize
     Section 11.15: "FirstBurstSize MUST NOT exceed MaxBurstSize."

2.  Between OFMarkInt (IFMarkInt) and OFMarker (IFMarker)
     Section A.3.2: "When the interval (in an OFMarkInt (IFMarkInt)
     offer) is unacceptable the responder answers with "Reject".
     Reject is resetting the marker function (i.e., OFMarker
     (IFMarker)) in the specified direction (Output or Input) to No."

3.  Between SessionType and MaxConnections
     Section 11.22: "The discovery session implies MaxConnections = 1
     and overrides both the default and an explicit setting."


"Trivial" dependencies (i.e., those that only allow the option of
replying with "Irrelevant" instead of a normally selected value, and
therefore can be ignored).

1.  Between FirstBurstSize, InitialR2T, and ImmediateData
     The table in section 11.12 implies that the combination
     InitialR2T=Yes and ImmediateData=No allows the response
     FirstBurstSize=Irrelevant.

2.  Between OFMarker (IFMarker) and OFMarkInt (IFMarkInt).
     Sections A.3.1 and A.3.2 imply that OFMarker=No (IFMarker=No)
     allows the response OFMarkInt=Irrelevant (IFMarkInt=Irrelevant).



Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774

--=_alternative 005ECB04C2256BCE_=-- From owner-ips@ece.cmu.edu Tue Jun 4 13:36:11 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07097 for ; Tue, 4 Jun 2002 13:36:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g54HJWU04389 for ips-outgoing; Tue, 4 Jun 2002 13:19:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g54HJRw04367; Tue, 4 Jun 2002 13:19:27 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g54HJLUN011018; Tue, 4 Jun 2002 19:19:21 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g54HJKN45582; Tue, 4 Jun 2002 19:19:20 +0200 To: "Robert D. Russell" Cc: ips@ece.cmu.edu, Martins Krikis , owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: keys/parameter dependence X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 4 Jun 2002 20:19:18 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 04/06/2002 20:19:20, Serialize complete at 04/06/2002 20:19:20 Content-Type: multipart/alternative; boundary="=_alternative 005E9192C2256BCE_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005E9192C2256BCE_= Content-Type: text/plain; charset="us-ascii" I have one comment regarding to batching. Batching is not related to the C-bit. C-bit is meant to simplify spanning over PDU boundaries. Batching can be done with the previous structure as well - there is a lot you can do with an 8k block! Julo "Robert D. Russell" Sent by: owner-ips@ece.cmu.edu 06/04/2002 09:46 AM Please respond to "Robert D. Russell" To: Martins Krikis cc: ips@ece.cmu.edu Subject: Re: iSCSI: keys/parameter dependence Martins: Comments below on all your e-mails in this one reply. > As to "running and tested", > I don't think many people have encountered split > PDUs in operational stage or FFP Text negotiations > yet. Agreed. > Those, who prefer the "batch-processing" approach > fought for the C-bit, so I would say that it was > introduced in order to allow it. I missed that point earlier. > Regarding ordering, however, it had never been > defined, and I would hate to see it introduced. It was defined before draft 8, but was taken out when that draft came in. Unfortunately, I did not take it out of my memory. I agree that it should not be reintroduced. > In my opinion, it is best to treat all operational > parameters as independent and negotiate them as > such. Agreed. > Just before the commit > (i.e., turning on the T or F bit), one can do an > all-encompassing consistency check and reset > the negotiations if the values violate the laws > imposed on them, or offer some more keys to solve > any such problems, if this is still possible. What you are saying seems to imply that C=0 does NOT require the receiver to reply to keys received up to that point -- it could send another empty PDU, or more likely, it could send new offers of its own. I agree that there is nothing in the draft that says when replies to keys should be sent, only that they MUST be sent (sometime). For example, consider a login negotiation of operational parameters in which the initiator sends a login pdu containing key=value offers and the C bit 0. The target responds with a login response pdu containing key=value offers of its own (offering different keys) but no replies to any of the offers it received in the login. The initiator can then reply to the target's new offers, or it can decide not to reply, and instead send additional new offers or even an empty pdu, (C bit 0 in both alternatives). And now the target could do as it did before, not replying to any offers but either sending back new offers or sending back an empty login response pdu (again C bit 0 in both alternatives). This could go on indefinitely. It would seem that the initiator might try to force replies by setting T=1 to force an end-of-stage transition. However, the target can refuse to make the transition and can reply with T=0 and still no replies to the keys it was offered. This is admittedly a rather far-out example, because presumably both initiator and target want to end the negotiations as soon as possible. My point only is that I do not see anything in the draft that says when the replies to keys have to be sent, only several references that there MUST be a reply to every key offered (eventually). Thoughts, comments? > I could even imagine negotiations > succeeding but laws > (e.g. FirstBurstSize <= MaxBurstSize) not being > broken when sending data... OK, the last thing > might technically be forbidden at the moment > but it is not that unreasonable. It would be > something like > FirstBursSize = min(FirstBurstSize, MaxBurstSize) > done after the negotiation end, and then you can > forget about dependencies. I think it is way > easier than worrying about key ordering every > time something is sent or received. The dependency can be accounted for when generating the reply. For example, reply.FirstBurstSize = min(offer.FirstBurstSize, reply.MaxBurstSize) That way nothing is broken when sending data. > And how many instances of TargetName and TargetAddress > can the SendTargets command provoke from the other > side? I think it can easily overflow the 8192 bytes. Yes it can, but there was already a mechanism in place to deal with this. In fact, this brings up an interesting point. Presumably the C bit has to be used with replies sent to SendTargets (or any other offer that might generate a long reply), since the C bit is in the Text Response PDU used to send these replies. Refering to sections 9.10.2 and 9.10.4: If the target generating a long reply has more text to send than will fit in one PDU, then it should indicate this by setting C = 1. Setting C = 1 also forces F=0, and this in turn forces the Target Transfer Tag to be something other than 0xffffffff. When there is no more text to send, the target sets C = 0 and F = 1 and TTT=0xffffffff in the last text response pdu it sends to the initiator. There is no situation in which C = 1 and F = 1 can occur (since this is explicitly stated in 9.10.2 as being an error), nor is there a situation in which C = 0 and F = 0 should occur (because C = 0 means "I'm done sending stuff" and F = 0 means "I'm not done sending stuff"). Is this the way you interpret the merging of the C bit with the long text reply mechanism? If there is a consensus on this, perhaps the wording in the draft in section 9.10.4 should include the (required) settings of the C bit whenever it mentions the corresponding settings of the F bit and TTT field. > > -- FirstBurstSize and MaxBurstSize are dependent > > because of the > > requirement in section 11.15: "FirstBurstSize MUST > > NOT exceed > > MaxBurstSize." See my e-mail response to Mike for > > details > > on that dependence. > > I saw it. I consider it unbelievably ugly to have to > look at the values in order to figure out ordering > requirements. I prefer ignoring ordering completely > and check for overall consistency before commit. You are correct, the values can be figured out without resorting to an ordering -- my mistake. > Nowhere does it say anything about the order. Agreed. > So, are you really proposing a requirement that > we must look at the values in order to figure out in > which order to send keys? That is so UGLY, it is > hard to believe that this is happening. Please forget I even suggested it. > > The existence of a dependency between OFMarker and > > OFMarkInt, and between > > IFMarker and IFMarkInt, is implied by the statements > > in section A.3.2: > > "When the interval is unacceptable the responder > > answers with > > "Reject". Reject is resetting the marker function > > in the spcified > > direction (Output or Input) to No." > > No it isn't. IMO, it is resetting the marker interval > to its previous value, which is likely the default > value. I believe it's perfectly legal to negotiate > the marker interval but to not turn on marker use, > or to turn on the use but stay with current (default) > values for the interval. If one side can't tolerate > the other's Reject (i.e., can't live with the > default value), it is welcome to bail and try next > time w/o markers. BTW, we could use 0 here as a > special value, meaning that markers are not in use, > then we wouldn't need the boolean keys for > markers. > > > This last sentence should probably be reworded to > > say: > > "A response value of "Reject" to an OFMarkInt > > (IFMarkInt) key resets the > > corresponding OFMarker (IFMarker) key value to > > "No"." > > No, thank you. I would prefer if Reject meant the > same as with the other keys, i.e., negotiation > failed for this key, let's stick with the old > value, or bail if we must. Either the sentence needs to be reworded so it is proper English or it should be taken out of the draft. I take it you are advocating its removal? Bob Russell --=_alternative 005E9192C2256BCE_= Content-Type: text/html; charset="us-ascii"
I have one comment regarding to batching.

Batching is not related to the C-bit. C-bit is meant to simplify spanning over PDU boundaries.
Batching can be done with the previous structure as well - there is a lot you can do with an 8k block!

Julo


"Robert D. Russell" <rdr@io.iol.unh.edu>
Sent by: owner-ips@ece.cmu.edu

06/04/2002 09:46 AM
Please respond to "Robert D. Russell"

       
        To:        Martins Krikis <mkrikis@yahoo.com>
        cc:        ips@ece.cmu.edu
        Subject:        Re: iSCSI: keys/parameter dependence

       


Martins:

Comments below on all your e-mails in this one reply.

> As to "running and tested",
> I don't think many people have encountered split
> PDUs in operational stage or FFP Text negotiations
> yet.

Agreed.


> Those, who prefer the "batch-processing" approach
> fought for the C-bit, so I would say that it was
> introduced in order to allow it.

I missed that point earlier.


> Regarding ordering, however, it had never been
> defined, and I would hate to see it introduced.

It was defined before draft 8, but was taken out when that
draft came in.  Unfortunately, I did not take it out of
my memory.  I agree that it should not be reintroduced.


> In my opinion, it is best to treat all operational
> parameters as independent and negotiate them as
> such.

Agreed.


> Just before the commit
> (i.e., turning on the T or F bit), one can do an
> all-encompassing consistency check and reset
> the negotiations if the values violate the laws
> imposed on them, or offer some more keys to solve
> any such problems, if this is still possible.


What you are saying seems to imply that C=0 does NOT
require the receiver to reply to keys received up to that point
-- it could send another empty PDU, or more likely, it could send
new offers of its own.  I agree that there is nothing in the draft
that says when replies to keys should be sent, only that they
MUST be sent (sometime).

For example, consider a login negotiation of operational parameters
in which the initiator sends a login pdu containing key=value offers
and the C bit 0.  The target responds with a login response pdu
containing key=value offers of its own (offering different keys)
but no replies to any of the offers it received in the login.
The initiator can then reply to the target's new offers, or it
can decide not to reply, and instead send additional new offers
or even an empty pdu, (C bit 0 in both alternatives).  And now
the target could do as it did before, not replying to any offers
but either sending back new offers or sending back an empty login
response pdu (again C bit 0 in both alternatives).  This could go
on indefinitely.

It would seem that the initiator might try to force replies by
setting T=1 to force an end-of-stage transition.  However, the target
can refuse to make the transition and can reply with T=0 and still
no replies to the keys it was offered.

This is admittedly a rather far-out example, because presumably both
initiator and target want to end the negotiations as soon as possible.
My point only is that I do not see anything in the draft that says
when the replies to keys have to be sent, only several references
that there MUST be a reply to every key offered (eventually).

Thoughts, comments?


> I could even imagine negotiations
> succeeding but laws
> (e.g. FirstBurstSize <= MaxBurstSize) not being
> broken when sending data... OK, the last thing
> might technically be forbidden at the moment
> but it is not that unreasonable. It would be
> something like
> FirstBursSize = min(FirstBurstSize, MaxBurstSize)
> done after the negotiation end, and then you can
> forget about dependencies. I think it is way
> easier than worrying about key ordering every
> time something is sent or received.

The dependency can be accounted for when generating the reply.
For example,

reply.FirstBurstSize = min(offer.FirstBurstSize, reply.MaxBurstSize)

That way nothing is broken when sending data.


> And how many instances of TargetName and TargetAddress
> can the SendTargets command provoke from the other
> side? I think it can easily overflow the 8192 bytes.

Yes it can, but there was already a mechanism in place to deal
with this.  In fact, this brings up an interesting point.
Presumably the C bit has to be used with replies sent to
SendTargets (or any other offer that might generate a long reply),
since the C bit is in the Text Response PDU used to send these replies.

Refering to sections 9.10.2 and 9.10.4:  If the target generating a
long reply has more text to send than will fit in one PDU, then it
should indicate this by setting C = 1.  Setting C = 1 also forces F=0,
and this in turn forces the Target Transfer Tag to be something
other than 0xffffffff.  When there is no more text to send,
the target sets C = 0 and F = 1 and TTT=0xffffffff in the last
text response pdu it sends to the initiator.  There is no
situation in which C = 1 and F = 1 can occur (since this is
explicitly stated in 9.10.2 as being an error), nor is there a
situation in which C = 0 and F = 0 should occur (because C = 0
means "I'm done sending stuff" and F = 0 means "I'm not done sending
stuff").

Is this the way you interpret the merging of the C bit with the
long text reply mechanism?  If there is a consensus on this,
perhaps the wording in the draft in section 9.10.4 should include
the (required) settings of the C bit whenever it mentions the
corresponding settings of the F bit and TTT field.


> > -- FirstBurstSize and MaxBurstSize are dependent
> > because of the
> > requirement in section 11.15: "FirstBurstSize MUST
> > NOT exceed
> > MaxBurstSize."  See my e-mail response to Mike for
> > details
> > on that dependence.
>
> I saw it. I consider it unbelievably ugly to have to
> look at the values in order to figure out ordering
> requirements. I prefer ignoring ordering completely
> and check for overall consistency before commit.

You are correct, the values can be figured out without
resorting to an ordering -- my mistake.


> Nowhere does it say anything about the order.

Agreed.


> So, are you really proposing a requirement that
> we must look at the values in order to figure out in
> which order to send keys? That is so UGLY, it is
> hard to believe that this is happening.

Please forget I even suggested it.


> > The existence of a dependency between OFMarker and
> > OFMarkInt, and between
> > IFMarker and IFMarkInt, is implied by the statements
> > in section A.3.2:
> > "When the interval is unacceptable the responder
> > answers with
> > "Reject".  Reject is resetting the marker function
> > in the spcified
> > direction (Output or Input) to No."
>
> No it isn't. IMO, it is resetting the marker interval
> to its previous value, which is likely the default
> value. I believe it's perfectly legal to negotiate
> the marker interval but to not turn on marker use,
> or to turn on the use but stay with current (default)
> values for the interval. If one side can't  tolerate
> the other's  Reject (i.e., can't live with the
> default value), it is welcome to bail and try next
> time w/o markers. BTW, we could use 0 here as a
> special value, meaning that markers are not in use,
> then we wouldn't need the boolean keys for
> markers.
>
> > This last sentence should probably be reworded to
> > say:
> > "A response value of "Reject" to an OFMarkInt
> > (IFMarkInt) key resets the
> > corresponding OFMarker (IFMarker) key value to
> > "No"."
>
> No, thank you. I would prefer if Reject meant the
> same as with the other keys, i.e., negotiation
> failed for this key, let's stick with the old
> value, or bail if we must.

Either the sentence needs to be reworded so it is proper English
or it should be taken out of the draft.  I take it you are advocating
its removal?

Bob Russell

--=_alternative 005E9192C2256BCE_=-- From owner-ips@ece.cmu.edu Tue Jun 4 14:12:23 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08523 for ; Tue, 4 Jun 2002 14:12:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g54HVOV05392 for ips-outgoing; Tue, 4 Jun 2002 13:31:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g54HVKw05382 for ; Tue, 4 Jun 2002 13:31:20 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g54HV9UN024902; Tue, 4 Jun 2002 19:31:14 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g54HV5s20492; Tue, 4 Jun 2002 19:31:05 +0200 To: iSCSI , Luben Tuikov MIME-Version: 1.0 Subject: Re: null termination of keys X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 4 Jun 2002 20:31:04 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 04/06/2002 20:31:09, Serialize complete at 04/06/2002 20:31:09 Content-Type: multipart/alternative; boundary="=_alternative 005F53D5C2256BCE_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005F53D5C2256BCE_= Content-Type: text/plain; charset="us-ascii" Luben, You may be interested in pursuing a "Formal-iSCSI" and pass it through IETF as iSCSI-2. Many of us although appreciate the beauty of formalism want this standard out and used by people to build equipment. In retrospect - the informal nature of almost all TCP/IP was not such a bad thing. Julo Luben Tuikov Sent by: luben@ns.splentec.com 06/04/2002 06:38 PM Please respond to iSCSI; Please respond to Luben Tuikov To: Julian Satran/Haifa/IBM@IBMIL cc: "Robert D. Russell" , ips@ece.cmu.edu Subject: Re: null termination of keys Julian, I agree with Robert. Robert's point of view (as any academic in the computer/math sciences) is CONSISTENCY. Which is, btw, a _good_ thing! The reason is simple: a key=value pair is an entity starting with non-NUL char (cf. def. of key) and ending with NUL (0x0) char. With such a simple definition, parsing the keys is a walk in the park. In the draft we are lacking clear-cut, precise definition of concepts, objects, their interactions and algorithmic steps. If we have those set, then finishing and/or changing iSCSI will be extremely easy. Take for example the concepts of ``immediate data'' and ``unsolicied data'' and their interactions -- what a spaghetti. If we define those properly, then we can express many constraints simply, such as ``A + B <= FirstBurstSize'' where A is blah-blah, and B is blah-blah; ``TargetQueueSize=Max... - blah + 1'' and so on. Many of us, I'm sure, are reading the draft and re-writing it, in terms of definitions like the above, in order to clearly understand it... and you know what happens then... _inconsistencies_ are found. This is why, for example, very recently it was decided that 4.1 should contain definitions in it... even though it was prompted for a while back. BTW, I'm surprised that only _one_ person objected to such a _BIG_ change(s) in the draft. Considering from personal experience and scaling properly, we should've seen at least 100 people complaining... -- Luben P.S. The above definition of a key=value pair would also solve by default the problem with more than one NUL char, rather than you explicitly having to put more text in the draft. Of course putting more than one NUL char would be frowned upon but a proper parser following the above rule would have no problem with it... But I digress... Julian Satran wrote: > > Bob, > > The reason it was put in is to to enable "parsing" without the C bit. > With key spanning PDUs before having the C bit the sender had to avoid sending a 0 if this was the > last byte of the PDU as he had no other means of signaling continuation. A 0 at the end of a PDU > meant end-of-LTDS. > > Now that we have the C bit we can live with or without having a 0 at the end of the last PDU. > Let's hear some more voices. > > Regards, > Julo > > "Robert D. Russell" > To: Julian Satran/Haifa/IBM@IBMIL > 06/04/2002 09:48 AM cc: ips@ece.cmu.edu > Please respond to "Robert D. Russell" Subject: Re: null termination of keys > > > > Julian: > > Draft 12-96, section 4.1 defines an LTDS and then says: > > "Every key=value pair, excluding the last or only pair in a LTDS, > MUST be followed by one null (0x00) delimiter; the last or only pair > in a LTDS ends at the LTDS end." > > This brings us back to where we were in draft 6 -- that key=value pairs > are separated by nulls, not terminated by nulls. If I remember > correctly, one of the primary reasons that this was changed going to draft > 7 is that implementations prefer to treat each key=value pair as one string, > and in C and C++, strings are null terminated. > > I do not believe this change is in any way necessary for the LTDS or > C-bit mechanism, and would request that it be put back to the way it has > been from draft 7 through draft 12-94: > > "Every key=value pair, including the last or only pair in a LTDS, > MUST be followed by one null (0x00) delimiter." > > Thanks > > Bob Russell --=_alternative 005F53D5C2256BCE_= Content-Type: text/html; charset="us-ascii"
Luben,

You may be interested in pursuing a "Formal-iSCSI" and pass it through IETF as iSCSI-2.
Many of us although appreciate the beauty of formalism want this standard out and used by people to build equipment.
In retrospect - the informal nature of almost all TCP/IP was not such a bad thing.

Julo


Luben Tuikov <luben@splentec.com>
Sent by: luben@ns.splentec.com

06/04/2002 06:38 PM
Please respond to iSCSI; Please respond to Luben Tuikov

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        "Robert D. Russell" <rdr@io.iol.unh.edu>, ips@ece.cmu.edu
        Subject:        Re: null termination of keys

       


Julian,

I agree with Robert. Robert's point of view (as any academic
in the computer/math sciences) is CONSISTENCY. Which is, btw,
a _good_ thing!

The reason is simple: a key=value pair is an entity
starting with non-NUL char (cf. def. of key) and
ending with NUL (0x0) char.

With such a simple definition, parsing the keys is a walk
in the park.

In the draft we are lacking clear-cut, precise
definition of concepts, objects, their interactions
and algorithmic steps.

If we have those set, then finishing and/or changing
iSCSI will be extremely easy.

Take for example the concepts of ``immediate data'' and
``unsolicied data'' and their interactions -- what a spaghetti.

If we define those properly, then we can express many
constraints simply, such as ``A + B <= FirstBurstSize''
where A is blah-blah, and B is blah-blah;
``TargetQueueSize=Max... - blah + 1'' and so on.

Many of us, I'm sure, are reading the draft and re-writing
it, in terms of definitions like the above, in order
to clearly understand it... and you know what happens
then... _inconsistencies_ are found.

This is why, for example, very recently it was decided
that 4.1 should contain definitions in it... even though
it was prompted for a while back.

BTW, I'm surprised that only _one_ person objected to
such a _BIG_ change(s) in the draft. Considering from
personal experience and scaling properly, we
should've seen at least 100 people complaining...

--
Luben
P.S. The above definition of a key=value pair would also
solve by default the problem with more than one NUL char,
rather than you explicitly having to put more text in the
draft. Of course putting more than one NUL char would be
frowned upon but a proper parser following the above rule
would have no problem with it... But I digress...


Julian Satran wrote:
>
> Bob,
>
> The reason it was put in is to to enable "parsing" without the C bit.
> With key spanning PDUs before having the C bit the sender had to avoid sending a 0 if this was the
> last byte of the PDU as he had no other means of signaling continuation. A 0 at the end of a PDU
> meant end-of-LTDS.
>
> Now that we have the C bit we can live with or without having a 0 at the end of the last PDU.
> Let's hear some more voices.
>
> Regards,
> Julo
>
>   "Robert D. Russell" <rdr@io.iol.unh.edu>
>                                                     To:        Julian Satran/Haifa/IBM@IBMIL
>   06/04/2002 09:48 AM                               cc:        ips@ece.cmu.edu
>   Please respond to "Robert D. Russell"             Subject:        Re: null termination of keys
>
>
>
> Julian:
>
> Draft 12-96, section 4.1 defines an LTDS and then says:
>
> "Every key=value pair, excluding the last or only pair in a LTDS,
> MUST be followed by one null (0x00) delimiter; the last or only pair
> in a LTDS ends at the LTDS end."
>
> This brings us back to where we were in draft 6 -- that key=value pairs
> are separated by nulls, not terminated by nulls.  If I remember
> correctly, one of the primary reasons that this was changed going to draft
> 7 is that implementations prefer to treat each key=value pair as one string,
> and in C and C++, strings are null terminated.
>
> I do not believe this change is in any way necessary for the LTDS or
> C-bit mechanism, and would request that it be put back to the way it has
> been from draft 7 through draft 12-94:
>
> "Every key=value pair, including the last or only pair in a LTDS,
> MUST be followed by one null (0x00) delimiter."
>
> Thanks
>
> Bob Russell

--=_alternative 005F53D5C2256BCE_=-- From owner-ips@ece.cmu.edu Tue Jun 4 14:27:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09634 for ; Tue, 4 Jun 2002 14:27:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g54I7wM08431 for ips-outgoing; Tue, 4 Jun 2002 14:07:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g54I7uw08425 for ; Tue, 4 Jun 2002 14:07:56 -0400 (EDT) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g54I7qEF031353; Tue, 4 Jun 2002 14:07:52 -0400 (EDT) Received: from zydeco.research.bell-labs.com (zydeco.research.bell-labs.com [135.104.120.150]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g54I7ko12442; Tue, 4 Jun 2002 14:07:46 -0400 (EDT) Received: from zydeco.research.bell-labs.com (localhost [127.0.0.1]) by zydeco.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g54I7ki0022533; Tue, 4 Jun 2002 14:07:46 -0400 (EDT) Received: (from jkf@localhost) by zydeco.research.bell-labs.com (8.12.2/8.12.2/Submit) id g54I7ju8022532; Tue, 4 Jun 2002 14:07:45 -0400 (EDT) Date: Tue, 4 Jun 2002 14:07:45 -0400 (EDT) From: Jeff Fellin Message-Id: <200206041807.g54I7ju8022532@zydeco.research.bell-labs.com> To: Julian_Satran@il.ibm.com Subject: iSCSI: connection definition Cc: ips@ece.cmu.edu X-Sun-Charset: US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, I am confused by the definition of Connection in section 1.1. The definition states a Connection is the communication between the initiator and target occuring over one or more TCP connections. However by the definition of the CID (Connection ID): Connections within a session are identified by a connection ID, which is unique ID within the session. In Section 5.1.3, state S2 for the initiator is waiting for a response to its transport connection establishment request. In section 5.1.4, state S2 changes to state S4, when the transport connection is established. The description for the Login PDU in section 9.12 states the Login is on every TCP connection. Since each Login Request PDU must contain a unique CID cause logout of the existing non-zero TSIH (assuming to be part of the same session) causes a logout of the connection as described in Section 4.3. So is the definition of Connection in Section 1.1 incorrect in stating a connection is possibly multiple TCP connections or is there some other method of having multiple TCP connections between an initiator and target with the same CID and non-zero TSIH? Thank you for your clarification. Jeff Fellin Bell Labs From owner-ips@ece.cmu.edu Tue Jun 4 14:33:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09885 for ; Tue, 4 Jun 2002 14:33:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g54I49c08126 for ips-outgoing; Tue, 4 Jun 2002 14:04:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g54I44w08119 for ; Tue, 4 Jun 2002 14:04:04 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel6.hp.com (Postfix) with ESMTP id B0E06479; Tue, 4 Jun 2002 14:03:58 -0400 (EDT) Received: from swathi (dhcp-rosefl-baj235.rose.hp.com [15.3.109.235]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id LAA01533; Tue, 4 Jun 2002 11:05:46 -0700 (PDT) Message-ID: <00a301c20bf2$31a2f6f0$eb6d030f@rose.hp.com> From: "Mallikarjun C." To: Cc: Subject: IPS schedule for Yokohama Date: Tue, 4 Jun 2002 11:03:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, Can you please comment on the IPS schedule for Yokohama? I know that the agenda is open to changes, but a confirmation of the IPS meetings in Yokohama and a rough agenda if so, would help. Thanks. Mallikarjun From owner-ips@ece.cmu.edu Tue Jun 4 14:49:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10374 for ; Tue, 4 Jun 2002 14:49:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g54IVEh10347 for ips-outgoing; Tue, 4 Jun 2002 14:31:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13708.mail.yahoo.com (web13708.mail.yahoo.com [216.136.175.141]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g54IV5w10325 for ; Tue, 4 Jun 2002 14:31:05 -0400 (EDT) Message-ID: <20020604183104.96562.qmail@web13708.mail.yahoo.com> Received: from [192.55.52.4] by web13708.mail.yahoo.com via HTTP; Tue, 04 Jun 2002 11:31:04 PDT Date: Tue, 4 Jun 2002 11:31:04 -0700 (PDT) From: Martins Krikis Subject: Re: null termination of keys To: ips@ece.cmu.edu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I agree with Bob and the rest that having '\0' after the last or only pair in the LTDS is much nicer than not having it. There is no compelling reason to try to save a byte here. Please, let's put back the '\0' after the last or only pair. Martins Krikis, Intel Corp. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Tue Jun 4 14:50:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10428 for ; Tue, 4 Jun 2002 14:50:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g54I7lS08419 for ips-outgoing; Tue, 4 Jun 2002 14:07:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g54I7bw08399 for ; Tue, 4 Jun 2002 14:07:37 -0400 (EDT) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g54I81UL078375 for ; Tue, 4 Jun 2002 14:08:01 -0400 (EDT) Received: from zydeco.research.bell-labs.com (zydeco.research.bell-labs.com [135.104.120.150]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g54I7Uo12407 for ; Tue, 4 Jun 2002 14:07:30 -0400 (EDT) Received: from zydeco.research.bell-labs.com (localhost [127.0.0.1]) by zydeco.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g54I7Ti0022515 for ; Tue, 4 Jun 2002 14:07:29 -0400 (EDT) Received: (from jkf@localhost) by zydeco.research.bell-labs.com (8.12.2/8.12.2/Submit) id g54I7ToL022514; Tue, 4 Jun 2002 14:07:29 -0400 (EDT) Date: Tue, 4 Jun 2002 14:07:29 -0400 (EDT) From: Jeff Fellin Message-Id: <200206041807.g54I7ToL022514@zydeco.research.bell-labs.com> To: Julian@Satran@il.ibm.com Subject: iSCSI: connection definition Cc: ips@ece.cmu.edu X-Sun-Charset: US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, I am confused by the definition of Connection in section 1.1. The definition states a Connection is the communication between the initiator and target occuring over one or more TCP connections. However by the definition of the CID (Connection ID): Connections within a session are identified by a connection ID, which is unique ID within the session. In Section 5.1.3, state S2 for the initiator is waiting for a response to its transport connection establishment request. In section 5.1.4, state S2 changes to state S4, when the transport connection is established. The description for the Login PDU in section 9.12 states the Login is on every TCP connection. Since each Login Request PDU must contain a unique CID cause logout of the existing non-zero TSIH (assuming to be part of the same session) causes a logout of the connection as described in Section 4.3. So is the definition of Connection in Section 1.1 incorrect in stating a connection is possibly multiple TCP connections or is there some other method of having multiple TCP connections between an initiator and target with the same CID and non-zero TSIH? Thank you for your clarification. Jeff Fellin Bell Labs From owner-ips@ece.cmu.edu Tue Jun 4 14:50:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10447 for ; Tue, 4 Jun 2002 14:50:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g54IQAI09921 for ips-outgoing; Tue, 4 Jun 2002 14:26:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g54IQ5w09913 for ; Tue, 4 Jun 2002 14:26:05 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g54HOWu29831; Tue, 4 Jun 2002 13:24:32 -0400 Message-ID: <3CFD0633.E4DADCF9@splentec.com> Date: Tue, 04 Jun 2002 14:25:55 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Julian Satran CC: iSCSI Subject: Re: null termination of keys References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian Satran wrote: > > Luben, > > You may be interested in pursuing a "Formal-iSCSI" and pass it through IETF as iSCSI-2. > Many of us although appreciate the beauty of formalism want this standard out and used by people > to build equipment. There was no need for this, since I'm not trying to slow it down. I was merely suggesting that _existing_ iSCSI concepts be put down into a more formal manner. Example of those are 4.1, 1.1 and the current work by Robert about key dependencies. That is, my suggestion was no changes at all, just rephrasing. Then iSCSI will be cleaner and clearer to work with and to be worked upon. > In retrospect - the informal nature of almost all TCP/IP was not such a bad thing. Not quite. TCP/IP is formal _enough_ to disassociate ambiguities. (E.g. RFC793/STD7 page 25, 26, 41, all full of inequalites, equialities and definitions.) From owner-ips@ece.cmu.edu Tue Jun 4 14:51:29 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10476 for ; Tue, 4 Jun 2002 14:51:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g54IhkH11446 for ips-outgoing; Tue, 4 Jun 2002 14:43:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13709.mail.yahoo.com (web13709.mail.yahoo.com [216.136.175.251]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g54Ihiw11442 for ; Tue, 4 Jun 2002 14:43:44 -0400 (EDT) Message-ID: <20020604184343.55649.qmail@web13709.mail.yahoo.com> Received: from [192.55.52.3] by web13709.mail.yahoo.com via HTTP; Tue, 04 Jun 2002 11:43:43 PDT Date: Tue, 4 Jun 2002 11:43:43 -0700 (PDT) From: Martins Krikis Subject: RE: iSCSI: keys/parameter dependence To: "Robert D. Russell" , Julian Satran Cc: ips@ece.cmu.edu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- "Robert D. Russell" wrote: > With a bit of work, we could probably get rid of all > the dependencies > between the OFMarkInt (IFMarkInt) and OFMarker > (IFMarker) keys, perhaps, > as suggested by Martins Krikis, by eliminating the > OFMarker (IFMarker) > key and substituting a default (and response) value > of 0 for the > OFMarkInt (IFMarkInt) to mean "no markers in that > direction". > > This would also eliminate the need for a "Reject" > reply to an OFMarkInt > (IFMarkInt) offer. I just started thinking that the introduction of 0 might require the responder to "respond with a value (the 0) out of range" if it does not want markers, and thus thought that this plan wasn't very good. However, if 0 is the default and if Reject returns us to the previous (in this case, default) value, then this would actually work fine, and eliminate the boolean marker keys. We cannot get by without allowing Reject as a response to range not acceptable or not admissible, however. If we keep the boolean marker keys, is there any chance of NOT having a Reject for a marker interval reset the corresponding boolean key to "no"? Then we wouldn't have a dependency there. Can we have the Reset mean "stick with the previous (i.e., default in this case) value"? Thanks, Martins Krikis, Intel Corp. Disclaimer: my opinions, not necessarily Intel's. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Tue Jun 4 14:53:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10528 for ; Tue, 4 Jun 2002 14:53:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g54IP6b09841 for ips-outgoing; Tue, 4 Jun 2002 14:25:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail1.hd.intel.com (hdfdns01.hd.intel.com [192.52.58.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g54IP3w09834 for ; Tue, 4 Jun 2002 14:25:03 -0400 (EDT) Received: from mkrikis-laptop (mkrikis-laptop.hd.intel.com [10.127.144.131]) by mail1.hd.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with ESMTP id g54IOv017968; Tue, 4 Jun 2002 18:24:57 GMT Received: from martinsk by mkrikis-laptop with local (Exim 3.35 #1 (Debian)) id 17FJud-0000m4-00; Tue, 04 Jun 2002 14:24:12 -0500 To: ips@ece.cmu.edu, rdr@io.iol.unh.edu Subject: Re: iSCSI: keys/parameter dependence Message-Id: From: Martins Krikis Date: Tue, 04 Jun 2002 14:24:12 -0500 Sender: owner-ips@ece.cmu.edu Precedence: bulk Robert, I'm cutting text out to keep it shorter... > What you are saying seems to imply that C=0 does NOT > require the receiver to reply to keys received up to that point > -- it could send another empty PDU, or more likely, it could send > new offers of its own. I agree that there is nothing in the draft > that says when replies to keys should be sent, only that they > MUST be sent (sometime). Yes. The other side cannot be forced to send anything. > It would seem that the initiator might try to force replies by > setting T=1 to force an end-of-stage transition. However, the target > can refuse to make the transition and can reply with T=0 and still > no replies to the keys it was offered. > > This is admittedly a rather far-out example, because presumably both > initiator and target want to end the negotiations as soon as possible. > My point only is that I do not see anything in the draft that says > when the replies to keys have to be sent, only several references > that there MUST be a reply to every key offered (eventually). Yes, there is the possibility that one or both sides don't want to commit the negotiation and keep ping-ponging empty PDUs. Thus, implementations will likely be counting such request-response rounds and have some threshold value for how many times this can go on... > The dependency can be accounted for when generating the reply. > For example, > > reply.FirstBurstSize = min(offer.FirstBurstSize, reply.MaxBurstSize) > > That way nothing is broken when sending data. except that reply.MaxBurstSize may have to be substituted by current.MaxBurstSize or offer.MaxBurstSize or something like that... i.e., there can be chicken-and-egg problems, I think. I prefer negotiating each key individually, according to its type, allowed values, desired values, who may send it at the concrete stage of the negotiations, etc. I am not fond of the idea that it may be necessary to look at the (current or future) values of other keys in addition to what already has to be done for each key. > > And how many instances of TargetName and TargetAddress > > can the SendTargets command provoke from the other > > side? I think it can easily overflow the 8192 bytes. > > Yes it can, but there was already a mechanism in place to deal > with this. In fact, this brings up an interesting point. > Presumably the C bit has to be used with replies sent to > SendTargets (or any other offer that might generate a long reply), > since the C bit is in the Text Response PDU used to send these replies. Yes, it should. There was just an example of "long responses" in 9.10.4, but some people understood it to mean that empty PDUs going in the other direction are mandatory. For SendTargets there isn't much else the initiator can send anyways (?). Well, the empty PDUs of 9.10.4 weren't mandated yet when the discussions for C-bit started, but that's basically what the C-bit mandates. Would be nice to add it to the example of 9.10.4, too. > Refering to sections 9.10.2 and 9.10.4: If the target generating a > long reply has more text to send than will fit in one PDU, then it > should indicate this by setting C = 1. Setting C = 1 also forces F=0, > and this in turn forces the Target Transfer Tag to be something > other than 0xffffffff. Yes. > When there is no more text to send, > the target sets C = 0 and F = 1 and TTT=0xffffffff in the last > text response pdu it sends to the initiator. C = 0 yes, but F and TTT only if initiator set F and if the target is ready to commit. It may still be missing values from initiator, or just taking a break (:-)) for a couple request-response rounds. > There is no > situation in which C = 1 and F = 1 can occur (since this is > explicitly stated in 9.10.2 as being an error), Yes. > nor is there a > situation in which C = 0 and F = 0 should occur (because C = 0 > means "I'm done sending stuff" and F = 0 means "I'm not done sending > stuff"). This can occur. C=0 just means "I'm done with this "set of keys" ("batch"), now I'm willing to listen what you may have to say". It does not imply F=1, as the target may not be ready to commit yet. In fact, initiator need not have set F yet, so in fact target may be forbidden to set it. > Is this the way you interpret the merging of the C bit with the > long text reply mechanism? C-bit now IS the "long login/text request/reply mechanism". > If there is a consensus on this, > perhaps the wording in the draft in section 9.10.4 should include > the (required) settings of the C bit whenever it mentions the > corresponding settings of the F bit and TTT field. Perhaps something can be added, especially to the example there. > > > The existence of a dependency between OFMarker and > > > OFMarkInt, and between > > > IFMarker and IFMarkInt, is implied by the statements > > > in section A.3.2: > > > "When the interval is unacceptable the responder > > > answers with > > > "Reject". Reject is resetting the marker function > > > in the spcified > > > direction (Output or Input) to No." > > > > No it isn't. IMO, it is resetting the marker interval > > to its previous value, which is likely the default > > value. I believe it's perfectly legal to negotiate > > the marker interval but to not turn on marker use, > > or to turn on the use but stay with current (default) > > values for the interval. If one side can't tolerate > > the other's Reject (i.e., can't live with the > > default value), it is welcome to bail and try next > > time w/o markers. BTW, we could use 0 here as a > > special value, meaning that markers are not in use, > > then we wouldn't need the boolean keys for > > markers. > > > > > This last sentence should probably be reworded to > > > say: > > > "A response value of "Reject" to an OFMarkInt > > > (IFMarkInt) key resets the > > > corresponding OFMarker (IFMarker) key value to > > > "No"." > > > > No, thank you. I would prefer if Reject meant the > > same as with the other keys, i.e., negotiation > > failed for this key, let's stick with the old > > value, or bail if we must. > > Either the sentence needs to be reworded so it is proper English > or it should be taken out of the draft. I take it you are advocating > its removal? Oops. My mistake. I hadn't even read the sentence about "Reject" that is in the draft currently. I have no objections to English there, but I don't like that Reject is "resetting the marker function to no", since that certainly introduces a dependency, and I understand that it is legal to treat the other Rejects as "stick to the old value"., I would like this Reject to allow the same interpretation, i.e., not require to touch any other keys immediately. Using 0 as a special value for intervals also has a drawback---it can be a value "out of range", to be returned. Suggestions? Martins Krikis, Intel Corp. Disclaimer: my opinions, not necessarily Intel's. From owner-ips@ece.cmu.edu Tue Jun 4 16:07:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13123 for ; Tue, 4 Jun 2002 16:07:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g54JU2E15331 for ips-outgoing; Tue, 4 Jun 2002 15:30:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13701.mail.yahoo.com (web13701.mail.yahoo.com [216.136.175.134]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g54JTxw15324 for ; Tue, 4 Jun 2002 15:29:59 -0400 (EDT) Message-ID: <20020604192958.77843.qmail@web13701.mail.yahoo.com> Received: from [192.55.52.4] by web13701.mail.yahoo.com via HTTP; Tue, 04 Jun 2002 12:29:58 PDT Date: Tue, 4 Jun 2002 12:29:58 -0700 (PDT) From: Martins Krikis Subject: RE: iSCSI: keys/parameter dependence To: "'Robert D. Russell'" , Robert Snively Cc: ips@ece.cmu.edu In-Reply-To: <2F37CED150E21640A9C6E75B8BE6AF830A4C94@hq-ex-4> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- Robert Snively wrote: > I stand corrected. If you want to order batches, > you must > not only transmit the keys that you want to batch, > but you must > also not transmit another batch of keys until you > have received the > replies for the outstanding batch. That's if you don't want to send the next batch before hearing something back about the previous. If you are happy with the little you did (or didn't) receive back), you could just send your next batch and consider having ordered them. I.e., there was a moment when the other side was allowed to say something, so your batches were "ordered"... > I haven't studied all aspects of this carefully, but > I would > expect that the processing must proceed on a batch > by batch > basis, since it is never clear when the > Final-Response exchange > will be requested and the target must have completed > whatever > negotiation is going on with respect to previous > batch exchanges. There is no such requirement. If the target likes to respond with nothing (or not with everything possible) to initiator's first 17 batches and only send the missing responses in round (exchange) number 18, that's perfectly legal. It is even legal to wait for the initiator to set the F-bit and only then to start negotiating something else, or respond to keys that can be responded to. (A correct initiator shouldn't set the F-bit if it doesn't have the mandated responses, but it could be that it sends a bunch of boolean keys first that don't require responses, target answers with empty, initiator decides to set the F-bit, target decides to send a bunch of responses, etc.) Obviously, implementations will likely check how many rounds (exchanges) have already taken place and not let the negotiations go on forever. > I would not expect the target to be allowed to hang > around doing nothing > until Final-Response exchanges were requested. This > seems to be > what section 4.4 says, at least for post-login > activities. The target is allowed to. 4.4 just says that it is discouraged to reset the F-bit back to 0 while sending 0-length data. > I was a little surprised to see that post-login > negotiations of > a parameter a second time without an intervening > reset > constitute a protocol error. Some of the values, > notably > those duplicating MODE SENSE/SELECT parameters, have > traditionally > been renegotiable as desired by the SCSI device > without an > intervening reset, and I would expect that > capability to have > been mapped into the key=value negotations. They can be renegotiated, but this has to be after a negotiation reset (i.e., after sending TTT=0xffffffff), not necessarily after a device reset, or in a new negotiation sequence (i.e., new ITT, TTT=0xffffffff). But they can be renegotiated as many times as needed on the same connection or in the same session. Martins Krikis, Intel Corp. Disclaimer: my opinions, not necessarily Intel's. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Tue Jun 4 16:48:53 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14429 for ; Tue, 4 Jun 2002 16:48:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g54K4eq18336 for ips-outgoing; Tue, 4 Jun 2002 16:04:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g54K4bw18326 for ; Tue, 4 Jun 2002 16:04:37 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 31648C4BD; Tue, 4 Jun 2002 14:04:36 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id C9201EB; Tue, 4 Jun 2002 14:04:35 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 04 Jun 2002 14:04:35 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Jun 2002 14:04:35 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C353F3C@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: rdr@io.iol.unh.edu, pat_thaler@agilent.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence Date: Tue, 4 Jun 2002 14:04:35 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Robert, Responding to: This does, however, bring up another question. When the C bit is 0, the receiver of that PDU does not seem to be required to send replies to the keys it has received up to that point -- it could send another empty PDU, or more likely, it could send new offers of its own. It seems to me that there is nothing in the draft that says when replies to keys should be sent, only that they MUST be sent. There wasn't any requirement for how soon one responded to keys before the C bit was created. I don't think any such requirement is needed. One makes ones offers. If they haven't been responded too by the end of the negotiation session - e.g. the target sets the T bit without having sent responses to all the Initiator's keys or the target times out waiting for the Initiator to respond to keys it sent - then the negotiation failed and the side that detected it should close the connection. Regards, Pat From owner-ips@ece.cmu.edu Tue Jun 4 16:51:58 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14509 for ; Tue, 4 Jun 2002 16:51:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g54KVOY20409 for ips-outgoing; Tue, 4 Jun 2002 16:31:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g54KVMw20402 for ; Tue, 4 Jun 2002 16:31:22 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 0216AC3C6; Tue, 4 Jun 2002 14:31:22 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id D584E2AC; Tue, 4 Jun 2002 14:31:21 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 04 Jun 2002 14:31:21 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Jun 2002 14:31:21 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C353F54@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: iSCSI CRC inconsistency Date: Tue, 4 Jun 2002 14:31:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, There is an inconsistency in the description of the CRC32. In 11.1, the final paragraph on page 207 is incorrect. The paragraph says: - The CRC bits appear after the message bits with x^31 first followed by x^30 etc. (when examples are provided, the value to be specified in the examples follows the same ordering as the rest of this document). At the top of the next page, it describes the magic number CRC check where one runs the CRC generator over the data or header plus the received digest and gets the magic number: - A receiver of a "good" segment (data or header) including the CRC built using the generator 0x11edc6f41 will get the value 0x1c2d19ed as its CRC (this is a polynomial value and not a word as outlined in this draft). The point of the magic number algorithm is that it uses exactly the same algorithm to check the CRC that was used to generate the CRC. When running the check, the received CRC is run through the generator with the same bit order as the covered data. Therefore, this check only works right when the CRC is appended to the data using the same bit ordering within a word as was used when sending the covered data through the CRC generator. The examples in B.4 show the bits ordered as they should be and page 207 is inconsistent with them.. Specifically, data bits go through the generator from byte 0 to byte 3 of the word with each bit going through bit 7 to bit 0. Therefore, paragraph on how the CRC bits are placed in the field should be: - The CRC bits appear after the message bits with the x^31 coefficient in bit 7 of the first byte (byte 0) of the digest continuing to through the byte the x^24 coefficient in bit 0 of byte 0, continuing with the x^23 coefficient in bit 7 of byte 1, etc. (When examples are provided they show the CRC as it appears in the PDU with the bit significance used throughout this document. That is, bit 7 of each byte is interpreted as most significant though it is the coefficient of the lowest order CRC term in the byte.). I have checked and this order matches the examples in B.4. Regards, Pat From owner-ips@ece.cmu.edu Tue Jun 4 16:52:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14528 for ; Tue, 4 Jun 2002 16:52:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g54KMS319695 for ips-outgoing; Tue, 4 Jun 2002 16:22:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtp3.electric.net (smtp3.electric.net [216.129.90.16]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g54KMQw19690 for ; Tue, 4 Jun 2002 16:22:26 -0400 (EDT) Received: from hm1.electric.net ([216.129.90.33]) by smtp3.electric.net with smtp (Exim 4.04) id 17FKoy-000Odw-CR for ips@ece.cmu.edu; Tue, 04 Jun 2002 13:22:24 -0700 Received: from osmtp1.electric.net ([216.129.90.28]) by hm1.electric.net (NAVGW 2.5.2.9) with SMTP id M2002060413222306446 ; Tue, 04 Jun 2002 13:22:23 -0700 Received: from [206.175.229.4] (helo=EGRodriguez) by osmtp1.electric.net with esmtp (Exim 3.22 #1) id 17FKox-000229-04; Tue, 04 Jun 2002 13:22:23 -0700 From: "Elizabeth G. Rodriguez" To: "'Mallikarjun C.'" , Cc: Subject: RE: IPS schedule for Yokohama Date: Tue, 4 Jun 2002 15:20:18 -0600 Keywords: IETF-IPS Message-ID: <002c01c20c0d$a1ebf9a0$04e5afce@EGRodriguez> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <00a301c20bf2$31a2f6f0$eb6d030f@rose.hp.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Mallikarjun, We have asked for two sessions during Yokohoma. One 2.5 hour session and one 1 hour session. The agenda has not yet been set, but since we are trying to get last calls on several of the drafts, that will factor into the agenda schedule. e.g. if the FC base drafts complete last call, and do not need time at the meeting, then they may only have a few minutes total. If there are on the other hand issues that need to be discussed, they would get time on the agenda. Same goes for iSCSI and security drafts. As of right now, not even a tentative schedule has been published to my knowledge. One thing that I was told is that IPS would not be meeting on Friday -- though this is not guaranteed until the schedule is finalized. Hope this helps. Elizabeth -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com] Sent: Tuesday, June 04, 2002 12:04 PM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: IPS schedule for Yokohama David, Can you please comment on the IPS schedule for Yokohama? I know that the agenda is open to changes, but a confirmation of the IPS meetings in Yokohama and a rough agenda if so, would help. Thanks. Mallikarjun From owner-ips@ece.cmu.edu Tue Jun 4 17:29:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16302 for ; Tue, 4 Jun 2002 17:29:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g54KiAx21263 for ips-outgoing; Tue, 4 Jun 2002 16:44:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g54Ki9w21259 for ; Tue, 4 Jun 2002 16:44:09 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id C6EBBC89F; Tue, 4 Jun 2002 14:44:08 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 5357B2D2; Tue, 4 Jun 2002 14:44:08 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 04 Jun 2002 14:44:08 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Jun 2002 14:44:08 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C353F5D@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: wrstuden@wasabisystems.com, Julian_Satran@il.ibm.com Cc: rdr@io.iol.unh.edu, ips@ece.cmu.edu Subject: RE: null termination of keys Date: Tue, 4 Jun 2002 14:44:07 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Bill, I agree. Also, changing this bit is unnecessary thrashing and it is time to stop changing things that aren't broken. We are already seeing that changing the C bit is in danger of having a ripple effect. Regards, Pat -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Tuesday, June 04, 2002 9:50 AM To: Julian Satran Cc: Robert D. Russell; ips@ece.cmu.edu Subject: Re: null termination of keys On Tue, 4 Jun 2002, Julian Satran wrote: > Bob, > > The reason it was put in is to to enable "parsing" without the C bit. > With key spanning PDUs before having the C bit the sender had to avoid > sending a 0 if this was the last byte of the PDU as he had no other means > of signaling continuation. A 0 at the end of a PDU meant end-of-LTDS. > > Now that we have the C bit we can live with or without having a 0 at the > end of the last PDU. > Let's hear some more voices. As a C/C++ programmer, I really like the idea of having 0s at the end of a key/value pair. I agree with Bob that having key/value pairs terminated by NULs is easier. Take care, Bill From owner-ips@ece.cmu.edu Tue Jun 4 17:31:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16339 for ; Tue, 4 Jun 2002 17:31:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g54L2uE22792 for ips-outgoing; Tue, 4 Jun 2002 17:02:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g54L2sw22787 for ; Tue, 4 Jun 2002 17:02:54 -0400 (EDT) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g54L2rEF032885 for ; Tue, 4 Jun 2002 17:02:53 -0400 (EDT) Received: from zydeco.research.bell-labs.com (zydeco.research.bell-labs.com [135.104.120.150]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g54L2lk89578 for ; Tue, 4 Jun 2002 17:02:47 -0400 (EDT) Received: from zydeco.research.bell-labs.com (localhost [127.0.0.1]) by zydeco.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g54L2ki0029513 for ; Tue, 4 Jun 2002 17:02:46 -0400 (EDT) Received: (from jkf@localhost) by zydeco.research.bell-labs.com (8.12.2/8.12.2/Submit) id g54L2kSc029512 for ips@ece.cmu.edu; Tue, 4 Jun 2002 17:02:46 -0400 (EDT) Date: Tue, 4 Jun 2002 17:02:46 -0400 (EDT) From: Jeff Fellin Message-Id: <200206042102.g54L2kSc029512@zydeco.research.bell-labs.com> To: ips@ece.cmu.edu Subject: iSCSI SCSI Port Name X-Sun-Charset: US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, In reading 12-96, I came across two different definitions of a SCSI Port Name. In Section 1.1 SCSI Port Name: A name made up as UTF-8 characters and is the iSCSI name + 'i' or 't' + ISID or Portal Group Tag In Section 2.4.2 SCSI Port Name is mandatory in iSCSI. WHen used in SCSI parameter data, the SCSI port name MUST be encoded as: - The iSCSI Name in UTF-8 format, followed by - a comma separator (1 byte), followed by - the ASCII character 'i' () or the ASCII character 't' (), followed by - a comma separator (1 byte), followed by - zero to 3 null pad bytes , followed by - the 6 byte value of the ISID or the 2 byte value of the Portal Group Tag I'm assumming the definition in Section 2.4.2 is the "correct definition", and the one in Section 1.1 needs to be changed to match this definition. Jeff Fellin Bell Labs From owner-ips@ece.cmu.edu Tue Jun 4 17:31:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16357 for ; Tue, 4 Jun 2002 17:31:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g54Kmmj21780 for ips-outgoing; Tue, 4 Jun 2002 16:48:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtp2.electricmail.net (smtp2.electric.net [216.129.90.15]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g54Kmkw21775 for ; Tue, 4 Jun 2002 16:48:46 -0400 (EDT) Received: from hm1.electric.net ([216.129.90.33]) by smtp2.electricmail.net with smtp (Exim 4.04) id 17FLET-000OTY-02 for ips@ece.cmu.edu; Tue, 04 Jun 2002 13:48:45 -0700 Received: from osmtp3.electric.net ([216.129.90.30]) by hm1.electric.net (NAVGW 2.5.2.9) with SMTP id M2002060413484425088 for ; Tue, 04 Jun 2002 13:48:44 -0700 Received: from [206.175.229.4] (helo=EGRodriguez) by osmtp3.electric.net with esmtp (Exim 3.22 #1) id 17FLER-0002WS-04 for ips@ece.cmu.edu; Tue, 04 Jun 2002 13:48:44 -0700 From: "Elizabeth G. Rodriguez" To: Subject: IPS-ALL: PDF versions of the drafts Date: Tue, 4 Jun 2002 15:46:39 -0600 Message-ID: <00d201c20c11$5036a110$04e5afce@EGRodriguez> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D3_01C20BDF.059C3110" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00D3_01C20BDF.059C3110 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, For a number of our drafts, the editor publishes both text and PDF versions. It is often difficult to find the PDF version on the IETF web site though. The best place to reference for the PDF version of our drafts is http://www.ietf.org/ids.by.wg/ips.html. At the end of the description, it will indicate if a PDF version is also available. This said, I must caution everyone - the TXT version of the draft is the official version of the draft. So, it is recommend that when reviewing the draft for last call, the TXT version be used. Thanks, Elizabeth ------=_NextPart_000_00D3_01C20BDF.059C3110 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

For a number of our drafts, the editor publishes both = text and PDF versions.

It is often difficult to find the PDF version on the = IETF web site though.

 

The best place to reference for the PDF version of = our drafts is http://www.ietf.org/ids.b= y.wg/ips.html.

At the end of the description, it will indicate if a = PDF version is also available.

 

This said, I must caution everyone – the TXT = version of the draft is the official version of the draft.

So, it is recommend that when reviewing the draft for = last call, the TXT version be used.

 

Thanks,

 

Elizabeth

------=_NextPart_000_00D3_01C20BDF.059C3110-- From owner-ips@ece.cmu.edu Tue Jun 4 18:25:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17820 for ; Tue, 4 Jun 2002 18:25:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g54LipX25877 for ips-outgoing; Tue, 4 Jun 2002 17:44:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g54Linw25870 for ; Tue, 4 Jun 2002 17:44:49 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 4F393C67B; Tue, 4 Jun 2002 15:44:47 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 07350135; Tue, 4 Jun 2002 15:44:47 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 04 Jun 2002 15:44:46 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Jun 2002 15:44:46 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C353F89@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: jkf@research.bell-labs.com, ips@ece.cmu.edu Subject: RE: iSCSI SCSI Port Name Date: Tue, 4 Jun 2002 15:44:45 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Jeff, It appears that the problem is that section 1.1. ignores details of the format (commas and pad). One way to fix this while still allowing the section 1.1 definition to be brief and keeping the rigorous definition in just on place would be to replace "and is" with "includes", "based on", or "containing" and adding a reference to the detailed description: In Section 1.1 SCSI Port Name: A name made up as UTF-8 characters containing the iSCSI name, 'i' or 't', and ISID or Portal Group Tag (see 2.4.2) Perhaps the UTF-8 character part isn't needed at the glossary level of detail. SCSI Port Name: A name containing the iSCSI name, 'i' or 't', and ISID or Portal Group Tag (see 2.4.2) Pat -----Original Message----- From: Jeff Fellin [mailto:jkf@research.bell-labs.com] Sent: Tuesday, June 04, 2002 2:03 PM To: ips@ece.cmu.edu Subject: iSCSI SCSI Port Name Julian, In reading 12-96, I came across two different definitions of a SCSI Port Name. In Section 1.1 SCSI Port Name: A name made up as UTF-8 characters and is the iSCSI name + 'i' or 't' + ISID or Portal Group Tag In Section 2.4.2 SCSI Port Name is mandatory in iSCSI. WHen used in SCSI parameter data, the SCSI port name MUST be encoded as: - The iSCSI Name in UTF-8 format, followed by - a comma separator (1 byte), followed by - the ASCII character 'i' () or the ASCII character 't' (), followed by - a comma separator (1 byte), followed by - zero to 3 null pad bytes , followed by - the 6 byte value of the ISID or the 2 byte value of the Portal Group Tag I'm assumming the definition in Section 2.4.2 is the "correct definition", and the one in Section 1.1 needs to be changed to match this definition. Jeff Fellin Bell Labs From owner-ips@ece.cmu.edu Tue Jun 4 18:58:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18967 for ; Tue, 4 Jun 2002 18:58:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g54MNmf28571 for ips-outgoing; Tue, 4 Jun 2002 18:23:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g54MNlw28567 for ; Tue, 4 Jun 2002 18:23:47 -0400 (EDT) Received: from twestrelay04.boulder.ibm.com (twestrelay04.boulder.ibm.com [9.17.194.55]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g54MNeg5080998; Tue, 4 Jun 2002 18:23:40 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by twestrelay04.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g54MNeN162144; Tue, 4 Jun 2002 16:23:40 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI SCSI Port Name To: pat_thaler@agilent.com Cc: jkf@research.bell-labs.com, ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Tue, 4 Jun 2002 15:21:50 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 06/04/2002 04:23:39 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Actually I think the difference is the difference in the name (which has no commas) and the way SCSI needs the name structured in a parameter. These do not have to be exactly the same syntax. We actually only use the Name (not the SCSI parameter) in written communication. So the SCSI parameter syntax is probably not the best form for that type of use. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com pat_thaler@agilent.com@ece.cmu.edu on 06/04/2002 02:44:45 PM Sent by: owner-ips@ece.cmu.edu To: jkf@research.bell-labs.com, ips@ece.cmu.edu cc: Subject: RE: iSCSI SCSI Port Name Jeff, It appears that the problem is that section 1.1. ignores details of the format (commas and pad). One way to fix this while still allowing the section 1.1 definition to be brief and keeping the rigorous definition in just on place would be to replace "and is" with "includes", "based on", or "containing" and adding a reference to the detailed description: In Section 1.1 SCSI Port Name: A name made up as UTF-8 characters containing the iSCSI name, 'i' or 't', and ISID or Portal Group Tag (see 2.4.2) Perhaps the UTF-8 character part isn't needed at the glossary level of detail. SCSI Port Name: A name containing the iSCSI name, 'i' or 't', and ISID or Portal Group Tag (see 2.4.2) Pat -----Original Message----- From: Jeff Fellin [mailto:jkf@research.bell-labs.com] Sent: Tuesday, June 04, 2002 2:03 PM To: ips@ece.cmu.edu Subject: iSCSI SCSI Port Name Julian, In reading 12-96, I came across two different definitions of a SCSI Port Name. In Section 1.1 SCSI Port Name: A name made up as UTF-8 characters and is the iSCSI name + 'i' or 't' + ISID or Portal Group Tag In Section 2.4.2 SCSI Port Name is mandatory in iSCSI. WHen used in SCSI parameter data, the SCSI port name MUST be encoded as: - The iSCSI Name in UTF-8 format, followed by - a comma separator (1 byte), followed by - the ASCII character 'i' () or the ASCII character 't' (), followed by - a comma separator (1 byte), followed by - zero to 3 null pad bytes , followed by - the 6 byte value of the ISID or the 2 byte value of the Portal Group Tag I'm assumming the definition in Section 2.4.2 is the "correct definition", and the one in Section 1.1 needs to be changed to match this definition. Jeff Fellin Bell Labs From owner-ips@ece.cmu.edu Tue Jun 4 20:42:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20587 for ; Tue, 4 Jun 2002 20:42:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5500jP04578 for ips-outgoing; Tue, 4 Jun 2002 20:00:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5500iw04574 for ; Tue, 4 Jun 2002 20:00:44 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 102B0B590; Tue, 4 Jun 2002 18:00:43 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1.cos.agilent.com (Postfix) with SMTP id C3D952C6; Tue, 4 Jun 2002 18:00:42 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 04 Jun 2002 18:00:41 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Jun 2002 18:00:41 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C353FC5@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: rdr@io.iol.unh.edu, ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence Date: Tue, 4 Jun 2002 18:00:40 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Robert, You seem to be assuming that the set of values for keys must be a valid set of keys at any time during the negotiation. If that is the rule then, for example, if one is planning to increase FirstBurstSize over the default value of MaxBurstSize, one has to increase MaxBurstSize first. Similarly, if one was going to decrease MaxBurstSize below the default of FirstBurstSize then one needs to decrease FirstBurstSize first. (Call this "valid when set") The draft doesn't state that this is a rule for negotiation. It would work just as well to require that the set of parameters be valid at the end of negotiation. With this rule, it is okay to set the parameters in either order. One can check that a parameter relationship rule is met when all the parameters covered by the rule have been negotiated or when one is ready to set the T bit. (Call this "valid at commit") The draft needs to clarify whether the rule is valid when set or valid at commit because there will be interoperability problems between a device applying valid when set and one applying valid at commit. Actually, the draft doesn't even say you need to check the values and it isn't clear a check is necessary though it is prudent. One possibility is to say that one doesn't check non-final results but may check when the negotiations involved have responses or before commit. Note that the valid when set rule imposes certain complexities. For example: Initiator wants to set FirstBurstSize larger than MaxBurstSize default. It therefore sends MaxBurstSize first. It turns out that the target wants to set MaxBurstSize smaller than the default for FirstBurstSize so it cannot reply to MaxBurstSize right away. It has to lower FirstBurstSize first First the Target has to check forward in its receive buffer to see if the initiator made an offer for FirstBurstSize, then respond to that offer or, if the offer hasn't been made it has to make its offer. Then it can send MaxBurstSize. That is a pain and things like this are causing login code to grow beyond what is reasonable and necessary. Furthermore, 4.2 says "Conservative design requires also that default values should not be relied upon when use of some other value has serious consequences." Failing negotiation because you think your partner set MaxBurstSize lower than the default value of FirstBurstSize seems like a serious consequence. Actually, the draft does not explicitly say that one needs to check that MaxBurstSize and FirstBurstSize have the right relationship at the end of negotiation. Is that a requirement? Mathematically, if both sides offer/respond with a pair of values that meet the rule, then the final values will meet the rule. Call the values: Mi - initiator's preferred value of MaxBurstSize Mt - target's preferred value of MaxBurstSize Fi - initiator's preferred value of FirstBurstSize Ft - target's preferred value of FirstBurstSize Mn - negotiation result for MaxBurstSize Fn - negotiation result for FirstBursSize Mi >= Fi Mt >= Ft Mn = min (Mi, Mt) Fn = min (Fi, Ft) then it is guaranteed that Mn >= Fn for example, take the case where Mi < Mt. This results in Mn = Mi If Fi > Ft Then Fn = Ft and Mn = Mi > Fi > Ft = Fn I might check anyway because I don't trust my partner to get the values right or to offer both when changing one to the point that the other needs to change, but should the check be required? One could do a sentence like: While negotiations are incomplete, the set of values may not meet all the dependency requirements (e.g. MaxBurstSize might be less than FirstBurst size when one has been negotiated and the other has not completed negotiation). The initiator or target making an offer or sending a response that results in such an inconsistancy MUST offer the other value when necessary to resolve the inconsistancy. Conservative design also requires that the final values of negotiation be checked for a dependency when failure to meet the dependency has serious consequences. Regards, Pat -----Original Message----- From: Robert D. Russell [mailto:rdr@io.iol.unh.edu] Sent: Sunday, June 02, 2002 12:08 PM To: ips@ece.cmu.edu Subject: Re: iSCSI: keys/parameter dependence Hi Mike: Comments in text below: > >From 12-95 4.3.3 pg 80 (and also in 4.4 pg 83): > > Whenever parameter action or acceptance are dependent on other parameters, > the dependent parameters MUST be sent after the parameters on > which they depend. If they are sent within the same command, a > response for a parameter might imply responses for others. > > > Is an example of this FirstBurstSize being dependent on MaxBurstSize (or > vis-versa)? yes > So MaxBurstSize MUST come before FirstBurstSize? Not necessarily, since it says "Whenever parameter action or acceptance are dependent on other parameters, ...". If you want to offer a value of FirstBurstSize (say 524288) that is greater than the default value 262144 of MaxBurstSize then a value of MaxBurstSize at least as large as 524288 must be offered first -- otherwise the offered value of 262144 for FirstBurstSize could not be accepted, since that would violate the requirement in section 11.14 that "FirstBurstSize MUST NOT exceed MaxBurstSize." (and the (default) value for MaxBurstSize would be exceeded if the offered value were accepted at that point in the negotiations.) On the other hand, if you want to offer a value of MaxBurstSize (say 32768) that is smaller than the default value 65536 of FirstBurstSize then a value of FirstBurstSize no larger than 32768 must be offered first -- otherwise the offered value of 32768 for MaxBurstSize cannot be accepted, since that would violate the same requirement at that point in the negotiations. > I don't see any definition of operational parameters. Just in section 11 > keys that are not "declarative" are "operational keys". In draft 12-95, Chapter 11 is entitled "Login/Text Operational Keys", and the fourth paragraph in this chapter says: "Keys marked as "declarative" may appear also in the SecurityNegotiation stage while all other keys described in this chaper are operational keys." Doesn't that pretty clearly define operational keys? > Also, the spec goes back and forth between the terms "keys"/"parameters" and > "operational keys"/"operational parameters"/"operational negotiation > parameter keys". Is this something that should be cleaned up? It would certainly help to use consistent terminology throughout. Best, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Tue Jun 4 20:45:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20626 for ; Tue, 4 Jun 2002 20:45:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g550NJf05865 for ips-outgoing; Tue, 4 Jun 2002 20:23:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g550NIw05858 for ; Tue, 4 Jun 2002 20:23:18 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 7031FA878; Tue, 4 Jun 2002 18:23:17 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 11D1515C; Tue, 4 Jun 2002 18:23:17 -0600 (MDT) Received: from 130.29.152.143 by axcsbh1.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 04 Jun 2002 18:23:16 -0600 Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Jun 2002 18:23:16 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C353FD6@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: "Robert D. Russell" , Robert Snively Cc: ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence Date: Tue, 4 Jun 2002 18:23:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Bob, I agree. There is no requirement to respond to the keys received in the last batch in your next batch. Pat -----Original Message----- From: Robert D. Russell [mailto:rdr@io.iol.unh.edu] Sent: Monday, June 03, 2002 11:45 PM To: Robert Snively Cc: ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence Robert: You are, of course, absolutely correct. There is no mention in the current drafts of "order" applied to the processing of keys -- there used to be such an "order" requirement, but that went out when draft 8 came in, and is now ancient history. My apologies to the entire list for mistakenly bringing it back. I do, however, have a question about one small point in what you said: > If you want to order processing, you would > have to send them one at a time without the C bit set. Is this true? When the C bit is not set, there appears to be no requirement in the standard that the receiver is forced to reply to the keys it has received at that time -- it MUST reply to every key eventually, but just having the C bit = 0 does not seem to require it to reply then -- it could send an empty reply PDU, or could offer new keys of its own at that time and delay responding to anything until "everything is on the table". Comments/corrections please. Thanks Bob Russell > Picking up on this in the middle of a thread, I > find the following reply from Bob Russell > interesting: > > > > It's > > > probably irrelevant, since due to the introduction > > > of the C-bit, parameters can be accumulated and > > > processed one "batch" at a time, without any > > > specific order within the "batch" and they will > > > quite likely not be processed PDU by PDU. > > > > I don't see this either. Nowhere does the newly added text > > describing the C-bit say anything about doing away with the > > specific order of the key=value pairs within the "batch". > > Why should it -- even if you don't process PDU by PDU you still > > have to process batch by batch, a batch still has to be scanned > > to find key=value pairs, and the natural way to scan is from the > > beginning of the batch, since the next key starts after the > > delimiter of the previous key in the batch. > > This is also a non-issue. > > Skimming over rev 12, I have not found the word "order" > applied in the context of processing a string of > key=value pairs. While they > must clearly be parsed linearly, it is perfectly reasonable > to process the parsed values in any order, or even in > a vendor-specific order than makes sense to a particular > target. That is why key=value pairs are used in the > first place, so that one does not have to worry about > ordering. In this context, batching would be normal behavior > and out of order processing within a batch would also be > normal behavior. If you want to order processing, you would > have to send them one at a time without the C bit set. From owner-ips@ece.cmu.edu Wed Jun 5 13:10:42 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07219 for ; Wed, 5 Jun 2002 13:10:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g55GkM915011 for ips-outgoing; Wed, 5 Jun 2002 12:46:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g55GkKw15007 for ; Wed, 5 Jun 2002 12:46:20 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g55GkCfm019412; Wed, 5 Jun 2002 18:46:12 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g55GkAn106986; Wed, 5 Jun 2002 18:46:11 +0200 To: "THALER,PAT (A-Roseville,ex1)" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: keys/parameter dependence X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 5 Jun 2002 19:46:07 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 05/06/2002 19:46:11, Serialize complete at 05/06/2002 19:46:11 Content-Type: multipart/alternative; boundary="=_alternative 005B820DC2256BCF_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005B820DC2256BCF_= Content-Type: text/plain; charset="us-ascii" There was never a requirement to respond immediately. Julo "THALER,PAT (A-Roseville,ex1)" Sent by: owner-ips@ece.cmu.edu 06/05/2002 03:23 AM Please respond to "THALER,PAT (A-Roseville,ex1)" To: "Robert D. Russell" , Robert Snively cc: ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence Bob, I agree. There is no requirement to respond to the keys received in the last batch in your next batch. Pat -----Original Message----- From: Robert D. Russell [mailto:rdr@io.iol.unh.edu] Sent: Monday, June 03, 2002 11:45 PM To: Robert Snively Cc: ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence Robert: You are, of course, absolutely correct. There is no mention in the current drafts of "order" applied to the processing of keys -- there used to be such an "order" requirement, but that went out when draft 8 came in, and is now ancient history. My apologies to the entire list for mistakenly bringing it back. I do, however, have a question about one small point in what you said: > If you want to order processing, you would > have to send them one at a time without the C bit set. Is this true? When the C bit is not set, there appears to be no requirement in the standard that the receiver is forced to reply to the keys it has received at that time -- it MUST reply to every key eventually, but just having the C bit = 0 does not seem to require it to reply then -- it could send an empty reply PDU, or could offer new keys of its own at that time and delay responding to anything until "everything is on the table". Comments/corrections please. Thanks Bob Russell > Picking up on this in the middle of a thread, I > find the following reply from Bob Russell > interesting: > > > > It's > > > probably irrelevant, since due to the introduction > > > of the C-bit, parameters can be accumulated and > > > processed one "batch" at a time, without any > > > specific order within the "batch" and they will > > > quite likely not be processed PDU by PDU. > > > > I don't see this either. Nowhere does the newly added text > > describing the C-bit say anything about doing away with the > > specific order of the key=value pairs within the "batch". > > Why should it -- even if you don't process PDU by PDU you still > > have to process batch by batch, a batch still has to be scanned > > to find key=value pairs, and the natural way to scan is from the > > beginning of the batch, since the next key starts after the > > delimiter of the previous key in the batch. > > This is also a non-issue. > > Skimming over rev 12, I have not found the word "order" > applied in the context of processing a string of > key=value pairs. While they > must clearly be parsed linearly, it is perfectly reasonable > to process the parsed values in any order, or even in > a vendor-specific order than makes sense to a particular > target. That is why key=value pairs are used in the > first place, so that one does not have to worry about > ordering. In this context, batching would be normal behavior > and out of order processing within a batch would also be > normal behavior. If you want to order processing, you would > have to send them one at a time without the C bit set. --=_alternative 005B820DC2256BCF_= Content-Type: text/html; charset="us-ascii"
There was never a requirement to respond immediately.

Julo


"THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>
Sent by: owner-ips@ece.cmu.edu

06/05/2002 03:23 AM
Please respond to "THALER,PAT (A-Roseville,ex1)"

       
        To:        "Robert D. Russell" <rdr@io.iol.unh.edu>, Robert Snively <rsnively@Brocade.COM>
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: keys/parameter dependence

       


Bob,

I agree. There is no requirement to respond to the keys received in the
last batch in your next batch.

Pat

-----Original Message-----
From: Robert D. Russell [mailto:rdr@io.iol.unh.edu]
Sent: Monday, June 03, 2002 11:45 PM
To: Robert Snively
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: keys/parameter dependence


Robert:

You are, of course, absolutely correct.  There is no mention
in the current drafts of "order" applied to the processing of keys
-- there used to be such an "order" requirement, but that went out
when draft 8 came in, and is now ancient history.

My apologies to the entire list for mistakenly bringing it back.

I do, however, have a question about one small point in what you said:

> If you want to order processing, you would
> have to send them one at a time without the C bit set.

Is this true?  When the C bit is not set, there appears to be
no requirement in the standard that the receiver is forced to
reply to the keys it has received at that time -- it MUST reply
to every key eventually, but just having the C bit = 0 does
not seem to require it to reply then -- it could send an empty
reply PDU, or could offer new keys of its own at that time
and delay responding to anything until "everything is on the
table".  Comments/corrections please.

Thanks
Bob Russell


> Picking up on this in the middle of a thread, I
> find the following reply from Bob Russell
> interesting:
>
> > > It's
> > > probably irrelevant, since due to the introduction
> > > of the C-bit, parameters can be accumulated and
> > > processed one "batch" at a time, without any
> > > specific order within the "batch" and they will
> > > quite likely not be processed PDU by PDU.
> >
> > I don't see this either.  Nowhere does the newly added text
> > describing the C-bit say anything about doing away with the
> > specific order of the key=value pairs within the "batch".
> > Why should it -- even if you don't process PDU by PDU you still
> > have to process batch by batch, a batch still has to be scanned
> > to find key=value pairs, and the natural way to scan is from the
> > beginning of the batch, since the next key starts after the
> > delimiter of the previous key in the batch.
> > This is also a non-issue.
>
> Skimming over rev 12, I have not found the word "order"
> applied in the context of processing a string of
> key=value pairs.  While they
> must clearly be parsed linearly, it is perfectly reasonable
> to process the parsed values in any order, or even in
> a vendor-specific order than makes sense to a particular
> target.  That is why key=value pairs are used in the
> first place, so that one does not have to worry about
> ordering.  In this context, batching would be normal behavior
> and out of order processing within a batch would also be
> normal behavior.  If you want to order processing, you would
> have to send them one at a time without the C bit set.

--=_alternative 005B820DC2256BCF_=-- From owner-ips@ece.cmu.edu Wed Jun 5 13:11:10 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07247 for ; Wed, 5 Jun 2002 13:11:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g55GYtf14163 for ips-outgoing; Wed, 5 Jun 2002 12:34:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g55GYqw14156; Wed, 5 Jun 2002 12:34:52 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g55GYkUN037126; Wed, 5 Jun 2002 18:34:46 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g55GYhn54898; Wed, 5 Jun 2002 18:34:44 +0200 To: Martins Krikis Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu, rdr@io.iol.unh.edu MIME-Version: 1.0 Subject: Re: iSCSI: keys/parameter dependence X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 5 Jun 2002 19:34:41 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 05/06/2002 19:34:45, Serialize complete at 05/06/2002 19:34:45 Content-Type: multipart/alternative; boundary="=_alternative 005A6076C2256BCF_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005A6076C2256BCF_= Content-Type: text/plain; charset="us-ascii" Almost everything is correct - except the mechanism for Very-Long-responses - (TTT). This is different than the spanning mechanism (C- bit) in the sense that has in theory no bounds (it was devised mainly for SendTargets but can be used by any mechanism that has to send a lot of data - not negotiations). Julo Martins Krikis Sent by: owner-ips@ece.cmu.edu 06/04/2002 10:24 PM Please respond to Martins Krikis To: ips@ece.cmu.edu, rdr@io.iol.unh.edu cc: Subject: Re: iSCSI: keys/parameter dependence Robert, I'm cutting text out to keep it shorter... > What you are saying seems to imply that C=0 does NOT > require the receiver to reply to keys received up to that point > -- it could send another empty PDU, or more likely, it could send > new offers of its own. I agree that there is nothing in the draft > that says when replies to keys should be sent, only that they > MUST be sent (sometime). Yes. The other side cannot be forced to send anything. > It would seem that the initiator might try to force replies by > setting T=1 to force an end-of-stage transition. However, the target > can refuse to make the transition and can reply with T=0 and still > no replies to the keys it was offered. > > This is admittedly a rather far-out example, because presumably both > initiator and target want to end the negotiations as soon as possible. > My point only is that I do not see anything in the draft that says > when the replies to keys have to be sent, only several references > that there MUST be a reply to every key offered (eventually). Yes, there is the possibility that one or both sides don't want to commit the negotiation and keep ping-ponging empty PDUs. Thus, implementations will likely be counting such request-response rounds and have some threshold value for how many times this can go on... > The dependency can be accounted for when generating the reply. > For example, > > reply.FirstBurstSize = min(offer.FirstBurstSize, reply.MaxBurstSize) > > That way nothing is broken when sending data. except that reply.MaxBurstSize may have to be substituted by current.MaxBurstSize or offer.MaxBurstSize or something like that... i.e., there can be chicken-and-egg problems, I think. I prefer negotiating each key individually, according to its type, allowed values, desired values, who may send it at the concrete stage of the negotiations, etc. I am not fond of the idea that it may be necessary to look at the (current or future) values of other keys in addition to what already has to be done for each key. > > And how many instances of TargetName and TargetAddress > > can the SendTargets command provoke from the other > > side? I think it can easily overflow the 8192 bytes. > > Yes it can, but there was already a mechanism in place to deal > with this. In fact, this brings up an interesting point. > Presumably the C bit has to be used with replies sent to > SendTargets (or any other offer that might generate a long reply), > since the C bit is in the Text Response PDU used to send these replies. Yes, it should. There was just an example of "long responses" in 9.10.4, but some people understood it to mean that empty PDUs going in the other direction are mandatory. For SendTargets there isn't much else the initiator can send anyways (?). Well, the empty PDUs of 9.10.4 weren't mandated yet when the discussions for C-bit started, but that's basically what the C-bit mandates. Would be nice to add it to the example of 9.10.4, too. > Refering to sections 9.10.2 and 9.10.4: If the target generating a > long reply has more text to send than will fit in one PDU, then it > should indicate this by setting C = 1. Setting C = 1 also forces F=0, > and this in turn forces the Target Transfer Tag to be something > other than 0xffffffff. Yes. > When there is no more text to send, > the target sets C = 0 and F = 1 and TTT=0xffffffff in the last > text response pdu it sends to the initiator. C = 0 yes, but F and TTT only if initiator set F and if the target is ready to commit. It may still be missing values from initiator, or just taking a break (:-)) for a couple request-response rounds. > There is no > situation in which C = 1 and F = 1 can occur (since this is > explicitly stated in 9.10.2 as being an error), Yes. > nor is there a > situation in which C = 0 and F = 0 should occur (because C = 0 > means "I'm done sending stuff" and F = 0 means "I'm not done sending > stuff"). This can occur. C=0 just means "I'm done with this "set of keys" ("batch"), now I'm willing to listen what you may have to say". It does not imply F=1, as the target may not be ready to commit yet. In fact, initiator need not have set F yet, so in fact target may be forbidden to set it. > Is this the way you interpret the merging of the C bit with the > long text reply mechanism? C-bit now IS the "long login/text request/reply mechanism". > If there is a consensus on this, > perhaps the wording in the draft in section 9.10.4 should include > the (required) settings of the C bit whenever it mentions the > corresponding settings of the F bit and TTT field. Perhaps something can be added, especially to the example there. > > > The existence of a dependency between OFMarker and > > > OFMarkInt, and between > > > IFMarker and IFMarkInt, is implied by the statements > > > in section A.3.2: > > > "When the interval is unacceptable the responder > > > answers with > > > "Reject". Reject is resetting the marker function > > > in the spcified > > > direction (Output or Input) to No." > > > > No it isn't. IMO, it is resetting the marker interval > > to its previous value, which is likely the default > > value. I believe it's perfectly legal to negotiate > > the marker interval but to not turn on marker use, > > or to turn on the use but stay with current (default) > > values for the interval. If one side can't tolerate > > the other's Reject (i.e., can't live with the > > default value), it is welcome to bail and try next > > time w/o markers. BTW, we could use 0 here as a > > special value, meaning that markers are not in use, > > then we wouldn't need the boolean keys for > > markers. > > > > > This last sentence should probably be reworded to > > > say: > > > "A response value of "Reject" to an OFMarkInt > > > (IFMarkInt) key resets the > > > corresponding OFMarker (IFMarker) key value to > > > "No"." > > > > No, thank you. I would prefer if Reject meant the > > same as with the other keys, i.e., negotiation > > failed for this key, let's stick with the old > > value, or bail if we must. > > Either the sentence needs to be reworded so it is proper English > or it should be taken out of the draft. I take it you are advocating > its removal? Oops. My mistake. I hadn't even read the sentence about "Reject" that is in the draft currently. I have no objections to English there, but I don't like that Reject is "resetting the marker function to no", since that certainly introduces a dependency, and I understand that it is legal to treat the other Rejects as "stick to the old value"., I would like this Reject to allow the same interpretation, i.e., not require to touch any other keys immediately. Using 0 as a special value for intervals also has a drawback---it can be a value "out of range", to be returned. Suggestions? Martins Krikis, Intel Corp. Disclaimer: my opinions, not necessarily Intel's. --=_alternative 005A6076C2256BCF_= Content-Type: text/html; charset="us-ascii"
Almost everything is correct - except the mechanism for Very-Long-responses - (TTT).
This is different than the spanning mechanism (C- bit) in the sense that has in theory no bounds (it was devised mainly for SendTargets but can be used by any mechanism that has to send a lot of data - not negotiations).

Julo


Martins Krikis <mkrikis@yahoo.com>
Sent by: owner-ips@ece.cmu.edu

06/04/2002 10:24 PM
Please respond to Martins Krikis

       
        To:        ips@ece.cmu.edu, rdr@io.iol.unh.edu
        cc:        
        Subject:        Re: iSCSI: keys/parameter dependence

       


Robert,

I'm cutting text out to keep it shorter...

> What you are saying seems to imply that C=0 does NOT
> require the receiver to reply to keys received up to that point
> -- it could send another empty PDU, or more likely, it could send
> new offers of its own.  I agree that there is nothing in the draft
> that says when replies to keys should be sent, only that they
> MUST be sent (sometime).

Yes. The other side cannot be forced to send anything.

> It would seem that the initiator might try to force replies by
> setting T=1 to force an end-of-stage transition.  However, the target
> can refuse to make the transition and can reply with T=0 and still
> no replies to the keys it was offered.
>
> This is admittedly a rather far-out example, because presumably both
> initiator and target want to end the negotiations as soon as possible.
> My point only is that I do not see anything in the draft that says
> when the replies to keys have to be sent, only several references
> that there MUST be a reply to every key offered (eventually).

Yes, there is the possibility that one or both sides don't want
to commit the negotiation and keep ping-ponging empty PDUs. Thus,
implementations will likely be counting such request-response rounds
and have some threshold value for how many times this can go on...

> The dependency can be accounted for when generating the reply.
> For example,
>
> reply.FirstBurstSize = min(offer.FirstBurstSize, reply.MaxBurstSize)
>
> That way nothing is broken when sending data.

except that reply.MaxBurstSize may have to be substituted by
current.MaxBurstSize or offer.MaxBurstSize or something like that...
i.e., there can be chicken-and-egg problems, I think. I prefer
negotiating each key individually, according to its type, allowed
values, desired values, who may send it at the concrete stage
of the negotiations, etc. I am not fond of the idea that it may
be necessary to look at the (current or future) values of other keys
in addition to what already has to be done for each key.

> > And how many instances of TargetName and TargetAddress
> > can the SendTargets command provoke from the other
> > side? I think it can easily overflow the 8192 bytes.
>
> Yes it can, but there was already a mechanism in place to deal
> with this.  In fact, this brings up an interesting point.
> Presumably the C bit has to be used with replies sent to
> SendTargets (or any other offer that might generate a long reply),
> since the C bit is in the Text Response PDU used to send these replies.

Yes, it should. There was just an example of "long responses" in 9.10.4,
but some people understood it to mean that empty PDUs going in the
other direction are mandatory. For SendTargets there isn't much
else the initiator can send anyways (?). Well, the empty PDUs
of 9.10.4 weren't mandated yet when the discussions for C-bit
started, but that's basically what the C-bit mandates. Would
be nice to add it to the example of 9.10.4, too.

> Refering to sections 9.10.2 and 9.10.4:  If the target generating a
> long reply has more text to send than will fit in one PDU, then it
> should indicate this by setting C = 1.  Setting C = 1 also forces F=0,
> and this in turn forces the Target Transfer Tag to be something
> other than 0xffffffff.  

Yes.

> When there is no more text to send,
> the target sets C = 0 and F = 1 and TTT=0xffffffff in the last
> text response pdu it sends to the initiator.

C = 0 yes, but F and TTT only if initiator set F and if the
target is ready to commit. It may still be missing values
from initiator, or just taking a break (:-)) for a couple
request-response rounds.

> There is no
> situation in which C = 1 and F = 1 can occur (since this is
> explicitly stated in 9.10.2 as being an error),

Yes.

> nor is there a
> situation in which C = 0 and F = 0 should occur (because C = 0
> means "I'm done sending stuff" and F = 0 means "I'm not done sending
> stuff").

This can occur. C=0 just means "I'm done with this "set of keys" ("batch"),
now I'm willing to listen what you may have to say". It does not imply
F=1, as the target may not be ready to commit yet. In fact, initiator
need not have set F yet, so in fact target may be forbidden to set it.

> Is this the way you interpret the merging of the C bit with the
> long text reply mechanism?  

C-bit now IS the "long login/text request/reply mechanism".

> If there is a consensus on this,
> perhaps the wording in the draft in section 9.10.4 should include
> the (required) settings of the C bit whenever it mentions the
> corresponding settings of the F bit and TTT field.

Perhaps something can be added, especially to the example there.

> > > The existence of a dependency between OFMarker and
> > > OFMarkInt, and between
> > > IFMarker and IFMarkInt, is implied by the statements
> > > in section A.3.2:
> > > "When the interval is unacceptable the responder
> > > answers with
> > > "Reject".  Reject is resetting the marker function
> > > in the spcified
> > > direction (Output or Input) to No."
> >
> > No it isn't. IMO, it is resetting the marker interval
> > to its previous value, which is likely the default
> > value. I believe it's perfectly legal to negotiate
> > the marker interval but to not turn on marker use,
> > or to turn on the use but stay with current (default)
> > values for the interval. If one side can't  tolerate
> > the other's  Reject (i.e., can't live with the
> > default value), it is welcome to bail and try next
> > time w/o markers. BTW, we could use 0 here as a
> > special value, meaning that markers are not in use,
> > then we wouldn't need the boolean keys for
> > markers.
> >
> > > This last sentence should probably be reworded to
> > > say:
> > > "A response value of "Reject" to an OFMarkInt
> > > (IFMarkInt) key resets the
> > > corresponding OFMarker (IFMarker) key value to
> > > "No"."
> >
> > No, thank you. I would prefer if Reject meant the
> > same as with the other keys, i.e., negotiation
> > failed for this key, let's stick with the old
> > value, or bail if we must.
>
> Either the sentence needs to be reworded so it is proper English
> or it should be taken out of the draft.  I take it you are advocating
> its removal?

Oops. My mistake. I hadn't even read the sentence about "Reject"
that is in the draft currently. I have no objections to English
there, but I don't like that Reject is "resetting the marker function
to no", since that certainly introduces a dependency, and I understand
that it is legal to treat the other Rejects as "stick to the old value".,
I would like this Reject to allow the same interpretation, i.e., not
require to touch any other keys immediately. Using 0 as a special value
for intervals also has a drawback---it can be a value "out of range",
to be returned. Suggestions?

Martins Krikis, Intel Corp.

Disclaimer: my opinions, not necessarily Intel's.

--=_alternative 005A6076C2256BCF_=-- From owner-ips@ece.cmu.edu Wed Jun 5 13:15:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07517 for ; Wed, 5 Jun 2002 13:15:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g55GMtA13239 for ips-outgoing; Wed, 5 Jun 2002 12:22:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g55GMqw13234 for ; Wed, 5 Jun 2002 12:22:52 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g55GMjfm011786; Wed, 5 Jun 2002 18:22:45 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g55GMfn106784; Wed, 5 Jun 2002 18:22:43 +0200 To: Jeff Fellin Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: keys/parameter dependence X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 5 Jun 2002 19:22:39 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 05/06/2002 19:22:43, Serialize complete at 05/06/2002 19:22:43 Content-Type: multipart/alternative; boundary="=_alternative 00587516C2256BCF_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00587516C2256BCF_= Content-Type: text/plain; charset="us-ascii" Jeff, We had a statement about dependencies that we now deferred to individual keys (as it is explicit in the security exchanges). For operational parameters we have 2 choices: State the dependency and force ordering Take all values and check before committing Taking into consideration that a negotiation is atomic - i.e., failure must return ALL values to the status before and as such we have to keep them and that most of the dependencies are of a kind that can be checked at the end and rather trivial it looks to me that 2 is slightly better than 1. Julo Jeff Fellin 06/04/2002 08:36 PM Please respond to Jeff Fellin To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: iSCSI: keys/parameter dependence Julian, I never saw any place in the document when or if consistency was done. By your proposing a final last stage consistency check to end the negotiation appears to be adding semantics that are not present to eliminate the issue of parameters having consistency requirements. When the definition of the parameters, for example FirstBurstSize MUST NOT exceed MaxBurstSize implies that when FirstBurstSize is received the value CANNOT exceed the current value of MaxBurstSize, the the value of MaxBurstSize at some later point in time. The state transistions for Login do not mention this overall parameter value consistency check, so how can you state it was already present. Jeff Fellin Bell Labs > From owner-ips@ece.cmu.edu Tue Jun 4 13:08:42 2002 > X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f > To: "Robert D. Russell" > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI: keys/parameter dependence > From: "Julian Satran" > Date: Tue, 4 Jun 2002 20:06:55 +0300 > X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at > 04/06/2002 20:06:56, > Serialize complete at 04/06/2002 20:06:56 > Content-Type: multipart/alternative; boundary="=_alternative 005D5E07C2256BCE_=" > Sender: owner-ips@ece.cmu.edu > Precedence: bulk > X-Lines: 192 > Content-Length: 7481 > > Bob, > > Thanks. That matches my list although I have a somewhat different > approach to some of them. > > 1. FirstBurstSize - MaxburstSize is not exactly a dependency as it means > only that the negotiated values have to relate to each other > at commit time or you have negotiation failure (login failure) > > 2 & 3 as above. > > I think tact we may want to say somewhere that value consistency to the > rules is to be determined a the end of the negotiation. > > Thanks, > Julo > > > > > > "Robert D. Russell" > 06/04/2002 11:13 AM > Please respond to "Robert D. Russell" > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: RE: iSCSI: keys/parameter dependence > > > > Julian: > > I have found the following dependencies between keys in draft 12-96, > and would ask other people on the mailing list to contribute others > they have found so we can all be aware of the complete set. > > There seem to be very few dependencies, which I believe is a credit > to a clean, orthogonal design. > > With a bit of work, we could probably get rid of all the dependencies > between the OFMarkInt (IFMarkInt) and OFMarker (IFMarker) keys, perhaps, > as suggested by Martins Krikis, by eliminating the OFMarker (IFMarker) > key and substituting a default (and response) value of 0 for the > OFMarkInt (IFMarkInt) to mean "no markers in that direction". > > This would also eliminate the need for a "Reject" reply to an OFMarkInt > (IFMarkInt) offer. > > > "Meaningful" dependencies (i.e., those that cannot be ignored because > they effect operation): > > 1. Between FirstBurstSize and MaxBurstSize > Section 11.15: "FirstBurstSize MUST NOT exceed MaxBurstSize." > > 2. Between OFMarkInt (IFMarkInt) and OFMarker (IFMarker) > Section A.3.2: "When the interval (in an OFMarkInt (IFMarkInt) > offer) is unacceptable the responder answers with "Reject". > Reject is resetting the marker function (i.e., OFMarker > (IFMarker)) in the specified direction (Output or Input) to No." > > 3. Between SessionType and MaxConnections > Section 11.22: "The discovery session implies MaxConnections = 1 > and overrides both the default and an explicit setting." > > > "Trivial" dependencies (i.e., those that only allow the option of > replying with "Irrelevant" instead of a normally selected value, and > therefore can be ignored). > > 1. Between FirstBurstSize, InitialR2T, and ImmediateData > The table in section 11.12 implies that the combination > InitialR2T=Yes and ImmediateData=No allows the response > FirstBurstSize=Irrelevant. > > 2. Between OFMarker (IFMarker) and OFMarkInt (IFMarkInt). > Sections A.3.1 and A.3.2 imply that OFMarker=No (IFMarker=No) > allows the response OFMarkInt=Irrelevant (IFMarkInt=Irrelevant). > > > > Bob Russell > InterOperability Lab > University of New Hampshire > rdr@iol.unh.edu > 603-862-3774 > > > --=_alternative 00587516C2256BCF_= Content-Type: text/html; charset="us-ascii"
Jeff,

We had a statement about dependencies that we now deferred to individual keys (as it is explicit in the security exchanges).
For operational parameters we have 2 choices:
  1. State the dependency and force ordering
  2. Take all values and check before committing


    Taking into consideration that a negotiation is atomic - i.e., failure must return ALL values to the status before and as such we have to keep them
    and that most of the dependencies are of a kind that can be checked at the end and rather trivial it looks to me that 2 is slightly better than 1.

    Julo


    Jeff Fellin <jkf@research.bell-labs.com>

    06/04/2002 08:36 PM
    Please respond to Jeff Fellin

    		       
            To:        Julian Satran/Haifa/IBM@IBMIL
            cc:        
            Subject:        RE: iSCSI: keys/parameter dependence

           


    Julian,
    I never saw any place in the document when or if consistency was done. By your
    proposing a final last stage consistency check to end the negotiation appears
    to be adding semantics that are not present to eliminate the issue of parameters
    having consistency requirements. When the definition of the parameters, for example
    FirstBurstSize MUST NOT exceed MaxBurstSize implies that when FirstBurstSize is received
    the value CANNOT exceed the current value of MaxBurstSize, the the value of MaxBurstSize
    at some later point in time. The state transistions for Login do not mention this
    overall parameter value consistency check, so how can you state it was already present.

    Jeff Fellin
    Bell Labs

    > From owner-ips@ece.cmu.edu Tue Jun  4 13:08:42 2002
    > X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
    > To: "Robert D. Russell" <rdr@io.iol.unh.edu>
    > Cc: ips@ece.cmu.edu
    > Subject: RE: iSCSI: keys/parameter dependence
    > From: "Julian Satran" <Julian_Satran@il.ibm.com>
    > Date: Tue, 4 Jun 2002 20:06:55 +0300
    > X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at
    >  04/06/2002 20:06:56,
    >                  Serialize complete at 04/06/2002 20:06:56
    > Content-Type: multipart/alternative; boundary="=_alternative 005D5E07C2256BCE_="
    > Sender: owner-ips@ece.cmu.edu
    > Precedence: bulk
    > X-Lines: 192
    > Content-Length: 7481
    >
    > Bob,
    >
    > Thanks.  That matches my list although I have a somewhat different
    > approach to some of them.
    >
    > 1. FirstBurstSize - MaxburstSize is not exactly a dependency as it means
    > only that the negotiated values have to relate to each other
    > at commit time or you have negotiation failure (login failure)
    >
    > 2 & 3 as above.
    >
    > I think tact we may want to say somewhere that value consistency to the
    > rules is to be determined a the end of the negotiation.
    >
    > Thanks,
    > Julo
    >
    >
    >
    >
    >
    > "Robert D. Russell" <rdr@io.iol.unh.edu>
    > 06/04/2002 11:13 AM
    > Please respond to "Robert D. Russell"
    >
    >  
    >         To:     Julian Satran/Haifa/IBM@IBMIL
    >         cc:     ips@ece.cmu.edu
    >         Subject:        RE: iSCSI: keys/parameter dependence
    >
    >  
    >
    > Julian:
    >
    > I have found the following dependencies between keys in draft 12-96,
    > and would ask other people on the mailing list to contribute others
    > they have found so we can all be aware of the complete set.
    >
    > There seem to be very few dependencies, which I believe is a credit
    > to a clean, orthogonal design.
    >
    > With a bit of work, we could probably get rid of all the dependencies
    > between the OFMarkInt (IFMarkInt) and OFMarker (IFMarker) keys, perhaps,
    > as suggested by Martins Krikis, by eliminating the OFMarker (IFMarker)
    > key and substituting a default (and response) value of 0 for the
    > OFMarkInt (IFMarkInt) to mean "no markers in that direction".
    >
    > This would also eliminate the need for a "Reject" reply to an OFMarkInt
    > (IFMarkInt) offer.
    >
    >
    > "Meaningful" dependencies (i.e., those that cannot be ignored because
    > they effect operation):
    >
    > 1.  Between FirstBurstSize and MaxBurstSize
    >       Section 11.15: "FirstBurstSize MUST NOT exceed MaxBurstSize."
    >
    > 2.  Between OFMarkInt (IFMarkInt) and OFMarker (IFMarker)
    >       Section A.3.2: "When the interval (in an OFMarkInt (IFMarkInt)
    >       offer) is unacceptable the responder answers with "Reject".
    >       Reject is resetting the marker function (i.e., OFMarker
    >       (IFMarker)) in the specified direction (Output or Input) to No."
    >
    > 3.  Between SessionType and MaxConnections
    >       Section 11.22: "The discovery session implies MaxConnections = 1
    >       and overrides both the default and an explicit setting."
    >
    >
    > "Trivial" dependencies (i.e., those that only allow the option of
    > replying with "Irrelevant" instead of a normally selected value, and
    > therefore can be ignored).
    >
    > 1.  Between FirstBurstSize, InitialR2T, and ImmediateData
    >       The table in section 11.12 implies that the combination
    >       InitialR2T=Yes and ImmediateData=No allows the response
    >       FirstBurstSize=Irrelevant.
    >
    > 2.  Between OFMarker (IFMarker) and OFMarkInt (IFMarkInt).
    >       Sections A.3.1 and A.3.2 imply that OFMarker=No (IFMarker=No)
    >       allows the response OFMarkInt=Irrelevant (IFMarkInt=Irrelevant).
    >
    >
    >
    > Bob Russell
    > InterOperability Lab
    > University of New Hampshire
    > rdr@iol.unh.edu
    > 603-862-3774
    >
    >
    >


--=_alternative 00587516C2256BCF_=-- From owner-ips@ece.cmu.edu Wed Jun 5 13:59:32 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09427 for ; Wed, 5 Jun 2002 13:59:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g55HLTx17741 for ips-outgoing; Wed, 5 Jun 2002 13:21:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g55HLQw17735 for ; Wed, 5 Jun 2002 13:21:26 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g55HLHvk022748; Wed, 5 Jun 2002 19:21:18 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g55HLGn45450; Wed, 5 Jun 2002 19:21:16 +0200 To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI CRC inconsistency X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 5 Jun 2002 20:21:14 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 05/06/2002 20:21:16, Serialize complete at 05/06/2002 20:21:16 Content-Type: multipart/alternative; boundary="=_alternative 005EF156C2256BCF_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005EF156C2256BCF_= Content-Type: text/plain; charset="us-ascii" ... and I know the examples are correct - I run them through two programs ! - Julo pat_thaler@agilent.com 06/04/2002 11:31 PM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: iSCSI CRC inconsistency Julian, There is an inconsistency in the description of the CRC32. In 11.1, the final paragraph on page 207 is incorrect. The paragraph says: - The CRC bits appear after the message bits with x^31 first followed by x^30 etc. (when examples are provided, the value to be specified in the examples follows the same ordering as the rest of this document). At the top of the next page, it describes the magic number CRC check where one runs the CRC generator over the data or header plus the received digest and gets the magic number: - A receiver of a "good" segment (data or header) including the CRC built using the generator 0x11edc6f41 will get the value 0x1c2d19ed as its CRC (this is a polynomial value and not a word as outlined in this draft). The point of the magic number algorithm is that it uses exactly the same algorithm to check the CRC that was used to generate the CRC. When running the check, the received CRC is run through the generator with the same bit order as the covered data. Therefore, this check only works right when the CRC is appended to the data using the same bit ordering within a word as was used when sending the covered data through the CRC generator. The examples in B.4 show the bits ordered as they should be and page 207 is inconsistent with them.. Specifically, data bits go through the generator from byte 0 to byte 3 of the word with each bit going through bit 7 to bit 0. Therefore, paragraph on how the CRC bits are placed in the field should be: - The CRC bits appear after the message bits with the x^31 coefficient in bit 7 of the first byte (byte 0) of the digest continuing to through the byte the x^24 coefficient in bit 0 of byte 0, continuing with the x^23 coefficient in bit 7 of byte 1, etc. (When examples are provided they show the CRC as it appears in the PDU with the bit significance used throughout this document. That is, bit 7 of each byte is interpreted as most significant though it is the coefficient of the lowest order CRC term in the byte.). I have checked and this order matches the examples in B.4. Regards, Pat --=_alternative 005EF156C2256BCF_= Content-Type: text/html; charset="us-ascii"
... and I know the examples are correct - I run them through two programs ! - Julo


pat_thaler@agilent.com

06/04/2002 11:31 PM
Please respond to pat_thaler

       
        To:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI CRC inconsistency

       


Julian,

There is an inconsistency in the description of the CRC32. In 11.1, the final paragraph on page 207 is incorrect. The paragraph says:
- The CRC bits appear after the message bits with x^31 first
followed by x^30 etc. (when examples are provided, the value
to be specified in the examples follows the same
ordering as the rest of this document).

At the top of the next page, it describes the magic number CRC check where one runs the CRC generator over the data or header plus the received digest and gets the magic number:
- A receiver of a "good" segment (data or header) including the
CRC built using the generator 0x11edc6f41 will get the value
0x1c2d19ed as its CRC (this is a polynomial value and not a
word as outlined in this draft).

The point of the magic number algorithm is that it uses exactly the same algorithm to check the CRC that was used to generate the CRC. When running the check, the received CRC is run through the generator with the same bit order as the covered data. Therefore, this check only works right when the CRC is appended to the data using the same bit ordering within a word as was used when sending the covered data through the CRC generator. The examples in B.4 show the bits ordered as they should be and page 207 is inconsistent with them..

Specifically, data bits go through the generator from byte 0 to byte 3 of the word with each bit going through bit 7 to bit 0. Therefore, paragraph on how the CRC bits are placed in the field should be:
- The CRC bits appear after the message bits with the x^31 coefficient in bit 7 of the first byte (byte 0) of the digest continuing to through the byte the x^24 coefficient in bit 0 of byte 0, continuing with the x^23 coefficient in bit 7 of byte 1, etc. (When examples are provided they show the CRC as it appears in the PDU with the bit significance used throughout this document. That is, bit 7 of each byte is interpreted as most significant though it is the coefficient of the lowest order CRC term in the byte.).

I have checked and this order matches the examples in B.4.

Regards,
Pat

--=_alternative 005EF156C2256BCF_=-- From owner-ips@ece.cmu.edu Wed Jun 5 14:00:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09516 for ; Wed, 5 Jun 2002 14:00:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g55HJPV17589 for ips-outgoing; Wed, 5 Jun 2002 13:19:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g55HJNw17584 for ; Wed, 5 Jun 2002 13:19:23 -0400 (EDT) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g55HJNEF041686; Wed, 5 Jun 2002 13:19:23 -0400 (EDT) Received: from aura.research.bell-labs.com (aura.research.bell-labs.com [135.104.46.10]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g55HJGo22181; Wed, 5 Jun 2002 13:19:16 -0400 (EDT) Received: from research.bell-labs.com (philmac-pcmh1.research.bell-labs.com [135.104.54.81]) by aura.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g55HJF9m019495; Wed, 5 Jun 2002 13:19:15 -0400 (EDT) Message-ID: <3CFE4C18.3040203@research.bell-labs.com> Date: Wed, 05 Jun 2002 13:36:24 -0400 From: Philip MacKenzie Organization: Bell Labs, Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Bernard Aboba CC: ips@ece.cmu.edu Subject: Re: Security -13 draft References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > A -13 version of the security draft is available for your examination at: > > http://www.drizzle.com/~aboba/IPS/draft-ietf-ips-security-13.txt > > Since this is potentially the version that will go to WG last call, a careful reading is encouraged. This seemed odd to me: SRP is given what seems like an offhand comment in section 5.8.3, which seems totally incongruous to the laborious SRP implementation details given in section 5.10 and Appendix A. Why all the details for something that's just mentioned in passing as an alternative authentication method? Also, why in section 5.8.3 is CHAP not mentioned, given that it is the MUST implement method? -Phil From owner-ips@ece.cmu.edu Wed Jun 5 14:00:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09542 for ; Wed, 5 Jun 2002 14:00:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g55HLUL17748 for ips-outgoing; Wed, 5 Jun 2002 13:21:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g55HLSw17740 for ; Wed, 5 Jun 2002 13:21:28 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g55HLKUN035980; Wed, 5 Jun 2002 19:21:20 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g55HLHn106836; Wed, 5 Jun 2002 19:21:18 +0200 To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI CRC inconsistency X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 5 Jun 2002 20:21:14 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 05/06/2002 20:21:19, Serialize complete at 05/06/2002 20:21:19 Content-Type: multipart/alternative; boundary="=_alternative 005EBF55C2256BCF_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005EBF55C2256BCF_= Content-Type: text/plain; charset="us-ascii" Pat, I was referring to a hypothetical wire order and that matches the order I stated in the first list element. I will try to map it to the word order as the wire order is not relevant anyhow. The magical number is however a polynomial and not a word mapping. Julo pat_thaler@agilent.com 06/04/2002 11:31 PM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: iSCSI CRC inconsistency Julian, There is an inconsistency in the description of the CRC32. In 11.1, the final paragraph on page 207 is incorrect. The paragraph says: - The CRC bits appear after the message bits with x^31 first followed by x^30 etc. (when examples are provided, the value to be specified in the examples follows the same ordering as the rest of this document). At the top of the next page, it describes the magic number CRC check where one runs the CRC generator over the data or header plus the received digest and gets the magic number: - A receiver of a "good" segment (data or header) including the CRC built using the generator 0x11edc6f41 will get the value 0x1c2d19ed as its CRC (this is a polynomial value and not a word as outlined in this draft). The point of the magic number algorithm is that it uses exactly the same algorithm to check the CRC that was used to generate the CRC. When running the check, the received CRC is run through the generator with the same bit order as the covered data. Therefore, this check only works right when the CRC is appended to the data using the same bit ordering within a word as was used when sending the covered data through the CRC generator. The examples in B.4 show the bits ordered as they should be and page 207 is inconsistent with them.. Specifically, data bits go through the generator from byte 0 to byte 3 of the word with each bit going through bit 7 to bit 0. Therefore, paragraph on how the CRC bits are placed in the field should be: - The CRC bits appear after the message bits with the x^31 coefficient in bit 7 of the first byte (byte 0) of the digest continuing to through the byte the x^24 coefficient in bit 0 of byte 0, continuing with the x^23 coefficient in bit 7 of byte 1, etc. (When examples are provided they show the CRC as it appears in the PDU with the bit significance used throughout this document. That is, bit 7 of each byte is interpreted as most significant though it is the coefficient of the lowest order CRC term in the byte.). I have checked and this order matches the examples in B.4. Regards, Pat --=_alternative 005EBF55C2256BCF_= Content-Type: text/html; charset="us-ascii"
Pat,

I was referring to a hypothetical wire order and that matches the order I stated in the first list element.
I will try to map it to the word order as the wire order is not relevant anyhow.
The magical number is however a polynomial and not a word mapping.

Julo


pat_thaler@agilent.com

06/04/2002 11:31 PM
Please respond to pat_thaler

       
        To:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI CRC inconsistency

       


Julian,

There is an inconsistency in the description of the CRC32. In 11.1, the final paragraph on page 207 is incorrect. The paragraph says:
- The CRC bits appear after the message bits with x^31 first
followed by x^30 etc. (when examples are provided, the value
to be specified in the examples follows the same
ordering as the rest of this document).

At the top of the next page, it describes the magic number CRC check where one runs the CRC generator over the data or header plus the received digest and gets the magic number:
- A receiver of a "good" segment (data or header) including the
CRC built using the generator 0x11edc6f41 will get the value
0x1c2d19ed as its CRC (this is a polynomial value and not a
word as outlined in this draft).

The point of the magic number algorithm is that it uses exactly the same algorithm to check the CRC that was used to generate the CRC. When running the check, the received CRC is run through the generator with the same bit order as the covered data. Therefore, this check only works right when the CRC is appended to the data using the same bit ordering within a word as was used when sending the covered data through the CRC generator. The examples in B.4 show the bits ordered as they should be and page 207 is inconsistent with them..

Specifically, data bits go through the generator from byte 0 to byte 3 of the word with each bit going through bit 7 to bit 0. Therefore, paragraph on how the CRC bits are placed in the field should be:
- The CRC bits appear after the message bits with the x^31 coefficient in bit 7 of the first byte (byte 0) of the digest continuing to through the byte the x^24 coefficient in bit 0 of byte 0, continuing with the x^23 coefficient in bit 7 of byte 1, etc. (When examples are provided they show the CRC as it appears in the PDU with the bit significance used throughout this document. That is, bit 7 of each byte is interpreted as most significant though it is the coefficient of the lowest order CRC term in the byte.).

I have checked and this order matches the examples in B.4.

Regards,
Pat

--=_alternative 005EBF55C2256BCF_=-- From owner-ips@ece.cmu.edu Wed Jun 5 14:01:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09607 for ; Wed, 5 Jun 2002 14:01:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g55Ho1019770 for ips-outgoing; Wed, 5 Jun 2002 13:50:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g55Hnww19764 for ; Wed, 5 Jun 2002 13:49:58 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 1C2F9BBD1; Wed, 5 Jun 2002 11:49:58 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1.cos.agilent.com (Postfix) with SMTP id D536215C; Wed, 5 Jun 2002 11:49:57 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 05 Jun 2002 11:49:42 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Jun 2002 11:49:42 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C354159@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: jkf@research.bell-labs.com, Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: connection definition Date: Wed, 5 Jun 2002 11:49:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Jeff, I don't think the definition means that an iSCSI connection is one or more TCP connections. The problem is the definition is not in the usual definition form:"A connection is ...." and it never uses the word connection except as part of TCP connection. This could be fixed by: Connection: A connection is a TCP connection. Communication between .... Pat -----Original Message----- From: Jeff Fellin [mailto:jkf@research.bell-labs.com] Sent: Tuesday, June 04, 2002 11:08 AM To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: iSCSI: connection definition Julian, I am confused by the definition of Connection in section 1.1. The definition states a Connection is the communication between the initiator and target occuring over one or more TCP connections. However by the definition of the CID (Connection ID): Connections within a session are identified by a connection ID, which is unique ID within the session. In Section 5.1.3, state S2 for the initiator is waiting for a response to its transport connection establishment request. In section 5.1.4, state S2 changes to state S4, when the transport connection is established. The description for the Login PDU in section 9.12 states the Login is on every TCP connection. Since each Login Request PDU must contain a unique CID cause logout of the existing non-zero TSIH (assuming to be part of the same session) causes a logout of the connection as described in Section 4.3. So is the definition of Connection in Section 1.1 incorrect in stating a connection is possibly multiple TCP connections or is there some other method of having multiple TCP connections between an initiator and target with the same CID and non-zero TSIH? Thank you for your clarification. Jeff Fellin Bell Labs From owner-ips@ece.cmu.edu Wed Jun 5 14:01:28 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09620 for ; Wed, 5 Jun 2002 14:01:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g55HSpe18354 for ips-outgoing; Wed, 5 Jun 2002 13:28:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g55HSnw18349 for ; Wed, 5 Jun 2002 13:28:49 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 9DB71BBD1; Wed, 5 Jun 2002 11:28:48 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 80C0C2AC; Wed, 5 Jun 2002 11:28:48 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 05 Jun 2002 11:28:48 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Jun 2002 11:28:48 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C354141@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com, pat_thaler@agilent.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI CRC inconsistency Date: Wed, 5 Jun 2002 11:28:46 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-f139c003-44df-4256-bd1f-e8b4b8ac91e2" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-f139c003-44df-4256-bd1f-e8b4b8ac91e2 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20CB6.7294A2C0" ------_=_NextPart_001_01C20CB6.7294A2C0 Content-Type: text/plain; charset="iso-8859-1" Julian, Yes, magic number is stated in polynomial order and the accompanying text says that so I have no problem with the magic number text. It is only the description of how the CRC is placed into the message that needs correction/clarification. As you say, hypothetical wire order is not relevant. We need to specify with respect to iSCSI's defined word order. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 05, 2002 10:21 AM To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI CRC inconsistency Pat, I was referring to a hypothetical wire order and that matches the order I stated in the first list element. I will try to map it to the word order as the wire order is not relevant anyhow. The magical number is however a polynomial and not a word mapping. Julo pat_thaler@agilent.com 06/04/2002 11:31 PM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: iSCSI CRC inconsistency Julian, There is an inconsistency in the description of the CRC32. In 11.1, the final paragraph on page 207 is incorrect. The paragraph says: - The CRC bits appear after the message bits with x^31 first followed by x^30 etc. (when examples are provided, the value to be specified in the examples follows the same ordering as the rest of this document). At the top of the next page, it describes the magic number CRC check where one runs the CRC generator over the data or header plus the received digest and gets the magic number: - A receiver of a "good" segment (data or header) including the CRC built using the generator 0x11edc6f41 will get the value 0x1c2d19ed as its CRC (this is a polynomial value and not a word as outlined in this draft). The point of the magic number algorithm is that it uses exactly the same algorithm to check the CRC that was used to generate the CRC. When running the check, the received CRC is run through the generator with the same bit order as the covered data. Therefore, this check only works right when the CRC is appended to the data using the same bit ordering within a word as was used when sending the covered data through the CRC generator. The examples in B.4 show the bits ordered as they should be and page 207 is inconsistent with them.. Specifically, data bits go through the generator from byte 0 to byte 3 of the word with each bit going through bit 7 to bit 0. Therefore, paragraph on how the CRC bits are placed in the field should be: - The CRC bits appear after the message bits with the x^31 coefficient in bit 7 of the first byte (byte 0) of the digest continuing to through the byte the x^24 coefficient in bit 0 of byte 0, continuing with the x^23 coefficient in bit 7 of byte 1, etc. (When examples are provided they show the CRC as it appears in the PDU with the bit significance used throughout this document. That is, bit 7 of each byte is interpreted as most significant though it is the coefficient of the lowest order CRC term in the byte.). I have checked and this order matches the examples in B.4. Regards, Pat ------_=_NextPart_001_01C20CB6.7294A2C0 Content-Type: text/html; charset="iso-8859-1"
Julian,
 
Yes, magic number is stated in polynomial order and the accompanying text says that so I have no
problem with the magic number text.
 
It is only the description of how the CRC is placed into the message that needs correction/clarification.
As you say, hypothetical wire order is not relevant. We need to specify with respect to iSCSI's defined
word order.
 
Regards,
Pat
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 05, 2002 10:21 AM
To: pat_thaler@agilent.com
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI CRC inconsistency


Pat,

I was referring to a hypothetical wire order and that matches the order I stated in the first list element.
I will try to map it to the word order as the wire order is not relevant anyhow.
The magical number is however a polynomial and not a word mapping.

Julo


pat_thaler@agilent.com

06/04/2002 11:31 PM
Please respond to pat_thaler

       
        To:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI CRC inconsistency

       


Julian,

There is an inconsistency in the description of the CRC32. In 11.1, the final paragraph on page 207 is incorrect. The paragraph says:
- The CRC bits appear after the message bits with x^31 first
followed by x^30 etc. (when examples are provided, the value
to be specified in the examples follows the same
ordering as the rest of this document).

At the top of the next page, it describes the magic number CRC check where one runs the CRC generator over the data or header plus the received digest and gets the magic number:
- A receiver of a "good" segment (data or header) including the
CRC built using the generator 0x11edc6f41 will get the value
0x1c2d19ed as its CRC (this is a polynomial value and not a
word as outlined in this draft).

The point of the magic number algorithm is that it uses exactly the same algorithm to check the CRC that was used to generate the CRC. When running the check, the received CRC is run through the generator with the same bit order as the covered data. Therefore, this check only works right when the CRC is appended to the data using the same bit ordering within a word as was used when sending the covered data through the CRC generator. The examples in B.4 show the bits ordered as they should be and page 207 is inconsistent with them..

Specifically, data bits go through the generator from byte 0 to byte 3 of the word with each bit going through bit 7 to bit 0. Therefore, paragraph on how the CRC bits are placed in the field should be:
- The CRC bits appear after the message bits with the x^31 coefficient in bit 7 of the first byte (byte 0) of the digest continuing to through the byte the x^24 coefficient in bit 0 of byte 0, continuing with the x^23 coefficient in bit 7 of byte 1, etc. (When examples are provided they show the CRC as it appears in the PDU with the bit significance used throughout this document. That is, bit 7 of each byte is interpreted as most significant though it is the coefficient of the lowest order CRC term in the byte.).

I have checked and this order matches the examples in B.4.

Regards,
Pat


------_=_NextPart_001_01C20CB6.7294A2C0-- ------=_NextPartTM-000-f139c003-44df-4256-bd1f-e8b4b8ac91e2-- From owner-ips@ece.cmu.edu Wed Jun 5 15:22:49 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13853 for ; Wed, 5 Jun 2002 15:22:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g55Ifap23549 for ips-outgoing; Wed, 5 Jun 2002 14:41:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g55IfYw23543; Wed, 5 Jun 2002 14:41:34 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 1B189A9DF; Wed, 5 Jun 2002 12:41:33 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id E6623EB; Wed, 5 Jun 2002 12:41:32 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 05 Jun 2002 12:41:32 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Jun 2002 12:41:32 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C35418C@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com, rdr@io.iol.unh.edu Cc: ips@ece.cmu.edu, mkrikis@yahoo.com, owner-ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence Date: Wed, 5 Jun 2002 12:41:32 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-d9de56be-3564-494b-bef4-25f2295081b9" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-d9de56be-3564-494b-bef4-25f2295081b9 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20CC0.9CC05620" ------_=_NextPart_001_01C20CC0.9CC05620 Content-Type: text/plain; charset="iso-8859-1" Julian, Batching is related to the C-bit. Before the C-bit, a device could prepare a batch of keys to originate but they had to fit within the PDU because, if the keys extended beyond a PDU, the device's partner might originate some of the keys it had prepared but hadn't yet sent. With the C-bit, a device can prepare a batch of keys with out regard to their size because the device can ensure that they can be sent in multiple PDUs if necessary without the partner having an opportunity to originate keys in between. The C-bit releaves the size constraint on batching offers. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, June 04, 2002 10:19 AM To: Robert D. Russell Cc: ips@ece.cmu.edu; Martins Krikis; owner-ips@ece.cmu.edu Subject: Re: iSCSI: keys/parameter dependence I have one comment regarding to batching. Batching is not related to the C-bit. C-bit is meant to simplify spanning over PDU boundaries. Batching can be done with the previous structure as well - there is a lot you can do with an 8k block! Julo "Robert D. Russell" Sent by: owner-ips@ece.cmu.edu 06/04/2002 09:46 AM Please respond to "Robert D. Russell" To: Martins Krikis cc: ips@ece.cmu.edu Subject: Re: iSCSI: keys/parameter dependence Martins: Comments below on all your e-mails in this one reply. > As to "running and tested", > I don't think many people have encountered split > PDUs in operational stage or FFP Text negotiations > yet. Agreed. > Those, who prefer the "batch-processing" approach > fought for the C-bit, so I would say that it was > introduced in order to allow it. I missed that point earlier. > Regarding ordering, however, it had never been > defined, and I would hate to see it introduced. It was defined before draft 8, but was taken out when that draft came in. Unfortunately, I did not take it out of my memory. I agree that it should not be reintroduced. > In my opinion, it is best to treat all operational > parameters as independent and negotiate them as > such. Agreed. > Just before the commit > (i.e., turning on the T or F bit), one can do an > all-encompassing consistency check and reset > the negotiations if the values violate the laws > imposed on them, or offer some more keys to solve > any such problems, if this is still possible. What you are saying seems to imply that C=0 does NOT require the receiver to reply to keys received up to that point -- it could send another empty PDU, or more likely, it could send new offers of its own. I agree that there is nothing in the draft that says when replies to keys should be sent, only that they MUST be sent (sometime). For example, consider a login negotiation of operational parameters in which the initiator sends a login pdu containing key=value offers and the C bit 0. The target responds with a login response pdu containing key=value offers of its own (offering different keys) but no replies to any of the offers it received in the login. The initiator can then reply to the target's new offers, or it can decide not to reply, and instead send additional new offers or even an empty pdu, (C bit 0 in both alternatives). And now the target could do as it did before, not replying to any offers but either sending back new offers or sending back an empty login response pdu (again C bit 0 in both alternatives). This could go on indefinitely. It would seem that the initiator might try to force replies by setting T=1 to force an end-of-stage transition. However, the target can refuse to make the transition and can reply with T=0 and still no replies to the keys it was offered. This is admittedly a rather far-out example, because presumably both initiator and target want to end the negotiations as soon as possible. My point only is that I do not see anything in the draft that says when the replies to keys have to be sent, only several references that there MUST be a reply to every key offered (eventually). Thoughts, comments? > I could even imagine negotiations > succeeding but laws > (e.g. FirstBurstSize <= MaxBurstSize) not being > broken when sending data... OK, the last thing > might technically be forbidden at the moment > but it is not that unreasonable. It would be > something like > FirstBursSize = min(FirstBurstSize, MaxBurstSize) > done after the negotiation end, and then you can > forget about dependencies. I think it is way > easier than worrying about key ordering every > time something is sent or received. The dependency can be accounted for when generating the reply. For example, reply.FirstBurstSize = min(offer.FirstBurstSize, reply.MaxBurstSize) That way nothing is broken when sending data. > And how many instances of TargetName and TargetAddress > can the SendTargets command provoke from the other > side? I think it can easily overflow the 8192 bytes. Yes it can, but there was already a mechanism in place to deal with this. In fact, this brings up an interesting point. Presumably the C bit has to be used with replies sent to SendTargets (or any other offer that might generate a long reply), since the C bit is in the Text Response PDU used to send these replies. Refering to sections 9.10.2 and 9.10.4: If the target generating a long reply has more text to send than will fit in one PDU, then it should indicate this by setting C = 1. Setting C = 1 also forces F=0, and this in turn forces the Target Transfer Tag to be something other than 0xffffffff. When there is no more text to send, the target sets C = 0 and F = 1 and TTT=0xffffffff in the last text response pdu it sends to the initiator. There is no situation in which C = 1 and F = 1 can occur (since this is explicitly stated in 9.10.2 as being an error), nor is there a situation in which C = 0 and F = 0 should occur (because C = 0 means "I'm done sending stuff" and F = 0 means "I'm not done sending stuff"). Is this the way you interpret the merging of the C bit with the long text reply mechanism? If there is a consensus on this, perhaps the wording in the draft in section 9.10.4 should include the (required) settings of the C bit whenever it mentions the corresponding settings of the F bit and TTT field. > > -- FirstBurstSize and MaxBurstSize are dependent > > because of the > > requirement in section 11.15: "FirstBurstSize MUST > > NOT exceed > > MaxBurstSize." See my e-mail response to Mike for > > details > > on that dependence. > > I saw it. I consider it unbelievably ugly to have to > look at the values in order to figure out ordering > requirements. I prefer ignoring ordering completely > and check for overall consistency before commit. You are correct, the values can be figured out without resorting to an ordering -- my mistake. > Nowhere does it say anything about the order. Agreed. > So, are you really proposing a requirement that > we must look at the values in order to figure out in > which order to send keys? That is so UGLY, it is > hard to believe that this is happening. Please forget I even suggested it. > > The existence of a dependency between OFMarker and > > OFMarkInt, and between > > IFMarker and IFMarkInt, is implied by the statements > > in section A.3.2: > > "When the interval is unacceptable the responder > > answers with > > "Reject". Reject is resetting the marker function > > in the spcified > > direction (Output or Input) to No." > > No it isn't. IMO, it is resetting the marker interval > to its previous value, which is likely the default > value. I believe it's perfectly legal to negotiate > the marker interval but to not turn on marker use, > or to turn on the use but stay with current (default) > values for the interval. If one side can't tolerate > the other's Reject (i.e., can't live with the > default value), it is welcome to bail and try next > time w/o markers. BTW, we could use 0 here as a > special value, meaning that markers are not in use, > then we wouldn't need the boolean keys for > markers. > > > This last sentence should probably be reworded to > > say: > > "A response value of "Reject" to an OFMarkInt > > (IFMarkInt) key resets the > > corresponding OFMarker (IFMarker) key value to > > "No"." > > No, thank you. I would prefer if Reject meant the > same as with the other keys, i.e., negotiation > failed for this key, let's stick with the old > value, or bail if we must. Either the sentence needs to be reworded so it is proper English or it should be taken out of the draft. I take it you are advocating its removal? Bob Russell ------_=_NextPart_001_01C20CC0.9CC05620 Content-Type: text/html; charset="iso-8859-1"
Julian,
 
Batching is related to the C-bit. Before the C-bit, a device could prepare a batch of keys to originate
but they had to fit within the PDU because, if the keys extended beyond a PDU, the device's partner
might originate some of the keys it had prepared but hadn't yet sent.
 
With the C-bit, a device can prepare a batch of keys with out regard to their size because the device
can ensure that they can be sent in multiple PDUs if necessary without the partner having an 
opportunity to originate keys in between.
 
The C-bit releaves the size constraint on batching offers.
 
Regards,
Pat 
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, June 04, 2002 10:19 AM
To: Robert D. Russell
Cc: ips@ece.cmu.edu; Martins Krikis; owner-ips@ece.cmu.edu
Subject: Re: iSCSI: keys/parameter dependence


I have one comment regarding to batching.

Batching is not related to the C-bit. C-bit is meant to simplify spanning over PDU boundaries.
Batching can be done with the previous structure as well - there is a lot you can do with an 8k block!

Julo


"Robert D. Russell" <rdr@io.iol.unh.edu>
Sent by: owner-ips@ece.cmu.edu

06/04/2002 09:46 AM
Please respond to "Robert D. Russell"

       
        To:        Martins Krikis <mkrikis@yahoo.com>
        cc:        ips@ece.cmu.edu
        Subject:        Re: iSCSI: keys/parameter dependence

       


Martins:

Comments below on all your e-mails in this one reply.

> As to "running and tested",
> I don't think many people have encountered split
> PDUs in operational stage or FFP Text negotiations
> yet.

Agreed.


> Those, who prefer the "batch-processing" approach
> fought for the C-bit, so I would say that it was
> introduced in order to allow it.

I missed that point earlier.


> Regarding ordering, however, it had never been
> defined, and I would hate to see it introduced.

It was defined before draft 8, but was taken out when that
draft came in.  Unfortunately, I did not take it out of
my memory.  I agree that it should not be reintroduced.


> In my opinion, it is best to treat all operational
> parameters as independent and negotiate them as
> such.

Agreed.


> Just before the commit
> (i.e., turning on the T or F bit), one can do an
> all-encompassing consistency check and reset
> the negotiations if the values violate the laws
> imposed on them, or offer some more keys to solve
> any such problems, if this is still possible.


What you are saying seems to imply that C=0 does NOT
require the receiver to reply to keys received up to that point
-- it could send another empty PDU, or more likely, it could send
new offers of its own.  I agree that there is nothing in the draft
that says when replies to keys should be sent, only that they
MUST be sent (sometime).

For example, consider a login negotiation of operational parameters
in which the initiator sends a login pdu containing key=value offers
and the C bit 0.  The target responds with a login response pdu
containing key=value offers of its own (offering different keys)
but no replies to any of the offers it received in the login.
The initiator can then reply to the target's new offers, or it
can decide not to reply, and instead send additional new offers
or even an empty pdu, (C bit 0 in both alternatives).  And now
the target could do as it did before, not replying to any offers
but either sending back new offers or sending back an empty login
response pdu (again C bit 0 in both alternatives).  This could go
on indefinitely.

It would seem that the initiator might try to force replies by
setting T=1 to force an end-of-stage transition.  However, the target
can refuse to make the transition and can reply with T=0 and still
no replies to the keys it was offered.

This is admittedly a rather far-out example, because presumably both
initiator and target want to end the negotiations as soon as possible.
My point only is that I do not see anything in the draft that says
when the replies to keys have to be sent, only several references
that there MUST be a reply to every key offered (eventually).

Thoughts, comments?


> I could even imagine negotiations
> succeeding but laws
> (e.g. FirstBurstSize <= MaxBurstSize) not being
> broken when sending data... OK, the last thing
> might technically be forbidden at the moment
> but it is not that unreasonable. It would be
> something like
> FirstBursSize = min(FirstBurstSize, MaxBurstSize)
> done after the negotiation end, and then you can
> forget about dependencies. I think it is way
> easier than worrying about key ordering every
> time something is sent or received.

The dependency can be accounted for when generating the reply.
For example,

reply.FirstBurstSize = min(offer.FirstBurstSize, reply.MaxBurstSize)

That way nothing is broken when sending data.


> And how many instances of TargetName and TargetAddress
> can the SendTargets command provoke from the other
> side? I think it can easily overflow the 8192 bytes.

Yes it can, but there was already a mechanism in place to deal
with this.  In fact, this brings up an interesting point.
Presumably the C bit has to be used with replies sent to
SendTargets (or any other offer that might generate a long reply),
since the C bit is in the Text Response PDU used to send these replies.

Refering to sections 9.10.2 and 9.10.4:  If the target generating a
long reply has more text to send than will fit in one PDU, then it
should indicate this by setting C = 1.  Setting C = 1 also forces F=0,
and this in turn forces the Target Transfer Tag to be something
other than 0xffffffff.  When there is no more text to send,
the target sets C = 0 and F = 1 and TTT=0xffffffff in the last
text response pdu it sends to the initiator.  There is no
situation in which C = 1 and F = 1 can occur (since this is
explicitly stated in 9.10.2 as being an error), nor is there a
situation in which C = 0 and F = 0 should occur (because C = 0
means "I'm done sending stuff" and F = 0 means "I'm not done sending
stuff").

Is this the way you interpret the merging of the C bit with the
long text reply mechanism?  If there is a consensus on this,
perhaps the wording in the draft in section 9.10.4 should include
the (required) settings of the C bit whenever it mentions the
corresponding settings of the F bit and TTT field.


> > -- FirstBurstSize and MaxBurstSize are dependent
> > because of the
> > requirement in section 11.15: "FirstBurstSize MUST
> > NOT exceed
> > MaxBurstSize."  See my e-mail response to Mike for
> > details
> > on that dependence.
>
> I saw it. I consider it unbelievably ugly to have to
> look at the values in order to figure out ordering
> requirements. I prefer ignoring ordering completely
> and check for overall consistency before commit.

You are correct, the values can be figured out without
resorting to an ordering -- my mistake.


> Nowhere does it say anything about the order.

Agreed.


> So, are you really proposing a requirement that
> we must look at the values in order to figure out in
> which order to send keys? That is so UGLY, it is
> hard to believe that this is happening.

Please forget I even suggested it.


> > The existence of a dependency between OFMarker and
> > OFMarkInt, and between
> > IFMarker and IFMarkInt, is implied by the statements
> > in section A.3.2:
> > "When the interval is unacceptable the responder
> > answers with
> > "Reject".  Reject is resetting the marker function
> > in the spcified
> > direction (Output or Input) to No."
>
> No it isn't. IMO, it is resetting the marker interval
> to its previous value, which is likely the default
> value. I believe it's perfectly legal to negotiate
> the marker interval but to not turn on marker use,
> or to turn on the use but stay with current (default)
> values for the interval. If one side can't  tolerate
> the other's  Reject (i.e., can't live with the
> default value), it is welcome to bail and try next
> time w/o markers. BTW, we could use 0 here as a
> special value, meaning that markers are not in use,
> then we wouldn't need the boolean keys for
> markers.
>
> > This last sentence should probably be reworded to
> > say:
> > "A response value of "Reject" to an OFMarkInt
> > (IFMarkInt) key resets the
> > corresponding OFMarker (IFMarker) key value to
> > "No"."
>
> No, thank you. I would prefer if Reject meant the
> same as with the other keys, i.e., negotiation
> failed for this key, let's stick with the old
> value, or bail if we must.

Either the sentence needs to be reworded so it is proper English
or it should be taken out of the draft.  I take it you are advocating
its removal?

Bob Russell



------_=_NextPart_001_01C20CC0.9CC05620-- ------=_NextPartTM-000-d9de56be-3564-494b-bef4-25f2295081b9-- From owner-ips@ece.cmu.edu Wed Jun 5 15:23:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13868 for ; Wed, 5 Jun 2002 15:23:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g55Ix0r24966 for ips-outgoing; Wed, 5 Jun 2002 14:59:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g55Iwww24959 for ; Wed, 5 Jun 2002 14:58:58 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 9991C30706; Wed, 5 Jun 2002 14:58:57 -0400 (EDT) Date: Wed, 5 Jun 2002 11:56:51 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Cc: , Subject: RE: iSCSI: keys/parameter dependence In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00C353FC5@axcs04.cos.agilent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 4 Jun 2002 pat_thaler@agilent.com wrote: > Robert, > > You seem to be assuming that the set of values for keys must be a valid set > of keys at any time during the negotiation. If that is the rule then, for > example, if one is planning to increase FirstBurstSize over the default > value of MaxBurstSize, one has to increase MaxBurstSize first. Similarly, if > one was going to decrease MaxBurstSize below the default of FirstBurstSize > then one needs to decrease FirstBurstSize first. (Call this "valid when > set") > > The draft doesn't state that this is a rule for negotiation. It would work > just as well to require that the set of parameters be valid at the end of > negotiation. With this rule, it is okay to set the parameters in either > order. One can check that a parameter relationship rule is met when all the > parameters covered by the rule have been negotiated or when one is ready to > set the T bit. (Call this "valid at commit") I vote for the latter. > The draft needs to clarify whether the rule is valid when set or valid at > commit because there will be interoperability problems between a device > applying valid when set and one applying valid at commit. Actually, the > draft doesn't even say you need to check the values and it isn't clear a > check is necessary though it is prudent. One possibility is to say that one > doesn't check non-final results but may check when the negotiations involved > have responses or before commit. Sounds good. > Note that the valid when set rule imposes certain complexities. > For example: > Initiator wants to set FirstBurstSize larger than MaxBurstSize default. > It therefore sends MaxBurstSize first. > It turns out that the target wants to set MaxBurstSize smaller than the > default for FirstBurstSize so it cannot reply to MaxBurstSize right away. > It has to lower FirstBurstSize first > First the Target has to check forward in its receive buffer to see if > the initiator made an offer for FirstBurstSize, then respond to that > offer or, if the offer hasn't been made it has to make its offer. > Then it can send MaxBurstSize. > > That is a pain and things like this are causing login code to grow > beyond what is reasonable and necessary. Agreed. Let's avoid if if possible. > Furthermore, 4.2 says "Conservative > design requires also that default values should not be > relied upon when use of some other value has serious consequences." > Failing negotiation because you think your partner set MaxBurstSize > lower than the default value of FirstBurstSize seems like a serious > consequence. Eek. Yes. > One could do a sentence like: > While negotiations are incomplete, the set of values may not meet all the > dependency requirements (e.g. MaxBurstSize might be less than FirstBurst > size when one has been negotiated and the other has not completed > negotiation). The initiator or target making an offer or sending a response > that results in such an inconsistancy MUST offer the other value when > necessary to resolve the inconsistancy. Conservative design also requires > that the final values of negotiation be checked for a dependency when > failure to meet the dependency has serious consequences. That sounds good. Take care, Bill From owner-ips@ece.cmu.edu Wed Jun 5 16:09:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16432 for ; Wed, 5 Jun 2002 16:08:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g55JO2726947 for ips-outgoing; Wed, 5 Jun 2002 15:24:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g55JO0w26942 for ; Wed, 5 Jun 2002 15:24:00 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Jun 2002 15:23:59 -0400 Message-ID: From: Eddy Quicksall To: ips@ece.cmu.edu Subject: iSCSI: changing MaxPDUDataLength Date: Wed, 5 Jun 2002 15:23:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Does anybody know a case where it is necessary to support a new PDU data length during full feature phase? Eddy mailto: Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Wed Jun 5 16:10:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16534 for ; Wed, 5 Jun 2002 16:10:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g55JXCI27681 for ips-outgoing; Wed, 5 Jun 2002 15:33:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13708.mail.yahoo.com (web13708.mail.yahoo.com [216.136.175.141]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g55JX8w27671 for ; Wed, 5 Jun 2002 15:33:09 -0400 (EDT) Message-ID: <20020605193307.13827.qmail@web13708.mail.yahoo.com> Received: from [192.55.52.3] by web13708.mail.yahoo.com via HTTP; Wed, 05 Jun 2002 12:33:07 PDT Date: Wed, 5 Jun 2002 12:33:07 -0700 (PDT) From: Martins Krikis Subject: Re: iSCSI: keys/parameter dependence To: Julian Satran Cc: ips@ece.cmu.edu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- Julian Satran wrote: > Almost everything is correct - except the mechanism > for > Very-Long-responses - (TTT). > This is different than the spanning mechanism (C- > bit) in the sense that > has in theory no bounds (it was devised mainly for > SendTargets but can be > used by any mechanism that has to send a lot of data > - not negotiations). Hmm, let me verify that I'm understanding this... Let's suppose the following scenario: A target is planning to send a very long response (exceeding the mandatory buffering capabilities of the other side) to a TextRequest that contained the SendTargets key. This is legal, because it is not a negotiation, right? Let's suppose the text it is sending will get broken in m TextResponse PDUs. For any of these PDUs, if the key=value pairs fit completely (i.e., including the terminating '\0'), and if the target doesn't mind the possibility that the initiator may send some data back (for example, do a little negotiation in parallel with hearing what SendTargets will return...), then it need not set the C-bit. Correct? But it is also permissible to set the C-bit, since the target may not consider itself as "being done with this set of keys". Right? If, however, in some PDU the last key=value pair is split (i.e., will continue in the next PDU), then it MUST set the C-bit, because such a PDU cannot possibly "end a set of keys". Can anybody comment on this understanding, please? Applying this understanding to the example in section 9.10.4, I can conjecture that the C bit may or may not be set; it depends on whether contains only complete (with '\0' at the end) pairs or not, and possibly on target's preferences. The PDUs travelling in the other direction need not necessarily be empty, unless the C-bit in the preceding PDU forces them to be. Is this true? Many thanks in advance, Martins Krikis, Intel Corp. Disclaimer: these are my own opinions and are not necessarily Intel's opinions. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Wed Jun 5 16:51:14 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19068 for ; Wed, 5 Jun 2002 16:51:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g55KBin00600 for ips-outgoing; Wed, 5 Jun 2002 16:11:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g55KBgw00596 for ; Wed, 5 Jun 2002 16:11:42 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 1C5E9ADC1; Wed, 5 Jun 2002 14:11:38 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with SMTP id CA08A241; Wed, 5 Jun 2002 14:11:37 -0600 (MDT) Received: from 130.29.152.143 by axcsbh1.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 05 Jun 2002 14:11:37 -0600 Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Jun 2002 14:11:37 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C354203@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Martins Krikis , Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence Date: Wed, 5 Jun 2002 14:11:34 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk This matches my understanding of what we were doing with the C bit and it is consistant with the C bit text in the draft. Pat -----Original Message----- From: Martins Krikis [mailto:mkrikis@yahoo.com] Sent: Wednesday, June 05, 2002 12:33 PM To: Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iSCSI: keys/parameter dependence --- Julian Satran wrote: > Almost everything is correct - except the mechanism > for > Very-Long-responses - (TTT). > This is different than the spanning mechanism (C- > bit) in the sense that > has in theory no bounds (it was devised mainly for > SendTargets but can be > used by any mechanism that has to send a lot of data > - not negotiations). Hmm, let me verify that I'm understanding this... Let's suppose the following scenario: A target is planning to send a very long response (exceeding the mandatory buffering capabilities of the other side) to a TextRequest that contained the SendTargets key. This is legal, because it is not a negotiation, right? Let's suppose the text it is sending will get broken in m TextResponse PDUs. For any of these PDUs, if the key=value pairs fit completely (i.e., including the terminating '\0'), and if the target doesn't mind the possibility that the initiator may send some data back (for example, do a little negotiation in parallel with hearing what SendTargets will return...), then it need not set the C-bit. Correct? But it is also permissible to set the C-bit, since the target may not consider itself as "being done with this set of keys". Right? If, however, in some PDU the last key=value pair is split (i.e., will continue in the next PDU), then it MUST set the C-bit, because such a PDU cannot possibly "end a set of keys". Can anybody comment on this understanding, please? Applying this understanding to the example in section 9.10.4, I can conjecture that the C bit may or may not be set; it depends on whether contains only complete (with '\0' at the end) pairs or not, and possibly on target's preferences. The PDUs travelling in the other direction need not necessarily be empty, unless the C-bit in the preceding PDU forces them to be. Is this true? Many thanks in advance, Martins Krikis, Intel Corp. Disclaimer: these are my own opinions and are not necessarily Intel's opinions. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Wed Jun 5 17:57:22 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22236 for ; Wed, 5 Jun 2002 17:57:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g55LWfr06419 for ips-outgoing; Wed, 5 Jun 2002 17:32:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g55LWew06413 for ; Wed, 5 Jun 2002 17:32:40 -0400 (EDT) Received: from xparelay1.corp.hp.com (xparelay1.corp.hp.com [15.58.136.173]) by palrel10.hp.com (Postfix) with ESMTP id 66994C003EB; Wed, 5 Jun 2002 14:32:34 -0700 (PDT) Received: from xpabh4.corp.hp.com (xpabh4.corp.hp.com [15.58.136.1]) by xparelay1.corp.hp.com (Postfix) with ESMTP id 3878FE000A3; Wed, 5 Jun 2002 14:32:34 -0700 (PDT) Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Jun 2002 14:32:33 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF631@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "Julian Satran (E-mail)" Cc: "Ips Reflector (E-mail)" Subject: RE: iSCSI: editorial corrections to Appendix D:SendTargets Date: Wed, 5 Jun 2002 14:32:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Found another, > Should be changed to > > After obtaining a list of targets from the discovery target session, > an iSCSI initiator may initiate new sessions to log in to the discov- > ered targets for full operation. The initiator MAY keep the discovery > session open, and MAY send subsequently SendTargets commands to discover ^^^^^^^^^^^^ should be "subsequent" From owner-ips@ece.cmu.edu Wed Jun 5 17:59:51 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22483 for ; Wed, 5 Jun 2002 17:59:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g55LMDi05664 for ips-outgoing; Wed, 5 Jun 2002 17:22:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g55LMBw05658 for ; Wed, 5 Jun 2002 17:22:11 -0400 (EDT) Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel6.hp.com (Postfix) with ESMTP id 38FAD4C6; Wed, 5 Jun 2002 17:22:06 -0400 (EDT) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 0F850113; Wed, 5 Jun 2002 17:22:06 -0400 (EDT) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Jun 2002 17:22:05 -0400 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF630@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "Julian Satran (E-mail)" Cc: "Ips Reflector (E-mail)" Subject: iSCSI: editorial corrections to Appendix D:SendTargets Date: Wed, 5 Jun 2002 17:21:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, I think there's a sentence in appendix D that needs to be cleaned up from previous edits. "A SendTargets response MUST NOT contain iSCSI default target names." (it's on page 246 of the .pdf) This should be deleted since there are no longer any "iSCSI default target names" (or at least they are not defined). Also, to clarify, I think the paragraph 3 should be modified from: A system that contains targets MUST support discovery sessions on each of its IP addresses, and MUST support the SendTargets command on the discovery session. A target MUST support the SendTargets command on operational sessions; these will only return address information about the target to which the session is connected, and do not return information about other targets. to the following: A system that contains targets MUST support discovery sessions on each of its TCP addresses, and MUST support the SendTargets command on the discovery session. A target MUST return all path information (TCP addresses and portal group tags) for the target in question for which the requesting initiator is authorized. A target MUST support the SendTargets command on operational sessions; these will only return path information about the target to which the session is connected, and need not return information about other target names that may be defined in the responding device. This is just an explicit statement of what's implicit in the current appendix. I corrected "IP address" to "TCP address" cause it's the TCP listening port that must provide the discovery session. Also, on page 234, the paragraph: After obtaining a list of targets from the discovery target session, an iSCSI initiator may initiate new sessions to log in to the discov- ered targets for full operation. The initiator MAY keep the session to a default target open, and MAY send subsequently SendTargets com- mands to discover new targets. Should be changed to After obtaining a list of targets from the discovery target session, an iSCSI initiator may initiate new sessions to log in to the discov- ered targets for full operation. The initiator MAY keep the discovery session open, and MAY send subsequently SendTargets commands to discover new targets. On page 235, the paragraphs: In the above example, a DNS host name could have been returned instead of an IP address, and that an IPv6 addresses (5 to 16 dotted-decimal numbers) could have also been returned. The next text response shows a target that supports spanning sessions across multiple addresses, which indicates the use of the portal group tags: Should be In the above example, a DNS host name or an IPv6 address (5 to 16 dotted-decimal numbers) could have been returned instead of an IPv4 address. The next text response shows a target that supports spanning sessions across multiple addresses, and illustrates further the use of the portal group tags: Thanks, Marjorie From owner-ips@ece.cmu.edu Wed Jun 5 18:40:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24912 for ; Wed, 5 Jun 2002 18:40:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g55LxV408295 for ips-outgoing; Wed, 5 Jun 2002 17:59:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar1aa.compuserve.com (siaar1aa.compuserve.com [149.174.40.9]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g55LuNw08064 for ; Wed, 5 Jun 2002 17:56:23 -0400 (EDT) Received: (from mailgate@localhost) by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id RAA18089 for ips@ece.cmu.edu; Wed, 5 Jun 2002 17:56:13 -0400 (EDT) Received: from compuserve.com (dal-tgn-tkt-vty30.as.wcom.net [216.192.231.30]) by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id RAA18050; Wed, 5 Jun 2002 17:56:09 -0400 (EDT) Message-ID: <3CFE896D.50FBCE8C@compuserve.com> Date: Wed, 05 Jun 2002 16:58:05 -0500 From: Ralph Weber X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IPS Reflector CC: "Rodriguez, Elizabeth" Subject: Re: IPS-ALL: PDF versions of the drafts References: <00d201c20c11$5036a110$04e5afce@EGRodriguez> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Elizabeth, The TXT and PDF versions of the FC Encapsulation and FCIP drafts are prepared from a common source using automation that should make the two identical in terms of content. I cannot speak for the other drafts editors, but I believe they are using similar processes. The only difference between the TXT and the PDF for the FC Encapsulation and FCIP drafts is that the PDF contains change bars. If you have reviewed the FCIP draft before and want to review only the changes resulting from the 1st Last Call, start with the PDF. If you find problems, you should be able to go to the same page in TXT file and prepare your comment. As the above paragraph suggests, I second Elizabeth's reminder that the TXT file is the official file. The PDF file is there only to make some tasks (like find changes from the last revision) easier. All the best. .Ralph "Elizabeth G. Rodriguez" wrote: > All, > > For a number of our drafts, the editor publishes both text and PDF versions. > > It is often difficult to find the PDF version on the IETF web site though. > > The best place to reference for the PDF version of our drafts is > http://www.ietf.org/ids.by.wg/ips.html. > > At the end of the description, it will indicate if a PDF version is also > available. > > This said, I must caution everyone – the TXT version of the draft is the > official version of the draft. > > So, it is recommend that when reviewing the draft for last call, the TXT > version be used. > > Thanks, > > Elizabeth From owner-ips@ece.cmu.edu Wed Jun 5 21:32:36 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04204 for ; Wed, 5 Jun 2002 21:32:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g560hbc18117 for ips-outgoing; Wed, 5 Jun 2002 20:43:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ariel.nishansystems.com (ultrex.nishansystems.com [12.36.127.195]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g560hYw18110 for ; Wed, 5 Jun 2002 20:43:34 -0400 (EDT) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Jun 2002 17:43:24 -0700 Message-ID: From: Charles Monia To: "Ips (E-mail)" Cc: Charles Monia , "Franco Travostino (E-mail)" , "David Black (E-mail)" , "Elizabeth Rodriguez (E-mail)" Subject: Nishan IPR Notice Date: Wed, 5 Jun 2002 17:43:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk On behalf of Nishan Systems, the following notice is submitted ==================================================== Periodically Nishan Systems Inc.'s employees are involved in various IPS working groups and will submit technical information that is adopted as a standard by the IETF. Nishan Systems' submissions will conform to RFC 2026. This is to advise the IETF that Nishan Systems, Inc. has U.S. Patent Number 6,400,730, with the issue date of June 4, 2002, that may relate to the FCIP and iFCP protocols being discussed as a part of the IETF standards process. If such protocols become IETF standards) ("the IETF standard(s)"), and to the extent the above referenced patent is necessary for implementation of the IETF standard(s), Nishan Systems will provide, to implementers of the IETF standard(s), a non-exclusive license on reasonable and non-discriminatory terms, provided a similarly situated reciprocal license is granted to Nishan Systems and other parties by the licensed party for any protocol technologies necessary for the implementation of the IETF standard(s). Any questions or issues regarding this communication should be directed to: Office of General Counsel Nishan Systems, Inc. 3850 North First Street San Jose, CA 95134 ======================================================== Charles Monia Senior Technology Consultant Nishan Systems email: cmonia@nishansystems.com voice: (408) 519-3986 fax: (408) 435-8385 From owner-ips@ece.cmu.edu Wed Jun 5 21:39:52 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04651 for ; Wed, 5 Jun 2002 21:39:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5613WT19263 for ips-outgoing; Wed, 5 Jun 2002 21:03:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com ([192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5613Uw19258 for ; Wed, 5 Jun 2002 21:03:30 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id EFDE5B072; Wed, 5 Jun 2002 19:02:08 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id CF5BE1B6; Wed, 5 Jun 2002 19:02:08 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 05 Jun 2002 19:02:08 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Jun 2002 19:02:08 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C3542BA@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: marjorie_krueger@hp.com, julian_satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: corrections to Appendix D:SendTargets Date: Wed, 5 Jun 2002 19:02:07 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Marjorie, IP addresses shouldn't be changed to TCP addresses because that could be interpreted as meaning it needs to support SendTargets on ports connected to non-iSCSI ports. Thinking about that, I also don't think it should be required to support disovery sessions on each IP address. It seems reasonable for a system to have some IP addresses that aren't connected to an iSCSI protocol at all. For example one might build a box with storage that does both iSCSI and NAT and one might choose to use different IP addresses for those two services. One might do that because the services are on different LAN interfaces or for numerous other reasons. I think the text should be something more like: "on each IP address that supports iSCSI". Regards, Pat -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) to the following: A system that contains targets MUST support discovery sessions on each of its TCP addresses, and MUST support the SendTargets command on the discovery session. A target MUST return all path information (TCP addresses and portal group tags) for the target in question for which the requesting initiator is authorized. A target MUST support the SendTargets command on operational sessions; these will only return path information about the target to which the session is connected, and need not return information about other target names that may be defined in the responding device. This is just an explicit statement of what's implicit in the current appendix. I corrected "IP address" to "TCP address" cause it's the TCP listening port that must provide the discovery session. Also, on page 234, the paragraph: After obtaining a list of targets from the discovery target session, an iSCSI initiator may initiate new sessions to log in to the discov- ered targets for full operation. The initiator MAY keep the session to a default target open, and MAY send subsequently SendTargets com- mands to discover new targets. Should be changed to After obtaining a list of targets from the discovery target session, an iSCSI initiator may initiate new sessions to log in to the discov- ered targets for full operation. The initiator MAY keep the discovery session open, and MAY send subsequently SendTargets commands to discover new targets. On page 235, the paragraphs: In the above example, a DNS host name could have been returned instead of an IP address, and that an IPv6 addresses (5 to 16 dotted-decimal numbers) could have also been returned. The next text response shows a target that supports spanning sessions across multiple addresses, which indicates the use of the portal group tags: Should be In the above example, a DNS host name or an IPv6 address (5 to 16 dotted-decimal numbers) could have been returned instead of an IPv4 address. The next text response shows a target that supports spanning sessions across multiple addresses, and illustrates further the use of the portal group tags: Thanks, Marjorie From owner-ips@ece.cmu.edu Thu Jun 6 00:47:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16907 for ; Thu, 6 Jun 2002 00:47:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g563txh28635 for ips-outgoing; Wed, 5 Jun 2002 23:55:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g563tuw28629 for ; Wed, 5 Jun 2002 23:55:57 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g563toUN019838 for ; Thu, 6 Jun 2002 05:55:50 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g563tof125498 for ; Thu, 6 Jun 2002 05:55:50 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: keys/parameter dependence X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 6 Jun 2002 06:55:47 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 06/06/2002 06:55:50, Serialize complete at 06/06/2002 06:55:50 Content-Type: multipart/alternative; boundary="=_alternative 0014C01BC2256BD0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0014C01BC2256BD0_= Content-Type: text/plain; charset="us-ascii" As I pointed out earlier - you can batch all your keys but some certificates in 8k! It was never forbidden nor mandated. Julo pat_thaler@agilent.com 06/05/2002 09:41 PM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL, rdr@io.iol.unh.edu cc: ips@ece.cmu.edu, mkrikis@yahoo.com, owner-ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence Julian, Batching is related to the C-bit. Before the C-bit, a device could prepare a batch of keys to originate but they had to fit within the PDU because, if the keys extended beyond a PDU, the device's partner might originate some of the keys it had prepared but hadn't yet sent. With the C-bit, a device can prepare a batch of keys with out regard to their size because the device can ensure that they can be sent in multiple PDUs if necessary without the partner having an opportunity to originate keys in between. The C-bit releaves the size constraint on batching offers. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, June 04, 2002 10:19 AM To: Robert D. Russell Cc: ips@ece.cmu.edu; Martins Krikis; owner-ips@ece.cmu.edu Subject: Re: iSCSI: keys/parameter dependence I have one comment regarding to batching. Batching is not related to the C-bit. C-bit is meant to simplify spanning over PDU boundaries. Batching can be done with the previous structure as well - there is a lot you can do with an 8k block! Julo "Robert D. Russell" Sent by: owner-ips@ece.cmu.edu 06/04/2002 09:46 AM Please respond to "Robert D. Russell" To: Martins Krikis cc: ips@ece.cmu.edu Subject: Re: iSCSI: keys/parameter dependence Martins: Comments below on all your e-mails in this one reply. > As to "running and tested", > I don't think many people have encountered split > PDUs in operational stage or FFP Text negotiations > yet. Agreed. > Those, who prefer the "batch-processing" approach > fought for the C-bit, so I would say that it was > introduced in order to allow it. I missed that point earlier. > Regarding ordering, however, it had never been > defined, and I would hate to see it introduced. It was defined before draft 8, but was taken out when that draft came in. Unfortunately, I did not take it out of my memory. I agree that it should not be reintroduced. > In my opinion, it is best to treat all operational > parameters as independent and negotiate them as > such. Agreed. > Just before the commit > (i.e., turning on the T or F bit), one can do an > all-encompassing consistency check and reset > the negotiations if the values violate the laws > imposed on them, or offer some more keys to solve > any such problems, if this is still possible. What you are saying seems to imply that C=0 does NOT require the receiver to reply to keys received up to that point -- it could send another empty PDU, or more likely, it could send new offers of its own. I agree that there is nothing in the draft that says when replies to keys should be sent, only that they MUST be sent (sometime). For example, consider a login negotiation of operational parameters in which the initiator sends a login pdu containing key=value offers and the C bit 0. The target responds with a login response pdu containing key=value offers of its own (offering different keys) but no replies to any of the offers it received in the login. The initiator can then reply to the target's new offers, or it can decide not to reply, and instead send additional new offers or even an empty pdu, (C bit 0 in both alternatives). And now the target could do as it did before, not replying to any offers but either sending back new offers or sending back an empty login response pdu (again C bit 0 in both alternatives). This could go on indefinitely. It would seem that the initiator might try to force replies by setting T=1 to force an end-of-stage transition. However, the target can refuse to make the transition and can reply with T=0 and still no replies to the keys it was offered. This is admittedly a rather far-out example, because presumably both initiator and target want to end the negotiations as soon as possible. My point only is that I do not see anything in the draft that says when the replies to keys have to be sent, only several references that there MUST be a reply to every key offered (eventually). Thoughts, comments? > I could even imagine negotiations > succeeding but laws > (e.g. FirstBurstSize <= MaxBurstSize) not being > broken when sending data... OK, the last thing > might technically be forbidden at the moment > but it is not that unreasonable. It would be > something like > FirstBursSize = min(FirstBurstSize, MaxBurstSize) > done after the negotiation end, and then you can > forget about dependencies. I think it is way > easier than worrying about key ordering every > time something is sent or received. The dependency can be accounted for when generating the reply. For example, reply.FirstBurstSize = min(offer.FirstBurstSize, reply.MaxBurstSize) That way nothing is broken when sending data. > And how many instances of TargetName and TargetAddress > can the SendTargets command provoke from the other > side? I think it can easily overflow the 8192 bytes. Yes it can, but there was already a mechanism in place to deal with this. In fact, this brings up an interesting point. Presumably the C bit has to be used with replies sent to SendTargets (or any other offer that might generate a long reply), since the C bit is in the Text Response PDU used to send these replies. Refering to sections 9.10.2 and 9.10.4: If the target generating a long reply has more text to send than will fit in one PDU, then it should indicate this by setting C = 1. Setting C = 1 also forces F=0, and this in turn forces the Target Transfer Tag to be something other than 0xffffffff. When there is no more text to send, the target sets C = 0 and F = 1 and TTT=0xffffffff in the last text response pdu it sends to the initiator. There is no situation in which C = 1 and F = 1 can occur (since this is explicitly stated in 9.10.2 as being an error), nor is there a situation in which C = 0 and F = 0 should occur (because C = 0 means "I'm done sending stuff" and F = 0 means "I'm not done sending stuff"). Is this the way you interpret the merging of the C bit with the long text reply mechanism? If there is a consensus on this, perhaps the wording in the draft in section 9.10.4 should include the (required) settings of the C bit whenever it mentions the corresponding settings of the F bit and TTT field. > > -- FirstBurstSize and MaxBurstSize are dependent > > because of the > > requirement in section 11.15: "FirstBurstSize MUST > > NOT exceed > > MaxBurstSize." See my e-mail response to Mike for > > details > > on that dependence. > > I saw it. I consider it unbelievably ugly to have to > look at the values in order to figure out ordering > requirements. I prefer ignoring ordering completely > and check for overall consistency before commit. You are correct, the values can be figured out without resorting to an ordering -- my mistake. > Nowhere does it say anything about the order. Agreed. > So, are you really proposing a requirement that > we must look at the values in order to figure out in > which order to send keys? That is so UGLY, it is > hard to believe that this is happening. Please forget I even suggested it. > > The existence of a dependency between OFMarker and > > OFMarkInt, and between > > IFMarker and IFMarkInt, is implied by the statements > > in section A.3.2: > > "When the interval is unacceptable the responder > > answers with > > "Reject". Reject is resetting the marker function > > in the spcified > > direction (Output or Input) to No." > > No it isn't. IMO, it is resetting the marker interval > to its previous value, which is likely the default > value. I believe it's perfectly legal to negotiate > the marker interval but to not turn on marker use, > or to turn on the use but stay with current (default) > values for the interval. If one side can't tolerate > the other's Reject (i.e., can't live with the > default value), it is welcome to bail and try next > time w/o markers. BTW, we could use 0 here as a > special value, meaning that markers are not in use, > then we wouldn't need the boolean keys for > markers. > > > This last sentence should probably be reworded to > > say: > > "A response value of "Reject" to an OFMarkInt > > (IFMarkInt) key resets the > > corresponding OFMarker (IFMarker) key value to > > "No"." > > No, thank you. I would prefer if Reject meant the > same as with the other keys, i.e., negotiation > failed for this key, let's stick with the old > value, or bail if we must. Either the sentence needs to be reworded so it is proper English or it should be taken out of the draft. I take it you are advocating its removal? Bob Russell --=_alternative 0014C01BC2256BD0_= Content-Type: text/html; charset="us-ascii"

As I pointed out earlier - you can batch all your keys but some certificates in 8k!
It was never forbidden nor mandated.

Julo


pat_thaler@agilent.com

06/05/2002 09:41 PM
Please respond to pat_thaler

       
        To:        Julian Satran/Haifa/IBM@IBMIL, rdr@io.iol.unh.edu
        cc:        ips@ece.cmu.edu, mkrikis@yahoo.com, owner-ips@ece.cmu.edu
        Subject:        RE: iSCSI: keys/parameter dependence

       


Julian,
 
Batching is related to the C-bit. Before the C-bit, a device could prepare a batch of keys to originate
but they had to fit within the PDU because, if the keys extended beyond a PDU, the device's partner
might originate some of the keys it had prepared but hadn't yet sent.
 
With the C-bit, a device can prepare a batch of keys with out regard to their size because the device
can ensure that they can be sent in multiple PDUs if necessary without the partner having an
opportunity to originate keys in between.
 
The C-bit releaves the size constraint on batching offers.
 
Regards,
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, June 04, 2002 10:19 AM
To: Robert D. Russell
Cc: ips@ece.cmu.edu; Martins Krikis; owner-ips@ece.cmu.edu
Subject: Re: iSCSI: keys/parameter dependence

I have one comment regarding to batching.

Batching is not related to the C-bit. C-bit is meant to simplify spanning over PDU boundaries.
Batching can be done with the previous structure as well - there is a lot you can do with an 8k block!

Julo

"Robert D. Russell" <rdr@io.iol.unh.edu>
Sent by: owner-ips@ece.cmu.edu

06/04/2002 09:46 AM
Please respond to "Robert D. Russell"

       
       To:        Martins Krikis <mkrikis@yahoo.com>
       cc:        ips@ece.cmu.edu
       Subject:        Re: iSCSI: keys/parameter dependence

     



Martins:

Comments below on all your e-mails in this one reply.

> As to "running and tested",
> I don't think many people have encountered split
> PDUs in operational stage or FFP Text negotiations
> yet.

Agreed.


> Those, who prefer the "batch-processing" approach
> fought for the C-bit, so I would say that it was
> introduced in order to allow it.

I missed that point earlier.


> Regarding ordering, however, it had never been
> defined, and I would hate to see it introduced.

It was defined before draft 8, but was taken out when that
draft came in.  Unfortunately, I did not take it out of
my memory.  I agree that it should not be reintroduced.


> In my opinion, it is best to treat all operational
> parameters as independent and negotiate them as
> such.

Agreed.


> Just before the commit
> (i.e., turning on the T or F bit), one can do an
> all-encompassing consistency check and reset
> the negotiations if the values violate the laws
> imposed on them, or offer some more keys to solve
> any such problems, if this is still possible.


What you are saying seems to imply that C=0 does NOT
require the receiver to reply to keys received up to that point
-- it could send another empty PDU, or more likely, it could send
new offers of its own.  I agree that there is nothing in the draft
that says when replies to keys should be sent, only that they
MUST be sent (sometime).

For example, consider a login negotiation of operational parameters
in which the initiator sends a login pdu containing key=value offers
and the C bit 0.  The target responds with a login response pdu
containing key=value offers of its own (offering different keys)
but no replies to any of the offers it received in the login.
The initiator can then reply to the target's new offers, or it
can decide not to reply, and instead send additional new offers
or even an empty pdu, (C bit 0 in both alternatives).  And now
the target could do as it did before, not replying to any offers
but either sending back new offers or sending back an empty login
response pdu (again C bit 0 in both alternatives).  This could go
on indefinitely.

It would seem that the initiator might try to force replies by
setting T=1 to force an end-of-stage transition.  However, the target
can refuse to make the transition and can reply with T=0 and still
no replies to the keys it was offered.

This is admittedly a rather far-out example, because presumably both
initiator and target want to end the negotiations as soon as possible.
My point only is that I do not see anything in the draft that says
when the replies to keys have to be sent, only several references
that there MUST be a reply to every key offered (eventually).

Thoughts, comments?


> I could even imagine negotiations
> succeeding but laws
> (e.g. FirstBurstSize <= MaxBurstSize) not being
> broken when sending data... OK, the last thing
> might technically be forbidden at the moment
> but it is not that unreasonable. It would be
> something like
> FirstBursSize = min(FirstBurstSize, MaxBurstSize)
> done after the negotiation end, and then you can
> forget about dependencies. I think it is way
> easier than worrying about key ordering every
> time something is sent or received.

The dependency can be accounted for when generating the reply.
For example,

reply.FirstBurstSize = min(offer.FirstBurstSize, reply.MaxBurstSize)

That way nothing is broken when sending data.


> And how many instances of TargetName and TargetAddress
> can the SendTargets command provoke from the other
> side? I think it can easily overflow the 8192 bytes.

Yes it can, but there was already a mechanism in place to deal
with this.  In fact, this brings up an interesting point.
Presumably the C bit has to be used with replies sent to
SendTargets (or any other offer that might generate a long reply),
since the C bit is in the Text Response PDU used to send these replies.

Refering to sections 9.10.2 and 9.10.4:  If the target generating a
long reply has more text to send than will fit in one PDU, then it
should indicate this by setting C = 1.  Setting C = 1 also forces F=0,
and this in turn forces the Target Transfer Tag to be something
other than 0xffffffff.  When there is no more text to send,
the target sets C = 0 and F = 1 and TTT=0xffffffff in the last
text response pdu it sends to the initiator.  There is no
situation in which C = 1 and F = 1 can occur (since this is
explicitly stated in 9.10.2 as being an error), nor is there a
situation in which C = 0 and F = 0 should occur (because C = 0
means "I'm done sending stuff" and F = 0 means "I'm not done sending
stuff").

Is this the way you interpret the merging of the C bit with the
long text reply mechanism?  If there is a consensus on this,
perhaps the wording in the draft in section 9.10.4 should include
the (required) settings of the C bit whenever it mentions the
corresponding settings of the F bit and TTT field.


> > -- FirstBurstSize and MaxBurstSize are dependent
> > because of the
> > requirement in section 11.15: "FirstBurstSize MUST
> > NOT exceed
> > MaxBurstSize."  See my e-mail response to Mike for
> > details
> > on that dependence.
>
> I saw it. I consider it unbelievably ugly to have to
> look at the values in order to figure out ordering
> requirements. I prefer ignoring ordering completely
> and check for overall consistency before commit.

You are correct, the values can be figured out without
resorting to an ordering -- my mistake.


> Nowhere does it say anything about the order.

Agreed.


> So, are you really proposing a requirement that
> we must look at the values in order to figure out in
> which order to send keys? That is so UGLY, it is
> hard to believe that this is happening.

Please forget I even suggested it.


> > The existence of a dependency between OFMarker and
> > OFMarkInt, and between
> > IFMarker and IFMarkInt, is implied by the statements
> > in section A.3.2:
> > "When the interval is unacceptable the responder
> > answers with
> > "Reject".  Reject is resetting the marker function
> > in the spcified
> > direction (Output or Input) to No."
>
> No it isn't. IMO, it is resetting the marker interval
> to its previous value, which is likely the default
> value. I believe it's perfectly legal to negotiate
> the marker interval but to not turn on marker use,
> or to turn on the use but stay with current (default)
> values for the interval. If one side can't  tolerate
> the other's  Reject (i.e., can't live with the
> default value), it is welcome to bail and try next
> time w/o markers. BTW, we could use 0 here as a
> special value, meaning that markers are not in use,
> then we wouldn't need the boolean keys for
> markers.
>
> > This last sentence should probably be reworded to
> > say:
> > "A response value of "Reject" to an OFMarkInt
> > (IFMarkInt) key resets the
> > corresponding OFMarker (IFMarker) key value to
> > "No"."
>
> No, thank you. I would prefer if Reject meant the
> same as with the other keys, i.e., negotiation
> failed for this key, let's stick with the old
> value, or bail if we must.

Either the sentence needs to be reworded so it is proper English
or it should be taken out of the draft.  I take it you are advocating
its removal?

Bob Russell



--=_alternative 0014C01BC2256BD0_=-- From owner-ips@ece.cmu.edu Thu Jun 6 05:31:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03321 for ; Thu, 6 Jun 2002 05:31:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g568RuZ23455 for ips-outgoing; Thu, 6 Jun 2002 04:27:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g568Rrw23448 for ; Thu, 6 Jun 2002 04:27:53 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g568RgUN006310; Thu, 6 Jun 2002 10:27:44 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g568Rek111010; Thu, 6 Jun 2002 10:27:41 +0200 To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" Cc: "Ips Reflector (E-mail)" MIME-Version: 1.0 Subject: Re: iSCSI: editorial corrections to Appendix D:SendTargets X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 6 Jun 2002 11:27:39 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 06/06/2002 11:27:41, Serialize complete at 06/06/2002 11:27:41 Content-Type: multipart/alternative; boundary="=_alternative 002E75A7C2256BD0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 002E75A7C2256BD0_= Content-Type: text/plain; charset="us-ascii" thanks - Julo "KRUEGER,MARJORIE (HP-Roseville,ex1)" 06/06/2002 12:21 AM Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: Julian Satran/Haifa/IBM@IBMIL cc: "Ips Reflector (E-mail)" Subject: iSCSI: editorial corrections to Appendix D:SendTargets Julian, I think there's a sentence in appendix D that needs to be cleaned up from previous edits. "A SendTargets response MUST NOT contain iSCSI default target names." (it's on page 246 of the .pdf) This should be deleted since there are no longer any "iSCSI default target names" (or at least they are not defined). Also, to clarify, I think the paragraph 3 should be modified from: A system that contains targets MUST support discovery sessions on each of its IP addresses, and MUST support the SendTargets command on the discovery session. A target MUST support the SendTargets command on operational sessions; these will only return address information about the target to which the session is connected, and do not return information about other targets. to the following: A system that contains targets MUST support discovery sessions on each of its TCP addresses, and MUST support the SendTargets command on the discovery session. A target MUST return all path information (TCP addresses and portal group tags) for the target in question for which the requesting initiator is authorized. A target MUST support the SendTargets command on operational sessions; these will only return path information about the target to which the session is connected, and need not return information about other target names that may be defined in the responding device. This is just an explicit statement of what's implicit in the current appendix. I corrected "IP address" to "TCP address" cause it's the TCP listening port that must provide the discovery session. Also, on page 234, the paragraph: After obtaining a list of targets from the discovery target session, an iSCSI initiator may initiate new sessions to log in to the discov- ered targets for full operation. The initiator MAY keep the session to a default target open, and MAY send subsequently SendTargets com- mands to discover new targets. Should be changed to After obtaining a list of targets from the discovery target session, an iSCSI initiator may initiate new sessions to log in to the discov- ered targets for full operation. The initiator MAY keep the discovery session open, and MAY send subsequently SendTargets commands to discover new targets. On page 235, the paragraphs: In the above example, a DNS host name could have been returned instead of an IP address, and that an IPv6 addresses (5 to 16 dotted-decimal numbers) could have also been returned. The next text response shows a target that supports spanning sessions across multiple addresses, which indicates the use of the portal group tags: Should be In the above example, a DNS host name or an IPv6 address (5 to 16 dotted-decimal numbers) could have been returned instead of an IPv4 address. The next text response shows a target that supports spanning sessions across multiple addresses, and illustrates further the use of the portal group tags: Thanks, Marjorie --=_alternative 002E75A7C2256BD0_= Content-Type: text/html; charset="us-ascii"
thanks - Julo


"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>

06/06/2002 12:21 AM
Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        "Ips Reflector (E-mail)" <ips@ece.cmu.edu>
        Subject:        iSCSI: editorial corrections to Appendix D:SendTargets

       


Julian,
I think there's a sentence in appendix D that needs to be cleaned up from
previous edits.

"A SendTargets response MUST NOT contain iSCSI default target names." (it's
on page 246 of the .pdf) This should be deleted since there are no longer
any "iSCSI default target names" (or at least they are not defined).

Also, to clarify, I think the paragraph 3 should be modified from:

    A system that contains targets MUST support discovery sessions on each
    of its IP addresses, and MUST support the SendTargets command on the
    discovery session.  A target MUST support the SendTargets command on
    operational sessions; these will only return address information
    about the target to which the session is connected, and do not return
    information about other targets.

to the following:

    A system that contains targets MUST support discovery sessions on each
    of its TCP addresses, and MUST support the SendTargets command on the
    discovery session.  A target MUST return all path information (TCP
    addresses and portal group tags) for the target in question for
    which the requesting initiator is authorized.

    A target MUST support the SendTargets command on operational sessions;
    these will only return path information about the target to which
    the session is connected, and need not return information about other
    target names that may be defined in the responding device.

This is just an explicit statement of what's implicit in the current
appendix.  I corrected "IP address" to "TCP address" cause it's the TCP
listening port that must provide the discovery session.

Also, on page 234, the paragraph:

    After obtaining a list of targets from the discovery target session,
    an iSCSI initiator may initiate new sessions to log in to the discov-
    ered targets for full operation.  The initiator MAY keep the session
    to a default target open, and MAY send subsequently SendTargets com-
    mands to discover new targets.

Should be changed to

    After obtaining a list of targets from the discovery target session,
    an iSCSI initiator may initiate new sessions to log in to the discov-
    ered targets for full operation.  The initiator MAY keep the discovery
    session open, and MAY send subsequently SendTargets commands to
discover
    new targets.

On page 235, the paragraphs:

    In the above example, a DNS host name could have been returned instead
    of an IP address, and that an IPv6 addresses (5 to 16 dotted-decimal
    numbers) could have also been returned.

    The next text response shows a target that supports spanning sessions
    across multiple addresses, which indicates the use of the portal group
    tags:

Should be

    In the above example, a DNS host name or an IPv6 address (5 to 16
    dotted-decimal numbers) could have been returned instead
    of an IPv4 address.

    The next text response shows a target that supports spanning sessions
    across multiple addresses, and illustrates further the use of the
portal
    group tags:

Thanks,
Marjorie


--=_alternative 002E75A7C2256BD0_=-- From owner-ips@ece.cmu.edu Thu Jun 6 10:49:28 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16684 for ; Thu, 6 Jun 2002 10:49:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g56DwaD11561 for ips-outgoing; Thu, 6 Jun 2002 09:58:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g56DwYw11557 for ; Thu, 6 Jun 2002 09:58:34 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g56DwRtK024136; Thu, 6 Jun 2002 15:58:27 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g56DwOk86138; Thu, 6 Jun 2002 15:58:24 +0200 To: "Elliott, Robert (Server Storage)" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: SAM service response mapping X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 6 Jun 2002 16:58:22 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 06/06/2002 16:58:27, Serialize complete at 06/06/2002 16:58:27 Content-Type: multipart/alternative; boundary="=_alternative 004B9A64C2256BD0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004B9A64C2256BD0_= Content-Type: text/plain; charset="us-ascii" Rob, What you are suggesting is a "symbol Mapping" (are the responses symbols you quote associated with numerical values?). At the time we wrote this part there was no mapping for any of the protocols and we can do the "symbol mapping" to match whatever others have but only if this level of detail is sufficient. Julo "Elliott, Robert (Server Storage)" 06/06/2002 08:09 AM Please respond to "Elliott, Robert (Server Storage)" To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: iSCSI: SAM service response mapping [I'll post this to ips as soon as my email address on the reflector is updated from robert.elliott@compaq.com to elliott@hp.com] A few comments on the SCSI mappings in iscsi-12-96... 1. In section 9.6.1 (Task management function response) I disagree with this: "The mapping of the response code into a SCSI service response code, if needed, is outside the scope of this document." Serial Attached SCSI and Parallel SCSI (SPI-5) are going to map the SAM-2 remote procedure call results to their response codes; this closes a gap in the SCSI architecture mappings. I propose replacing that paragraph with: "Response value 0 maps to the SCSI service response of FUNCTION COMPLETE. All other Response values map to the SCSI service response of FUNCTION REJECTED. If a Task Management Function Response PDU does not arrive before the session is terminated, the SCSI service response is SERVICE DELIVERY OR TARGET FAILURE." For reference, the task management response codes are: a) 0 - Function Complete. b) 1 - Task does not exist. c) 2 - LUN does not exist. d) 3 - Task still allegiant. e) 4 - Task failover not supported. f) 5 - Task management function not supported. g) 6 - Function authorization failed. h) 255 - Function Rejected. 2. The same applies for command responses in 9.4.3: "The Response is used to report a Service Response. The exact mapping of the iSCSI response codes to SAM service response symbols is outside the scope of this document." I suggest: "Response value 0x00 maps to the SCSI service response of TASK COMPLETE. All other Response values map to the SCSI service response of SERVICE DELIVERY OR TARGET FAILURE. If a SCSI Response PDU does not arrive before the session is terminated, the SCSI service response is SERVICE DELIVERY OR TARGET FAILURE." For reference, the command response codes are: 0x00 - Command Completed at Target 0x01 - Target Failure 0x80-0xff - Vendor specific -- Rob Elliott, elliott@hp.com Industry Standard Server Storage Advanced Technology Hewlett-Packard --=_alternative 004B9A64C2256BD0_= Content-Type: text/html; charset="us-ascii"
Rob,

What you are suggesting is a "symbol Mapping" (are the responses symbols you quote associated with numerical values?).
At the time we wrote this part there was no mapping for any of the protocols and we can do the "symbol mapping" to match whatever others have but
only if this level of detail is sufficient.

Julo


"Elliott, Robert (Server Storage)" <Elliott@hp.com>

06/06/2002 08:09 AM
Please respond to "Elliott, Robert (Server Storage)"

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        
        Subject:        iSCSI: SAM service response mapping

       


[I'll post this to ips as soon as my email address on the
reflector is updated from robert.elliott@compaq.com
to elliott@hp.com]

A few comments on the SCSI mappings in iscsi-12-96...

1. In section 9.6.1 (Task management function response)
I disagree with this:
"The mapping of the response code into a SCSI service
response code, if needed, is outside the scope of
this document."

Serial Attached SCSI and Parallel SCSI (SPI-5) are going to
map the SAM-2 remote procedure call results to their
response codes; this closes a gap in the SCSI architecture
mappings.

I propose replacing that paragraph with:
"Response value 0 maps to the SCSI service response
of FUNCTION COMPLETE.  All other Response values map to
the SCSI service response of FUNCTION REJECTED.  If a
Task Management Function Response PDU does not arrive
before the session is terminated, the SCSI service
response is SERVICE DELIVERY OR TARGET FAILURE."

For reference, the task management response codes are:
a) 0 - Function Complete.
b) 1 - Task does not exist.
c) 2 - LUN does not exist.
d) 3 - Task still allegiant.
e) 4 - Task failover not supported.
f) 5 - Task management function not supported.
g) 6 - Function authorization failed.
h) 255 - Function Rejected.


2.  The same applies for command responses in 9.4.3:
"The Response is used to report a Service Response. The exact
mapping of the iSCSI response codes to SAM service response
symbols is outside the scope of this document."

I suggest:
"Response value 0x00 maps to the SCSI service response of
TASK COMPLETE.  All other Response values map to the SCSI
service response of SERVICE DELIVERY OR TARGET FAILURE.
If a SCSI Response PDU does not arrive before the session
is terminated, the SCSI service response is SERVICE
DELIVERY OR TARGET FAILURE."

For reference, the command response codes are:
0x00 - Command Completed at Target
0x01 - Target Failure
0x80-0xff - Vendor specific

--
Rob Elliott, elliott@hp.com
Industry Standard Server Storage Advanced Technology
Hewlett-Packard

--=_alternative 004B9A64C2256BD0_=-- From owner-ips@ece.cmu.edu Thu Jun 6 11:58:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18663 for ; Thu, 6 Jun 2002 11:58:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g56FBTE17061 for ips-outgoing; Thu, 6 Jun 2002 11:11:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g56FBQw17054 for ; Thu, 6 Jun 2002 11:11:26 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g56FBKUN027260 for ; Thu, 6 Jun 2002 17:11:20 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g56FBJk20780 for ; Thu, 6 Jun 2002 17:11:19 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: minor conflict introduced by C bit X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 6 Jun 2002 18:11:18 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 06/06/2002 18:11:20, Serialize complete at 06/06/2002 18:11:20 Content-Type: multipart/alternative; boundary="=_alternative 005351FBC2256BD0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005351FBC2256BD0_= Content-Type: text/plain; charset="us-ascii" In fact for 11.9 the text will be: Target portal group tag is a 16-bit numerical-value that uniquely identifies a portal group within an iSCSI target node. This key car-ries the value of the tag of the portal group that is servicing the Login request. The iSCSI target returns this key to the initiator in the first non-empty Login Response PDU (where empty responses may be required by Login Requests with the C bit set to 1). 11.4 refers to the Sendtargets response that will be presented whenever and has no other apparent conflict with C. Julo ----- Forwarded by Julian Satran/Haifa/IBM on 06/06/2002 06:06 PM ----- Julian Satran 06/03/2002 08:21 PM To: "THALER,PAT (A-Roseville,ex1)" cc: ips@ece.cmu.edu From: Julian Satran/Haifa/IBM@IBMIL Subject: RE: iSCSI: minor conflict introduced by C bit Thanks Pat - I think that 3 is acceptable and keeps current semantics unchanged. Julo "THALER,PAT (A-Roseville,ex1)" 06/03/2002 07:47 PM Please respond to "THALER,PAT (A-Roseville,ex1)" To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: minor conflict introduced by C bit Julian, I have noticed a minor conflict of the C bit with existing text. 11.4 and 11.9 require the target to return TargetName and TargetPortal group in the first Login Response PDU but the new text on the C bit in 4.2 requires the target to return an empty response if the C bit is set. Therefore, if the C bit is set on the first Login Request PDU, the target will have conflicting requirements on it. One could resolve this by: 1) Specify that the C bit MUST NOT be set in the first Login Request PDU; or 2) Allow declarations to be sent in PDUs when the other side has the C bit set; or 3) Change the requirement in 11.4 and 11.9 to be the response to the first Login Request PDU with the C bit set to zero. Regards, Pat --=_alternative 005351FBC2256BD0_= Content-Type: text/html; charset="us-ascii"
In fact for 11.9 the text will be:

Target portal group tag is a 16-bit numerical-value that uniquely identifies a portal group within an iSCSI target node. This key car-ries the value of the tag of the portal group that is servicing the Login request. The iSCSI target returns this key to the initiator in the first non-empty Login Response PDU (where empty responses may be required by Login Requests with the C bit set to 1).

11.4 refers to the Sendtargets response that will be presented whenever and has no other apparent conflict with C.

Julo
----- Forwarded by Julian Satran/Haifa/IBM on 06/06/2002 06:06 PM -----
Julian Satran

06/03/2002 08:21 PM


        To:        "THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>
        cc:        ips@ece.cmu.edu
        From:        Julian Satran/Haifa/IBM@IBMIL
        Subject:        RE: iSCSI: minor conflict introduced by C bitLink
 





Thanks Pat - I think that 3 is acceptable and keeps current semantics unchanged.

Julo


"THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>

06/03/2002 07:47 PM
Please respond to "THALER,PAT (A-Roseville,ex1)"

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: minor conflict introduced by C bit

       


Julian,
 
I have noticed a minor conflict of the C bit with existing text.
 
11.4 and 11.9 require the target to return TargetName and TargetPortal group in the first Login Response PDU but the new text on the C bit in 4.2 requires the target to return an empty response if the C bit is set. Therefore, if the C bit is set on the first Login Request PDU, the target will have conflicting requirements on it.
 
One could resolve this by:
1) Specify that the C bit MUST NOT be set in the first Login Request PDU; or
2) Allow declarations to be sent in PDUs when the other side has the C bit set; or
3) Change the requirement in 11.4 and 11.9 to be the response to the first Login Request PDU with the C bit set to zero.
 
Regards,
Pat



--=_alternative 005351FBC2256BD0_=-- From owner-ips@ece.cmu.edu Thu Jun 6 12:02:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18770 for ; Thu, 6 Jun 2002 12:02:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g56FkPl19370 for ips-outgoing; Thu, 6 Jun 2002 11:46:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g56FkMw19365 for ; Thu, 6 Jun 2002 11:46:22 -0400 (EDT) Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.48 2002/05/24 00:39:04 root Exp $) with ESMTP id g56FijN06402 for ; Thu, 6 Jun 2002 15:44:45 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.22 2002/05/24 00:38:22 root Exp $) with SMTP id g56Fo9o27883 for ; Thu, 6 Jun 2002 15:50:09 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002060608453821395 for ; Thu, 06 Jun 2002 08:45:38 -0700 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 08:46:17 -0700 Message-ID: <9795DB627281D941B9E608445730DFC839B6C7@fmsmsx106.fm.intel.com> From: "Yao, Xuebin" To: ips@ece.cmu.edu Subject: iSCSI: CHAP Question Date: Thu, 6 Jun 2002 08:45:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20D71.1E9BAEA0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C20D71.1E9BAEA0 Content-Type: text/plain All, Since now the CHAP will be the MUST for the in-band secured authentication, I have a question regarding the CHAP RFCs. In the draft 12-96, it refers to [RFC 1994] for CHAP. However, there are also [RFC 2433] (MS-CHAP v1) and [RFC 2759] (MS-CHAP v2) which claimed consistent of [RFC 1994]. Anyone knows if they are compatible or not? Could implementer choose to use either version, and would that cause interoperability issue? Thanks! Xuebin ------_=_NextPart_001_01C20D71.1E9BAEA0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

All,

 

Since now the CHAP will be the MUST for the in-band secured authentication, I = have a question regarding the CHAP RFCs.

In the draft 12-96, it refers to [RFC 1994] for CHAP. However, there are also [RFC = 2433] (MS-CHAP v1) and [RFC 2759] (MS-CHAP v2) which claimed consistent of = [RFC 1994].

Anyone knows if they are compatible or not? Could implementer choose to use either = version, and would that cause interoperability = issue?

 

Thanks!

 

 

Xuebin

=
------_=_NextPart_001_01C20D71.1E9BAEA0-- From owner-ips@ece.cmu.edu Thu Jun 6 12:04:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18805 for ; Thu, 6 Jun 2002 12:03:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g56FcY318783 for ips-outgoing; Thu, 6 Jun 2002 11:38:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (io.iol.unh.edu [132.177.123.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g56F8Bw16813 for ; Thu, 6 Jun 2002 11:08:11 -0400 (EDT) Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.3/8.12.3) with ESMTP id g56F7r6U009324 for ; Thu, 6 Jun 2002 11:07:53 -0400 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.3/8.12.3/Submit) with ESMTP id g56F7r6u009321 for ; Thu, 6 Jun 2002 11:07:53 -0400 Date: Thu, 6 Jun 2002 11:07:53 -0400 (EDT) From: "Robert D. Russell" To: ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian: I came across another dependency in draft 12-96 (but it has been in the drafts for some time): The end of section 11.20 says: "If ErrorRecoveryLevel is not 0 and if DataSequenceInOrder is set to Yes, a target may retry at most the last R2T, and an initiator may at most request retransmission for the last read data sequence. MaxOutstandingR2T MUST be set to 1 in this case." It is unclear to me from reading this just what the "in this case" refers to -- does it mean: 1) if MaxOutstandingR2T is not 1 then the target may not retry and the initiator may not request retransmission. or 2) the combination ErrorRecoveryLevel > 0 and DataSequenceInOrder=Yes requires MaxOutStandingR2T=1. If the first interpretation is correct, then this is not really a dependency between the keys, but a subtle restriction on behavior from a certain combination of keys. If the second interpretation is correct, then this is a dependency between keys. Whichever interpretation is correct, I would suggest that the statement in section 11.20 be reworded to make the interpretation unambiguous. Thanks, Bob Russell From owner-ips@ece.cmu.edu Thu Jun 6 12:14:52 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19047 for ; Thu, 6 Jun 2002 12:14:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g56Fi4p19196 for ips-outgoing; Thu, 6 Jun 2002 11:44:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from best.eurologic.com ([213.190.135.5]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g56Fi1w19188 for ; Thu, 6 Jun 2002 11:44:01 -0400 (EDT) Received: from there (wombat [192.168.7.41]) by best.eurologic.com (8.9.3+Sun/8.9.3) with SMTP id QAA10154 for ; Thu, 6 Jun 2002 16:43:54 +0100 (BST) Message-Id: <200206061543.QAA10154@best.eurologic.com> Content-Type: text/plain; charset="iso-8859-1" From: Ken Sandars Organization: Eurologic Systems To: "Ips Reflector (E-mail)" Subject: iSCSI: Some proposed vendor-specific (X-) keys Date: Thu, 6 Jun 2002 15:43:09 +0000 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi all, Can all you implementers out there consider this proposal please? This is intended to be an aid to interoperability. Obviously once the spec is approved and everyone is fully complient there will be no need for this. This proposal is in no means intended to go into the specification (unless people REALLY want it), so feel free to skip this message now ;-) I suggest three vendor specific declarative keys which MAY/SHOULD be sent during the login phase (during the operational parameter negotiation stage): X-vendor X-product X-revision These all contains strings, eg: X-vendor=fredsIscsiShop X-product=YetAnotherIscsiTarget X-revision=1.003 These keys follow the SCSI inquiry command fields in terms of names, and are used to identify the iSCSI node's information. What does this achieve? I'm looking for an opportunity to provide automated interoperability between systems which are not yet fully complient. But I hear you think, "But why don't they just fix them?", and I have to agree. However, there are a number of iSCSI products which work wonderfully well already out there (as long as you don't excite one of their quirks). If you find out what you are connecting with during login, you can decide what things you should or shouldn't do with it. -- Ken Sandars Eurologic Systems Ltd ksandars@eurologic.com From owner-ips@ece.cmu.edu Thu Jun 6 12:37:40 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19727 for ; Thu, 6 Jun 2002 12:37:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g56G8Vk20807 for ips-outgoing; Thu, 6 Jun 2002 12:08:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g56G8Tw20803 for ; Thu, 6 Jun 2002 12:08:29 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g56G8LtK010056; Thu, 6 Jun 2002 18:08:21 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g56G8Kk102730; Thu, 6 Jun 2002 18:08:20 +0200 To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu, marjorie_krueger@hp.com MIME-Version: 1.0 Subject: RE: iSCSI: corrections to Appendix D:SendTargets X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 6 Jun 2002 19:08:18 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 06/06/2002 19:08:19, Serialize complete at 06/06/2002 19:08:19 Content-Type: multipart/alternative; boundary="=_alternative 0058484EC2256BD0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0058484EC2256BD0_= Content-Type: text/plain; charset="us-ascii" Pat, I have trouble understanding your statements WRT to IP addresses. You should be able to use addresses to whatever you want the port is what distinguishes the service (iSCSI or NAS) - if you wish (that is the usual practice) and will allow you to use a common physical interface for various services. However TCP addresses is a somewhat unusual term - addresses are IP - iSCSI is serviced at specified (or well known) ports. Julo pat_thaler@agilent.com 06/06/2002 04:02 AM Please respond to pat_thaler To: marjorie_krueger@hp.com, Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: corrections to Appendix D:SendTargets Marjorie, IP addresses shouldn't be changed to TCP addresses because that could be interpreted as meaning it needs to support SendTargets on ports connected to non-iSCSI ports. Thinking about that, I also don't think it should be required to support disovery sessions on each IP address. It seems reasonable for a system to have some IP addresses that aren't connected to an iSCSI protocol at all. For example one might build a box with storage that does both iSCSI and NAT and one might choose to use different IP addresses for those two services. One might do that because the services are on different LAN interfaces or for numerous other reasons. I think the text should be something more like: "on each IP address that supports iSCSI". Regards, Pat -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) to the following: A system that contains targets MUST support discovery sessions on each of its TCP addresses, and MUST support the SendTargets command on the discovery session. A target MUST return all path information (TCP addresses and portal group tags) for the target in question for which the requesting initiator is authorized. A target MUST support the SendTargets command on operational sessions; these will only return path information about the target to which the session is connected, and need not return information about other target names that may be defined in the responding device. This is just an explicit statement of what's implicit in the current appendix. I corrected "IP address" to "TCP address" cause it's the TCP listening port that must provide the discovery session. Also, on page 234, the paragraph: After obtaining a list of targets from the discovery target session, an iSCSI initiator may initiate new sessions to log in to the discov- ered targets for full operation. The initiator MAY keep the session to a default target open, and MAY send subsequently SendTargets com- mands to discover new targets. Should be changed to After obtaining a list of targets from the discovery target session, an iSCSI initiator may initiate new sessions to log in to the discov- ered targets for full operation. The initiator MAY keep the discovery session open, and MAY send subsequently SendTargets commands to discover new targets. On page 235, the paragraphs: In the above example, a DNS host name could have been returned instead of an IP address, and that an IPv6 addresses (5 to 16 dotted-decimal numbers) could have also been returned. The next text response shows a target that supports spanning sessions across multiple addresses, which indicates the use of the portal group tags: Should be In the above example, a DNS host name or an IPv6 address (5 to 16 dotted-decimal numbers) could have been returned instead of an IPv4 address. The next text response shows a target that supports spanning sessions across multiple addresses, and illustrates further the use of the portal group tags: Thanks, Marjorie --=_alternative 0058484EC2256BD0_= Content-Type: text/html; charset="us-ascii"
Pat,

I have trouble understanding your statements  WRT to IP addresses. You should be able to use addresses to whatever you want the port is what distinguishes the service (iSCSI or NAS) - if you wish (that is the usual practice) and will allow you to use a common physical interface for various services.

However TCP addresses is a somewhat unusual term - addresses are IP - iSCSI is serviced at specified (or well known) ports.

Julo


pat_thaler@agilent.com

06/06/2002 04:02 AM
Please respond to pat_thaler

       
        To:        marjorie_krueger@hp.com, Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: corrections to Appendix D:SendTargets

       


Marjorie,

IP addresses shouldn't be changed to TCP addresses because that could
be interpreted as meaning it needs to support SendTargets on ports connected to
non-iSCSI ports.

Thinking about that, I also don't think it should be required to support
disovery sessions on each IP address. It seems reasonable for a system to have
some IP addresses that aren't connected to an iSCSI protocol at all. For example
one might build a box with storage that does both iSCSI and NAT and one might choose
to use different IP addresses for those two services. One might do that because the
services are on different LAN interfaces or for numerous other reasons.

I think the text should be something more like: "on each IP address that supports
iSCSI".

Regards,
Pat

-----Original Message-----
From: KRUEGER,MARJORIE (HP-Roseville,ex1)

to the following:

    A system that contains targets MUST support discovery sessions on each
    of its TCP addresses, and MUST support the SendTargets command on the
    discovery session.  A target MUST return all path information (TCP
    addresses and portal group tags) for the target in question for
    which the requesting initiator is authorized.

    A target MUST support the SendTargets command on operational sessions;
    these will only return path information about the target to which
    the session is connected, and need not return information about other
    target names that may be defined in the responding device.

This is just an explicit statement of what's implicit in the current
appendix.  I corrected "IP address" to "TCP address" cause it's the TCP
listening port that must provide the discovery session.

Also, on page 234, the paragraph:

    After obtaining a list of targets from the discovery target session,
    an iSCSI initiator may initiate new sessions to log in to the discov-
    ered targets for full operation.  The initiator MAY keep the session
    to a default target open, and MAY send subsequently SendTargets com-
    mands to discover new targets.

Should be changed to

    After obtaining a list of targets from the discovery target session,
    an iSCSI initiator may initiate new sessions to log in to the discov-
    ered targets for full operation.  The initiator MAY keep the discovery
    session open, and MAY send subsequently SendTargets commands to
discover
    new targets.

On page 235, the paragraphs:

    In the above example, a DNS host name could have been returned instead
    of an IP address, and that an IPv6 addresses (5 to 16 dotted-decimal
    numbers) could have also been returned.

    The next text response shows a target that supports spanning sessions
    across multiple addresses, which indicates the use of the portal group
    tags:

Should be

    In the above example, a DNS host name or an IPv6 address (5 to 16
    dotted-decimal numbers) could have been returned instead
    of an IPv4 address.

    The next text response shows a target that supports spanning sessions
    across multiple addresses, and illustrates further the use of the
portal
    group tags:

Thanks,
Marjorie


--=_alternative 0058484EC2256BD0_=-- From owner-ips@ece.cmu.edu Thu Jun 6 12:37:49 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19742 for ; Thu, 6 Jun 2002 12:37:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g56GKGf21611 for ips-outgoing; Thu, 6 Jun 2002 12:20:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g56GKBw21596 for ; Thu, 6 Jun 2002 12:20:11 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g56GK5tK042276 for ; Thu, 6 Jun 2002 18:20:05 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g56GK4S28468 for ; Thu, 6 Jun 2002 18:20:04 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: editorial corrections to Appendix D:SendTargets X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 6 Jun 2002 19:20:02 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 06/06/2002 19:20:05, Serialize complete at 06/06/2002 19:20:05 Content-Type: multipart/alternative; boundary="=_alternative 0059B4D5C2256BD0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0059B4D5C2256BD0_= Content-Type: text/plain; charset="us-ascii" The text I suggest is: A system that contains targets MUST support discovery sessions on each of its iSCSI IP address-port pairs, and MUST support the Send-Targets command on the discovery session. A target MUST return all path information (IP address-port pairs and portal group tags) for the targets for which the requesting initiator is authorized. A target MUST support the SendTargets command on operational ses-sions; these will only return path information about the target to which the session is connected, and need not return information about other target names that may be defined in the responding system. ----- Forwarded by Julian Satran/Haifa/IBM on 06/06/2002 07:11 PM ----- Julian Satran 06/06/2002 11:27 AM To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" cc: "Ips Reflector (E-mail)" From: Julian Satran/Haifa/IBM@IBMIL Subject: Re: iSCSI: editorial corrections to Appendix D:SendTargets thanks - Julo "KRUEGER,MARJORIE (HP-Roseville,ex1)" 06/06/2002 12:21 AM Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: Julian Satran/Haifa/IBM@IBMIL cc: "Ips Reflector (E-mail)" Subject: iSCSI: editorial corrections to Appendix D:SendTargets Julian, I think there's a sentence in appendix D that needs to be cleaned up from previous edits. "A SendTargets response MUST NOT contain iSCSI default target names." (it's on page 246 of the .pdf) This should be deleted since there are no longer any "iSCSI default target names" (or at least they are not defined). Also, to clarify, I think the paragraph 3 should be modified from: A system that contains targets MUST support discovery sessions on each of its IP addresses, and MUST support the SendTargets command on the discovery session. A target MUST support the SendTargets command on operational sessions; these will only return address information about the target to which the session is connected, and do not return information about other targets. to the following: A system that contains targets MUST support discovery sessions on each of its TCP addresses, and MUST support the SendTargets command on the discovery session. A target MUST return all path information (TCP addresses and portal group tags) for the target in question for which the requesting initiator is authorized. A target MUST support the SendTargets command on operational sessions; these will only return path information about the target to which the session is connected, and need not return information about other target names that may be defined in the responding device. This is just an explicit statement of what's implicit in the current appendix. I corrected "IP address" to "TCP address" cause it's the TCP listening port that must provide the discovery session. Also, on page 234, the paragraph: After obtaining a list of targets from the discovery target session, an iSCSI initiator may initiate new sessions to log in to the discov- ered targets for full operation. The initiator MAY keep the session to a default target open, and MAY send subsequently SendTargets com- mands to discover new targets. Should be changed to After obtaining a list of targets from the discovery target session, an iSCSI initiator may initiate new sessions to log in to the discov- ered targets for full operation. The initiator MAY keep the discovery session open, and MAY send subsequently SendTargets commands to discover new targets. On page 235, the paragraphs: In the above example, a DNS host name could have been returned instead of an IP address, and that an IPv6 addresses (5 to 16 dotted-decimal numbers) could have also been returned. The next text response shows a target that supports spanning sessions across multiple addresses, which indicates the use of the portal group tags: Should be In the above example, a DNS host name or an IPv6 address (5 to 16 dotted-decimal numbers) could have been returned instead of an IPv4 address. The next text response shows a target that supports spanning sessions across multiple addresses, and illustrates further the use of the portal group tags: Thanks, Marjorie --=_alternative 0059B4D5C2256BD0_= Content-Type: text/html; charset="us-ascii"
The text I suggest is:

A system that contains targets MUST support discovery sessions on each of its iSCSI IP address-port pairs, and MUST support the Send-Targets command on the discovery session.  A target MUST return all path information (IP address-port pairs and portal group tags) for the targets for which the requesting initiator is authorized.

A target MUST support the SendTargets command on operational ses-sions; these will only return path information about the target to which the session is connected, and need not return information about other target names that may be defined in the responding system.



----- Forwarded by Julian Satran/Haifa/IBM on 06/06/2002 07:11 PM -----
Julian Satran

06/06/2002 11:27 AM


        To:        "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
        cc:        "Ips Reflector (E-mail)" <ips@ece.cmu.edu>
        From:        Julian Satran/Haifa/IBM@IBMIL
        Subject:        Re: iSCSI: editorial corrections to Appendix D:SendTargetsLink
 





thanks - Julo


"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>

06/06/2002 12:21 AM
Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        "Ips Reflector (E-mail)" <ips@ece.cmu.edu>
        Subject:        iSCSI: editorial corrections to Appendix D:SendTargets

       


Julian,
I think there's a sentence in appendix D that needs to be cleaned up from
previous edits.

"A SendTargets response MUST NOT contain iSCSI default target names." (it's
on page 246 of the .pdf) This should be deleted since there are no longer
any "iSCSI default target names" (or at least they are not defined).

Also, to clarify, I think the paragraph 3 should be modified from:

    A system that contains targets MUST support discovery sessions on each
    of its IP addresses, and MUST support the SendTargets command on the
    discovery session.  A target MUST support the SendTargets command on
    operational sessions; these will only return address information
    about the target to which the session is connected, and do not return
    information about other targets.

to the following:

    A system that contains targets MUST support discovery sessions on each
    of its TCP addresses, and MUST support the SendTargets command on the
    discovery session.  A target MUST return all path information (TCP
    addresses and portal group tags) for the target in question for
    which the requesting initiator is authorized.

    A target MUST support the SendTargets command on operational sessions;
    these will only return path information about the target to which
    the session is connected, and need not return information about other
    target names that may be defined in the responding device.

This is just an explicit statement of what's implicit in the current
appendix.  I corrected "IP address" to "TCP address" cause it's the TCP
listening port that must provide the discovery session.

Also, on page 234, the paragraph:

    After obtaining a list of targets from the discovery target session,
    an iSCSI initiator may initiate new sessions to log in to the discov-
    ered targets for full operation.  The initiator MAY keep the session
    to a default target open, and MAY send subsequently SendTargets com-
    mands to discover new targets.

Should be changed to

    After obtaining a list of targets from the discovery target session,
    an iSCSI initiator may initiate new sessions to log in to the discov-
    ered targets for full operation.  The initiator MAY keep the discovery
    session open, and MAY send subsequently SendTargets commands to
discover
    new targets.

On page 235, the paragraphs:

    In the above example, a DNS host name could have been returned instead
    of an IP address, and that an IPv6 addresses (5 to 16 dotted-decimal
    numbers) could have also been returned.

    The next text response shows a target that supports spanning sessions
    across multiple addresses, which indicates the use of the portal group
    tags:

Should be

    In the above example, a DNS host name or an IPv6 address (5 to 16
    dotted-decimal numbers) could have been returned instead
    of an IPv4 address.

    The next text response shows a target that supports spanning sessions
    across multiple addresses, and illustrates further the use of the
portal
    group tags:

Thanks,
Marjorie




--=_alternative 0059B4D5C2256BD0_=-- From owner-ips@ece.cmu.edu Thu Jun 6 12:38:20 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19767 for ; Thu, 6 Jun 2002 12:38:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g56GCXt21091 for ips-outgoing; Thu, 6 Jun 2002 12:12:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g56GCVw21082 for ; Thu, 6 Jun 2002 12:12:32 -0400 (EDT) Received: from cisco.com (dhcp-161-44-68-217.cisco.com [161.44.68.217]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA11337; Thu, 6 Jun 2002 12:12:24 -0400 (EDT) Message-ID: <3CFF89E8.7964C689@cisco.com> Date: Thu, 06 Jun 2002 11:12:24 -0500 From: Steve Senum X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Yao, Xuebin" CC: ips@ece.cmu.edu Subject: Re: iSCSI: CHAP Question References: <9795DB627281D941B9E608445730DFC839B6C7@fmsmsx106.fm.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit These are additional algorithms that can be negotiated with the CHAP_A key, and are not compatible with the algorithm in RFC 1994. I don't know if anyone has implemented them in iSCSI. RFC 2433 and RFC 2759 are informational, so there use is optional. Steve Senum -------------------------- All, Since now the CHAP will be the MUST for the in-band secured authentication, I have a question regarding the CHAP RFCs. In the draft 12-96, it refers to [RFC 1994] for CHAP. However, there are also [RFC 2433] (MS-CHAP v1) and [RFC 2759] (MS-CHAP v2) which claimed consistent of [RFC 1994]. Anyone knows if they are compatible or not? Could implementer choose to use either version, and would that cause interoperability issue? Thanks! From owner-ips@ece.cmu.edu Thu Jun 6 12:38:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19798 for ; Thu, 6 Jun 2002 12:38:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g56GB3520988 for ips-outgoing; Thu, 6 Jun 2002 12:11:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g56GB1w20982 for ; Thu, 6 Jun 2002 12:11:01 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id E62481516; Thu, 6 Jun 2002 10:11:00 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id BB6552DC; Thu, 6 Jun 2002 10:11:00 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 06 Jun 2002 10:11:00 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 10:11:00 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E3842@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI: minor conflict introduced by C bit Date: Thu, 6 Jun 2002 10:10:59 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-78eb5bb3-0fb1-408a-b15d-cbf564987844" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-78eb5bb3-0fb1-408a-b15d-cbf564987844 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20D74.BF1C1010" ------_=_NextPart_001_01C20D74.BF1C1010 Content-Type: text/plain; charset="iso-8859-1" Julian, I don't think that does it because the text is ambiguous about whether the target could delay sending the tag by sending empty Login Response PDUs when the C bit is set to 0. I suggest: Target portal group tag is a 16-bit numerical-value that uniquely identifies a portal group within an iSCSI target node. This key car-ries the value of the tag of the portal group that is servicing the Login request. The iSCSI target returns this key to the initiator in the Login Response PDU to the first Login Request PDU that has the C bit set to 0. Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, June 06, 2002 8:11 AM To: ips@ece.cmu.edu Subject: RE: iSCSI: minor conflict introduced by C bit In fact for 11.9 the text will be: Target portal group tag is a 16-bit numerical-value that uniquely identifies a portal group within an iSCSI target node. This key car-ries the value of the tag of the portal group that is servicing the Login request. The iSCSI target returns this key to the initiator in the first non-empty Login Response PDU (where empty responses may be required by Login Requests with the C bit set to 1). 11.4 refers to the Sendtargets response that will be presented whenever and has no other apparent conflict with C. Julo ----- Forwarded by Julian Satran/Haifa/IBM on 06/06/2002 06:06 PM ----- Julian Satran 06/03/2002 08:21 PM To: "THALER,PAT (A-Roseville,ex1)" cc: ips@ece.cmu.edu From: Julian Satran/Haifa/IBM@IBMIL Subject: RE: iSCSI: minor conflict introduced by C bit Link Thanks Pat - I think that 3 is acceptable and keeps current semantics unchanged. Julo "THALER,PAT (A-Roseville,ex1)" 06/03/2002 07:47 PM Please respond to "THALER,PAT (A-Roseville,ex1)" To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: minor conflict introduced by C bit Julian, I have noticed a minor conflict of the C bit with existing text. 11.4 and 11.9 require the target to return TargetName and TargetPortal group in the first Login Response PDU but the new text on the C bit in 4.2 requires the target to return an empty response if the C bit is set. Therefore, if the C bit is set on the first Login Request PDU, the target will have conflicting requirements on it. One could resolve this by: 1) Specify that the C bit MUST NOT be set in the first Login Request PDU; or 2) Allow declarations to be sent in PDUs when the other side has the C bit set; or 3) Change the requirement in 11.4 and 11.9 to be the response to the first Login Request PDU with the C bit set to zero. Regards, Pat ------_=_NextPart_001_01C20D74.BF1C1010 Content-Type: text/html; charset="iso-8859-1"
Julian,
 
I don't think that does it because the text is ambiguous about whether the target could delay sending the tag by sending empty Login Response PDUs when the C bit is set to 0. I suggest:
 
Target portal group tag is a 16-bit numerical-value that uniquely identifies a portal group within an iSCSI target node. This key car-ries the value of the tag of the portal group that is servicing the Login request. The iSCSI target returns this key to the initiator in the Login Response PDU to the first Login Request PDU that has the C bit set to 0.

Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, June 06, 2002 8:11 AM
To: ips@ece.cmu.edu
Subject: RE: iSCSI: minor conflict introduced by C bit


In fact for 11.9 the text will be:

Target portal group tag is a 16-bit numerical-value that uniquely identifies a portal group within an iSCSI target node. This key car-ries the value of the tag of the portal group that is servicing the Login request. The iSCSI target returns this key to the initiator in the first non-empty Login Response PDU (where empty responses may be required by Login Requests with the C bit set to 1).

11.4 refers to the Sendtargets response that will be presented whenever and has no other apparent conflict with C.

Julo
----- Forwarded by Julian Satran/Haifa/IBM on 06/06/2002 06:06 PM -----
Julian Satran

06/03/2002 08:21 PM


        To:        "THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>
        cc:        ips@ece.cmu.edu
        From:        Julian Satran/Haifa/IBM@IBMIL
        Subject:        RE: iSCSI: minor conflict introduced by C bitLink
 





Thanks Pat - I think that 3 is acceptable and keeps current semantics unchanged.

Julo


"THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>

06/03/2002 07:47 PM
Please respond to "THALER,PAT (A-Roseville,ex1)"

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: minor conflict introduced by C bit

       


Julian,
 
I have noticed a minor conflict of the C bit with existing text.
 
11.4 and 11.9 require the target to return TargetName and TargetPortal group in the first Login Response PDU but the new text on the C bit in 4.2 requires the target to return an empty response if the C bit is set. Therefore, if the C bit is set on the first Login Request PDU, the target will have conflicting requirements on it.
 
One could resolve this by:
1) Specify that the C bit MUST NOT be set in the first Login Request PDU; or
2) Allow declarations to be sent in PDUs when the other side has the C bit set; or
3) Change the requirement in 11.4 and 11.9 to be the response to the first Login Request PDU with the C bit set to zero.
 
Regards,
Pat



------_=_NextPart_001_01C20D74.BF1C1010-- ------=_NextPartTM-000-78eb5bb3-0fb1-408a-b15d-cbf564987844-- From owner-ips@ece.cmu.edu Thu Jun 6 12:43:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19948 for ; Thu, 6 Jun 2002 12:43:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g56FsCv19940 for ips-outgoing; Thu, 6 Jun 2002 11:54:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g56FsAw19935 for ; Thu, 6 Jun 2002 11:54:10 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 6061C16FD; Thu, 6 Jun 2002 09:54:09 -0600 (MDT) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 2C26C187; Thu, 6 Jun 2002 09:54:09 -0600 (MDT) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 06 Jun 2002 09:54:08 -0600 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 09:54:08 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E382F@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Julian Satran , ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence Date: Thu, 6 Jun 2002 09:54:07 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-8254d201-7963-11d6-ac7e-009027aa5b50" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-8254d201-7963-11d6-ac7e-009027aa5b50 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20D72.63F293F0" ------_=_NextPart_001_01C20D72.63F293F0 Content-Type: text/plain; charset="iso-8859-1" Julian, Then we shouldn't have added the C bit at all. One doesn't need it to indicate that a key-value isn't complete and one certainly doesn't need it for security negotiation where there is already a fairly lock step process for the certificate exchange. The arguments people used for adding it were that they wanted to be able to batch offers larger than a PDU without worrying about length. I agree that isn't necessary today for any of the standard keys. During login one can send all the standard keys in a single 8k PDU. During FFP, the only standard negotiated key exchanged is MaxRcvPDUDataSize. One could respond to a SendTargets with keys spread over multiple PDUs without an issue. The current places where C helps are: Implementation doesn't support 8k transmit PDU size - the negotiation default of 8 k is for the size PDU one supports receiving. An implementation might chose to only send a much shorter PDU and then its keys would not al fit in a single PDU. I find it difficult to imagine someone designing an implementation that creates a long batch of keys and then sends it in multiple short PDUs when it could send it in one PDU, so this doesn't seem like a very good reason to have the C bit. Anticipation of many more or longer standard keys in the future so that they don't all fit in 8k. Anticipation of more FFP negotiations so that FFP offers don't all fit in a single PDU when PDU size might be as small as 512. Support for vendor specific extension keys that are more then 8 k in login or more than MaxRcvPDUDataSize in FFP. Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 05, 2002 8:56 PM To: ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence As I pointed out earlier - you can batch all your keys but some certificates in 8k! It was never forbidden nor mandated. Julo pat_thaler@agilent.com 06/05/2002 09:41 PM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL, rdr@io.iol.unh.edu cc: ips@ece.cmu.edu, mkrikis@yahoo.com, owner-ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence Julian, Batching is related to the C-bit. Before the C-bit, a device could prepare a batch of keys to originate but they had to fit within the PDU because, if the keys extended beyond a PDU, the device's partner might originate some of the keys it had prepared but hadn't yet sent. With the C-bit, a device can prepare a batch of keys with out regard to their size because the device can ensure that they can be sent in multiple PDUs if necessary without the partner having an opportunity to originate keys in between. The C-bit releaves the size constraint on batching offers. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, June 04, 2002 10:19 AM To: Robert D. Russell Cc: ips@ece.cmu.edu; Martins Krikis; owner-ips@ece.cmu.edu Subject: Re: iSCSI: keys/parameter dependence I have one comment regarding to batching. Batching is not related to the C-bit. C-bit is meant to simplify spanning over PDU boundaries. Batching can be done with the previous structure as well - there is a lot you can do with an 8k block! Julo "Robert D. Russell" Sent by: owner-ips@ece.cmu.edu 06/04/2002 09:46 AM Please respond to "Robert D. Russell" To: Martins Krikis cc: ips@ece.cmu.edu Subject: Re: iSCSI: keys/parameter dependence Martins: Comments below on all your e-mails in this one reply. > As to "running and tested", > I don't think many people have encountered split > PDUs in operational stage or FFP Text negotiations > yet. Agreed. > Those, who prefer the "batch-processing" approach > fought for the C-bit, so I would say that it was > introduced in order to allow it. I missed that point earlier. > Regarding ordering, however, it had never been > defined, and I would hate to see it introduced. It was defined before draft 8, but was taken out when that draft came in. Unfortunately, I did not take it out of my memory. I agree that it should not be reintroduced. > In my opinion, it is best to treat all operational > parameters as independent and negotiate them as > such. Agreed. > Just before the commit > (i.e., turning on the T or F bit), one can do an > all-encompassing consistency check and reset > the negotiations if the values violate the laws > imposed on them, or offer some more keys to solve > any such problems, if this is still possible. What you are saying seems to imply that C=0 does NOT require the receiver to reply to keys received up to that point -- it could send another empty PDU, or more likely, it could send new offers of its own. I agree that there is nothing in the draft that says when replies to keys should be sent, only that they MUST be sent (sometime). For example, consider a login negotiation of operational parameters in which the initiator sends a login pdu containing key=value offers and the C bit 0. The target responds with a login response pdu containing key=value offers of its own (offering different keys) but no replies to any of the offers it received in the login. The initiator can then reply to the target's new offers, or it can decide not to reply, and instead send additional new offers or even an empty pdu, (C bit 0 in both alternatives). And now the target could do as it did before, not replying to any offers but either sending back new offers or sending back an empty login response pdu (again C bit 0 in both alternatives). This could go on indefinitely. It would seem that the initiator might try to force replies by setting T=1 to force an end-of-stage transition. However, the target can refuse to make the transition and can reply with T=0 and still no replies to the keys it was offered. This is admittedly a rather far-out example, because presumably both initiator and target want to end the negotiations as soon as possible. My point only is that I do not see anything in the draft that says when the replies to keys have to be sent, only several references that there MUST be a reply to every key offered (eventually). Thoughts, comments? > I could even imagine negotiations > succeeding but laws > (e.g. FirstBurstSize <= MaxBurstSize) not being > broken when sending data... OK, the last thing > might technically be forbidden at the moment > but it is not that unreasonable. It would be > something like > FirstBursSize = min(FirstBurstSize, MaxBurstSize) > done after the negotiation end, and then you can > forget about dependencies. I think it is way > easier than worrying about key ordering every > time something is sent or received. The dependency can be accounted for when generating the reply. For example, reply.FirstBurstSize = min(offer.FirstBurstSize, reply.MaxBurstSize) That way nothing is broken when sending data. > And how many instances of TargetName and TargetAddress > can the SendTargets command provoke from the other > side? I think it can easily overflow the 8192 bytes. Yes it can, but there was already a mechanism in place to deal with this. In fact, this brings up an interesting point. Presumably the C bit has to be used with replies sent to SendTargets (or any other offer that might generate a long reply), since the C bit is in the Text Response PDU used to send these replies. Refering to sections 9.10.2 and 9.10.4: If the target generating a long reply has more text to send than will fit in one PDU, then it should indicate this by setting C = 1. Setting C = 1 also forces F=0, and this in turn forces the Target Transfer Tag to be something other than 0xffffffff. When there is no more text to send, the target sets C = 0 and F = 1 and TTT=0xffffffff in the last text response pdu it sends to the initiator. There is no situation in which C = 1 and F = 1 can occur (since this is explicitly stated in 9.10.2 as being an error), nor is there a situation in which C = 0 and F = 0 should occur (because C = 0 means "I'm done sending stuff" and F = 0 means "I'm not done sending stuff"). Is this the way you interpret the merging of the C bit with the long text reply mechanism? If there is a consensus on this, perhaps the wording in the draft in section 9.10.4 should include the (required) settings of the C bit whenever it mentions the corresponding settings of the F bit and TTT field. > > -- FirstBurstSize and MaxBurstSize are dependent > > because of the > > requirement in section 11.15: "FirstBurstSize MUST > > NOT exceed > > MaxBurstSize." See my e-mail response to Mike for > > details > > on that dependence. > > I saw it. I consider it unbelievably ugly to have to > look at the values in order to figure out ordering > requirements. I prefer ignoring ordering completely > and check for overall consistency before commit. You are correct, the values can be figured out without resorting to an ordering -- my mistake. > Nowhere does it say anything about the order. Agreed. > So, are you really proposing a requirement that > we must look at the values in order to figure out in > which order to send keys? That is so UGLY, it is > hard to believe that this is happening. Please forget I even suggested it. > > The existence of a dependency between OFMarker and > > OFMarkInt, and between > > IFMarker and IFMarkInt, is implied by the statements > > in section A.3.2: > > "When the interval is unacceptable the responder > > answers with > > "Reject". Reject is resetting the marker function > > in the spcified > > direction (Output or Input) to No." > > No it isn't. IMO, it is resetting the marker interval > to its previous value, which is likely the default > value. I believe it's perfectly legal to negotiate > the marker interval but to not turn on marker use, > or to turn on the use but stay with current (default) > values for the interval. If one side can't tolerate > the other's Reject (i.e., can't live with the > default value), it is welcome to bail and try next > time w/o markers. BTW, we could use 0 here as a > special value, meaning that markers are not in use, > then we wouldn't need the boolean keys for > markers. > > > This last sentence should probably be reworded to > > say: > > "A response value of "Reject" to an OFMarkInt > > (IFMarkInt) key resets the > > corresponding OFMarker (IFMarker) key value to > > "No"." > > No, thank you. I would prefer if Reject meant the > same as with the other keys, i.e., negotiation > failed for this key, let's stick with the old > value, or bail if we must. Either the sentence needs to be reworded so it is proper English or it should be taken out of the draft. I take it you are advocating its removal? Bob Russell ------_=_NextPart_001_01C20D72.63F293F0 Content-Type: text/html; charset="iso-8859-1"
Julian,
 
Then we shouldn't have added the C bit at all. One doesn't need it to indicate that a key-value isn't complete and one certainly doesn't need it for security negotiation where there is already a fairly lock step process for the certificate exchange.
 
The arguments people used for adding it were that they wanted to be able to batch offers larger than a PDU without worrying about length. I agree that isn't necessary today for any of the standard keys.
 
During login one can send all the standard keys in a single 8k PDU. During FFP, the only standard negotiated key exchanged is MaxRcvPDUDataSize. One could respond to a SendTargets with keys spread over multiple PDUs without an issue.
 
The current places where C helps are:
Implementation doesn't support 8k transmit PDU size - the negotiation default of 8 k is for the size PDU one supports receiving. An implementation might chose to only send a much shorter PDU and then its keys would not al fit in a single PDU. I find it difficult to imagine someone designing an implementation that creates a long batch of keys and then sends it in multiple short PDUs when it could send it in one PDU, so this doesn't seem like a very good reason to have the C bit.
 
Anticipation of many more or longer standard keys in the future so that they don't all fit in 8k.
 
Anticipation of more FFP negotiations so that FFP offers don't all fit in a single PDU when PDU size might be as small as 512.
 
Support for vendor specific extension keys that are more then 8 k in login or more than MaxRcvPDUDataSize in FFP.
 
Pat
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 05, 2002 8:56 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI: keys/parameter dependence



As I pointed out earlier - you can batch all your keys but some certificates in 8k!
It was never forbidden nor mandated.

Julo


pat_thaler@agilent.com

06/05/2002 09:41 PM
Please respond to pat_thaler

       
        To:        Julian Satran/Haifa/IBM@IBMIL, rdr@io.iol.unh.edu
        cc:        ips@ece.cmu.edu, mkrikis@yahoo.com, owner-ips@ece.cmu.edu
        Subject:        RE: iSCSI: keys/parameter dependence

       


Julian,
 
Batching is related to the C-bit. Before the C-bit, a device could prepare a batch of keys to originate
but they had to fit within the PDU because, if the keys extended beyond a PDU, the device's partner
might originate some of the keys it had prepared but hadn't yet sent.
 
With the C-bit, a device can prepare a batch of keys with out regard to their size because the device
can ensure that they can be sent in multiple PDUs if necessary without the partner having an
opportunity to originate keys in between.
 
The C-bit releaves the size constraint on batching offers.
 
Regards,
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, June 04, 2002 10:19 AM
To: Robert D. Russell
Cc: ips@ece.cmu.edu; Martins Krikis; owner-ips@ece.cmu.edu
Subject: Re: iSCSI: keys/parameter dependence


I have one comment regarding to batching.

Batching is not related to the C-bit. C-bit is meant to simplify spanning over PDU boundaries.
Batching can be done with the previous structure as well - there is a lot you can do with an 8k block!

Julo

"Robert D. Russell" <rdr@io.iol.unh.edu>
Sent by: owner-ips@ece.cmu.edu

06/04/2002 09:46 AM
Please respond to "Robert D. Russell"

       
       To:        Martins Krikis <mkrikis@yahoo.com>
       cc:        ips@ece.cmu.edu
       Subject:        Re: iSCSI: keys/parameter dependence

     



Martins:

Comments below on all your e-mails in this one reply.

> As to "running and tested",
> I don't think many people have encountered split
> PDUs in operational stage or FFP Text negotiations
> yet.

Agreed.


> Those, who prefer the "batch-processing" approach
> fought for the C-bit, so I would say that it was
> introduced in order to allow it.

I missed that point earlier.


> Regarding ordering, however, it had never been
> defined, and I would hate to see it introduced.

It was defined before draft 8, but was taken out when that
draft came in.  Unfortunately, I did not take it out of
my memory.  I agree that it should not be reintroduced.


> In my opinion, it is best to treat all operational
> parameters as independent and negotiate them as
> such.

Agreed.


> Just before the commit
> (i.e., turning on the T or F bit), one can do an
> all-encompassing consistency check and reset
> the negotiations if the values violate the laws
> imposed on them, or offer some more keys to solve
> any such problems, if this is still possible.


What you are saying seems to imply that C=0 does NOT
require the receiver to reply to keys received up to that point
-- it could send another empty PDU, or more likely, it could send
new offers of its own.  I agree that there is nothing in the draft
that says when replies to keys should be sent, only that they
MUST be sent (sometime).

For example, consider a login negotiation of operational parameters
in which the initiator sends a login pdu containing key=value offers
and the C bit 0.  The target responds with a login response pdu
containing key=value offers of its own (offering different keys)
but no replies to any of the offers it received in the login.
The initiator can then reply to the target's new offers, or it
can decide not to reply, and instead send additional new offers
or even an empty pdu, (C bit 0 in both alternatives).  And now
the target could do as it did before, not replying to any offers
but either sending back new offers or sending back an empty login
response pdu (again C bit 0 in both alternatives).  This could go
on indefinitely.

It would seem that the initiator might try to force replies by
setting T=1 to force an end-of-stage transition.  However, the target
can refuse to make the transition and can reply with T=0 and still
no replies to the keys it was offered.

This is admittedly a rather far-out example, because presumably both
initiator and target want to end the negotiations as soon as possible.
My point only is that I do not see anything in the draft that says
when the replies to keys have to be sent, only several references
that there MUST be a reply to every key offered (eventually).

Thoughts, comments?


> I could even imagine negotiations
> succeeding but laws
> (e.g. FirstBurstSize <= MaxBurstSize) not being
> broken when sending data... OK, the last thing
> might technically be forbidden at the moment
> but it is not that unreasonable. It would be
> something like
> FirstBursSize = min(FirstBurstSize, MaxBurstSize)
> done after the negotiation end, and then you can
> forget about dependencies. I think it is way
> easier than worrying about key ordering every
> time something is sent or received.

The dependency can be accounted for when generating the reply.
For example,

reply.FirstBurstSize = min(offer.FirstBurstSize, reply.MaxBurstSize)

That way nothing is broken when sending data.


> And how many instances of TargetName and TargetAddress
> can the SendTargets command provoke from the other
> side? I think it can easily overflow the 8192 bytes.

Yes it can, but there was already a mechanism in place to deal
with this.  In fact, this brings up an interesting point.
Presumably the C bit has to be used with replies sent to
SendTargets (or any other offer that might generate a long reply),
since the C bit is in the Text Response PDU used to send these replies.

Refering to sections 9.10.2 and 9.10.4:  If the target generating a
long reply has more text to send than will fit in one PDU, then it
should indicate this by setting C = 1.  Setting C = 1 also forces F=0,
and this in turn forces the Target Transfer Tag to be something
other than 0xffffffff.  When there is no more text to send,
the target sets C = 0 and F = 1 and TTT=0xffffffff in the last
text response pdu it sends to the initiator.  There is no
situation in which C = 1 and F = 1 can occur (since this is
explicitly stated in 9.10.2 as being an error), nor is there a
situation in which C = 0 and F = 0 should occur (because C = 0
means "I'm done sending stuff" and F = 0 means "I'm not done sending
stuff").

Is this the way you interpret the merging of the C bit with the
long text reply mechanism?  If there is a consensus on this,
perhaps the wording in the draft in section 9.10.4 should include
the (required) settings of the C bit whenever it mentions the
corresponding settings of the F bit and TTT field.


> > -- FirstBurstSize and MaxBurstSize are dependent
> > because of the
> > requirement in section 11.15: "FirstBurstSize MUST
> > NOT exceed
> > MaxBurstSize."  See my e-mail response to Mike for
> > details
> > on that dependence.
>
> I saw it. I consider it unbelievably ugly to have to
> look at the values in order to figure out ordering
> requirements. I prefer ignoring ordering completely
> and check for overall consistency before commit.

You are correct, the values can be figured out without
resorting to an ordering -- my mistake.


> Nowhere does it say anything about the order.

Agreed.


> So, are you really proposing a requirement that
> we must look at the values in order to figure out in
> which order to send keys? That is so UGLY, it is
> hard to believe that this is happening.

Please forget I even suggested it.


> > The existence of a dependency between OFMarker and
> > OFMarkInt, and between
> > IFMarker and IFMarkInt, is implied by the statements
> > in section A.3.2:
> > "When the interval is unacceptable the responder
> > answers with
> > "Reject".  Reject is resetting the marker function
> > in the spcified
> > direction (Output or Input) to No."
>
> No it isn't. IMO, it is resetting the marker interval
> to its previous value, which is likely the default
> value. I believe it's perfectly legal to negotiate
> the marker interval but to not turn on marker use,
> or to turn on the use but stay with current (default)
> values for the interval. If one side can't  tolerate
> the other's  Reject (i.e., can't live with the
> default value), it is welcome to bail and try next
> time w/o markers. BTW, we could use 0 here as a
> special value, meaning that markers are not in use,
> then we wouldn't need the boolean keys for
> markers.
>
> > This last sentence should probably be reworded to
> > say:
> > "A response value of "Reject" to an OFMarkInt
> > (IFMarkInt) key resets the
> > corresponding OFMarker (IFMarker) key value to
> > "No"."
>
> No, thank you. I would prefer if Reject meant the
> same as with the other keys, i.e., negotiation
> failed for this key, let's stick with the old
> value, or bail if we must.

Either the sentence needs to be reworded so it is proper English
or it should be taken out of the draft.  I take it you are advocating
its removal?

Bob Russell






------_=_NextPart_001_01C20D72.63F293F0-- ------=_NextPartTM-000-8254d201-7963-11d6-ac7e-009027aa5b50-- From owner-ips@ece.cmu.edu Thu Jun 6 13:00:39 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20312 for ; Thu, 6 Jun 2002 13:00:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g56Gc4w22823 for ips-outgoing; Thu, 6 Jun 2002 12:38:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g56Gc1w22813 for ; Thu, 6 Jun 2002 12:38:01 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g56GbtPI014104; Thu, 6 Jun 2002 09:37:55 -0700 (PDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA13572; Thu, 6 Jun 2002 09:37:54 -0700 (PDT) Message-ID: <3CFF93DF.F6AB9C29@cisco.com> Date: Thu, 06 Jun 2002 11:54:55 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" CC: "Julian Satran (E-mail)" , "Ips Reflector (E-mail)" Subject: Re: iSCSI: editorial corrections to Appendix D:SendTargets References: <6BD67FFB937FD411A04F00D0B74FE87805CCF630@xrose06.rose.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Marjorie- I agree with your proposed changes. We should also remove the expression: (5 to 16 dotted-decimal numbers) From the IPv6 address note on page 235, since IPv6 addresses are no longer expressed in dotted-decimal. -- Mark "KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote: > > Julian, > I think there's a sentence in appendix D that needs to be cleaned up from > previous edits. > > "A SendTargets response MUST NOT contain iSCSI default target names." (it's > on page 246 of the .pdf) This should be deleted since there are no longer > any "iSCSI default target names" (or at least they are not defined). > > Also, to clarify, I think the paragraph 3 should be modified from: > > A system that contains targets MUST support discovery sessions on each > of its IP addresses, and MUST support the SendTargets command on the > discovery session. A target MUST support the SendTargets command on > operational sessions; these will only return address information > about the target to which the session is connected, and do not return > information about other targets. > > to the following: > > A system that contains targets MUST support discovery sessions on each > of its TCP addresses, and MUST support the SendTargets command on the > discovery session. A target MUST return all path information (TCP > addresses and portal group tags) for the target in question for > which the requesting initiator is authorized. > > A target MUST support the SendTargets command on operational sessions; > these will only return path information about the target to which > the session is connected, and need not return information about other > target names that may be defined in the responding device. > > This is just an explicit statement of what's implicit in the current > appendix. I corrected "IP address" to "TCP address" cause it's the TCP > listening port that must provide the discovery session. > > Also, on page 234, the paragraph: > > After obtaining a list of targets from the discovery target session, > an iSCSI initiator may initiate new sessions to log in to the discov- > ered targets for full operation. The initiator MAY keep the session > to a default target open, and MAY send subsequently SendTargets com- > mands to discover new targets. > > Should be changed to > > After obtaining a list of targets from the discovery target session, > an iSCSI initiator may initiate new sessions to log in to the discov- > ered targets for full operation. The initiator MAY keep the discovery > session open, and MAY send subsequently SendTargets commands to > discover > new targets. > > On page 235, the paragraphs: > > In the above example, a DNS host name could have been returned instead > of an IP address, and that an IPv6 addresses (5 to 16 dotted-decimal > numbers) could have also been returned. > > The next text response shows a target that supports spanning sessions > across multiple addresses, which indicates the use of the portal group > tags: > > Should be > > In the above example, a DNS host name or an IPv6 address (5 to 16 > dotted-decimal numbers) could have been returned instead > of an IPv4 address. > > The next text response shows a target that supports spanning sessions > across multiple addresses, and illustrates further the use of the > portal > group tags: > > Thanks, > Marjorie -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Thu Jun 6 13:00:46 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20325 for ; Thu, 6 Jun 2002 13:00:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g56GWUK22447 for ips-outgoing; Thu, 6 Jun 2002 12:32:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g56GWRw22440 for ; Thu, 6 Jun 2002 12:32:27 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id JAA16308; Thu, 6 Jun 2002 09:32:18 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 09:32:18 -0700 Message-ID: <2F37CED150E21640A9C6E75B8BE6AF830A4CBD@hq-ex-4> From: Robert Snively To: "'Ken Sandars'" , "Ips Reflector (E-mail)" Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys Date: Thu, 6 Jun 2002 09:32:14 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk I am not in favor of replicating a standard SCSI function that is not part of the link protocol outside the SCSI command set. What this does is fragment the driver designs in a way that might prevent the usual SCSI driver interoperation with parallel SCSI, SBP, FC, and SRP SCSI devices. You would then need non-standard SCSI drivers for iSCSI devices. Bob > -----Original Message----- > From: Ken Sandars [mailto:ksandars@eurologic.com] > Sent: Thursday, June 06, 2002 8:43 AM > To: Ips Reflector (E-mail) > Subject: iSCSI: Some proposed vendor-specific (X-) keys > > > Hi all, > > Can all you implementers out there consider this proposal > please? This is > intended to be an aid to interoperability. Obviously once the spec is > approved and everyone is fully complient there will be no > need for this. > > This proposal is in no means intended to go into the > specification (unless > people REALLY want it), so feel free to skip this message now ;-) > > I suggest three vendor specific declarative keys which > MAY/SHOULD be sent > during the login phase (during the operational parameter > negotiation stage): > > X-vendor > X-product > X-revision > > These all contains strings, eg: > > X-vendor=fredsIscsiShop > X-product=YetAnotherIscsiTarget > X-revision=1.003 > > These keys follow the SCSI inquiry command fields in terms of > names, and are > used to identify the iSCSI node's information. > > What does this achieve? I'm looking for an opportunity to > provide automated > interoperability between systems which are not yet fully complient. > > But I hear you think, "But why don't they just fix them?", > and I have to > agree. > > However, there are a number of iSCSI products which work > wonderfully well > already out there (as long as you don't excite one of their > quirks). If you > find out what you are connecting with during login, you can > decide what > things you should or shouldn't do with it. > > > -- > Ken Sandars > Eurologic Systems Ltd > ksandars@eurologic.com > From owner-ips@ece.cmu.edu Thu Jun 6 18:57:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05633 for ; Thu, 6 Jun 2002 18:57:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g56JbMk05044 for ips-outgoing; Thu, 6 Jun 2002 15:37:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from exboulder2.aciesnetworks.com (exchange.aciesnetworks.com [65.90.51.20]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g56IGXw29533 for ; Thu, 6 Jun 2002 14:16:37 -0400 (EDT) Received: from inactive ([10.105.2.74]) by exboulder2.aciesnetworks.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 6 Jun 2002 12:16:26 -0600 Message-ID: <00a001c20d86$70cf0770$4a02690a@inactive> From: "Bob Mastors" To: "Ken Sandars" , "Ips Reflector \(E-mail\)" References: <200206061543.QAA10154@best.eurologic.com> Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys Date: Thu, 6 Jun 2002 12:17:38 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 06 Jun 2002 18:16:26.0646 (UTC) FILETIME=[45BB0B60:01C20D86] Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I like it. Otherwise the user has to configure the initiator with the target type and the target with the initiator type. It is unlikely that this problem will disappear for a long time if ever. As the threads on the C bit has shown there will be lots of ways to implement the spec and probably no device will correctly support all possibilities. I am already putting "if (vendor)" code in my implementation. Maybe in a few years I will not need it. But until then it would be nice if I could dynamically determine vendor information for iscsi so the user does not have to configure it. Bob ----- Original Message ----- From: "Ken Sandars" To: "Ips Reflector (E-mail)" Sent: Thursday, June 06, 2002 9:43 AM Subject: iSCSI: Some proposed vendor-specific (X-) keys > Hi all, > > Can all you implementers out there consider this proposal please? This is > intended to be an aid to interoperability. Obviously once the spec is > approved and everyone is fully complient there will be no need for this. > > This proposal is in no means intended to go into the specification (unless > people REALLY want it), so feel free to skip this message now ;-) > > I suggest three vendor specific declarative keys which MAY/SHOULD be sent > during the login phase (during the operational parameter negotiation stage): > > X-vendor > X-product > X-revision > > These all contains strings, eg: > > X-vendor=fredsIscsiShop > X-product=YetAnotherIscsiTarget > X-revision=1.003 > > These keys follow the SCSI inquiry command fields in terms of names, and are > used to identify the iSCSI node's information. > > What does this achieve? I'm looking for an opportunity to provide automated > interoperability between systems which are not yet fully complient. > > But I hear you think, "But why don't they just fix them?", and I have to > agree. > > However, there are a number of iSCSI products which work wonderfully well > already out there (as long as you don't excite one of their quirks). If you > find out what you are connecting with during login, you can decide what > things you should or shouldn't do with it. > > > -- > Ken Sandars > Eurologic Systems Ltd > ksandars@eurologic.com From owner-ips@ece.cmu.edu Thu Jun 6 19:01:20 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07027 for ; Thu, 6 Jun 2002 19:01:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g56JFUt03515 for ips-outgoing; Thu, 6 Jun 2002 15:15:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g56JFSw03508 for ; Thu, 6 Jun 2002 15:15:28 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 7A90830706; Thu, 6 Jun 2002 15:15:27 -0400 (EDT) Date: Thu, 6 Jun 2002 12:13:20 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: "THALER,PAT (A-Roseville,ex1)" Cc: Julian Satran , Subject: RE: iSCSI: keys/parameter dependence In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00C5E382F@axcs04.cos.agilent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 6 Jun 2002, THALER,PAT (A-Roseville,ex1) wrote: > Julian, > > Then we shouldn't have added the C bit at all. One doesn't need it to > indicate that a key-value isn't complete and one certainly doesn't > need it for security negotiation where there is already a fairly lock > step process for the certificate exchange. > > The arguments people used for adding it were that they wanted to be > able to batch offers larger than a PDU without worrying about length. > I agree that isn't necessary today for any of the standard keys. Kinda. The spec says that you can have keys & values span a PDU. My main concern was I took the negotiation code I was writing down the path that split keys would lead to, and I found an UGLY mess. So I would either have to code up a mess, or I would have to have a not-strictly-conforming implementation. The whole thread on it was an effort to avoid that mess and follow the spec. > During login one can send all the standard keys in a single 8k PDU. > During FFP, the only standard negotiated key exchanged is > MaxRcvPDUDataSize. One could respond to a SendTargets with keys spread > over multiple PDUs without an issue. > The current places where C helps are: > Implementation doesn't support 8k transmit PDU size - the negotiation > default of 8 k is for the size PDU one supports receiving. An > implementation might chose to only send a much shorter PDU and then > its keys would not al fit in a single PDU. I find it difficult to > imagine someone designing an implementation that creates a long batch > of keys and then sends it in multiple short PDUs when it could send it > in one PDU, so this doesn't seem like a very good reason to have the C > bit. I agree this isn't a strong reason. > Anticipation of many more or longer standard keys in the future so > that they don't all fit in 8k. > > Anticipation of more FFP negotiations so that FFP offers don't all fit > in a single PDU when PDU size might be as small as 512. > > Support for vendor specific extension keys that are more then 8 k in > login or more than MaxRcvPDUDataSize in FFP. The latter ones are good reasons. But the main reason I saw for the C bit is that the way the spec was written, to strictly comply with it would lead to a real mess. It certainly could be done, but where I saw things going was (as the thread indicated) not where the majority of the WG had seen them going. For instance Julian had a sender making a buffer and chopping it into PDUs in mind, which wasn't simple with the spec as it was. Yes, there are other ways out of the mess, but the C bit is one that required little change to current negotiations. All you have to do is stick some buffer control code in the head of the login PDU analysis code (I posted pseudocode based off of what I am using), and your current code works as-is. Take care, Bill From owner-ips@ece.cmu.edu Thu Jun 6 19:01:20 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07032 for ; Thu, 6 Jun 2002 19:01:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g56JW1R04609 for ips-outgoing; Thu, 6 Jun 2002 15:32:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g56JVww04602 for ; Thu, 6 Jun 2002 15:31:58 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g56JVqPI001766; Thu, 6 Jun 2002 12:31:52 -0700 (PDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA24088; Thu, 6 Jun 2002 12:31:51 -0700 (PDT) Message-ID: <3CFFBCA4.2352C693@cisco.com> Date: Thu, 06 Jun 2002 14:48:52 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Julian Satran CC: "Ips Reflector (E-mail)" , "KRUEGER,MARJORIE (HP-Roseville,ex1)" Subject: Re: iSCSI: editorial corrections to Appendix D:SendTargets References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian Satran wrote: > > the doted thing was removed a long time ago - your text is stale! - julo Yep; that's why I want to remove it. -- Mark > > Mark Bakke > Sent by: mbakke@cisco.com To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" > > 06/06/2002 07:54 PM cc: Julian Satran/Haifa/IBM@IBMIL, "Ips Reflector > Please respond to Mark Bakke (E-mail)" > Subject: Re: iSCSI: editorial corrections to > Appendix D:SendTargets > > > > Marjorie- > > I agree with your proposed changes. We should also remove the > expression: > > (5 to 16 dotted-decimal numbers) > > >From the IPv6 address note on page 235, since IPv6 addresses are > no longer expressed in dotted-decimal. > > -- > Mark > > "KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote: > > > > Julian, > > I think there's a sentence in appendix D that needs to be cleaned up from > > previous edits. > > > > "A SendTargets response MUST NOT contain iSCSI default target names." (it's > > on page 246 of the .pdf) This should be deleted since there are no longer > > any "iSCSI default target names" (or at least they are not defined). > > > > Also, to clarify, I think the paragraph 3 should be modified from: > > > > A system that contains targets MUST support discovery sessions on each > > of its IP addresses, and MUST support the SendTargets command on the > > discovery session. A target MUST support the SendTargets command on > > operational sessions; these will only return address information > > about the target to which the session is connected, and do not return > > information about other targets. > > > > to the following: > > > > A system that contains targets MUST support discovery sessions on each > > of its TCP addresses, and MUST support the SendTargets command on the > > discovery session. A target MUST return all path information (TCP > > addresses and portal group tags) for the target in question for > > which the requesting initiator is authorized. > > > > A target MUST support the SendTargets command on operational sessions; > > these will only return path information about the target to which > > the session is connected, and need not return information about other > > target names that may be defined in the responding device. > > > > This is just an explicit statement of what's implicit in the current > > appendix. I corrected "IP address" to "TCP address" cause it's the TCP > > listening port that must provide the discovery session. > > > > Also, on page 234, the paragraph: > > > > After obtaining a list of targets from the discovery target session, > > an iSCSI initiator may initiate new sessions to log in to the discov- > > ered targets for full operation. The initiator MAY keep the session > > to a default target open, and MAY send subsequently SendTargets com- > > mands to discover new targets. > > > > Should be changed to > > > > After obtaining a list of targets from the discovery target session, > > an iSCSI initiator may initiate new sessions to log in to the discov- > > ered targets for full operation. The initiator MAY keep the discovery > > session open, and MAY send subsequently SendTargets commands to > > discover > > new targets. > > > > On page 235, the paragraphs: > > > > In the above example, a DNS host name could have been returned instead > > of an IP address, and that an IPv6 addresses (5 to 16 dotted-decimal > > numbers) could have also been returned. > > > > The next text response shows a target that supports spanning sessions > > across multiple addresses, which indicates the use of the portal group > > tags: > > > > Should be > > > > In the above example, a DNS host name or an IPv6 address (5 to 16 > > dotted-decimal numbers) could have been returned instead > > of an IPv4 address. > > > > The next text response shows a target that supports spanning sessions > > across multiple addresses, and illustrates further the use of the > > portal > > group tags: > > > > Thanks, > > Marjorie > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Thu Jun 6 19:01:22 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07044 for ; Thu, 6 Jun 2002 19:01:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g56J4gn02836 for ips-outgoing; Thu, 6 Jun 2002 15:04:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g56J4ew02830 for ; Thu, 6 Jun 2002 15:04:40 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g56J4JtK020554; Thu, 6 Jun 2002 21:04:19 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g56J4IS68156; Thu, 6 Jun 2002 21:04:18 +0200 To: Mark Bakke Cc: "Ips Reflector (E-mail)" , "KRUEGER,MARJORIE (HP-Roseville,ex1)" , mbakke@cisco.com MIME-Version: 1.0 Subject: Re: iSCSI: editorial corrections to Appendix D:SendTargets X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 6 Jun 2002 22:04:12 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 06/06/2002 22:04:18, Serialize complete at 06/06/2002 22:04:18 Content-Type: multipart/alternative; boundary="=_alternative 005C95C6C2256BD0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005C95C6C2256BD0_= Content-Type: text/plain; charset="us-ascii" the doted thing was removed a long time ago - your text is stale! - julo Mark Bakke Sent by: mbakke@cisco.com 06/06/2002 07:54 PM Please respond to Mark Bakke To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" cc: Julian Satran/Haifa/IBM@IBMIL, "Ips Reflector (E-mail)" Subject: Re: iSCSI: editorial corrections to Appendix D:SendTargets Marjorie- I agree with your proposed changes. We should also remove the expression: (5 to 16 dotted-decimal numbers) From the IPv6 address note on page 235, since IPv6 addresses are no longer expressed in dotted-decimal. -- Mark "KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote: > > Julian, > I think there's a sentence in appendix D that needs to be cleaned up from > previous edits. > > "A SendTargets response MUST NOT contain iSCSI default target names." (it's > on page 246 of the .pdf) This should be deleted since there are no longer > any "iSCSI default target names" (or at least they are not defined). > > Also, to clarify, I think the paragraph 3 should be modified from: > > A system that contains targets MUST support discovery sessions on each > of its IP addresses, and MUST support the SendTargets command on the > discovery session. A target MUST support the SendTargets command on > operational sessions; these will only return address information > about the target to which the session is connected, and do not return > information about other targets. > > to the following: > > A system that contains targets MUST support discovery sessions on each > of its TCP addresses, and MUST support the SendTargets command on the > discovery session. A target MUST return all path information (TCP > addresses and portal group tags) for the target in question for > which the requesting initiator is authorized. > > A target MUST support the SendTargets command on operational sessions; > these will only return path information about the target to which > the session is connected, and need not return information about other > target names that may be defined in the responding device. > > This is just an explicit statement of what's implicit in the current > appendix. I corrected "IP address" to "TCP address" cause it's the TCP > listening port that must provide the discovery session. > > Also, on page 234, the paragraph: > > After obtaining a list of targets from the discovery target session, > an iSCSI initiator may initiate new sessions to log in to the discov- > ered targets for full operation. The initiator MAY keep the session > to a default target open, and MAY send subsequently SendTargets com- > mands to discover new targets. > > Should be changed to > > After obtaining a list of targets from the discovery target session, > an iSCSI initiator may initiate new sessions to log in to the discov- > ered targets for full operation. The initiator MAY keep the discovery > session open, and MAY send subsequently SendTargets commands to > discover > new targets. > > On page 235, the paragraphs: > > In the above example, a DNS host name could have been returned instead > of an IP address, and that an IPv6 addresses (5 to 16 dotted-decimal > numbers) could have also been returned. > > The next text response shows a target that supports spanning sessions > across multiple addresses, which indicates the use of the portal group > tags: > > Should be > > In the above example, a DNS host name or an IPv6 address (5 to 16 > dotted-decimal numbers) could have been returned instead > of an IPv4 address. > > The next text response shows a target that supports spanning sessions > across multiple addresses, and illustrates further the use of the > portal > group tags: > > Thanks, > Marjorie -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 --=_alternative 005C95C6C2256BD0_= Content-Type: text/html; charset="us-ascii"
the doted thing was removed a long time ago - your text is stale!  - julo


Mark Bakke <mbakke@cisco.com>
Sent by: mbakke@cisco.com

06/06/2002 07:54 PM
Please respond to Mark Bakke

       
        To:        "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
        cc:        Julian Satran/Haifa/IBM@IBMIL, "Ips Reflector (E-mail)" <ips@ece.cmu.edu>
        Subject:        Re: iSCSI: editorial corrections to Appendix D:SendTargets

       



Marjorie-

I agree with your proposed changes.  We should also remove the
expression:

  (5 to 16 dotted-decimal numbers)

From the IPv6 address note on page 235, since IPv6 addresses are
no longer expressed in dotted-decimal.

--
Mark

"KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote:
>
> Julian,
> I think there's a sentence in appendix D that needs to be cleaned up from
> previous edits.
>
> "A SendTargets response MUST NOT contain iSCSI default target names." (it's
> on page 246 of the .pdf) This should be deleted since there are no longer
> any "iSCSI default target names" (or at least they are not defined).
>
> Also, to clarify, I think the paragraph 3 should be modified from:
>
>      A system that contains targets MUST support discovery sessions on each
>      of its IP addresses, and MUST support the SendTargets command on the
>      discovery session.  A target MUST support the SendTargets command on
>      operational sessions; these will only return address information
>      about the target to which the session is connected, and do not return
>      information about other targets.
>
> to the following:
>
>      A system that contains targets MUST support discovery sessions on each
>      of its TCP addresses, and MUST support the SendTargets command on the
>      discovery session.  A target MUST return all path information (TCP
>      addresses and portal group tags) for the target in question for
>      which the requesting initiator is authorized.
>
>      A target MUST support the SendTargets command on operational sessions;
>      these will only return path information about the target to which
>      the session is connected, and need not return information about other
>      target names that may be defined in the responding device.
>
> This is just an explicit statement of what's implicit in the current
> appendix.  I corrected "IP address" to "TCP address" cause it's the TCP
> listening port that must provide the discovery session.
>
> Also, on page 234, the paragraph:
>
>      After obtaining a list of targets from the discovery target session,
>      an iSCSI initiator may initiate new sessions to log in to the discov-
>      ered targets for full operation.  The initiator MAY keep the session
>      to a default target open, and MAY send subsequently SendTargets com-
>      mands to discover new targets.
>
> Should be changed to
>
>      After obtaining a list of targets from the discovery target session,
>      an iSCSI initiator may initiate new sessions to log in to the discov-
>      ered targets for full operation.  The initiator MAY keep the discovery
>      session open, and MAY send subsequently SendTargets commands to
> discover
>      new targets.
>
> On page 235, the paragraphs:
>
>      In the above example, a DNS host name could have been returned instead
>      of an IP address, and that an IPv6 addresses (5 to 16 dotted-decimal
>      numbers) could have also been returned.
>
>      The next text response shows a target that supports spanning sessions
>      across multiple addresses, which indicates the use of the portal group
>      tags:
>
> Should be
>
>      In the above example, a DNS host name or an IPv6 address (5 to 16
>      dotted-decimal numbers) could have been returned instead
>      of an IPv4 address.
>
>      The next text response shows a target that supports spanning sessions
>      across multiple addresses, and illustrates further the use of the
> portal
>      group tags:
>
> Thanks,
> Marjorie

--
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054

--=_alternative 005C95C6C2256BD0_=-- From owner-ips@ece.cmu.edu Thu Jun 6 19:01:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07078 for ; Thu, 6 Jun 2002 19:01:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g56J4Ot02803 for ips-outgoing; Thu, 6 Jun 2002 15:04:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g56J4Lw02795 for ; Thu, 6 Jun 2002 15:04:21 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g56J4A8Y010970; Thu, 6 Jun 2002 21:04:10 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g56J49S114226; Thu, 6 Jun 2002 21:04:09 +0200 To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: minor conflict introduced by C bit X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 6 Jun 2002 22:04:04 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 06/06/2002 22:04:09, Serialize complete at 06/06/2002 22:04:09 Content-Type: multipart/alternative; boundary="=_alternative 005C0C6BC2256BD0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005C0C6BC2256BD0_= Content-Type: text/plain; charset="us-ascii" OK - julo pat_thaler@agilent.com 06/06/2002 07:10 PM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iSCSI: minor conflict introduced by C bit Julian, I don't think that does it because the text is ambiguous about whether the target could delay sending the tag by sending empty Login Response PDUs when the C bit is set to 0. I suggest: Target portal group tag is a 16-bit numerical-value that uniquely identifies a portal group within an iSCSI target node. This key car-ries the value of the tag of the portal group that is servicing the Login request. The iSCSI target returns this key to the initiator in the Login Response PDU to the first Login Request PDU that has the C bit set to 0. Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, June 06, 2002 8:11 AM To: ips@ece.cmu.edu Subject: RE: iSCSI: minor conflict introduced by C bit In fact for 11.9 the text will be: Target portal group tag is a 16-bit numerical-value that uniquely identifies a portal group within an iSCSI target node. This key car-ries the value of the tag of the portal group that is servicing the Login request. The iSCSI target returns this key to the initiator in the first non-empty Login Response PDU (where empty responses may be required by Login Requests with the C bit set to 1). 11.4 refers to the Sendtargets response that will be presented whenever and has no other apparent conflict with C. Julo ----- Forwarded by Julian Satran/Haifa/IBM on 06/06/2002 06:06 PM ----- Julian Satran 06/03/2002 08:21 PM To: "THALER,PAT (A-Roseville,ex1)" cc: ips@ece.cmu.edu From: Julian Satran/Haifa/IBM@IBMIL Subject: RE: iSCSI: minor conflict introduced by C bitLink Thanks Pat - I think that 3 is acceptable and keeps current semantics unchanged. Julo "THALER,PAT (A-Roseville,ex1)" 06/03/2002 07:47 PM Please respond to "THALER,PAT (A-Roseville,ex1)" To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: minor conflict introduced by C bit Julian, I have noticed a minor conflict of the C bit with existing text. 11.4 and 11.9 require the target to return TargetName and TargetPortal group in the first Login Response PDU but the new text on the C bit in 4.2 requires the target to return an empty response if the C bit is set. Therefore, if the C bit is set on the first Login Request PDU, the target will have conflicting requirements on it. One could resolve this by: 1) Specify that the C bit MUST NOT be set in the first Login Request PDU; or 2) Allow declarations to be sent in PDUs when the other side has the C bit set; or 3) Change the requirement in 11.4 and 11.9 to be the response to the first Login Request PDU with the C bit set to zero. Regards, Pat --=_alternative 005C0C6BC2256BD0_= Content-Type: text/html; charset="us-ascii"
OK - julo


pat_thaler@agilent.com

06/06/2002 07:10 PM
Please respond to pat_thaler

       
        To:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
        cc:        
        Subject:        RE: iSCSI: minor conflict introduced by C bit

       


Julian,
 
I don't think that does it because the text is ambiguous about whether the target could delay sending the tag by sending empty Login Response PDUs when the C bit is set to 0. I suggest:
 
Target portal group tag is a 16-bit numerical-value that uniquely identifies a portal group within an iSCSI target node. This key car-ries the value of the tag of the portal group that is servicing the Login request. The iSCSI target returns this key to the initiator in the Login Response PDU to the first Login Request PDU that has the C bit set to 0.

Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, June 06, 2002 8:11 AM
To: ips@ece.cmu.edu
Subject: RE: iSCSI: minor conflict introduced by C bit

In fact for 11.9 the text will be:

Target portal group tag is a 16-bit numerical-value that uniquely identifies a portal group within an iSCSI target node. This key car-ries the value of the tag of the portal group that is servicing the Login request. The iSCSI target returns this key to the initiator in the first non-empty Login Response PDU (where empty responses may be required by Login Requests with the C bit set to 1).

11.4 refers to the Sendtargets response that will be presented whenever and has no other apparent conflict with C.

Julo
----- Forwarded by Julian Satran/Haifa/IBM on 06/06/2002 06:06 PM -----
Julian Satran

06/03/2002 08:21 PM


       To:        "THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>
       cc:        ips@ece.cmu.edu
       From:        Julian Satran/Haifa/IBM@IBMIL
       Subject:        RE: iSCSI: minor conflict introduced by C bitLink
 





Thanks Pat - I think that 3 is acceptable and keeps current semantics unchanged.

Julo

"THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>

06/03/2002 07:47 PM
Please respond to "THALER,PAT (A-Roseville,ex1)"

       
       To:        Julian Satran/Haifa/IBM@IBMIL
       cc:        ips@ece.cmu.edu
       Subject:        RE: iSCSI: minor conflict introduced by C bit

     



Julian,
 
I have noticed a minor conflict of the C bit with existing text.
 
11.4 and 11.9 require the target to return TargetName and TargetPortal group in the first Login Response PDU but the new text on the C bit in 4.2 requires the target to return an empty response if the C bit is set. Therefore, if the C bit is set on the first Login Request PDU, the target will have conflicting requirements on it.
 
One could resolve this by:
1) Specify that the C bit MUST NOT be set in the first Login Request PDU; or
2) Allow declarations to be sent in PDUs when the other side has the C bit set; or
3) Change the requirement in 11.4 and 11.9 to be the response to the first Login Request PDU with the C bit set to zero.
 
Regards,
Pat




--=_alternative 005C0C6BC2256BD0_=-- From owner-ips@ece.cmu.edu Thu Jun 6 19:43:17 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16589 for ; Thu, 6 Jun 2002 19:43:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g56Hh7p27452 for ips-outgoing; Thu, 6 Jun 2002 13:43:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g56Hh4w27447 for ; Thu, 6 Jun 2002 13:43:04 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 1113130706; Thu, 6 Jun 2002 13:43:04 -0400 (EDT) Date: Thu, 6 Jun 2002 10:40:56 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Cc: , , Subject: RE: iSCSI: corrections to Appendix D:SendTargets In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00C3542BA@axcs04.cos.agilent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Wed, 5 Jun 2002 pat_thaler@agilent.com wrote: > Marjorie, > > IP addresses shouldn't be changed to TCP addresses because that could > be interpreted as meaning it needs to support SendTargets on ports connected to > non-iSCSI ports. > > Thinking about that, I also don't think it should be required to support > disovery sessions on each IP address. It seems reasonable for a system to have > some IP addresses that aren't connected to an iSCSI protocol at all. For example > one might build a box with storage that does both iSCSI and NAT and one might choose > to use different IP addresses for those two services. One might do that because the > services are on different LAN interfaces or for numerous other reasons. > > I think the text should be something more like: "on each IP address that supports > iSCSI". I see your point, but I also see Marjorie's point. How about "on each TCP port that supports iSCSI." ? That way we are sepecific that we're talking about TCP, and that only iSCSI-related ports support discovery sessions, which I think is the intent of the WG. :-) Take care, Bill From owner-ips@ece.cmu.edu Thu Jun 6 20:05:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18300 for ; Thu, 6 Jun 2002 20:05:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g56NPkO17879 for ips-outgoing; Thu, 6 Jun 2002 19:25:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g56NPiw17874 for ; Thu, 6 Jun 2002 19:25:44 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id DE15A30706; Thu, 6 Jun 2002 19:25:43 -0400 (EDT) Date: Thu, 6 Jun 2002 16:23:37 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Dennis Young Cc: "'Bob Mastors'" , Ken Sandars , "Ips Reflector (E-mail)" Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys In-Reply-To: <45BEF1D68145D51186C100B0D0AABE659E0152@med.corp.rhapsodynetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 6 Jun 2002, Dennis Young wrote: > I think this is useful besides run time interoperability purpose > (this is a hot button and can be argued either way, just like the > version # of the draft), such as for reporting problems on a remote > device to the device manufacturer. I agree with Dennis. I think though that Paul is right that these keys should NOT be used as an excuse to permit interoperability problems. They can though be informative. If a customer has problems with my code, I'd love to have revision info, which could be conveniently conveyed with these keys. As to the poster this morning (whose message I deleted too fast) who said this is wrong because the info should be available in SCSI sense data, I disagree. Consider the case of an iscsi->parallel scsi gateway (a box that has a traditional scsi drive, and exports it over iSCSI). There the scsi sense data & mode pages are (well might be) those of the attached drive, which can be from a different vendor than the iscsi device. Also, don't forget we're talking about an optional thing (they are X-keys after all). :-) Take care, Bill From owner-ips@ece.cmu.edu Thu Jun 6 20:05:49 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18325 for ; Thu, 6 Jun 2002 20:05:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g56Nxxe19460 for ips-outgoing; Thu, 6 Jun 2002 19:59:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g56Nxvw19456 for ; Thu, 6 Jun 2002 19:59:57 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 007BF30706; Thu, 6 Jun 2002 19:59:56 -0400 (EDT) Date: Thu, 6 Jun 2002 16:57:50 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Cc: , , , Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00C5E3987@axcs04.cos.agilent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 6 Jun 2002 pat_thaler@agilent.com wrote: > Bill, > > If x-keys are used for this then they should be given proper x-key names: > x-reversed.dns_name.key_name > > It is a bad precedent to ignore domain naming in some of the first x-keys. > People wouldn't want the dns name to be a vendor name in this case but > perhaps a neutral party such as SNIA or UNH would be willing to have > its domain name used for such keys (and they have nice short DNS names). True. Point taken. Any volinteers? Take care, Bill From owner-ips@ece.cmu.edu Thu Jun 6 20:06:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18356 for ; Thu, 6 Jun 2002 20:06:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g56K6Ch06975 for ips-outgoing; Thu, 6 Jun 2002 16:06:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g56K69w06968 for ; Thu, 6 Jun 2002 16:06:09 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g56K64p24105 for ; Thu, 6 Jun 2002 16:06:04 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g56K63c24065; Thu, 6 Jun 2002 16:06:03 -0400 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with SMTP id g56K62E16889; Thu, 6 Jun 2002 16:06:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15615.49322.620978.172434@pkoning.dev.equallogic.com> Date: Thu, 6 Jun 2002 16:06:02 -0400 From: Paul Koning To: bmastors@allocity.com Cc: ksandars@eurologic.com, ips@ece.cmu.edu Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys References: <200206061543.QAA10154@best.eurologic.com> <00a001c20d86$70cf0770$4a02690a@inactive> X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Bob" == Bob Mastors writes: Bob> I like it. Otherwise the user has to configure the initiator Bob> with the target type and the target with the initiator type. It Bob> is unlikely that this problem will disappear for a long time if Bob> ever. As the threads on the C bit has shown there will be lots Bob> of ways to implement the spec and probably no device will Bob> correctly support all possibilities. I am already putting "if Bob> (vendor)" code in my implementation. Maybe in a few years I will Bob> not need it. But until then it would be nice if I could Bob> dynamically determine vendor information for iscsi so the user Bob> does not have to configure it. Oh boy, now I'm well and truly frightened. I read your message as saying that there isn't going to be interoperability for several years. Sorather than create a serious incentive for implementers to fix their defects, we should implement a way to have them report which collection of defects they implement so we can invoke workaround collection #42. Of course, the larger the collection of crocks we work around, the larger the number of bugs in implementations that everyone else will have to work around. In the words of a well known American, "Just Say NO". paul From owner-ips@ece.cmu.edu Thu Jun 6 20:07:40 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18492 for ; Thu, 6 Jun 2002 20:07:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g56NqCw19108 for ips-outgoing; Thu, 6 Jun 2002 19:52:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g56NqBw19104 for ; Thu, 6 Jun 2002 19:52:11 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 3C590CE73; Thu, 6 Jun 2002 17:52:10 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1.cos.agilent.com (Postfix) with SMTP id E784D241; Thu, 6 Jun 2002 17:52:05 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 06 Jun 2002 17:52:05 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 17:52:05 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E3987@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: wrstuden@wasabisystems.com, dyoung@rhapsodynetworks.com Cc: bmastors@allocity.com, ksandars@eurologic.com, ips@ece.cmu.edu Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys Date: Thu, 6 Jun 2002 17:52:03 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Bill, If x-keys are used for this then they should be given proper x-key names: x-reversed.dns_name.key_name It is a bad precedent to ignore domain naming in some of the first x-keys. People wouldn't want the dns name to be a vendor name in this case but perhaps a neutral party such as SNIA or UNH would be willing to have its domain name used for such keys (and they have nice short DNS names). Regards, Pat -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Thursday, June 06, 2002 4:24 PM To: Dennis Young Cc: 'Bob Mastors'; Ken Sandars; Ips Reflector (E-mail) Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys On Thu, 6 Jun 2002, Dennis Young wrote: > I think this is useful besides run time interoperability purpose > (this is a hot button and can be argued either way, just like the > version # of the draft), such as for reporting problems on a remote > device to the device manufacturer. I agree with Dennis. I think though that Paul is right that these keys should NOT be used as an excuse to permit interoperability problems. They can though be informative. If a customer has problems with my code, I'd love to have revision info, which could be conveniently conveyed with these keys. As to the poster this morning (whose message I deleted too fast) who said this is wrong because the info should be available in SCSI sense data, I disagree. Consider the case of an iscsi->parallel scsi gateway (a box that has a traditional scsi drive, and exports it over iSCSI). There the scsi sense data & mode pages are (well might be) those of the attached drive, which can be from a different vendor than the iscsi device. Also, don't forget we're talking about an optional thing (they are X-keys after all). :-) Take care, Bill From owner-ips@ece.cmu.edu Thu Jun 6 20:08:22 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18573 for ; Thu, 6 Jun 2002 20:08:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g56NVqu18181 for ips-outgoing; Thu, 6 Jun 2002 19:31:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g56NVpw18176 for ; Thu, 6 Jun 2002 19:31:51 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 4B33413E4; Thu, 6 Jun 2002 17:31:48 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 60CB94F0; Thu, 6 Jun 2002 17:31:43 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 06 Jun 2002 17:31:10 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 17:31:10 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E396B@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: ni1d@arrl.net, bmastors@allocity.com Cc: ksandars@eurologic.com, ips@ece.cmu.edu Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys Date: Thu, 6 Jun 2002 17:31:09 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Paul, I agree. This would also create a testing nightmare for initiator developers. If the initiator has adapts itself for n targets then it has n different personalities that all need to be tested. We have interoperability testing to help us find and fix spec ambiguities that cause interoperability problems. The way to build market for iSCSI is to have interoperability - not to have cases wher Brand_x Target doesn't work with Brand_y Initiator because Brand_y doesn't have the tweak profile for Brand_x. Regards, Pat -----Original Message----- From: Paul Koning [mailto:ni1d@arrl.net] Sent: Thursday, June 06, 2002 1:06 PM To: bmastors@allocity.com Cc: ksandars@eurologic.com; ips@ece.cmu.edu Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys >>>>> "Bob" == Bob Mastors writes: Bob> I like it. Otherwise the user has to configure the initiator Bob> with the target type and the target with the initiator type. It Bob> is unlikely that this problem will disappear for a long time if Bob> ever. As the threads on the C bit has shown there will be lots Bob> of ways to implement the spec and probably no device will Bob> correctly support all possibilities. I am already putting "if Bob> (vendor)" code in my implementation. Maybe in a few years I will Bob> not need it. But until then it would be nice if I could Bob> dynamically determine vendor information for iscsi so the user Bob> does not have to configure it. Oh boy, now I'm well and truly frightened. I read your message as saying that there isn't going to be interoperability for several years. Sorather than create a serious incentive for implementers to fix their defects, we should implement a way to have them report which collection of defects they implement so we can invoke workaround collection #42. Of course, the larger the collection of crocks we work around, the larger the number of bugs in implementations that everyone else will have to work around. In the words of a well known American, "Just Say NO". paul From owner-ips@ece.cmu.edu Thu Jun 6 20:39:36 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20601 for ; Thu, 6 Jun 2002 20:39:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g56GmoZ23474 for ips-outgoing; Thu, 6 Jun 2002 12:48:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g56Gmlw23470 for ; Thu, 6 Jun 2002 12:48:47 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 92B9CCDE4; Thu, 6 Jun 2002 10:48:46 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 45966212; Thu, 6 Jun 2002 10:48:46 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 06 Jun 2002 10:48:35 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 10:48:34 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E386B@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com, pat_thaler@agilent.com Cc: ips@ece.cmu.edu, marjorie_krueger@hp.com Subject: RE: iSCSI: corrections to Appendix D:SendTargets Date: Thu, 6 Jun 2002 10:48:33 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-4277d0a4-127e-4b45-b7f1-e6f77882e94d" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-4277d0a4-127e-4b45-b7f1-e6f77882e94d Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20D79.FEDB6430" ------_=_NextPart_001_01C20D79.FEDB6430 Content-Type: text/plain; charset="iso-8859-1" Julian, Part of the problem is that the term "system" covers a very broad range of things. The current wording requires every IP address in a system to be able to be attached to the iSCSI service. There are reasonable implementations that would be prohibited by such a requirement. E.g. one could have a box containing storage plus separate NAS and iSCSI controllers each with their own IP addresses and LAN interfaces. Such a box could be considered a system containing targets and the IP address that goes to the NAS controller doesn't have an iSCSI service available to it. I don't see why we should prohibit this implementation. The term "iSCSI IP address-port pairs," used in the text proposed in your other email seems reasonable. Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, June 06, 2002 9:08 AM To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu; marjorie_krueger@hp.com Subject: RE: iSCSI: corrections to Appendix D:SendTargets Pat, I have trouble understanding your statements WRT to IP addresses. You should be able to use addresses to whatever you want the port is what distinguishes the service (iSCSI or NAS) - if you wish (that is the usual practice) and will allow you to use a common physical interface for various services. However TCP addresses is a somewhat unusual term - addresses are IP - iSCSI is serviced at specified (or well known) ports. Julo pat_thaler@agilent.com 06/06/2002 04:02 AM Please respond to pat_thaler To: marjorie_krueger@hp.com, Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: corrections to Appendix D:SendTargets Marjorie, IP addresses shouldn't be changed to TCP addresses because that could be interpreted as meaning it needs to support SendTargets on ports connected to non-iSCSI ports. Thinking about that, I also don't think it should be required to support disovery sessions on each IP address. It seems reasonable for a system to have some IP addresses that aren't connected to an iSCSI protocol at all. For example one might build a box with storage that does both iSCSI and NAT and one might choose to use different IP addresses for those two services. One might do that because the services are on different LAN interfaces or for numerous other reasons. I think the text should be something more like: "on each IP address that supports iSCSI". Regards, Pat -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) to the following: A system that contains targets MUST support discovery sessions on each of its TCP addresses, and MUST support the SendTargets command on the discovery session. A target MUST return all path information (TCP addresses and portal group tags) for the target in question for which the requesting initiator is authorized. A target MUST support the SendTargets command on operational sessions; these will only return path information about the target to which the session is connected, and need not return information about other target names that may be defined in the responding device. This is just an explicit statement of what's implicit in the current appendix. I corrected "IP address" to "TCP address" cause it's the TCP listening port that must provide the discovery session. Also, on page 234, the paragraph: After obtaining a list of targets from the discovery target session, an iSCSI initiator may initiate new sessions to log in to the discov- ered targets for full operation. The initiator MAY keep the session to a default target open, and MAY send subsequently SendTargets com- mands to discover new targets. Should be changed to After obtaining a list of targets from the discovery target session, an iSCSI initiator may initiate new sessions to log in to the discov- ered targets for full operation. The initiator MAY keep the discovery session open, and MAY send subsequently SendTargets commands to discover new targets. On page 235, the paragraphs: In the above example, a DNS host name could have been returned instead of an IP address, and that an IPv6 addresses (5 to 16 dotted-decimal numbers) could have also been returned. The next text response shows a target that supports spanning sessions across multiple addresses, which indicates the use of the portal group tags: Should be In the above example, a DNS host name or an IPv6 address (5 to 16 dotted-decimal numbers) could have been returned instead of an IPv4 address. The next text response shows a target that supports spanning sessions across multiple addresses, and illustrates further the use of the portal group tags: Thanks, Marjorie ------_=_NextPart_001_01C20D79.FEDB6430 Content-Type: text/html; charset="iso-8859-1"
Julian,
 
Part of the problem is that the term "system" covers a very broad range of things. The current wording requires every IP address in a system to be able to be attached to the iSCSI service. There are reasonable implementations that would be prohibited by such a requirement.  E.g. one could have a box containing storage plus separate NAS and iSCSI controllers each with their own IP addresses and LAN interfaces. Such a box could be considered a system containing targets and the IP address that goes to the NAS controller doesn't have an iSCSI service available to it. I don't see why we should prohibit this implementation.
 
The term "iSCSI IP address-port pairs," used in the text proposed in your other email seems reasonable.
 
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, June 06, 2002 9:08 AM
To: pat_thaler@agilent.com
Cc: ips@ece.cmu.edu; marjorie_krueger@hp.com
Subject: RE: iSCSI: corrections to Appendix D:SendTargets


Pat,

I have trouble understanding your statements  WRT to IP addresses. You should be able to use addresses to whatever you want the port is what distinguishes the service (iSCSI or NAS) - if you wish (that is the usual practice) and will allow you to use a common physical interface for various services.

However TCP addresses is a somewhat unusual term - addresses are IP - iSCSI is serviced at specified (or well known) ports.

Julo


pat_thaler@agilent.com

06/06/2002 04:02 AM
Please respond to pat_thaler

       
        To:        marjorie_krueger@hp.com, Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: corrections to Appendix D:SendTargets

       


Marjorie,

IP addresses shouldn't be changed to TCP addresses because that could
be interpreted as meaning it needs to support SendTargets on ports connected to
non-iSCSI ports.

Thinking about that, I also don't think it should be required to support
disovery sessions on each IP address. It seems reasonable for a system to have
some IP addresses that aren't connected to an iSCSI protocol at all. For example
one might build a box with storage that does both iSCSI and NAT and one might choose
to use different IP addresses for those two services. One might do that because the
services are on different LAN interfaces or for numerous other reasons.

I think the text should be something more like: "on each IP address that supports
iSCSI".

Regards,
Pat

-----Original Message-----
From: KRUEGER,MARJORIE (HP-Roseville,ex1)

to the following:

    A system that contains targets MUST support discovery sessions on each
    of its TCP addresses, and MUST support the SendTargets command on the
    discovery session.  A target MUST return all path information (TCP
    addresses and portal group tags) for the target in question for
    which the requesting initiator is authorized.

    A target MUST support the SendTargets command on operational sessions;
    these will only return path information about the target to which
    the session is connected, and need not return information about other
    target names that may be defined in the responding device.

This is just an explicit statement of what's implicit in the current
appendix.  I corrected "IP address" to "TCP address" cause it's the TCP
listening port that must provide the discovery session.

Also, on page 234, the paragraph:

    After obtaining a list of targets from the discovery target session,
    an iSCSI initiator may initiate new sessions to log in to the discov-
    ered targets for full operation.  The initiator MAY keep the session
    to a default target open, and MAY send subsequently SendTargets com-
    mands to discover new targets.

Should be changed to

    After obtaining a list of targets from the discovery target session,
    an iSCSI initiator may initiate new sessions to log in to the discov-
    ered targets for full operation.  The initiator MAY keep the discovery
    session open, and MAY send subsequently SendTargets commands to
discover
    new targets.

On page 235, the paragraphs:

    In the above example, a DNS host name could have been returned instead
    of an IP address, and that an IPv6 addresses (5 to 16 dotted-decimal
    numbers) could have also been returned.

    The next text response shows a target that supports spanning sessions
    across multiple addresses, which indicates the use of the portal group
    tags:

Should be

    In the above example, a DNS host name or an IPv6 address (5 to 16
    dotted-decimal numbers) could have been returned instead
    of an IPv4 address.

    The next text response shows a target that supports spanning sessions
    across multiple addresses, and illustrates further the use of the
portal
    group tags:

Thanks,
Marjorie


------_=_NextPart_001_01C20D79.FEDB6430-- ------=_NextPartTM-000-4277d0a4-127e-4b45-b7f1-e6f77882e94d-- From owner-ips@ece.cmu.edu Thu Jun 6 20:39:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20603 for ; Thu, 6 Jun 2002 20:39:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g56H6E124750 for ips-outgoing; Thu, 6 Jun 2002 13:06:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g56H6Aw24744 for ; Thu, 6 Jun 2002 13:06:10 -0400 (EDT) Received: from xparelay2.corp.hp.com (xparelay2.corp.hp.com [15.58.137.112]) by palrel12.hp.com (Postfix) with ESMTP id 94B92E00DAC; Thu, 6 Jun 2002 10:06:04 -0700 (PDT) Received: from xpabh3.corp.hp.com (xpabh3.corp.hp.com [15.58.136.223]) by xparelay2.corp.hp.com (Postfix) with ESMTP id 87ED2A9; Thu, 6 Jun 2002 10:06:04 -0700 (PDT) Received: by xpabh3.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 10:06:04 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF639@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Julian Satran'" , ips@ece.cmu.edu Subject: RE: iSCSI: editorial corrections to Appendix D:SendTargets Date: Thu, 6 Jun 2002 10:06:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20D7C.6E9109E0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C20D7C.6E9109E0 Content-Type: text/plain; charset="iso-8859-1" That looks fine to me. Thanks! ----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, June 06, 2002 9:20 AM To: ips@ece.cmu.edu Subject: Re: iSCSI: editorial corrections to Appendix D:SendTargets The text I suggest is: A system that contains targets MUST support discovery sessions on each of its iSCSI IP address-port pairs, and MUST support the Send-Targets command on the discovery session. A target MUST return all path information (IP address-port pairs and portal group tags) for the targets for which the requesting initiator is authorized. A target MUST support the SendTargets command on operational ses-sions; these will only return path information about the target to which the session is connected, and need not return information about other target names that may be defined in the responding system. ----- Forwarded by Julian Satran/Haifa/IBM on 06/06/2002 07:11 PM ----- Julian Satran 06/06/2002 11:27 AM To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" cc: "Ips Reflector (E-mail)" From: Julian Satran/Haifa/IBM@IBMIL Subject: Re: iSCSI: editorial corrections to Appendix D:SendTargets Link thanks - Julo "KRUEGER,MARJORIE (HP-Roseville,ex1)" 06/06/2002 12:21 AM Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: Julian Satran/Haifa/IBM@IBMIL cc: "Ips Reflector (E-mail)" Subject: iSCSI: editorial corrections to Appendix D:SendTargets Julian, I think there's a sentence in appendix D that needs to be cleaned up from previous edits. "A SendTargets response MUST NOT contain iSCSI default target names." (it's on page 246 of the .pdf) This should be deleted since there are no longer any "iSCSI default target names" (or at least they are not defined). Also, to clarify, I think the paragraph 3 should be modified from: A system that contains targets MUST support discovery sessions on each of its IP addresses, and MUST support the SendTargets command on the discovery session. A target MUST support the SendTargets command on operational sessions; these will only return address information about the target to which the session is connected, and do not return information about other targets. to the following: A system that contains targets MUST support discovery sessions on each of its TCP addresses, and MUST support the SendTargets command on the discovery session. A target MUST return all path information (TCP addresses and portal group tags) for the target in question for which the requesting initiator is authorized. A target MUST support the SendTargets command on operational sessions; these will only return path information about the target to which the session is connected, and need not return information about other target names that may be defined in the responding device. This is just an explicit statement of what's implicit in the current appendix. I corrected "IP address" to "TCP address" cause it's the TCP listening port that must provide the discovery session. Also, on page 234, the paragraph: After obtaining a list of targets from the discovery target session, an iSCSI initiator may initiate new sessions to log in to the discov- ered targets for full operation. The initiator MAY keep the session to a default target open, and MAY send subsequently SendTargets com- mands to discover new targets. Should be changed to After obtaining a list of targets from the discovery target session, an iSCSI initiator may initiate new sessions to log in to the discov- ered targets for full operation. The initiator MAY keep the discovery session open, and MAY send subsequently SendTargets commands to discover new targets. On page 235, the paragraphs: In the above example, a DNS host name could have been returned instead of an IP address, and that an IPv6 addresses (5 to 16 dotted-decimal numbers) could have also been returned. The next text response shows a target that supports spanning sessions across multiple addresses, which indicates the use of the portal group tags: Should be In the above example, a DNS host name or an IPv6 address (5 to 16 dotted-decimal numbers) could have been returned instead of an IPv4 address. The next text response shows a target that supports spanning sessions across multiple addresses, and illustrates further the use of the portal group tags: Thanks, Marjorie ------_=_NextPart_001_01C20D7C.6E9109E0 Content-Type: text/html; charset="iso-8859-1"
That looks fine to me. Thanks!
 
 ----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, June 06, 2002 9:20 AM
To: ips@ece.cmu.edu
Subject: Re: iSCSI: editorial corrections to Appendix D:SendTargets


The text I suggest is:

A system that contains targets MUST support discovery sessions on each of its iSCSI IP address-port pairs, and MUST support the Send-Targets command on the discovery session.  A target MUST return all path information (IP address-port pairs and portal group tags) for the targets for which the requesting initiator is authorized.

A target MUST support the SendTargets command on operational ses-sions; these will only return path information about the target to which the session is connected, and need not return information about other target names that may be defined in the responding system.



----- Forwarded by Julian Satran/Haifa/IBM on 06/06/2002 07:11 PM -----
Julian Satran

06/06/2002 11:27 AM


        To:        "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
        cc:        "Ips Reflector (E-mail)" <ips@ece.cmu.edu>
        From:        Julian Satran/Haifa/IBM@IBMIL
        Subject:        Re: iSCSI: editorial corrections to Appendix D:SendTargetsLink
 





thanks - Julo


"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>

06/06/2002 12:21 AM
Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        "Ips Reflector (E-mail)" <ips@ece.cmu.edu>
        Subject:        iSCSI: editorial corrections to Appendix D:SendTargets

       


Julian,
I think there's a sentence in appendix D that needs to be cleaned up from
previous edits.

"A SendTargets response MUST NOT contain iSCSI default target names." (it's
on page 246 of the .pdf) This should be deleted since there are no longer
any "iSCSI default target names" (or at least they are not defined).

Also, to clarify, I think the paragraph 3 should be modified from:

    A system that contains targets MUST support discovery sessions on each
    of its IP addresses, and MUST support the SendTargets command on the
    discovery session.  A target MUST support the SendTargets command on
    operational sessions; these will only return address information
    about the target to which the session is connected, and do not return
    information about other targets.

to the following:

    A system that contains targets MUST support discovery sessions on each
    of its TCP addresses, and MUST support the SendTargets command on the
    discovery session.  A target MUST return all path information (TCP
    addresses and portal group tags) for the target in question for
    which the requesting initiator is authorized.

    A target MUST support the SendTargets command on operational sessions;
    these will only return path information about the target to which
    the session is connected, and need not return information about other
    target names that may be defined in the responding device.

This is just an explicit statement of what's implicit in the current
appendix.  I corrected "IP address" to "TCP address" cause it's the TCP
listening port that must provide the discovery session.

Also, on page 234, the paragraph:

    After obtaining a list of targets from the discovery target session,
    an iSCSI initiator may initiate new sessions to log in to the discov-
    ered targets for full operation.  The initiator MAY keep the session
    to a default target open, and MAY send subsequently SendTargets com-
    mands to discover new targets.

Should be changed to

    After obtaining a list of targets from the discovery target session,
    an iSCSI initiator may initiate new sessions to log in to the discov-
    ered targets for full operation.  The initiator MAY keep the discovery
    session open, and MAY send subsequently SendTargets commands to
discover
    new targets.

On page 235, the paragraphs:

    In the above example, a DNS host name could have been returned instead
    of an IP address, and that an IPv6 addresses (5 to 16 dotted-decimal
    numbers) could have also been returned.

    The next text response shows a target that supports spanning sessions
    across multiple addresses, which indicates the use of the portal group
    tags:

Should be

    In the above example, a DNS host name or an IPv6 address (5 to 16
    dotted-decimal numbers) could have been returned instead
    of an IPv4 address.

    The next text response shows a target that supports spanning sessions
    across multiple addresses, and illustrates further the use of the
portal
    group tags:

Thanks,
Marjorie




------_=_NextPart_001_01C20D7C.6E9109E0-- From owner-ips@ece.cmu.edu Thu Jun 6 21:14:30 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22297 for ; Thu, 6 Jun 2002 21:14:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g56LZYp12249 for ips-outgoing; Thu, 6 Jun 2002 17:35:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from med.corp.rhapsodynetworks.com (64-160-62-201.rhapsodynetworks.com [64.160.62.201] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g56LZWw12244 for ; Thu, 6 Jun 2002 17:35:32 -0400 (EDT) Received: by med.corp.rhapsodynetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 14:35:25 -0700 Message-ID: <45BEF1D68145D51186C100B0D0AABE659E0152@med.corp.rhapsodynetworks.com> From: Dennis Young To: "'Bob Mastors'" , Ken Sandars , "Ips Reflector (E-mail)" Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys Date: Thu, 6 Jun 2002 14:35:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I think this is useful besides run time interoperability purpose (this is a hot button and can be argued either way, just like the version # of the draft), such as for reporting problems on a remote device to the device manufacturer. -Dennis >-----Original Message----- >From: Bob Mastors [mailto:bmastors@allocity.com] >Sent: Thursday, June 06, 2002 11:18 AM >To: Ken Sandars; Ips Reflector (E-mail) >Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys > > >I like it. >Otherwise the user has to configure the initiator with the >target type and >the target with the initiator type. >It is unlikely that this problem will disappear for a long >time if ever. >As the threads on the C bit has shown there will be lots of ways to >implement the spec and probably no device will correctly >support all possibilities. >I am already putting "if (vendor)" code in my implementation. >Maybe in a few >years I will not need it. But until then it would be nice if I >could dynamically determine >vendor information for iscsi so the user does not have to configure it. >Bob > >----- Original Message ----- >From: "Ken Sandars" >To: "Ips Reflector (E-mail)" >Sent: Thursday, June 06, 2002 9:43 AM >Subject: iSCSI: Some proposed vendor-specific (X-) keys > > >> Hi all, >> >> Can all you implementers out there consider this proposal >please? This is >> intended to be an aid to interoperability. Obviously once >the spec is >> approved and everyone is fully complient there will be no >need for this. >> >> This proposal is in no means intended to go into the >specification (unless >> people REALLY want it), so feel free to skip this message now ;-) >> >> I suggest three vendor specific declarative keys which >MAY/SHOULD be sent >> during the login phase (during the operational parameter >negotiation stage): >> >> X-vendor >> X-product >> X-revision >> >> These all contains strings, eg: >> >> X-vendor=fredsIscsiShop >> X-product=YetAnotherIscsiTarget >> X-revision=1.003 >> >> These keys follow the SCSI inquiry command fields in terms >of names, and are >> used to identify the iSCSI node's information. >> >> What does this achieve? I'm looking for an opportunity to >provide automated >> interoperability between systems which are not yet fully complient. >> >> But I hear you think, "But why don't they just fix them?", >and I have to >> agree. >> >> However, there are a number of iSCSI products which work >wonderfully well >> already out there (as long as you don't excite one of their >quirks). If you >> find out what you are connecting with during login, you can >decide what >> things you should or shouldn't do with it. >> >> >> -- >> Ken Sandars >> Eurologic Systems Ltd >> ksandars@eurologic.com > From owner-ips@ece.cmu.edu Thu Jun 6 21:18:28 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22453 for ; Thu, 6 Jun 2002 21:18:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g56LCcm10939 for ips-outgoing; Thu, 6 Jun 2002 17:12:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g56LCXw10922 for ; Thu, 6 Jun 2002 17:12:33 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g56LCNUN011132; Thu, 6 Jun 2002 23:12:23 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g56LCMk41110; Thu, 6 Jun 2002 23:12:22 +0200 To: "THALER,PAT (A-Roseville,ex1)" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: keys/parameter dependence X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 7 Jun 2002 00:12:17 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 07/06/2002 00:12:22, Serialize complete at 07/06/2002 00:12:22 Content-Type: multipart/alternative; boundary="=_alternative 0069133BC2256BD0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0069133BC2256BD0_= Content-Type: text/plain; charset="us-ascii" Pat, I wonder what I said to warrant such a long answer. I just pointed out that the C bit should not be viewed as related (directly) to batching. Julo "THALER,PAT (A-Roseville,ex1)" 06/06/2002 06:54 PM Please respond to "THALER,PAT (A-Roseville,ex1)" To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iSCSI: keys/parameter dependence Julian, Then we shouldn't have added the C bit at all. One doesn't need it to indicate that a key-value isn't complete and one certainly doesn't need it for security negotiation where there is already a fairly lock step process for the certificate exchange. The arguments people used for adding it were that they wanted to be able to batch offers larger than a PDU without worrying about length. I agree that isn't necessary today for any of the standard keys. During login one can send all the standard keys in a single 8k PDU. During FFP, the only standard negotiated key exchanged is MaxRcvPDUDataSize. One could respond to a SendTargets with keys spread over multiple PDUs without an issue. The current places where C helps are: Implementation doesn't support 8k transmit PDU size - the negotiation default of 8 k is for the size PDU one supports receiving. An implementation might chose to only send a much shorter PDU and then its keys would not al fit in a single PDU. I find it difficult to imagine someone designing an implementation that creates a long batch of keys and then sends it in multiple short PDUs when it could send it in one PDU, so this doesn't seem like a very good reason to have the C bit. Anticipation of many more or longer standard keys in the future so that they don't all fit in 8k. Anticipation of more FFP negotiations so that FFP offers don't all fit in a single PDU when PDU size might be as small as 512. Support for vendor specific extension keys that are more then 8 k in login or more than MaxRcvPDUDataSize in FFP. Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 05, 2002 8:56 PM To: ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence As I pointed out earlier - you can batch all your keys but some certificates in 8k! It was never forbidden nor mandated. Julo pat_thaler@agilent.com 06/05/2002 09:41 PM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL, rdr@io.iol.unh.edu cc: ips@ece.cmu.edu, mkrikis@yahoo.com, owner-ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence Julian, Batching is related to the C-bit. Before the C-bit, a device could prepare a batch of keys to originate but they had to fit within the PDU because, if the keys extended beyond a PDU, the device's partner might originate some of the keys it had prepared but hadn't yet sent. With the C-bit, a device can prepare a batch of keys with out regard to their size because the device can ensure that they can be sent in multiple PDUs if necessary without the partner having an opportunity to originate keys in between. The C-bit releaves the size constraint on batching offers. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, June 04, 2002 10:19 AM To: Robert D. Russell Cc: ips@ece.cmu.edu; Martins Krikis; owner-ips@ece.cmu.edu Subject: Re: iSCSI: keys/parameter dependence I have one comment regarding to batching. Batching is not related to the C-bit. C-bit is meant to simplify spanning over PDU boundaries. Batching can be done with the previous structure as well - there is a lot you can do with an 8k block! Julo "Robert D. Russell" Sent by: owner-ips@ece.cmu.edu 06/04/2002 09:46 AM Please respond to "Robert D. Russell" To: Martins Krikis cc: ips@ece.cmu.edu Subject: Re: iSCSI: keys/parameter dependence Martins: Comments below on all your e-mails in this one reply. > As to "running and tested", > I don't think many people have encountered split > PDUs in operational stage or FFP Text negotiations > yet. Agreed. > Those, who prefer the "batch-processing" approach > fought for the C-bit, so I would say that it was > introduced in order to allow it. I missed that point earlier. > Regarding ordering, however, it had never been > defined, and I would hate to see it introduced. It was defined before draft 8, but was taken out when that draft came in. Unfortunately, I did not take it out of my memory. I agree that it should not be reintroduced. > In my opinion, it is best to treat all operational > parameters as independent and negotiate them as > such. Agreed. > Just before the commit > (i.e., turning on the T or F bit), one can do an > all-encompassing consistency check and reset > the negotiations if the values violate the laws > imposed on them, or offer some more keys to solve > any such problems, if this is still possible. What you are saying seems to imply that C=0 does NOT require the receiver to reply to keys received up to that point -- it could send another empty PDU, or more likely, it could send new offers of its own. I agree that there is nothing in the draft that says when replies to keys should be sent, only that they MUST be sent (sometime). For example, consider a login negotiation of operational parameters in which the initiator sends a login pdu containing key=value offers and the C bit 0. The target responds with a login response pdu containing key=value offers of its own (offering different keys) but no replies to any of the offers it received in the login. The initiator can then reply to the target's new offers, or it can decide not to reply, and instead send additional new offers or even an empty pdu, (C bit 0 in both alternatives). And now the target could do as it did before, not replying to any offers but either sending back new offers or sending back an empty login response pdu (again C bit 0 in both alternatives). This could go on indefinitely. It would seem that the initiator might try to force replies by setting T=1 to force an end-of-stage transition. However, the target can refuse to make the transition and can reply with T=0 and still no replies to the keys it was offered. This is admittedly a rather far-out example, because presumably both initiator and target want to end the negotiations as soon as possible. My point only is that I do not see anything in the draft that says when the replies to keys have to be sent, only several references that there MUST be a reply to every key offered (eventually). Thoughts, comments? > I could even imagine negotiations > succeeding but laws > (e.g. FirstBurstSize <= MaxBurstSize) not being > broken when sending data... OK, the last thing > might technically be forbidden at the moment > but it is not that unreasonable. It would be > something like > FirstBursSize = min(FirstBurstSize, MaxBurstSize) > done after the negotiation end, and then you can > forget about dependencies. I think it is way > easier than worrying about key ordering every > time something is sent or received. The dependency can be accounted for when generating the reply. For example, reply.FirstBurstSize = min(offer.FirstBurstSize, reply.MaxBurstSize) That way nothing is broken when sending data. > And how many instances of TargetName and TargetAddress > can the SendTargets command provoke from the other > side? I think it can easily overflow the 8192 bytes. Yes it can, but there was already a mechanism in place to deal with this. In fact, this brings up an interesting point. Presumably the C bit has to be used with replies sent to SendTargets (or any other offer that might generate a long reply), since the C bit is in the Text Response PDU used to send these replies. Refering to sections 9.10.2 and 9.10.4: If the target generating a long reply has more text to send than will fit in one PDU, then it should indicate this by setting C = 1. Setting C = 1 also forces F=0, and this in turn forces the Target Transfer Tag to be something other than 0xffffffff. When there is no more text to send, the target sets C = 0 and F = 1 and TTT=0xffffffff in the last text response pdu it sends to the initiator. There is no situation in which C = 1 and F = 1 can occur (since this is explicitly stated in 9.10.2 as being an error), nor is there a situation in which C = 0 and F = 0 should occur (because C = 0 means "I'm done sending stuff" and F = 0 means "I'm not done sending stuff"). Is this the way you interpret the merging of the C bit with the long text reply mechanism? If there is a consensus on this, perhaps the wording in the draft in section 9.10.4 should include the (required) settings of the C bit whenever it mentions the corresponding settings of the F bit and TTT field. > > -- FirstBurstSize and MaxBurstSize are dependent > > because of the > > requirement in section 11.15: "FirstBurstSize MUST > > NOT exceed > > MaxBurstSize." See my e-mail response to Mike for > > details > > on that dependence. > > I saw it. I consider it unbelievably ugly to have to > look at the values in order to figure out ordering > requirements. I prefer ignoring ordering completely > and check for overall consistency before commit. You are correct, the values can be figured out without resorting to an ordering -- my mistake. > Nowhere does it say anything about the order. Agreed. > So, are you really proposing a requirement that > we must look at the values in order to figure out in > which order to send keys? That is so UGLY, it is > hard to believe that this is happening. Please forget I even suggested it. > > The existence of a dependency between OFMarker and > > OFMarkInt, and between > > IFMarker and IFMarkInt, is implied by the statements > > in section A.3.2: > > "When the interval is unacceptable the responder > > answers with > > "Reject". Reject is resetting the marker function > > in the spcified > > direction (Output or Input) to No." > > No it isn't. IMO, it is resetting the marker interval > to its previous value, which is likely the default > value. I believe it's perfectly legal to negotiate > the marker interval but to not turn on marker use, > or to turn on the use but stay with current (default) > values for the interval. If one side can't tolerate > the other's Reject (i.e., can't live with the > default value), it is welcome to bail and try next > time w/o markers. BTW, we could use 0 here as a > special value, meaning that markers are not in use, > then we wouldn't need the boolean keys for > markers. > > > This last sentence should probably be reworded to > > say: > > "A response value of "Reject" to an OFMarkInt > > (IFMarkInt) key resets the > > corresponding OFMarker (IFMarker) key value to > > "No"." > > No, thank you. I would prefer if Reject meant the > same as with the other keys, i.e., negotiation > failed for this key, let's stick with the old > value, or bail if we must. Either the sentence needs to be reworded so it is proper English or it should be taken out of the draft. I take it you are advocating its removal? Bob Russell --=_alternative 0069133BC2256BD0_= Content-Type: text/html; charset="us-ascii"
Pat,

I wonder what I said to warrant such a long answer.
I just pointed out that the C bit should not be viewed as related (directly) to batching.


Julo


"THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>

06/06/2002 06:54 PM
Please respond to "THALER,PAT (A-Roseville,ex1)"

       
        To:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
        cc:        
        Subject:        RE: iSCSI: keys/parameter dependence

       


Julian,
 
Then we shouldn't have added the C bit at all. One doesn't need it to indicate that a key-value isn't complete and one certainly doesn't need it for security negotiation where there is already a fairly lock step process for the certificate exchange.
 
The arguments people used for adding it were that they wanted to be able to batch offers larger than a PDU without worrying about length. I agree that isn't necessary today for any of the standard keys.
 
During login one can send all the standard keys in a single 8k PDU. During FFP, the only standard negotiated key exchanged is MaxRcvPDUDataSize. One could respond to a SendTargets with keys spread over multiple PDUs without an issue.
 
The current places where C helps are:
Implementation doesn't support 8k transmit PDU size - the negotiation default of 8 k is for the size PDU one supports receiving. An implementation might chose to only send a much shorter PDU and then its keys would not al fit in a single PDU. I find it difficult to imagine someone designing an implementation that creates a long batch of keys and then sends it in multiple short PDUs when it could send it in one PDU, so this doesn't seem like a very good reason to have the C bit.
 
Anticipation of many more or longer standard keys in the future so that they don't all fit in 8k.
 
Anticipation of more FFP negotiations so that FFP offers don't all fit in a single PDU when PDU size might be as small as 512.
 
Support for vendor specific extension keys that are more then 8 k in login or more than MaxRcvPDUDataSize in FFP.
 
Pat
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 05, 2002 8:56 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI: keys/parameter dependence


As I pointed out earlier - you can batch all your keys but some certificates in 8k!
It was never forbidden nor mandated.

Julo

pat_thaler@agilent.com

06/05/2002 09:41 PM
Please respond to pat_thaler

       
       To:        Julian Satran/Haifa/IBM@IBMIL, rdr@io.iol.unh.edu
       cc:        ips@ece.cmu.edu, mkrikis@yahoo.com, owner-ips@ece.cmu.edu
       Subject:        RE: iSCSI: keys/parameter dependence

     



Julian,
 
Batching is related to the C-bit. Before the C-bit, a device could prepare a batch of keys to originate
but they had to fit within the PDU because, if the keys extended beyond a PDU, the device's partner
might originate some of the keys it had prepared but hadn't yet sent.
 
With the C-bit, a device can prepare a batch of keys with out regard to their size because the device
can ensure that they can be sent in multiple PDUs if necessary without the partner having an
opportunity to originate keys in between.
 
The C-bit releaves the size constraint on batching offers.
 
Regards,
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, June 04, 2002 10:19 AM
To: Robert D. Russell
Cc: ips@ece.cmu.edu; Martins Krikis; owner-ips@ece.cmu.edu
Subject: Re: iSCSI: keys/parameter dependence


I have one comment regarding to batching.

Batching is not related to the C-bit. C-bit is meant to simplify spanning over PDU boundaries.
Batching can be done with the previous structure as well - there is a lot you can do with an 8k block!

Julo
"Robert D. Russell" <rdr@io.iol.unh.edu>
Sent by: owner-ips@ece.cmu.edu

06/04/2002 09:46 AM
Please respond to "Robert D. Russell"

       
      To:        Martins Krikis <mkrikis@yahoo.com>
      cc:        ips@ece.cmu.edu
      Subject:        Re: iSCSI: keys/parameter dependence

     




Martins:

Comments below on all your e-mails in this one reply.

> As to "running and tested",
> I don't think many people have encountered split
> PDUs in operational stage or FFP Text negotiations
> yet.

Agreed.


> Those, who prefer the "batch-processing" approach
> fought for the C-bit, so I would say that it was
> introduced in order to allow it.

I missed that point earlier.


> Regarding ordering, however, it had never been
> defined, and I would hate to see it introduced.

It was defined before draft 8, but was taken out when that
draft came in.  Unfortunately, I did not take it out of
my memory.  I agree that it should not be reintroduced.


> In my opinion, it is best to treat all operational
> parameters as independent and negotiate them as
> such.

Agreed.


> Just before the commit
> (i.e., turning on the T or F bit), one can do an
> all-encompassing consistency check and reset
> the negotiations if the values violate the laws
> imposed on them, or offer some more keys to solve
> any such problems, if this is still possible.


What you are saying seems to imply that C=0 does NOT
require the receiver to reply to keys received up to that point
-- it could send another empty PDU, or more likely, it could send
new offers of its own.  I agree that there is nothing in the draft
that says when replies to keys should be sent, only that they
MUST be sent (sometime).

For example, consider a login negotiation of operational parameters
in which the initiator sends a login pdu containing key=value offers
and the C bit 0.  The target responds with a login response pdu
containing key=value offers of its own (offering different keys)
but no replies to any of the offers it received in the login.
The initiator can then reply to the target's new offers, or it
can decide not to reply, and instead send additional new offers
or even an empty pdu, (C bit 0 in both alternatives).  And now
the target could do as it did before, not replying to any offers
but either sending back new offers or sending back an empty login
response pdu (again C bit 0 in both alternatives).  This could go
on indefinitely.

It would seem that the initiator might try to force replies by
setting T=1 to force an end-of-stage transition.  However, the target
can refuse to make the transition and can reply with T=0 and still
no replies to the keys it was offered.

This is admittedly a rather far-out example, because presumably both
initiator and target want to end the negotiations as soon as possible.
My point only is that I do not see anything in the draft that says
when the replies to keys have to be sent, only several references
that there MUST be a reply to every key offered (eventually).
Thoughts, comments?


> I could even imagine negotiations
> succeeding but laws
> (e.g. FirstBurstSize <= MaxBurstSize) not being
> broken when sending data... OK, the last thing
> might technically be forbidden at the moment
> but it is not that unreasonable. It would be
> something like
> FirstBursSize = min(FirstBurstSize, MaxBurstSize)
> done after the negotiation end, and then you can
> forget about dependencies. I think it is way
> easier than worrying about key ordering every
> time something is sent or received.

The dependency can be accounted for when generating the reply.
For example,

reply.FirstBurstSize = min(offer.FirstBurstSize, reply.MaxBurstSize)

That way nothing is broken when sending data.


> And how many instances of TargetName and TargetAddress
> can the SendTargets command provoke from the other
> side? I think it can easily overflow the 8192 bytes.

Yes it can, but there was already a mechanism in place to deal
with this.  In fact, this brings up an interesting point.
Presumably the C bit has to be used with replies sent to
SendTargets (or any other offer that might generate a long reply),
since the C bit is in the Text Response PDU used to send these replies.

Refering to sections 9.10.2 and 9.10.4:  If the target generating a
long reply has more text to send than will fit in one PDU, then it
should indicate this by setting C = 1.  Setting C = 1 also forces F=0,
and this in turn forces the Target Transfer Tag to be something
other than 0xffffffff.  When there is no more text to send,
the target sets C = 0 and F = 1 and TTT=0xffffffff in the last
text response pdu it sends to the initiator.  There is no
situation in which C = 1 and F = 1 can occur (since this is
explicitly stated in 9.10.2 as being an error), nor is there a
situation in which C = 0 and F = 0 should occur (because C = 0
means "I'm done sending stuff" and F = 0 means "I'm not done sending
stuff").

Is this the way you interpret the merging of the C bit with the
long text reply mechanism?  If there is a consensus on this,
perhaps the wording in the draft in section 9.10.4 should include
the (required) settings of the C bit whenever it mentions the
corresponding settings of the F bit and TTT field.


> > -- FirstBurstSize and MaxBurstSize are dependent
> > because of the
> > requirement in section 11.15: "FirstBurstSize MUST
> > NOT exceed
> > MaxBurstSize."  See my e-mail response to Mike for
> > details
> > on that dependence.
>
> I saw it. I consider it unbelievably ugly to have to
> look at the values in order to figure out ordering
> requirements. I prefer ignoring ordering completely
> and check for overall consistency before commit.

You are correct, the values can be figured out without
resorting to an ordering -- my mistake.


> Nowhere does it say anything about the order.

Agreed.


> So, are you really proposing a requirement that
> we must look at the values in order to figure out in
> which order to send keys? That is so UGLY, it is
> hard to believe that this is happening.

Please forget I even suggested it.


> > The existence of a dependency between OFMarker and
> > OFMarkInt, and between
> > IFMarker and IFMarkInt, is implied by the statements
> > in section A.3.2:
> > "When the interval is unacceptable the responder
> > answers with
> > "Reject".  Reject is resetting the marker function
> > in the spcified
> > direction (Output or Input) to No."
>
> No it isn't. IMO, it is resetting the marker interval
> to its previous value, which is likely the default
> value. I believe it's perfectly legal to negotiate
> the marker interval but to not turn on marker use,
> or to turn on the use but stay with current (default)
> values for the interval. If one side can't  tolerate
> the other's  Reject (i.e., can't live with the
> default value), it is welcome to bail and try next
> time w/o markers. BTW, we could use 0 here as a
> special value, meaning that markers are not in use,
> then we wouldn't need the boolean keys for
> markers.
>
> > This last sentence should probably be reworded to
> > say:
> > "A response value of "Reject" to an OFMarkInt
> > (IFMarkInt) key resets the
> > corresponding OFMarker (IFMarker) key value to
> > "No"."
>
> No, thank you. I would prefer if Reject meant the
> same as with the other keys, i.e., negotiation
> failed for this key, let's stick with the old
> value, or bail if we must.

Either the sentence needs to be reworded so it is proper English
or it should be taken out of the draft.  I take it you are advocating
its removal?

Bob Russell

--=_alternative 0069133BC2256BD0_=-- From owner-ips@ece.cmu.edu Thu Jun 6 21:24:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22734 for ; Thu, 6 Jun 2002 21:24:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g56LabD12301 for ips-outgoing; Thu, 6 Jun 2002 17:36:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g56LaZw12295 for ; Thu, 6 Jun 2002 17:36:36 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 1E107D004; Thu, 6 Jun 2002 15:36:35 -0600 (MDT) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id D7D5A120; Thu, 6 Jun 2002 15:36:34 -0600 (MDT) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 06 Jun 2002 15:36:34 -0600 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 15:36:34 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E393B@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Julian Satran , "THALER,PAT (A-Roseville,ex1)" Cc: ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence Date: Thu, 6 Jun 2002 15:36:33 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-e80fa7c5-797b-11d6-ac7e-009027aa5b50" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-e80fa7c5-797b-11d6-ac7e-009027aa5b50 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20DA2.3A5139E0" ------_=_NextPart_001_01C20DA2.3A5139E0 Content-Type: text/plain; charset="iso-8859-1" Julian, And I pointed out that the arguments for it were related to batching (even if current implementations of 12 don't send a multi-PDU batch) and C bit is unnecessary to deal with PDU spanning in the absence of batches. You still didn't agree so I explained my reasoning at greater length (though it doesn't seem to have done any good except to get you to add "(directly)" to the statement). I don't understand what you think justifies the addition of the C bit if it isn't to support batching. The C bit should be viewed as related directly to batching. Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, June 06, 2002 2:12 PM To: THALER,PAT (A-Roseville,ex1) Cc: ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence Pat, I wonder what I said to warrant such a long answer. I just pointed out that the C bit should not be viewed as related (directly) to batching. Julo "THALER,PAT (A-Roseville,ex1)" 06/06/2002 06:54 PM Please respond to "THALER,PAT (A-Roseville,ex1)" To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iSCSI: keys/parameter dependence Julian, Then we shouldn't have added the C bit at all. One doesn't need it to indicate that a key-value isn't complete and one certainly doesn't need it for security negotiation where there is already a fairly lock step process for the certificate exchange. The arguments people used for adding it were that they wanted to be able to batch offers larger than a PDU without worrying about length. I agree that isn't necessary today for any of the standard keys. During login one can send all the standard keys in a single 8k PDU. During FFP, the only standard negotiated key exchanged is MaxRcvPDUDataSize. One could respond to a SendTargets with keys spread over multiple PDUs without an issue. The current places where C helps are: Implementation doesn't support 8k transmit PDU size - the negotiation default of 8 k is for the size PDU one supports receiving. An implementation might chose to only send a much shorter PDU and then its keys would not al fit in a single PDU. I find it difficult to imagine someone designing an implementation that creates a long batch of keys and then sends it in multiple short PDUs when it could send it in one PDU, so this doesn't seem like a very good reason to have the C bit. Anticipation of many more or longer standard keys in the future so that they don't all fit in 8k. Anticipation of more FFP negotiations so that FFP offers don't all fit in a single PDU when PDU size might be as small as 512. Support for vendor specific extension keys that are more then 8 k in login or more than MaxRcvPDUDataSize in FFP. Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 05, 2002 8:56 PM To: ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence As I pointed out earlier - you can batch all your keys but some certificates in 8k! It was never forbidden nor mandated. Julo pat_thaler@agilent.com 06/05/2002 09:41 PM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL, rdr@io.iol.unh.edu cc: ips@ece.cmu.edu, mkrikis@yahoo.com, owner-ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence Julian, Batching is related to the C-bit. Before the C-bit, a device could prepare a batch of keys to originate but they had to fit within the PDU because, if the keys extended beyond a PDU, the device's partner might originate some of the keys it had prepared but hadn't yet sent. With the C-bit, a device can prepare a batch of keys with out regard to their size because the device can ensure that they can be sent in multiple PDUs if necessary without the partner having an opportunity to originate keys in between. The C-bit releaves the size constraint on batching offers. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, June 04, 2002 10:19 AM To: Robert D. Russell Cc: ips@ece.cmu.edu; Martins Krikis; owner-ips@ece.cmu.edu Subject: Re: iSCSI: keys/parameter dependence I have one comment regarding to batching. Batching is not related to the C-bit. C-bit is meant to simplify spanning over PDU boundaries. Batching can be done with the previous structure as well - there is a lot you can do with an 8k block! Julo "Robert D. Russell" Sent by: owner-ips@ece.cmu.edu 06/04/2002 09:46 AM Please respond to "Robert D. Russell" To: Martins Krikis cc: ips@ece.cmu.edu Subject: Re: iSCSI: keys/parameter dependence Martins: Comments below on all your e-mails in this one reply. > As to "running and tested", > I don't think many people have encountered split > PDUs in operational stage or FFP Text negotiations > yet. Agreed. > Those, who prefer the "batch-processing" approach > fought for the C-bit, so I would say that it was > introduced in order to allow it. I missed that point earlier. > Regarding ordering, however, it had never been > defined, and I would hate to see it introduced. It was defined before draft 8, but was taken out when that draft came in. Unfortunately, I did not take it out of my memory. I agree that it should not be reintroduced. > In my opinion, it is best to treat all operational > parameters as independent and negotiate them as > such. Agreed. > Just before the commit > (i.e., turning on the T or F bit), one can do an > all-encompassing consistency check and reset > the negotiations if the values violate the laws > imposed on them, or offer some more keys to solve > any such problems, if this is still possible. What you are saying seems to imply that C=0 does NOT require the receiver to reply to keys received up to that point -- it could send another empty PDU, or more likely, it could send new offers of its own. I agree that there is nothing in the draft that says when replies to keys should be sent, only that they MUST be sent (sometime). For example, consider a login negotiation of operational parameters in which the initiator sends a login pdu containing key=value offers and the C bit 0. The target responds with a login response pdu containing key=value offers of its own (offering different keys) but no replies to any of the offers it received in the login. The initiator can then reply to the target's new offers, or it can decide not to reply, and instead send additional new offers or even an empty pdu, (C bit 0 in both alternatives). And now the target could do as it did before, not replying to any offers but either sending back new offers or sending back an empty login response pdu (again C bit 0 in both alternatives). This could go on indefinitely. It would seem that the initiator might try to force replies by setting T=1 to force an end-of-stage transition. However, the target can refuse to make the transition and can reply with T=0 and still no replies to the keys it was offered. This is admittedly a rather far-out example, because presumably both initiator and target want to end the negotiations as soon as possible. My point only is that I do not see anything in the draft that says when the replies to keys have to be sent, only several references that there MUST be a reply to every key offered (eventually). Thoughts, comments? > I could even imagine negotiations > succeeding but laws > (e.g. FirstBurstSize <= MaxBurstSize) not being > broken when sending data... OK, the last thing > might technically be forbidden at the moment > but it is not that unreasonable. It would be > something like > FirstBursSize = min(FirstBurstSize, MaxBurstSize) > done after the negotiation end, and then you can > forget about dependencies. I think it is way > easier than worrying about key ordering every > time something is sent or received. The dependency can be accounted for when generating the reply. For example, reply.FirstBurstSize = min(offer.FirstBurstSize, reply.MaxBurstSize) That way nothing is broken when sending data. > And how many instances of TargetName and TargetAddress > can the SendTargets command provoke from the other > side? I think it can easily overflow the 8192 bytes. Yes it can, but there was already a mechanism in place to deal with this. In fact, this brings up an interesting point. Presumably the C bit has to be used with replies sent to SendTargets (or any other offer that might generate a long reply), since the C bit is in the Text Response PDU used to send these replies. Refering to sections 9.10.2 and 9.10.4: If the target generating a long reply has more text to send than will fit in one PDU, then it should indicate this by setting C = 1. Setting C = 1 also forces F=0, and this in turn forces the Target Transfer Tag to be something other than 0xffffffff. When there is no more text to send, the target sets C = 0 and F = 1 and TTT=0xffffffff in the last text response pdu it sends to the initiator. There is no situation in which C = 1 and F = 1 can occur (since this is explicitly stated in 9.10.2 as being an error), nor is there a situation in which C = 0 and F = 0 should occur (because C = 0 means "I'm done sending stuff" and F = 0 means "I'm not done sending stuff"). Is this the way you interpret the merging of the C bit with the long text reply mechanism? If there is a consensus on this, perhaps the wording in the draft in section 9.10.4 should include the (required) settings of the C bit whenever it mentions the corresponding settings of the F bit and TTT field. > > -- FirstBurstSize and MaxBurstSize are dependent > > because of the > > requirement in section 11.15: "FirstBurstSize MUST > > NOT exceed > > MaxBurstSize." See my e-mail response to Mike for > > details > > on that dependence. > > I saw it. I consider it unbelievably ugly to have to > look at the values in order to figure out ordering > requirements. I prefer ignoring ordering completely > and check for overall consistency before commit. You are correct, the values can be figured out without resorting to an ordering -- my mistake. > Nowhere does it say anything about the order. Agreed. > So, are you really proposing a requirement that > we must look at the values in order to figure out in > which order to send keys? That is so UGLY, it is > hard to believe that this is happening. Please forget I even suggested it. > > The existence of a dependency between OFMarker and > > OFMarkInt, and between > > IFMarker and IFMarkInt, is implied by the statements > > in section A.3.2: > > "When the interval is unacceptable the responder > > answers with > > "Reject". Reject is resetting the marker function > > in the spcified > > direction (Output or Input) to No." > > No it isn't. IMO, it is resetting the marker interval > to its previous value, which is likely the default > value. I believe it's perfectly legal to negotiate > the marker interval but to not turn on marker use, > or to turn on the use but stay with current (default) > values for the interval. If one side can't tolerate > the other's Reject (i.e., can't live with the > default value), it is welcome to bail and try next > time w/o markers. BTW, we could use 0 here as a > special value, meaning that markers are not in use, > then we wouldn't need the boolean keys for > markers. > > > This last sentence should probably be reworded to > > say: > > "A response value of "Reject" to an OFMarkInt > > (IFMarkInt) key resets the > > corresponding OFMarker (IFMarker) key value to > > "No"." > > No, thank you. I would prefer if Reject meant the > same as with the other keys, i.e., negotiation > failed for this key, let's stick with the old > value, or bail if we must. Either the sentence needs to be reworded so it is proper English or it should be taken out of the draft. I take it you are advocating its removal? Bob Russell ------_=_NextPart_001_01C20DA2.3A5139E0 Content-Type: text/html; charset="iso-8859-1"
Julian,
 
And I pointed out that the arguments for it were related to batching (even if current implementations of 12 don't send a multi-PDU batch) and C bit is unnecessary to deal with PDU spanning in the absence of batches. You still didn't agree so I explained my reasoning at greater length (though it doesn't seem to have done any good except to get you to add "(directly)" to the statement). I don't understand what you think justifies the addition of the C bit if it isn't to support batching.
 
The C bit should be viewed as related directly to batching.
 
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, June 06, 2002 2:12 PM
To: THALER,PAT (A-Roseville,ex1)
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: keys/parameter dependence


Pat,

I wonder what I said to warrant such a long answer.
I just pointed out that the C bit should not be viewed as related (directly) to batching.


Julo


"THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>

06/06/2002 06:54 PM
Please respond to "THALER,PAT (A-Roseville,ex1)"

       
        To:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
        cc:        
        Subject:        RE: iSCSI: keys/parameter dependence

       


Julian,
 
Then we shouldn't have added the C bit at all. One doesn't need it to indicate that a key-value isn't complete and one certainly doesn't need it for security negotiation where there is already a fairly lock step process for the certificate exchange.
 
The arguments people used for adding it were that they wanted to be able to batch offers larger than a PDU without worrying about length. I agree that isn't necessary today for any of the standard keys.
 
During login one can send all the standard keys in a single 8k PDU. During FFP, the only standard negotiated key exchanged is MaxRcvPDUDataSize. One could respond to a SendTargets with keys spread over multiple PDUs without an issue.
 
The current places where C helps are:
Implementation doesn't support 8k transmit PDU size - the negotiation default of 8 k is for the size PDU one supports receiving. An implementation might chose to only send a much shorter PDU and then its keys would not al fit in a single PDU. I find it difficult to imagine someone designing an implementation that creates a long batch of keys and then sends it in multiple short PDUs when it could send it in one PDU, so this doesn't seem like a very good reason to have the C bit.
 
Anticipation of many more or longer standard keys in the future so that they don't all fit in 8k.
 
Anticipation of more FFP negotiations so that FFP offers don't all fit in a single PDU when PDU size might be as small as 512.
 
Support for vendor specific extension keys that are more then 8 k in login or more than MaxRcvPDUDataSize in FFP.
 
Pat
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 05, 2002 8:56 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI: keys/parameter dependence



As I pointed out earlier - you can batch all your keys but some certificates in 8k!
It was never forbidden nor mandated.

Julo

pat_thaler@agilent.com

06/05/2002 09:41 PM
Please respond to pat_thaler

       
       To:        Julian Satran/Haifa/IBM@IBMIL, rdr@io.iol.unh.edu
       cc:        ips@ece.cmu.edu, mkrikis@yahoo.com, owner-ips@ece.cmu.edu
       Subject:        RE: iSCSI: keys/parameter dependence

     



Julian,
 
Batching is related to the C-bit. Before the C-bit, a device could prepare a batch of keys to originate
but they had to fit within the PDU because, if the keys extended beyond a PDU, the device's partner
might originate some of the keys it had prepared but hadn't yet sent.
 
With the C-bit, a device can prepare a batch of keys with out regard to their size because the device
can ensure that they can be sent in multiple PDUs if necessary without the partner having an
opportunity to originate keys in between.
 
The C-bit releaves the size constraint on batching offers.
 
Regards,
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, June 04, 2002 10:19 AM
To: Robert D. Russell
Cc: ips@ece.cmu.edu; Martins Krikis; owner-ips@ece.cmu.edu
Subject: Re: iSCSI: keys/parameter dependence


I have one comment regarding to batching.

Batching is not related to the C-bit. C-bit is meant to simplify spanning over PDU boundaries.
Batching can be done with the previous structure as well - there is a lot you can do with an 8k block!

Julo
"Robert D. Russell" <rdr@io.iol.unh.edu>
Sent by: owner-ips@ece.cmu.edu

06/04/2002 09:46 AM
Please respond to "Robert D. Russell"

       
      To:        Martins Krikis <mkrikis@yahoo.com>
      cc:        ips@ece.cmu.edu
      Subject:        Re: iSCSI: keys/parameter dependence

     




Martins:

Comments below on all your e-mails in this one reply.

> As to "running and tested",
> I don't think many people have encountered split
> PDUs in operational stage or FFP Text negotiations
> yet.

Agreed.


> Those, who prefer the "batch-processing" approach
> fought for the C-bit, so I would say that it was
> introduced in order to allow it.

I missed that point earlier.


> Regarding ordering, however, it had never been
> defined, and I would hate to see it introduced.

It was defined before draft 8, but was taken out when that
draft came in.  Unfortunately, I did not take it out of
my memory.  I agree that it should not be reintroduced.


> In my opinion, it is best to treat all operational
> parameters as independent and negotiate them as
> such.

Agreed.


> Just before the commit
> (i.e., turning on the T or F bit), one can do an
> all-encompassing consistency check and reset
> the negotiations if the values violate the laws
> imposed on them, or offer some more keys to solve
> any such problems, if this is still possible.


What you are saying seems to imply that C=0 does NOT
require the receiver to reply to keys received up to that point
-- it could send another empty PDU, or more likely, it could send
new offers of its own.  I agree that there is nothing in the draft
that says when replies to keys should be sent, only that they
MUST be sent (sometime).

For example, consider a login negotiation of operational parameters
in which the initiator sends a login pdu containing key=value offers
and the C bit 0.  The target responds with a login response pdu
containing key=value offers of its own (offering different keys)
but no replies to any of the offers it received in the login.
The initiator can then reply to the target's new offers, or it
can decide not to reply, and instead send additional new offers
or even an empty pdu, (C bit 0 in both alternatives).  And now
the target could do as it did before, not replying to any offers
but either sending back new offers or sending back an empty login
response pdu (again C bit 0 in both alternatives).  This could go
on indefinitely.

It would seem that the initiator might try to force replies by
setting T=1 to force an end-of-stage transition.  However, the target
can refuse to make the transition and can reply with T=0 and still
no replies to the keys it was offered.

This is admittedly a rather far-out example, because presumably both
initiator and target want to end the negotiations as soon as possible.
My point only is that I do not see anything in the draft that says
when the replies to keys have to be sent, only several references
that there MUST be a reply to every key offered (eventually).

Thoughts, comments?


> I could even imagine negotiations
> succeeding but laws
> (e.g. FirstBurstSize <= MaxBurstSize) not being
> broken when sending data... OK, the last thing
> might technically be forbidden at the moment
> but it is not that unreasonable. It would be
> something like
> FirstBursSize = min(FirstBurstSize, MaxBurstSize)
> done after the negotiation end, and then you can
> forget about dependencies. I think it is way
> easier than worrying about key ordering every
> time something is sent or received.

The dependency can be accounted for when generating the reply.
For example,

reply.FirstBurstSize = min(offer.FirstBurstSize, reply.MaxBurstSize)

That way nothing is broken when sending data.


> And how many instances of TargetName and TargetAddress
> can the SendTargets command provoke from the other
> side? I think it can easily overflow the 8192 bytes.

Yes it can, but there was already a mechanism in place to deal
with this.  In fact, this brings up an interesting point.
Presumably the C bit has to be used with replies sent to
SendTargets (or any other offer that might generate a long reply),
since the C bit is in the Text Response PDU used to send these replies.

Refering to sections 9.10.2 and 9.10.4:  If the target generating a
long reply has more text to send than will fit in one PDU, then it
should indicate this by setting C = 1.  Setting C = 1 also forces F=0,
and this in turn forces the Target Transfer Tag to be something
other than 0xffffffff.  When there is no more text to send,
the target sets C = 0 and F = 1 and TTT=0xffffffff in the last
text response pdu it sends to the initiator.  There is no
situation in which C = 1 and F = 1 can occur (since this is
explicitly stated in 9.10.2 as being an error), nor is there a
situation in which C = 0 and F = 0 should occur (because C = 0
means "I'm done sending stuff" and F = 0 means "I'm not done sending
stuff").

Is this the way you interpret the merging of the C bit with the
long text reply mechanism?  If there is a consensus on this,
perhaps the wording in the draft in section 9.10.4 should include
the (required) settings of the C bit whenever it mentions the
corresponding settings of the F bit and TTT field.


> > -- FirstBurstSize and MaxBurstSize are dependent
> > because of the
> > requirement in section 11.15: "FirstBurstSize MUST
> > NOT exceed
> > MaxBurstSize."  See my e-mail response to Mike for
> > details
> > on that dependence.
>
> I saw it. I consider it unbelievably ugly to have to
> look at the values in order to figure out ordering
> requirements. I prefer ignoring ordering completely
> and check for overall consistency before commit.

You are correct, the values can be figured out without
resorting to an ordering -- my mistake.


> Nowhere does it say anything about the order.

Agreed.


> So, are you really proposing a requirement that
> we must look at the values in order to figure out in
> which order to send keys? That is so UGLY, it is
> hard to believe that this is happening.

Please forget I even suggested it.


> > The existence of a dependency between OFMarker and
> > OFMarkInt, and between
> > IFMarker and IFMarkInt, is implied by the statements
> > in section A.3.2:
> > "When the interval is unacceptable the responder
> > answers with
> > "Reject".  Reject is resetting the marker function
> > in the spcified
> > direction (Output or Input) to No."
>
> No it isn't. IMO, it is resetting the marker interval
> to its previous value, which is likely the default
> value. I believe it's perfectly legal to negotiate
> the marker interval but to not turn on marker use,
> or to turn on the use but stay with current (default)
> values for the interval. If one side can't  tolerate
> the other's  Reject (i.e., can't live with the
> default value), it is welcome to bail and try next
> time w/o markers. BTW, we could use 0 here as a
> special value, meaning that markers are not in use,
> then we wouldn't need the boolean keys for
> markers.
>
> > This last sentence should probably be reworded to
> > say:
> > "A response value of "Reject" to an OFMarkInt
> > (IFMarkInt) key resets the
> > corresponding OFMarker (IFMarker) key value to
> > "No"."
>
> No, thank you. I would prefer if Reject meant the
> same as with the other keys, i.e., negotiation
> failed for this key, let's stick with the old
> value, or bail if we must.

Either the sentence needs to be reworded so it is proper English
or it should be taken out of the draft.  I take it you are advocating
its removal?

Bob Russell







------_=_NextPart_001_01C20DA2.3A5139E0-- ------=_NextPartTM-000-e80fa7c5-797b-11d6-ac7e-009027aa5b50-- From owner-ips@ece.cmu.edu Thu Jun 6 21:28:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23038 for ; Thu, 6 Jun 2002 21:28:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g56L8jh10707 for ips-outgoing; Thu, 6 Jun 2002 17:08:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g56L8fw10701 for ; Thu, 6 Jun 2002 17:08:41 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id D559816F1; Thu, 6 Jun 2002 15:08:40 -0600 (MDT) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 9152626C; Thu, 6 Jun 2002 15:08:40 -0600 (MDT) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 06 Jun 2002 15:08:39 -0600 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 15:08:38 -0600 Message-ID: <01A7DAF31F93D511AEE300D0B706ED9201BF494E@axcs13.cos.agilent.com> From: "CAVANNA,VICENTE V (A-Roseville,ex1)" To: "THALER,PAT (A-Roseville,ex1)" , Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu, "CAVANNA,VICENTE V (A-Roseville,ex1)" Subject: RE: iSCSI CRC inconsistency Date: Thu, 6 Jun 2002 15:08:35 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C20D9E.520490E0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C20D9E.520490E0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20D9E.520490E0" ------_=_NextPart_001_01C20D9E.520490E0 Content-Type: text/plain; charset="iso-8859-1" Julian, I concur with Pat's request for explicit mapping of the bits of the remainder polynomial to the bits of the CRC. I had pointed out the need for such explicit mapping, to resolve ambiguity in the process, in a memo on Aug 22, 2001. In that memo I also objected to the bit reflection but I later retracted that objection. I also outlined, in a memo on Nov. 27, 2001, how I would describe the CRC process at the transmitter and receiver to resolve the ambiguity. The particular step in the process that Pat pointed out is missing from the iSCSI spec, is the reversing of bits (bit reflection) within each byte of the remainder of the modular division. As Pat pointed out, the examples shown in the spec *do* assume this bit reversal, but the process steps in the spec seem to indicate no bit reversal. The wording that Pat is recommending seems accurate to me and is a good alternative to what I had suggested. Regards, Vince -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Wednesday, June 05, 2002 10:29 AM To: Julian_Satran@il.ibm.com; pat_thaler@agilent.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI CRC inconsistency Julian, Yes, magic number is stated in polynomial order and the accompanying text says that so I have no problem with the magic number text. It is only the description of how the CRC is placed into the message that needs correction/clarification. As you say, hypothetical wire order is not relevant. We need to specify with respect to iSCSI's defined word order. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 05, 2002 10:21 AM To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI CRC inconsistency Pat, I was referring to a hypothetical wire order and that matches the order I stated in the first list element. I will try to map it to the word order as the wire order is not relevant anyhow. The magical number is however a polynomial and not a word mapping. Julo pat_thaler@agilent.com 06/04/2002 11:31 PM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: iSCSI CRC inconsistency Julian, There is an inconsistency in the description of the CRC32. In 11.1, the final paragraph on page 207 is incorrect. The paragraph says: - The CRC bits appear after the message bits with x^31 first followed by x^30 etc. (when examples are provided, the value to be specified in the examples follows the same ordering as the rest of this document). At the top of the next page, it describes the magic number CRC check where one runs the CRC generator over the data or header plus the received digest and gets the magic number: - A receiver of a "good" segment (data or header) including the CRC built using the generator 0x11edc6f41 will get the value 0x1c2d19ed as its CRC (this is a polynomial value and not a word as outlined in this draft). The point of the magic number algorithm is that it uses exactly the same algorithm to check the CRC that was used to generate the CRC. When running the check, the received CRC is run through the generator with the same bit order as the covered data. Therefore, this check only works right when the CRC is appended to the data using the same bit ordering within a word as was used when sending the covered data through the CRC generator. The examples in B.4 show the bits ordered as they should be and page 207 is inconsistent with them.. Specifically, data bits go through the generator from byte 0 to byte 3 of the word with each bit going through bit 7 to bit 0. Therefore, paragraph on how the CRC bits are placed in the field should be: - The CRC bits appear after the message bits with the x^31 coefficient in bit 7 of the first byte (byte 0) of the digest continuing to through the byte the x^24 coefficient in bit 0 of byte 0, continuing with the x^23 coefficient in bit 7 of byte 1, etc. (When examples are provided they show the CRC as it appears in the PDU with the bit significance used throughout this document. That is, bit 7 of each byte is interpreted as most significant though it is the coefficient of the lowest order CRC term in the byte.). I have checked and this order matches the examples in B.4. Regards, Pat ------_=_NextPart_001_01C20D9E.520490E0 Content-Type: text/html; charset="iso-8859-1"
Julian,
I concur with Pat's request for explicit mapping of the bits of the remainder polynomial to the bits of the CRC. I had pointed out the need for such explicit mapping, to resolve ambiguity in the process, in a memo on Aug 22, 2001. In that memo I also objected to the bit reflection but I later retracted that objection. I also outlined, in a memo on Nov. 27, 2001, how I would describe the CRC process at the transmitter and receiver to resolve the ambiguity. The particular step in the process that Pat pointed out is missing from the iSCSI spec, is the reversing of bits (bit reflection) within each byte of the remainder of the modular division. As Pat pointed out, the examples shown in the spec *do* assume this bit reversal, but the process steps in the spec seem to indicate no bit reversal. The wording that Pat is recommending seems accurate to me and is a good alternative to what I had suggested.
Regards,
Vince
-----Original Message-----
From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]
Sent: Wednesday, June 05, 2002 10:29 AM
To: Julian_Satran@il.ibm.com; pat_thaler@agilent.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI CRC inconsistency

Julian,
 
Yes, magic number is stated in polynomial order and the accompanying text says that so I have no
problem with the magic number text.
 
It is only the description of how the CRC is placed into the message that needs correction/clarification.
As you say, hypothetical wire order is not relevant. We need to specify with respect to iSCSI's defined
word order.
 
Regards,
Pat
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 05, 2002 10:21 AM
To: pat_thaler@agilent.com
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI CRC inconsistency


Pat,

I was referring to a hypothetical wire order and that matches the order I stated in the first list element.
I will try to map it to the word order as the wire order is not relevant anyhow.
The magical number is however a polynomial and not a word mapping.

Julo


pat_thaler@agilent.com

06/04/2002 11:31 PM
Please respond to pat_thaler

       
        To:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI CRC inconsistency

       


Julian,

There is an inconsistency in the description of the CRC32. In 11.1, the final paragraph on page 207 is incorrect. The paragraph says:
- The CRC bits appear after the message bits with x^31 first
followed by x^30 etc. (when examples are provided, the value
to be specified in the examples follows the same
ordering as the rest of this document).

At the top of the next page, it describes the magic number CRC check where one runs the CRC generator over the data or header plus the received digest and gets the magic number:
- A receiver of a "good" segment (data or header) including the
CRC built using the generator 0x11edc6f41 will get the value
0x1c2d19ed as its CRC (this is a polynomial value and not a
word as outlined in this draft).

The point of the magic number algorithm is that it uses exactly the same algorithm to check the CRC that was used to generate the CRC. When running the check, the received CRC is run through the generator with the same bit order as the covered data. Therefore, this check only works right when the CRC is appended to the data using the same bit ordering within a word as was used when sending the covered data through the CRC generator. The examples in B.4 show the bits ordered as they should be and page 207 is inconsistent with them..

Specifically, data bits go through the generator from byte 0 to byte 3 of the word with each bit going through bit 7 to bit 0. Therefore, paragraph on how the CRC bits are placed in the field should be:
- The CRC bits appear after the message bits with the x^31 coefficient in bit 7 of the first byte (byte 0) of the digest continuing to through the byte the x^24 coefficient in bit 0 of byte 0, continuing with the x^23 coefficient in bit 7 of byte 1, etc. (When examples are provided they show the CRC as it appears in the PDU with the bit significance used throughout this document. That is, bit 7 of each byte is interpreted as most significant though it is the coefficient of the lowest order CRC term in the byte.).

I have checked and this order matches the examples in B.4.

Regards,
Pat


------_=_NextPart_001_01C20D9E.520490E0-- ------_=_NextPart_000_01C20D9E.520490E0 Content-Type: message/rfc822 Content-Description: RE: iSCSI CRC: A CRC-checking example Message-ID: From: "CAVANNA,VICENTE V (A-Roseville,ex1)" To: 'Julian Satran' , 'Mark Bakke' Cc: "CAVANNA,VICENTE V (A-Roseville,ex1)" , "'Pat.Thaler@d12relay01.de.ibm.com'" , "'ips@ece.cmu.edu'" Subject: RE: iSCSI CRC: A CRC-checking example Date: Wed, 22 Aug 2001 11:42:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C20D9E.520490E0" ------_=_NextPart_003_01C20D9E.520490E0 Content-Type: text/plain; charset="iso-8859-1" Julian and Mark and others, After I took into account the bit "reflection" and the byte order (Big Endian on Bytes and Little Endian on bits) I did finally obtain, using polynomial math, the (corrected) results you show in the CRC examples. The results have also been confirmed independently by an implementor here at Agilent. I am the one who originally suggested to Julian that we specify the CRC algorithm the same way as in ethernet even though for iSCSI it is not really important to initialize the CRC register to all 1s and to complement the CRC before transmission since there are other means to detect extra or missing PDU bytes. However I had not realzied until recently that conformance with the ethernet algorithm implies bit reflection. I had not been aware that in ethernet the bits are sent out on the serial link with the least significant bit first AND that the corresponding message polynomial is formed from the bits in the sequence that they appear on the serial link; thus the need for bit "reflection". Now that I understand the need for bit reflection (taken into account in the rocksoft parameterized CRC generator by setting the in and out reflection flag parameters to TRUE) I am not sure I agree that we want it in iSCSI. The penalty for full conformity with ethernet seems too great. If people feel strongly that we must keep the bit reflection I think that to make the existing documentation clear and unambiguous we would need to explicitly show the mapping of bits in the iSCSI PDU to coefficients of the message polynomial that represents the iSCSI PDU. We would also need to show the mapping of the CRC bits to the coefficients of its representative polynomial. If you don't agree I will elaborate further later this week to try to convince you. My objective is to be able to easily and unambiguously describe the polynomial math behind the algorithm; right now, with the bit reflection and without the explicit mapping it is awkward. Vince ------_=_NextPart_003_01C20D9E.520490E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: iSCSI CRC: A CRC-checking example

Julian and Mark and others,

After I took into account the bit = "reflection"  and the byte order (Big Endian on Bytes = and Little Endian on bits) I did finally obtain, using polynomial math, = the (corrected) results you show in the CRC examples. The results have = also been confirmed independently by an implementor here at Agilent. =

I am the one who originally suggested to Julian that = we specify the CRC algorithm the same way as in ethernet even though = for iSCSI it is not really important to initialize the CRC register to = all 1s and to complement the CRC before transmission since there are = other means to detect extra or missing PDU bytes. However I had not = realzied until recently that conformance with the ethernet algorithm = implies bit reflection. I had not been aware that in ethernet the bits = are sent out on the serial link with the least significant bit first = AND that the corresponding message polynomial is formed from the bits = in the sequence that they appear on the serial link; thus the need for = bit "reflection".

Now that I understand the need for bit reflection = (taken into account in the rocksoft parameterized CRC generator by = setting the in and out reflection flag parameters to TRUE) I am not = sure I agree that we want it in iSCSI. The penalty for full conformity = with ethernet seems too great. If people feel strongly that we must = keep the bit reflection I think that to make the existing documentation = clear and unambiguous we would need to explicitly show the mapping of = bits in the iSCSI PDU to coefficients of the message polynomial that = represents the iSCSI PDU. We would also need to show the mapping of the = CRC bits to the coefficients of its representative polynomial. =

If you don't agree I will elaborate further later = this week to try to convince you. My objective is to be able to easily = and unambiguously describe the polynomial math behind the algorithm; = right now, with the bit reflection and without the explicit mapping it = is awkward.

Vince 

------_=_NextPart_003_01C20D9E.520490E0-- ------_=_NextPart_000_01C20D9E.520490E0 Content-Type: message/rfc822 Content-Description: Re: iSCSI v8 CRC32c Message-ID: <01A7DAF31F93D511AEE300D0B706ED920CF705@axcs13.cos.agilent.com> From: "CAVANNA,VICENTE V (A-Roseville,ex1)" To: 'Luben Tuikov' Cc: "'ips@ece.cmu.edu'" , "THALER,PAT (A-Roseville,ex1)" , "CAVANNA,VICENTE V (A-Roseville,ex1)" Subject: Re: iSCSI v8 CRC32c Date: Tue, 27 Nov 2001 19:39:49 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C20D9E.520490E0" ------_=_NextPart_002_01C20D9E.520490E0 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C20D9E.520490E0" ------_=_NextPart_003_01C20D9E.520490E0 Content-Type: text/plain; charset="iso-8859-1" Luben, Your questions may have already been answered by Paul Koning who has apparently reviewed your code in detail but attached, as I promised, is a Mathematica worksheet (pdf format) that produces results consistent with the iSCSI spec. You do not need to know the syntax of Mathematica in order to follow the process, as I have inserted lots of comments. The example I describe uses, as data, 32 decrementing bytes. This is one of hte test cases in the iSCSI document. I have added an undetectable error pattern which does not change the results obtained at the receiver. I think it would be useful to include, in the iSCSI document, such an undetectable error pattern. I am considering writing an informative Internet Draft describing the process. I would incorporate the contents of the attached worksheet and also explain the theory behind the process. This should answer such questions as why is the expected remainder at the receiver the constant 1c 2d 19 ed in hex. If you or others have suggestions let me know. For those not interested in the math I summarize the process below. Vicente Cavanna Agilent Technologies The symbols I use: ------------------ G is the iSCSI CRC32c polynomial. L32 is the order-32 poly represting all 1s. F is the poly representing 32 decrementing bytes which I will use as my test data. ReflectedF is the poly representing F, after reversing the order of bits within each byte. R is the remainder of the division performed at the transmitter. ReflectedR is the poly obtained by reversing the order of bits within each byte of R. FCS is the complement of ReflectedR. This is the CRC that you would compare with the iSCSI document. In the case of this example of 32 decrementing bytes the FCS is a7 e4 e4 ae in hex. M is the transmitted message before injecting errors. Error is the error pattern that I add to M. I use G+x^5*G after applying reflection. Any linear combination of Gs will similarly be undetected. M* is the received message. ReflectedM* is M* with the order of bits within each byte reversed. Rec is the computed CRC at the receiver. You would expect 1c2d19ed in the absence of errors or if error pattern is undetectable as is the case in my example. The process, for the case of no errors, is as follows: ------------------------------------------------------ At the transmitter: ---------------------- F is the data. Reverse bits within each byte of F to obtain ReflectedF. Shift ReflectedF left by 32 positions. Add 1's to most significant 32 bits of the result (implemented by initializing CRC register to 1's). Divide by G to obtain the 32 bit remainderR. Note that R is not the CRC shown in iSCSI document! Reverse bits within each byte of R to obtain ReflectedR. Add 32 1's to the result to obtain the FCS (implemented by complementing). This is what is shown in the iSCSI document and, for this example, is a7 e4 e4 ae in hex. Form the transmitted message, M, by shifting F left by 32 positions and adding FCS. Note that M is derived from F rather than from ReflectedF even though the FCS is computed from ReflectedF. M* is hte same as M since we are not introducing errors here. See the Mathematica worksheet for the case with (undetectable) errors. At the receiver: ---------------- Receive M* Reverse bits within each byte of M* to obtain ReflectedM*. Shift the result left by 32 positions. Add 1's to most significant 32 bits of result (implemented by initializing CRc to 1's). Divide by G to obtain the remainder, Rec. The result (for the case of no errors) is expected to be the constant 1c 2d 19 ed in hex. In the Mathcad worksheet I actually introduce an undetectable error pattern, G+G*x^5, which I reflect and add to M to obtain M*. The rest is the same. Note that the error must also be "reflected". See the worksheet for details. <> ------_=_NextPart_003_01C20D9E.520490E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: iSCSI v8 CRC32c

Luben,

Your questions may have already = been answered by Paul Koning who has apparently reviewed your code in = detail but attached, as I promised, is a Mathematica worksheet (pdf = format) that produces results consistent with the iSCSI spec. You do = not need to know the syntax of Mathematica in order to follow the = process, as I have inserted lots of comments.

The example I describe uses, as = data, 32 decrementing bytes. This is one of hte test cases in the iSCSI = document. I have added an undetectable error pattern which does not = change the results obtained at the receiver. I think it would be useful = to include, in the iSCSI document, such an undetectable error = pattern.

I am considering writing an = informative Internet Draft describing the process. I would incorporate = the contents of the attached worksheet and also explain the theory = behind the process. This should answer such questions as why is the = expected remainder at the receiver the constant 1c 2d 19 ed in = hex.  If you or others have suggestions let me know.

For those not interested in the = math I summarize the process below.

Vicente Cavanna
Agilent Technologies


The symbols I use:
------------------

G is the iSCSI CRC32c = polynomial.

L32 is the order-32 poly = represting all 1s.

F is the poly representing 32 = decrementing bytes which I will use as my test data.

ReflectedF is the poly = representing F, after reversing the order of bits within each = byte.

R is the remainder of the = division performed at the transmitter.

ReflectedR is the poly obtained = by reversing the order of bits within each byte of R.

FCS is the complement of = ReflectedR. This is the CRC that you would compare with the iSCSI = document. In the case of this example of 32 decrementing bytes the FCS = is a7 e4 e4 ae in hex.

M is the transmitted message = before injecting errors.

Error is the error pattern that = I add to M. I use G+x^5*G after applying reflection. Any linear = combination of Gs will similarly be undetected.

M* is the received = message.

ReflectedM* is M* with the order = of bits within each byte reversed.

Rec is the computed CRC at the = receiver. You would expect 1c2d19ed in the absence of errors or if = error pattern is undetectable as is the case in my example.

The process, for the case of no = errors, is as follows:
------------------------------------------------------

At the transmitter:
----------------------

F is the data.

Reverse bits within each byte of = F to obtain ReflectedF.

Shift ReflectedF left by 32 = positions.

Add 1's to most significant 32 = bits of the result (implemented by initializing CRC register to = 1's).

Divide by G to obtain the 32 bit = remainderR. Note that R is not the CRC shown in iSCSI document!

Reverse bits within each byte of = R to obtain ReflectedR.

Add 32 1's to the result to = obtain the FCS (implemented by complementing). This is what is shown in = the iSCSI document and, for this example, is a7 e4 e4 ae in = hex.

Form the transmitted message, M, = by shifting F left by 32 positions and adding FCS. Note that M is = derived from F rather than from ReflectedF even though the FCS is = computed from ReflectedF.

M* is hte same as M since we are = not introducing errors here. See the Mathematica worksheet for the case = with (undetectable) errors.

At the receiver:
----------------

Receive M*

Reverse bits within each byte of = M* to obtain ReflectedM*.

Shift the result left by 32 = positions.

Add 1's to most significant 32 = bits of result (implemented by initializing CRc to 1's).

Divide by G to obtain the = remainder, Rec. The result (for the case of no errors) is expected to = be the constant 1c 2d 19 ed in hex.

In the Mathcad worksheet I = actually introduce an undetectable error pattern, G+G*x^5, which I = reflect and add to M to obtain M*. The rest is the same. Note that the = error must also be "reflected". See the worksheet for = details.


 


= <<TestingCRC32cDecrBytePattern.pdf>>

------_=_NextPart_003_01C20D9E.520490E0-- ------_=_NextPart_002_01C20D9E.520490E0 Content-Type: application/octet-stream; name="TestingCRC32cDecrBytePattern.pdf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="TestingCRC32cDecrBytePattern.pdf" Content-Transfer-Encoding: quoted-printable %PDF-1.3=0D%=E2=E3=CF=D3 1 0 obj=0D<< =0D/Creator = =0D/CreationDate = (D:20011127133834)=0D/Title = =0D/Author= =0D/Producer (Acrobat PDFWriter 4.05 = for Windows NT)=0D/ModDate (D:20011127135912-08'00')=0D>> =0Dendobj=0D3 = 0 obj=0D<< =0D/Pages 84 0 R =0D/Type /Catalog =0D>> =0Dendobj=0D4 0 = obj=0D<< =0D/Type /Page =0D/Parent 5 0 R =0D/Resources << /Font << /F1 = 10 0 R /F0 6 0 R /F4 16 0 R /F3 14 0 R /F2 12 0 R >> =0D/ProcSet [ /PDF = /Text ] >> =0D/Contents 85 0 R =0D>> =0Dendobj=0D5 0 obj=0D<< =0D/Kids = [ 4 0 R 21 0 R 29 0 R 33 0 R 37 0 R 41 0 R ] =0D/Count 6 =0D/Type = /Pages =0D/Parent 84 0 R =0D>> =0Dendobj=0D6 0 obj=0D<< =0D/Type /Font = =0D/Subtype /TrueType =0D/Name /F0 =0D/BaseFont /TimesNewRoman = =0D/FirstChar 32 =0D/LastChar 255 =0D/Widths [ 250 333 408 500 500 833 = 778 180 333 333 500 564 250 333 250 278 500 =0D500 500 500 500 500 500 = 500 500 500 278 278 564 564 564 444 921 =0D722 667 667 722 611 556 722 = 722 333 389 722 611 889 722 722 556 =0D722 667 556 611 722 722 944 722 = 722 611 333 278 333 469 500 333 =0D444 500 444 500 444 333 500 500 278 = 278 500 278 778 500 500 500 =0D500 333 389 278 500 500 722 500 500 444 = 480 200 480 541 778 500 =0D778 333 500 444 1000 500 500 333 1000 556 = 333 889 778 611 778 778 =0D333 333 444 444 350 500 1000 333 980 389 333 = 722 778 444 722 250 =0D333 500 500 500 500 200 500 333 760 276 500 564 = 333 760 500 400 =0D549 300 300 333 576 453 250 333 300 310 500 750 750 = 750 444 722 =0D722 722 722 722 722 889 667 611 611 611 611 333 333 333 = 333 722 =0D722 722 722 722 722 722 564 722 722 722 722 722 722 556 500 = 444 =0D444 444 444 444 444 667 444 444 444 444 444 278 278 278 278 500 = =0D500 500 500 500 500 500 549 500 500 500 500 500 500 500 500 ] = =0D/Encoding /WinAnsiEncoding =0D/FontDescriptor 7 0 R =0D>> = =0Dendobj=0D7 0 obj=0D<< =0D/Type /FontDescriptor =0D/FontName = /TimesNewRoman =0D/Flags 34 =0D/FontBBox [ -250 -216 1158 1000 ] = =0D/MissingWidth 321 =0D/StemV 73 =0D/StemH 73 =0D/ItalicAngle 0 = =0D/CapHeight 891 =0D/XHeight 446 =0D/Ascent 891 =0D/Descent -216 = =0D/Leading 149 =0D/MaxWidth 965 =0D/AvgWidth 401 =0D>> =0Dendobj=0D10 = 0 obj=0D<< =0D/Type /Font =0D/Subtype /TrueType =0D/Name /F1 = =0D/BaseFont /TimesNewRoman,Italic =0D/FirstChar 32 =0D/LastChar 255 = =0D/Widths [ 250 333 420 500 500 833 778 214 333 333 500 675 250 333 = 250 278 500 =0D500 500 500 500 500 500 500 500 500 333 333 675 675 675 = 500 920 =0D611 611 667 722 611 611 722 722 333 444 667 556 833 667 722 = 611 =0D722 611 500 556 722 611 833 611 556 556 389 278 389 422 500 333 = =0D500 500 444 500 444 278 500 500 278 278 444 278 722 500 500 500 = =0D500 389 389 278 500 444 667 444 444 389 400 275 400 541 778 500 = =0D778 333 500 556 889 500 500 333 1000 500 333 944 778 556 778 778 = =0D333 333 556 556 350 500 889 333 980 389 333 667 778 389 556 250 = =0D389 500 500 500 500 275 500 333 760 276 500 675 333 760 500 400 = =0D549 300 300 333 576 523 250 333 300 310 500 750 750 750 500 611 = =0D611 611 611 611 611 889 667 611 611 611 611 333 333 333 333 722 = =0D667 722 722 722 722 722 675 722 722 722 722 722 556 611 500 500 = =0D500 500 500 500 500 667 444 444 444 444 444 278 278 278 278 500 = =0D500 500 500 500 500 500 549 500 500 500 500 500 444 500 444 ] = =0D/Encoding /WinAnsiEncoding =0D/FontDescriptor 11 0 R =0D>> = =0Dendobj=0D11 0 obj=0D<< =0D/Type /FontDescriptor =0D/FontName = /TimesNewRoman,Italic =0D/Flags 98 =0D/FontBBox [ -250 -216 1158 1000 ] = =0D/MissingWidth 376 =0D/StemV 73 =0D/StemH 73 =0D/ItalicAngle -11 = =0D/CapHeight 891 =0D/XHeight 446 =0D/Ascent 891 =0D/Descent -216 = =0D/Leading 149 =0D/MaxWidth 965 =0D/AvgWidth 402 =0D>> =0Dendobj=0D12 = 0 obj=0D<< =0D/Type /Font =0D/Subtype /TrueType =0D/Name /F2 = =0D/BaseFont /CourierNew,Bold =0D/FirstChar 32 =0D/LastChar 255 = =0D/Widths [ 600 600 600 600 600 600 600 600 600 600 600 600 600 600 = 600 600 600 =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 = 600 600 =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 = 600 =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 = =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 = =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 = =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 = =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 = =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 = =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 = =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 = =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 = =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 = =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 ] = =0D/Encoding /WinAnsiEncoding =0D/FontDescriptor 13 0 R =0D>> = =0Dendobj=0D13 0 obj=0D<< =0D/Type /FontDescriptor =0D/FontName = /CourierNew,Bold =0D/Flags 16418 =0D/FontBBox [ -250 -300 713 1000 ] = =0D/MissingWidth 594 =0D/StemV 191 =0D/StemH 191 =0D/ItalicAngle 0 = =0D/CapHeight 833 =0D/XHeight 417 =0D/Ascent 833 =0D/Descent -300 = =0D/Leading 133 =0D/MaxWidth 594 =0D/AvgWidth 600 =0D>> =0Dendobj=0D14 = 0 obj=0D<< =0D/Type /Font =0D/Subtype /TrueType =0D/Name /F3 = =0D/BaseFont /ONHAEA+Math2Mono,Bold =0D/FirstChar 30 =0D/LastChar 255 = =0D/Widths [ 500 500 263 260 1041 260 1183 260 1214 260 1143 1143 1143 = 260 918 =0D1041 1182 1214 918 1041 1183 1214 1143 1143 1143 255 600 600 = 600 =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 = =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 = =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 = =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 = =0D600 600 600 600 1000 600 600 600 600 600 600 600 600 600 600 600 = =0D600 300 300 300 918 600 600 600 600 600 600 600 600 447 723 447 = =0D447 447 764 764 764 600 600 600 600 600 600 600 600 655 1087 655 = =0D811 655 1205 1206 1206 600 600 600 600 600 600 600 600 874 1496 = =0D874 1123 870 1737 1736 1736 600 600 600 600 600 600 600 600 600 = =0D600 263 600 600 447 655 870 600 600 600 600 600 600 200 600 600 = =0D447 784 821 764 764 692 694 643 870 1265 1819 1223 1645 1205 1737 = =0D1205 1737 861 1333 861 1333 600 600 600 600 600 600 734 1102 1469 = =0D600 600 600 600 600 600 600 600 600 ] =0D/FontDescriptor 15 0 R = =0D>> =0Dendobj=0D15 0 obj=0D<< =0D/Type /FontDescriptor =0D/FontName = /ONHAEA+Math2Mono,Bold =0D/Flags 16388 =0D/FontBBox [ -250 -4039 2183 = 2212 ] =0D/MissingWidth 600 =0D/StemV 159 =0D/StemH 159 =0D/ItalicAngle = 0 =0D/CapHeight 2212 =0D/XHeight 1106 =0D/Ascent 2212 =0D/Descent -4039 = =0D/Leading 5251 =0D/MaxWidth 1819 =0D/AvgWidth 500 =0D/FontFile2 64 0 = R =0D>> =0Dendobj=0D16 0 obj=0D<< =0D/Type /Font =0D/Subtype /TrueType = =0D/Name /F4 =0D/BaseFont /PNHAEA+Math1Mono,Bold =0D/FirstChar 30 = =0D/LastChar 255 =0D/Widths [ 500 500 263 600 600 600 600 600 600 600 = 600 600 600 600 600 600 600 =0D600 600 600 600 600 600 600 600 600 600 = 600 600 600 600 600 600 =0D600 600 600 600 600 600 600 600 600 600 600 = 600 600 600 600 600 =0D600 600 600 600 600 600 600 600 600 600 600 600 = 600 600 600 600 =0D600 600 600 600 600 600 600 600 600 600 600 600 600 = 600 600 600 =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 = 600 600 =0D1000 240 291 600 600 600 600 1200 1200 600 600 798 600 600 = 600 600 =0D600 600 600 1200 200 1200 790 1200 600 1200 1200 1200 733 = 600 600 =0D600 600 600 600 411 600 600 735 740 600 600 600 600 790 720 = 600 =0D720 600 600 600 649 600 600 600 600 600 600 600 600 600 995 600 = =0D200 628 600 337 654 600 600 600 600 628 628 600 1000 600 600 600 = =0D600 600 600 600 600 600 797 679 600 600 600 694 692 790 720 600 = =0D720 600 600 600 598 600 600 650 600 600 600 600 600 600 600 600 = =0D600 600 600 600 682 870 870 870 600 600 600 600 600 600 600 600 = =0D600 918 ] =0D/FontDescriptor 17 0 R =0D>> =0Dendobj=0D17 0 obj=0D<< = =0D/Type /FontDescriptor =0D/FontName /PNHAEA+Math1Mono,Bold =0D/Flags = 16390 =0D/FontBBox [ -250 -234 1417 1000 ] =0D/MissingWidth 590 = =0D/StemV 159 =0D/StemH 159 =0D/ItalicAngle 0 =0D/CapHeight 853 = =0D/XHeight 427 =0D/Ascent 853 =0D/Descent -234 =0D/Leading 87 = =0D/MaxWidth 1181 =0D/AvgWidth 500 =0D/FontFile2 69 0 R =0D>> = =0Dendobj=0D21 0 obj=0D<< =0D/Type /Page =0D/Parent 5 0 R =0D/Resources = << /Font << /F1 10 0 R /F0 6 0 R /F6 24 0 R /F4 16 0 R /F3 14 0 R /F7 = 26 0 R =0D/F2 12 0 R >> =0D/ProcSet [ /PDF /Text ] >> =0D/Contents 87 0 = R =0D>> =0Dendobj=0D24 0 obj=0D<< =0D/Type /Font =0D/Subtype /TrueType = =0D/Name /F6 =0D/BaseFont /CourierNew =0D/FirstChar 32 =0D/LastChar 255 = =0D/Widths [ 600 600 600 600 600 600 600 600 600 600 600 600 600 600 = 600 600 600 =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 = 600 600 =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 = 600 =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 = =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 = =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 = =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 = =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 = =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 = =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 = =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 = =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 = =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 = =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 ] = =0D/Encoding /WinAnsiEncoding =0D/FontDescriptor 25 0 R =0D>> = =0Dendobj=0D25 0 obj=0D<< =0D/Type /FontDescriptor =0D/FontName = /CourierNew =0D/Flags 34 =0D/FontBBox [ -250 -300 768 1000 ] = =0D/MissingWidth 640 =0D/StemV 109 =0D/StemH 109 =0D/ItalicAngle 0 = =0D/CapHeight 833 =0D/XHeight 417 =0D/Ascent 833 =0D/Descent -300 = =0D/Leading 133 =0D/MaxWidth 640 =0D/AvgWidth 600 =0D>> =0Dendobj=0D26 = 0 obj=0D<< =0D/Type /Font =0D/Subtype /TrueType =0D/Name /F7 = =0D/BaseFont /AOHAEA+Math1Mono =0D/FirstChar 30 =0D/LastChar 255 = =0D/Widths [ 500 500 263 600 600 600 600 600 600 600 600 600 600 600 = 600 600 600 =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 = 600 600 =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 = 600 =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 = =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 = =0D600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 = =0D1000 240 291 600 600 600 600 1200 1200 600 600 798 600 600 600 600 = =0D600 600 600 1200 200 1200 790 1200 600 1200 1200 1200 696 600 600 = =0D600 600 600 600 371 600 600 695 750 600 600 600 600 790 720 600 = =0D720 600 600 600 569 600 600 600 600 600 600 600 600 600 988 600 = =0D200 628 600 270 587 600 600 600 600 580 580 600 1000 600 600 600 = =0D600 600 600 600 600 600 600 631 600 600 600 600 600 790 720 600 = =0D720 600 600 600 598 600 600 602 600 600 600 600 600 600 600 600 = =0D600 600 600 600 590 796 796 796 600 600 600 600 600 600 600 600 = =0D600 835 ] =0D/FontDescriptor 27 0 R =0D>> =0Dendobj=0D27 0 obj=0D<< = =0D/Type /FontDescriptor =0D/FontName /AOHAEA+Math1Mono =0D/Flags 6 = =0D/FontBBox [ -250 -234 1481 1000 ] =0D/MissingWidth 617 =0D/StemV 91 = =0D/StemH 91 =0D/ItalicAngle 0 =0D/CapHeight 853 =0D/XHeight 427 = =0D/Ascent 853 =0D/Descent -234 =0D/Leading 87 =0D/MaxWidth 1234 = =0D/AvgWidth 500 =0D/FontFile2 74 0 R =0D>> =0Dendobj=0D29 0 obj=0D<< = =0D/Type /Page =0D/Parent 5 0 R =0D/Resources << /Font << /F1 10 0 R = /F0 6 0 R /F6 24 0 R /F4 16 0 R /F3 14 0 R /F7 26 0 R =0D/F2 12 0 R >> = =0D/ProcSet [ /PDF /Text ] >> =0D/Contents 101 0 R =0D>> =0Dendobj=0D33 = 0 obj=0D<< =0D/Type /Page =0D/Parent 5 0 R =0D/Resources << /Font << = /F1 10 0 R /F0 6 0 R /F6 24 0 R /F4 16 0 R /F3 14 0 R /F7 26 0 R =0D/F2 = 12 0 R >> =0D/ProcSet [ /PDF /Text ] >> =0D/Contents 103 0 R =0D>> = =0Dendobj=0D37 0 obj=0D<< =0D/Type /Page =0D/Parent 5 0 R =0D/Resources = << /Font << /F1 10 0 R /F0 6 0 R /F6 24 0 R /F4 16 0 R /F3 14 0 R /F7 = 26 0 R =0D/F2 12 0 R >> =0D/ProcSet [ /PDF /Text ] >> =0D/Contents 105 = 0 R =0D>> =0Dendobj=0D41 0 obj=0D<< =0D/Type /Page =0D/Parent 5 0 R = =0D/Resources << /Font << /F1 10 0 R /F0 6 0 R /F6 24 0 R /F8 44 0 R = /F4 16 0 R /F3 14 0 R =0D/F7 26 0 R /F2 12 0 R >> =0D/ProcSet [ /PDF = /Text ] >> =0D/Contents 107 0 R =0D>> =0Dendobj=0D44 0 obj=0D<< = =0D/Type /Font =0D/Subtype /TrueType =0D/Name /F8 =0D/BaseFont = /BOHAEA+Math2Mono =0D/FirstChar 30 =0D/LastChar 255 =0D/Widths [ 500 = 500 263 255 919 255 1064 255 1072 255 994 994 994 255 819 919 =0D1063 = 1072 819 919 1064 1072 994 994 994 255 600 600 600 600 600 =0D600 600 = 600 600 600 600 600 600 600 600 600 600 600 600 600 600 =0D600 600 600 = 600 600 600 600 600 600 600 600 600 600 600 600 600 =0D600 600 600 600 = 600 600 600 600 600 600 600 600 600 600 600 600 =0D600 600 600 600 600 = 600 600 600 600 600 600 600 600 600 600 600 =0D600 600 1000 600 600 600 = 600 600 600 600 600 600 600 600 600 300 =0D300 300 819 600 600 600 600 = 600 600 600 600 386 598 386 478 375 =0D704 704 704 600 600 600 600 600 = 600 600 600 602 972 602 761 595 =0D1145 1146 1146 600 600 600 600 600 = 600 600 600 854 1415 854 1098 =0D843 1677 1676 1676 600 600 600 600 600 = 600 600 600 600 600 263 600 =0D600 374 571 796 600 600 600 600 600 600 = 200 600 600 374 724 761 =0D704 704 600 600 571 796 1205 1759 1163 1585 = 1145 1677 1145 1677 =0D741 1215 741 1215 600 600 600 600 600 600 734 = 1102 1469 600 600 =0D600 600 600 600 600 600 600 ] =0D/FontDescriptor = 45 0 R =0D>> =0Dendobj=0D45 0 obj=0D<< =0D/Type /FontDescriptor = =0D/FontName /BOHAEA+Math2Mono =0D/Flags 4 =0D/FontBBox [ -250 -4091 = 2110 2469 ] =0D/MissingWidth 600 =0D/StemV 91 =0D/StemH 91 = =0D/ItalicAngle 0 =0D/CapHeight 2469 =0D/XHeight 1235 =0D/Ascent 2469 = =0D/Descent -4091 =0D/Leading 5560 =0D/MaxWidth 1758 =0D/AvgWidth 500 = =0D/FontFile2 79 0 R =0D>> =0Dendobj=0D47 0 obj=0D<< =0D/Type /Page = =0D/Parent 48 0 R =0D/Resources << /Font << /F1 10 0 R /F0 6 0 R /F6 24 = 0 R /F8 44 0 R /F4 16 0 R /F3 14 0 R =0D/F7 26 0 R /F2 12 0 R >> = =0D/ProcSet [ /PDF /Text ] >> =0D/Contents 109 0 R =0D>> =0Dendobj=0D48 = 0 obj=0D<< =0D/Kids [ 47 0 R 52 0 R 56 0 R 60 0 R ] =0D/Count 4 = =0D/Type /Pages =0D/Parent 84 0 R =0D>> =0Dendobj=0D52 0 obj=0D<< = =0D/Type /Page =0D/Parent 48 0 R =0D/Resources << /Font << /F1 10 0 R = /F0 6 0 R /F6 24 0 R /F4 16 0 R /F3 14 0 R /F7 26 0 R =0D/F2 12 0 R >> = =0D/ProcSet [ /PDF /Text ] >> =0D/Contents 111 0 R =0D>> =0Dendobj=0D56 = 0 obj=0D<< =0D/Type /Page =0D/Parent 48 0 R =0D/Resources << /Font << = /F1 10 0 R /F0 6 0 R /F6 24 0 R /F4 16 0 R /F3 14 0 R /F7 26 0 R =0D/F2 = 12 0 R /F8 44 0 R >> =0D/ProcSet [ /PDF /Text ] >> =0D/Contents 113 0 R = =0D>> =0Dendobj=0D60 0 obj=0D<< =0D/Type /Page =0D/Parent 48 0 R = =0D/Resources << /Font << /F1 10 0 R /F0 6 0 R /F6 24 0 R /F4 16 0 R = /F3 14 0 R /F7 26 0 R =0D/F2 12 0 R /F8 44 0 R >> =0D/ProcSet [ /PDF = /Text ] >> =0D/Contents 115 0 R =0D>> =0Dendobj=0D64 0 obj=0D<< /Filter = /FlateDecode /Length 65 0 R /Length1 67 0 R >> =0Dstream H=89=84V TTG=16=BD=F5=B7n=E8=06=BA=D9E=D4n=D9=DC=10=90M=14=03Q = =82=06=011"=8B=0A= =08b"-=0A= =0A= =06=11P=D1=A81&1=EE&=12%=C6=10B=B0=C1=15=DC=82;=A21j=D4(A=E3df2g2=87=E39= =89=CB=81=DF=F3=9A%38sf~=9F[=EF=BFW=EF=D7=BFu=EB=D7=AB=06=03`=852=F0=88=9B= 6=DDgL~=83=E11E=1E=10b3s=D3=F3=9A=E2=9F=06=03l=04=C0uf.+=D0=A5=9D=A8=DF = =08=9E=14=1B=9C=9D7?wt=FC=15=1E=10#(=7F=D0=FC=85=CB=B3=9DV4=AD!?=1D=E0=DD= s=B2=D2=E7]u=9D=F0=1B=A0=AC=A0=FE=A0=1C=0A= =E8=1C=FE*=93=DFH=BE{NnA=D1=E3=AD-=F9=E4=B7S=FE=8A=85=8B2=D3=B7=AF=DA^ = =A8Sh=FCK=B9=E9Ey\=14=B7=17=B0v=A3|=9D!=3D7=EB|]8=8Dg=3D=89=9E=89=CA[=94= _=10=E8Y=14=058=AE=A7=FC=BF=E7-=C9=CA{=F6=E4=80=0B=E0=BC=94=FC=BF=11OpM=10= =A1=14w=89=FE=14=F1=E8=B1|%=B29[=1A=11=0A= =FC=F7kfB=B4=0E=BA=0E]=87I=D2=CBz@k=D4=C5Q=98=03=EB=EE=B6'=B5=E8b=F4&&=A1= 7H=96=EF=CE=E9=7FQ'/=88=92Bia=A9R[Y=DBh=B4=B6v=F6=0E=8EN=CE=03\=06=BA=0E= =1Aaz=E2=8C7f&=CDJ= NIM=9B=3Dgn:2=E7ee=CF=CFY=F0=E6[=0Bs=0D=8B=F2=16/=C9/X=BA=AC=B0h=F9=DB=C5= +JV=96=96=95=AFZ=BD=A6b=ED=BAw=D6o=D8=F8=EE=A6=F76=BF=FF=C1=87[>=DA=BAm=FB= =8E=9D=BBv=EF=F9=F8=93=BD=95=9F=EE=DB_=F5=D9=81=CF=0F~Q=FDe=0D_=FBu=DD!c= }=C3=E1#G=8F=1D?=D1=D8t=F2=D4=E93g=BFi>w=FE=C2=C5K=97=AF=B4\m=BDv=FD=DB=1B= =DF=DD=BCu=FB=FB;w=EF=FDp=FFA=DB=8F=ED=0F=1F=FD=04=81=FD=04=B3=D8=82y=B6= =1D&=93=89Z=9D=B9%_ = =CBS=8F=08=89=E4V=C2=02=96PAM=DF=9C5l=A0=81=16=B6=B0#E=1D=E0=08'8c=00\0=10= =AE=18=84=C1=18=02=1D=F4=18=0A= 7=B8=C3=03=9E=F0=C20=0C=C7=08=8C=C4(xc4|=E0=0B?=8C=81?=02=10=88 = =04c,B0=0E=E3=11=8A = x=05a=08=C7=AB=98=88I=88@$=A2=F0=1A&#=1A1=98=82=A9x=1D=B1=98=868=C4#=01=D3= =91=88=19x=033=91=84YHF=0A= R=91=86=D9=98=83=B9HG=0621=0FY=C8=C6|=E4`=01=DE=C4[X=88\=18=B0=08yX=8C%=C8= G=01=96b=19=0A= Q=84=E5x=1B=C5X=81=12=ACD)=ED=ABr=AC=C2j=ACA=05=D6b=1D=DE=C1zl=C0F=BC=8B= Mx=0F=9B=F1>>=C0=87=D8=82=8F=B0=15=DB=B0=1D;=B0=13=BB=B0=1B{=F01>=C1^T=E2= S=EC=C3~T=E13=1C=C0=E78=88/P=8D/Q=83=AFP=8B=AFQ=87C0=A2=1E=0D8=8C#8=8Ac8= =8E=13hD=13N=E2=14N=E3=0C=CE=E2=1B4=E3=1C=CE=E3=02.=E2=12.=E3=0A= Zp=15=AD=B8=86=EB=F8=167=F0=1Dn=E2=16n=E3{=DC=C1]=DC=C3=0F=B8O=FB=BF=0D?= =A2=1D=0F=F1=08=E6=B5=85Pj=BA/T=F1=ABM=8F=F8}r=9B|[T=0A= =FF=10=AEs=AB=C5=1Cu=92=B8Hn=D0zs=D90=8A=90+=A4{=9D5=CA=F5/:-=F5=CF=E7=D1= =A2=FF=CB=CB=E9=EE=BD=DE=D9=A0=AC =DF=E9y = =B7I=9AjZ+=AAY=A0=E4=A3=A8=EC*V=DB=BD=C8=D7=1A=9F&=89=8B=E5l=D3xeL'T=CFL= =A6=E7=BB=B8=95LfG=10F=B5=E0>Ss=83L&=D6=C0=FCY;=A7fa=F4u=D5=B2=0C)=8A=E3= X*=A7=E4=ACi5KQ=C7=E2HSc=F7=EF4}=1F5=D4=D6=D3=EC[h=F6=E6=D8=1AZ=07=994=3D= O:]=A0=DEX=14=B0=F1=8Cc=C9t=7F=98Vs7i=F4=B3=A9=FB=92K)r=1C=C7=A4y=D2=15=E1= =84=DC"=AE=C4an=00=FB=85Us=19,=88=B3d = =B8{h=88=CD(7=DD=86=0D=91qIz=FD=C0=C8=88Y=DE=A3=A6$$EF=0C=D4=EBgySA(=A3=12= P&=E9i=1B(`=7FT=C1h3=F0=02|=DA|=DA=BA=1B?_=7F=AD^=EB=A1=D7=EA=CBxt=95qDM= =D2?o/=13=F5`,N=AE=E0=ABD=AAp=88=0E=F7=B6djK=17=E6jy=94=89Z=D1 = =AD=8Bq4=C0AmP=D9o=D1=EE=D76ky=AD=9D=A8=82=8D]=8A=A8=E4=E3=9D4=BF=87=9E=EB= =0A= }=10=AA=B5=0DICXW=D8=AF=CB=C2=9C=BBB=FC|Y=1A=D3i=B5=01n=81c=02=B5=1A=BD=C3= P=07=AD=BD=C2=91=1A=7F=BEJ=9Em4=B2}=1D=19=19=1Dr=05=F3c=B1=0BjrX,=F3=AB.= =97k=0B=A3=E3=16=CB=B5=E5=C4h81*!F=AE=88 = =F7=16D=CE=D1^=B4u<.=8Aj=18\=D7=C5(=0C=92=83=9D=C1=DE~=8F=BAF}E=CD=AB-`/= i,R=E0$=C4=0F=D6=C8=FF=C9=A8=8F=D2P=C9=81=D8=989=05=04{zR=EBI=04=CD=B4=9C= =1C=FD=F9=92=E4$yvG=86=9F=DF=92=95=B7=AE=8D=1C6=87=E5=06=06=C8F=F9zu9KX=1C= =E7=9E=19=C2=12"C=AB=B7=EF=92=8DA.=CETt8N.=E5=9B=84=17=A4=B7W=B8=B3=C2=80= =12=C1=C0=BB=0A= 6TP|=A8(=08=90RY=BCR#=FF=DA=96=16j&=D2E=14H~=07=02=DF$G=B1=13=F23=A6=94K= =A5=E2=9A=17m4c=8D\=CA=B5=F4=8D=C6=19X = i=EF*=81i=98=8E=F92=81=F1=A9=88=B7xi=B4@=1A+P=CF=B5=C8=91=CCB~=CA=1A=E5=D2= =1A=D1=AD=C6=CCM"=FD=9E=88=E6C71=FC=95 = >H=8C=E2=A3=C4D.Q=9Aa1=C3*=8B=CF=12=B3-UpW=BAE=A9=0A= =85e*=9E=05+"=14s=15y=8A2=85=A8P=86=87QI=3D=E3=A5b=AA4!=DE=9A=DE=99=E6=D2= =96=E6r=EBA=DA9R4=AC[I7O.0=C06=D8_=E2=1C=ECm=F9'=F5Eg=EB=D6=D7'=DF<#W=1C= a=07=1F=B6=B3=8D7+e=FD=A9?=C9=B94=D2=1D=B9=82k=EE=E6=12=17>n,=1Bk5=99M=B6= J=E1R=C4=14=8B=14u=0E=CB=B1=B2=14=DC-=DD=A2=15E=0A= =8E=0FQMQ-T=95=AA6=ABD=95=A5=AF=C0=C2=853=C3=14L=91=86x=9B=1E=1E.i=FDx=D8= s=0A= =B7 = =DB=C0=00=CE=CB=DF=D1=96kn.4=CEm=BD=98m,md=CD=7F=96=93=8DU=AC=B1=FD1=DBw= =ACY^=DAs=82=12l=E7=1FK=99c=13=FA=1B=06(=BB=CF=CE=AF~?=99g=B6u=DBb<=E4=C4= =F6:=8D=95=D6Hy=16=BD=87,3=1F=CC=EDu=F4w`=93=9C=F8=FCg=8D=D5=1F'q=DFu_=80= y=F7=D1=A9<=B0=17=F6=F4=C7!=11=C5fkQ=D8k=8F=F4Z=0F=14[xHQf=98}E=12=8A=CD= =B9=16K = =94=F3=87_=D8=E3=F7=CB=B7=A4=12=D9=CA=E2=08^B+~!=EC=A0=FB=E1=04=8A=A3=96= =90*=B4r\=7F0=0D=C5; = =7F!=DC=A4=98=D4=1F=B8C=B8Ah"=1C=A4=FC=D4=FE@b=7F0=0FB=18a"=C1=9Fb=B7=C9= =FA=10=02{=B94=FC=7Fp=CA=7F=835=8D=91=D0c=BB=EFO=FDop=F4^=94=F7&=D2=C4D=BA=C9=89/=FB=FC=16=A4=8A=97=91j=B6}=90=06=E1=9F=EDW= kt\U=15=FE=EEd=12=9260tYK=86=B6=CC=E1=D1=D0=B4c=1Em=A5=B4Z=93=B4i=1BH=DB= I=A6B=1Fd=DA=DC=CC=DCd=C6N=EE=1D=EF=BDc=92j!* = L=13=08=E0=8B=82=82=80=A8=15=05=E2+=E0=83=FAB=EA=0B=F0=FD=16W=F5=9Fk=F1C= =97=CB=1F,=EBw=CE=3D=D3=A6!=AEJ=7F=E0=1F=E7=AC=3D{=9F=B3=F7=D9=8F=F3=BA{= '=CB@=BD=F7=9C =A1=DA=99P=B9=01=BD=D5S=D4A\u(=C05=8F = Y=F3h=00=B4w=FCL06=CC=84=AA=7Fa=DF=FC=7F"E=9C=AA~=85=F8=1F=D8w=FE_=90<=FF= D=00zof=80=B4=AB=E8#z=FF=95=1F=F2=9C=96i=15=93=F4=87=BA(=B78XStj=90g=AB=D3= 8=12`=D9W1oa=BCw=9D=8E=BB=F2v=C2=04a=99=D2=D3;/=86=E4=05=EC=D7=1C=A7_=0D= =C4=8CQ=FAY=C6U=F4u=DE=D1=D3=98z=A75=C8=3DxL=C3=D1J&=ED=D5/=02=F3=8F=A9=B3= =EF=E1~#=83 = =F9Q=96=00Y=12\rNmP=B7=A7t{)h=C6y=BAm=D7=ED=EE=FF=B7=D7=A3=A9W=F5=04=D3=E1= 0Su=83oo5=D3j=C1=E7w=8D=F1W=F6%=B7=CE=A8?=F5=F6=DE=8CrEd0=BD=BFY=D3!=CE=FE= =A0=A6+=98=EC=7FT=D3a=D2=9F=D3t%=CB=82oi=BA=8A=E3?=D6t5=F5=9C=D0t=0Dm=FF= M=D3=F3=0C=C3X=AD=E9=F9X=14Z=A3=E9Z=D2=D7=CA=12-\C'=AAC}=9A6 = *=B2=9Af=14=15=B7i=BA=02+*&5=1D&=FD=B4=A6+QW=F1gMWq=FC=15MWC=84=EB5]=83=B1= =F0=16M=CF=E3=BB=F6=AC=A6=E7#^=F5=9C=A6kI=FF}=BB=E9gWmwlGd,/7h[=19=D1?*=DA= =ED=8Ck = =D1U=81=AD=1C=CF=13=0A= =84A=EA=F58=D61C=B3=94p9^=A4=84=A0=8C=AD,=ED=E4l=8B#Y=FEK=99]=94=C8c=80=92= &=86=D0=C8=91M=1C)=D0=1FW=E9=C9R^`9=D2h = n=C1:=B6=AB=94'=01=BDV=F9z=A6=16=C1rO=FAa)=CF=D3=D4=D1=88=04=CB=B9NF=B8=99= =B0r=8EU=D9=A84d=CE*=17?=07=C9=EB=E9=89=AB=D6=C5Q1=B7=D0=9FUh~=0D=1A=CE=16= =DF=CC=9D=FB_=EC=DB\=A7,=A74=9B=844uy=E4;=CA=F7=01%=E1=CF:=87=E53x=B6H=83= =F9.qQ=8D=CF=8C=AC=EC=85=C5=99=92=CAq=86=A9=A2/s=92JSF=EDG|Ft=8E=9E=E7=FE= W=1E=14=D4=FAd=E8A=9A=F3=C6=F1&z=D1=C4{=DA=C2s=BD=1Ak=F0f=BE=98F=88;=96V=E7= r@=BDy9=BC=83=F76=CF=F8m=F5=1A=BES=9D=15=9F;=F8.=AE=D3=08O=C0A=BC=1B=EF=C1= !=DC=88=9BX=CB=BE=17=EF=C3=FB=99U=DD=82[=F1=01=DC=86=DBQ=C2a=8Cc=02w=E0N= L=E2.=DC=8D{=98i}=08=1F=C6G=98e=DD=8B#=B8=0F=F7=E3c=F88=1E=C0=83=F8=04=1E= =C2=C3x=04=9F=C4=A3=F8=14>=8D=CF=E0(>=8B=C7=98=83}=1E=8F=E3 = <=89)|=01_=C4=97=F0e|=05=D3=CC=BE=9F=C6W=F15|=1D=DF=C038=86o2C=FB6=BE=83= =EF=E2Y|=0F=CF=E18=BE=8F=1F=E0=87=F8=11=B3=B5=E7=F1=02^=C4O=F0S=FC=0C?=C7= /=F0K=FC=0A= =BF=C6o=F0[=FC=0E=BF=C7=1F=F0Gf=F1=7F=AA=E8=D8=BC=ADm=E3=E2=CB=A2=B1=8B/= =8D=C6=A2"=1A=AB=8BEc=17]=12=8D-Z=1A=8D=BD=F1P4=B6pI4=B6=82=FC=06=F2=97=93= =7F%=F9=F5=E4/#=FF=0A= =F2/'?;8m=88=A9H>@=83=F6=B4=D17=15=B9=91=E8=C1=A9=C8=80Dmu=91=88=FD=B8=FD= =8C=FD=BC=1Dn=B5=13=F6=CB=F6I;|=A7m=DC=DAK=D1=B6=AB#(]X=12=A5=8A=EER=A14= Vz=A2t=ACT=89Rs=A9=AD=D4]=EA=1E=EF=9E=E8+=F5=8DK=C6=D8=E1=B1=F1=C9=D2=E4= =E1=C9=F1=17J/=95=16=0C=8F(s=A3=01=1AI)4&Q=DB=C2H=A4=C9=A8=89$=8C=EA=A6D= k"=91=D8=9F=08=DF=D4=AF=F8=07R=CA=ABL=D0K=07=A8/@f=80=FA=03M;=02=C9;=02=B4= ?@=BD=01=BA!@=C5=BD=D2=D8=06=1A=9DL=85b)=A3)=D5=9AJ=A4=F6=A7=9CT%z.=EC=11= =3D=CD=3D=DD=3D}=3DU"=D9=9C=0C=89m=CD=DBB=E82"Fk=ED=03=C6=CBFxu=FD=92=05= =D7=19=D3=C6=C9[&=BAv=EE=9E6=B0tOW=CF=EE'=F7=8Eu=04=F8=98=C2Oa=AF=81ST[=C7= =1EO=FD=FC=E2=CA=99?o=1F=9B"=C8=C0ln=F9=F7oz=F2=A0{=0Dendstream=0Dendobj= =0D65 0 obj=0D3901 =0Dendobj=0D67 0 obj=0D6751 =0Dendobj=0D69 0 = obj=0D<< /Filter /FlateDecode /Length 70 0 R /Length1 72 0 R >> = =0Dstream H=89\VyTTe=1B=FF=BDw=1D=86m=86=94=CDPn=88=B8=D1=80=84@=0E1)=A8=A8!=E2=02= .=A8=A8,=A1(=A8)=8A=0A= dZ=A0fV.=A1=A6=E1^|j=E3=86=1Bi=92+=A3=99=BB=88Ju=F2|=E7h=C7=FE=F84=FB=E4= =CE=F7=DC=99k=C7=BE{=EEo=9E=F7=BE=CF=FE<=EF2`=00=BCQ=01=1E=E9C=87[z=8D=1F= \"=D0=CC=1DB=DA=E4=A2=9C=E2c=C3=9E=C6=01=AC;=C0=3D=9FtzNQn=FCq=7F=0E=F0=A1OCu=F1= =8CY=B3S=CA=E3=1B=01=FFj@^P<3=B7xFY=FF=15@G=89=F4=FF=A08=C1=1D=83=08=83X= #=C6=D0L=B8=9B=F2=9B=91=C7=F9yA=94=0C=E0)=7F=A6=D5=E0=1FOfFj(B=1F=87>vJ=8A= =AA=00=D2=15v=8F=A69=B8%=DBQ=B5=E8a=C1=04=CD=93=AE=C5x=97=CC?=1Fb=F2=82(= =C9=06=0F=A3=A7=97=B7=8F=AF=C9=EC=F7J=BB=F6=FE=01=81A=C1=1D^=0D=E9=D8)Ty= -=ACsx=97=88=AE=DD=BA=F7=E8=19=F9=BA%*=BAW=CC=1B=B1=BD=E3=E2=13=DE=ECcM|= +=C9=F6v=DF~=C9)=FD=07=0CL=1D4x=C8;iC=D3=87e=0C=1F1rTf=D6=E81c=C7e=8F=9F= 01=07=93=A7=E4=E6=E5=17=BC[8uZ=D1=F4=19=C5%3g=CD~o=CE=DC=D2y=F3=CB=16,\T= ^Q=F9=FE=E2=0F=96,=FD=F0=A3=AA=EAe=CBW|=BC=F2=93U=9F~=F6=F9=EA5k=D7}Q=B3= ~=C3=C6/7m=FE=AAv=CB=D6m=DBw=EC=DC=F5=F57u=FC=EE=3D{=BF=B5=EF=DB=7F=E0=E0= =A1=FA=C3G=8E=1E;=DE=F0=DD=89=93=DF=9Fj=FC=E1=F4=99=B3=E7=CE_hr\=BC=F4=E3= =E5=9F=AE\=BDv=FD=C6=CD[=B7=9B=EF=B4=DC=BDw=BF=F5g=08=ECgh=C5=16=B4l=1F;= =9D=D4=F1=C7=A1=DA/}=0BDy=E2=88=90 =C3=00=0F=18=E1 /Zs>=F0=85 = f=F8=E1=15=AAh{=F8#=00=81=08B0:=E0U=84=A0#:!=14=0A= ^C=18:#=1C]=10=81=AE=E8=86=EE=E8=81=9E=88=C4=EB=B0 =0A= =D1=E8=85=18=BC=81X=F4F=1C=E2=91=807=D1=07V$=E2-$=C1=86=B7=D1=17=FD=90=8C= =14=F4=C7=00=0CD*=06a0=86=E0=1D=A4a(=D21=0C=19=18=8E=11=18=89Q=C8D=16Fc=0C= =C6b=1C=B21=1E=130=119=98=84=C9=98=82\=E4!=1F=05x=17=85=98=8Ai(=C2t=CC@1= J0=13=B30=1B=EFa=0E=E6=A2=14=F30=1FeX=80=85X=84r=DAW=95x=1F=8B=F1=01=96`= )>=C4G=A8B5=96a9V=E0c=AC=C4'X=85O=F1=19>=C7j=AC=C1Z=AC=C3=17=A8=C1zl=C0F= |=89M=D8=8C=AFP=8B-=D8=8Am=D8=8E=1D=D8=89]=F8=1A=DF=A0=0E=FF=C2n=EC=C1^|= =0B;=F6a?=0E=E0 = =0E=A1=1E=87q=04Gq=0C=C7=D1=80=EFp=02'=F1=3DN=A1=11?=E04=CE=E0,=CE=E1<.=A0= =0E\=C4%=FC=88=CB=F8 = Wp=15=D7p=1D7p=13=B7p=1B=CD=B4=FF[p=17=F7p=1F=AD=D0z=0B=A1=DC=D9,l=E5=17= ;[=F9Z=B5E=BD&=1A=84=DF=85KB=16=FB7=D7=EC=0C=E3O9=F5=C7=90=F6=1C=9E=7F>=AB= =11K=D4=81j=1E=BF=92=0B=E1=13_=F0=D4=1A)Vz=80_=C5E=C2=11=F5=82=E8=C5=AD=E0= |=9CK9=8E3HS=A4=F3,=96:WO=99=D5SF=FB)=87=06=8A=FC,=FD6=E2 = =1B=02=95=F5g=15=C2T=D9f<(\=A4=0A= =EDd=D5=D8J=9B-=0D=7F=90=CEr=D2M=A4=9A=D5QU=06=91~=3D=AD=BA=06=EA=CA=13f= q=E9=E6R=15Oc=1D=1B=C1=FA!M=84=BAD=F8K=BD,=EEt>=14k=D9=18=D4=B1tV=C3=CE=B0= =1D=D4=8F=83=A8=E3=82=B8$=CE=87=8D=E0,=D4?;=EC=AC=12'=EC=A6N=BE=3D=C3B=AB= =ABS=D2=B3=14=A5CJ=F2=E8=C8=9E=833=B2R=92;(=0A= =0D_=E2=EC=B5=E5=10=93=CE=81=0A= =DA=F9=15=92B=AB_F=90=CD(3=DA=04=BC=87=00=83=E9n=0B=BD=B0=B4XZ=A2=A3b=CC= =8A9\1+=15<=DA*8=A8=90=94g=F7*DE=DB;u=08=10=14~"=ED=94T[=98=D1=9B = =B2(=FAxxx=F2=A2''1=0E=B2d=10=04o#=BC=BC=0D=9EF=A3=C9=D7=EC=97`illil=A4A= =90%=D0/!=81^=8B=05=16=8B=958V=BF=80=84=E8(&=06=C8=11rD\x=9C=C8=C7=F0=E1= =82=A2=B6=D6=EF=DE=BEm=CFa=B55=99=F9{=DD=F2b=FE=CC=91=F6=A0=F2=E9=D3=CA=07= i=97=F2Y=0F=F5Z=BE=16=8B=03=9D=04=F0y=B4w=BB=DB=DA=F3L=C84=18=A5=10=18=B9= =85r=B1=C8D=9E=F7=F6=D2=BC7e[=DB=ACw=90dm"B=CE=14s=98Y=89U=CC=94=A5=00=B5= =C1=AE=9EdIv=D6=97=15=AA=07=D8=E0},U=3D=E4=B2=CD=0A= =E9=A4=0E=A1J=F9=1C`=994`=14tR=9B=A6=1FKz=CF=1D|=0C+=DC=A7IV9=D7P=14=BF=D3= i2=F60=1D-=8Fm=91B&=13x1S;i2=19=9F=C9q=14=0CG=07=0E=E3i=04=96D=9B=9DC=14= =97L=CBL`=08=B2X=1B=B3=AFfS=A8=F4=062=8B=A3%=C0*=0B=A6G=A2=E9=91l=12=1E=19= L=8FX|t=94=C8X{F=EDz^=C5=CFm;=C7=C5=15r=91\=0F=87Z=ABn=D2=CEw=07=EA(=DAf= W_=03m=9Eb=A6D1=FB=90G=D1b=B5X=91=F4=E8=AA=1E=B9=F9=EF=E85p=DD=ECm=97=ED= =B4.=1D=94C2=E50=80*=EA=00mQ=9B=96Y=06Lb = ?=97N=C8q=B6v6=8E=97DE`2=C7Og=8B$q=BA=1C"=1C%U=06=D9=E9=B4=F9=C8=F3=05=18= m|)=15^=E1$Z=EB=FB=A52A=F00]7=B5=C5[=83of[=83=DD=C3x=0A= &=A1=ADM=CB5=D8t=C7t'X=8B+@f,@V=C4=92=E7=B1=CD=E5j:=DB[=DE=CC_`=85=CD=E5= =EC=00=B3=977=83=DC=E8=B1=B0=01X)=9E=D2#=94=ED=06=81eGG=B9=AF;=C23=FE=F2= =98 =BE=D6=FF = =D0=E0=BA=E8v=CB%M=1A=DD{=EC=CF8=E7=06=B5=87=A7Q=BABr=1E=FA=8D=C8=B4[T=BB= K=3Dj=9C=1B=FE=FB=D0=D3=88=FF=BFu=7F=A1?=1E=15=DA=80=EB=E0=86=E0`=A7=A8B= =89=845=84<}<=9E0Ipp=12=D1=1B=82=D6=0D=07=1C$=DBI=A7=DB=89^#=9C!=1C!=AC=D2= =F5+ [=DD2XBh = =1Ct=CB=BBt=ABt=9E=86=16=DD=AEI=F7=9B@h=A7=8F5=14=11=92u=D9=81=841=BA=AC= &=A3=D9J=D7=F9=1A=ADu=C7=8BQ=84X=C22B=1A!=8BP=E8=8E=89=D6=A6=03=C3(=0E=D3= K>=AE=10=86=10"=05=87s=03=D1=B9=84=12]7=CCM=99=EE=C3=A9=EA=FE-:=7F=0A= =A1=1B=A1/=81=D3}j=F6V=12=FA=E8=D8=AC=FB=D1=EC=90=0D=CE=8B=A8=A6S=A7=F5=93= =3D=A4=1E=8C@=99^=AB*=B7=0C=8B=F1=A8=C1=03B=93=DB>=93=A4I=AE=9A=8F#h5=98= G=A0=9E=B1=08w^,=9Dd3X=8D=D6udH=19=C8=D0(=F1=F6k=F4=05=C4=16=D7=DC=11=BD= =9E=11=EE=BE=B2=07Z=BD=F8A=AE=18j=08=19b+=12=C5=87.=D9H=BD=16=9A=EC*=CD.= =ADS=97=DD=17=94=F4=3D4{b=B4K_=B3[=A6=F7=A4=80xy/=F5ZC=9D=FC=04=BB=A8=06= >Z=AC=A2=F4?=EE=AB-=B6=8E=A3=0C=CF=7F=EE7=DB-m=D3$M=DB%=A5m.=C6=C9q!=B7=D2= =D6=CE=85$=CD=CD8=CE=85=90=B6=99=B3;>g=F0=DE=B2;=1B=1F=DB=94=84=14(=05B = =BD=A7=85=84R=04R=DF=90=90=8A=C4=03=AFH}EB<=81=F2=8ADy=C9k=F8fv=8F=ED:)=A1= HH=C0Y=CD=EE=F7=CF=FC=F3=CF=F7=FF3s=E6=1F=13=B7=FD=B9_=B1=B5=C5=C7M=1C=D1= =EF=C6=8D=B4=B01=B4=8F=EB=A2=FB=EAXes=BC=B4xY=ECI=97=D2)=D8=0A= L=9F=1A=C6=FF=83=E1v=01v^J=E3=92=F1~=B7=F7E=B9=06=BD=87=0B=BFg=8F=F5=D6<= rW=B4=E5*=8BJnQ=E9=D71J=BF=06?=AA=E7=A7=98=C0=FEuv=B2t=BD8=AEK=BA=0Ft_=B3= =1F=B0=07r+=B2=BD0=DE=B3Q>=8E=CC=8B!=F3=FA=B8=A7=8Dl=E5U=E4!=FF=EC=F9+5=E8= =DE=FF=E3=E7=19<=DE=7F=FFc=FEe=AF!=FB-"=CF=CE=E1=A9=E0=CF=DC=C2=FE=1E=C5= =FD=88L=EBrzd=FE=BF=F8<=EB]g=08=B9=F9=F9=0C=E7=90=BF_=CAp=1E=99=FAk=19.=00= =BF=97=E1"r=FA=DFe=B8=84=FA=0F2\=81=9D=BFd=B8=8A=1C=FB=EF=19=AEQ=1E=E7K=8A= =EBlY=EE=E9=0C7=80O=E9=FBU=A1=0A= =12=85=DC=99=0C=13=B3=F2=B3=19=86=17=F9=CB=19=CE=B3u=F9w2\=00=FE = =C3E=B6<=7F=3D=C3%=B6=AE=D0=9F=E1=0A= []=D8=92=E1*=FE=E3Od=B8=96+aO=A7=B8=CE=06=CB=8D=0C7=80=B7=1C=E0=AA=D3<=10= =F8=81=E5=88X=B6}=E1X=AD=19k=D4w"a=EDKf}=C9#15hMK=D5=B1vs=97=87=BC=1D=C4= =D6N=A3k=ED=8E=82$=B4=B8=EFX=87=95=08;=C2=B7=8E=05=EEd=C4=BD!kG=10=CED=B2= =DDQ=D6=1A{=AD=D5=DC=BAu=D3=A0~o=EEiX=E3"=16<=B2;Cc=07=F7=8C=EE=1A]?Od{=E0= :K=EB=06?=B6=F2=A8=88b=19=F8Vshx=E3-=15=96=8E=F7=9Fqx=C1=AA=8C-n=D9I=AC=02= =CF=9A=0C|=95=0D=A3=07YJ=05=ED=91=95=C4"=1DL=9B=10=1EW=D2=E6=83F=18=17=DC= =11=D1=A0=19.@[t=B3=810=0A= =9C=C4V=F1=90=B5W=E9=91]i=0B?=86K*=B0=C2=04=1A=DCFg!K=F4=D75Sl=10=B5=D3=90= =B55=0B=99'=C7=0D=96=E3=F6=CAa'=80=3D=8B=ED\dWkD=A8O=A0aA=C77=E3=1CFo=81= =9A=0E=DEZ=E7=184\6 M=CE<6=84=9A=1D=A8 = =C1&2v:=D0=B7=D8=1Af=B3=B5=F86=D9V<=9B=0C=93=14o=BE=C9=86=85=CCS=B3=10=86= =B7=0D=0BCl=0C7=BC=3D=F0n=17=CA=FA[Dd=BB=B1=E0=DCVo=F0=DF=D0<=0A= &=91=89J`= Ew=D1=DDt=0F-C~=B7=9CV=D0J=BA=8F]=A1Ut?=3D=C0=9E=A4=07=D9=08Y=D8=D9=7F=A4= O=D3jz=88>C=0F=D3#=F4(=AD=A1=B5=B4=8E=D6=D3 = {=9D>KC=EC-=DA@=1B=A9I=C3=F4=18}=8E>O=9Bh3ma=CF=B2=E7=D8)=DAJ=DB=E8q=FA=02= =3DAO=D2S4=82,l;=ED=A0=9D=B4=0B=FF=9D=17=E8=8B=C8=88=FED{h/=3DM=FBh?=1D=A0= =83t=88=C6=E8K4N=87i=82=8E=B0=87=E8(=1D=A3=E3=F4e=F6=0A= =FB-=BBD'=E8+t=12=99=E8=B3=F4=1C=9D"N-=B2=D9=0B=ECer=90=9F=7FH=82=BD=C1^= d=EF=B3=8B4=C9~=C1=DE=A36uH=D2Wi=8A\=E4=86>=05=14=D2i=8A(&E = =9D=A1i=EA=D2=0C=CD=D2=1C}=8D=9E=A7=AF=B3=CB=EC=E7t=96=BDK=E7=E8=1Bt=9E^= =A0o=D2=B7=E8=DB=EC7=F4"}=87^=A2=EF=B27=E9{=F4}=BA@?=A0=8B=F4C=FA=11]=A2= =97=E9=15z=95^co=D3=EB=F4=06=BDI=97=E9-z=9B~L?=A1+t=95~J=EF=D0=CF=AA=89/= =CF=E0=BC=E5n]tq=9C=0A= _I=EEV=E2=C4=EE=A8=0EW=0D=8E=AAH=C6S8=E4;U;=F0=DBQ=02=95=E2=A8=1Bvxa=BBP= <=BF=A3#=CB=BB=C2X=BA=81=9F=1F=EB=C8=E2n=EEy<=BFK=F1=C2=DE@=F1=12=CEc=C5= =9B=C5}<=0Cyi?=F7Z=0E=CF=1DHr=07=93=F2!O=DAQ=E0=E7=C6dqB+=E5=C7;A=F1=B0l= =A3=F7=04O=CAGR=9B=A5X=D74s=C7e~,=96=85=13P=AC=EA=C4B = =11=11}8=E1C=E1;=D2N\=1E=15=B9a=D5=D2=B6l0q=84=ABxYd=DCB=D4=B4=0D7=B4=17= $=B8=15P=D5,N=19fn=CA=CCO=CAAJ=ABh=88=E7#p2=0C=F2=0A= =9C=92=8CS=E0=896=9C2=9F\W=E6Q]=98=85z9=96=9E=D4L=E2N=10=A9:R=07[!=FBh=19= n=92=C7=F58p=A5=13=BA=DC=16Q)=FD4=10T%=FD=84k=C5J<%\=A1=02=BF=E1=8AI=D5=13= =FALR=DA=93Jq=A8=FB=15A2=8EK=E2t=C2=DDf=C5i=C1=18=F2=A0j=80=C9T=D2uDU=FA= J=B4#4=CE=A3=E1B=9CxM=FD=1A=AEdYU=B3=07=86KX=08=81=DFL?=C35=DD'=8A=054=16= =E0p>=88=9A(=C3=05dbM=FD=1AN=1D=F2=84=13=9F=8E=CAzl'P=95l=E6=9A=C50=92=9E= =A8G=89+0=15|F8=05=DBMZeGr/=F0=9Db=07i=98*=C2=1D=B0=E5Q=14L=B7=902=A6H=BB= _6( k=E6kb=906:=C1=B4_w=82=A4=E5=0A= 3B=03>=84=887=88=EBe|:=91g=B8+|[=D4=8D=BA=8E=88=E86=0C=C6=B4=C8Y=D1=ED=B7= !I=DE=C62RI=E4cr=90=19W=F6b=BE=A6 = W=C63P=9F=16=12=AE=AB=88=C7q=BF-#=DB=15^=E2*=19=BA3=B5T=0C=DD$=AE=08/T3=B1= P=8D=F9H=81I=D1=04=B2_SC]=A2_B=F5c=D9=BA=A2=DB=13=AB=C8d=E3=A4=A5=BB=F6=F4= =8C=D0=D3=D2B=19=B3=EEa=CB=D5=A0=9B=C1"=F7=DB=AE=A8`J=1D = =B1/=12m=BDsa1=92=93=FDv=EF=16=93=8A =EF = E=8F=A6=8CX=C6=FC=E8=AD\s=836=92v=17sX=CD`=10=A5!=C2R=D2=F30/=E8=A9=A8=F5= =84$=EC=EBA3=C6=BC=96=9E=93=AA=E1=A5=F5=8B=8E=9C=9Ct=0A= =C8=C3EQz=BC-=EB!=AE(=BEnR=E1=02=16=DD=05=DCR}-l=97)=A1R=AD=C5=92=E8.=96= Z=AA=AE%=91=EA5=E6=B1'=9D=85=86=96*=1B,=BA=85=D8=0D=E0=80=A6f(=D7z=DBA=85= =F3Pt=E7a=0Bs=A19=19]=98_=10=B0=86=16=84=96=EA=CF(e=8A=1F=11=B1=C2=16=8B= =B0i=C8d=AA}=0B=028/jj=A9=82=BEp=FC=FA=DC=C4=AA=07=CF=3D=FE>]=1Dyb=A0=CA= =BA4=82bu7vG=BA=F9=B0{=AE=9Bcsw=CC=85s=17=E7=AE=CC]9[b=B3#scscg=C3=D9=0F= =E7J=FB&=FE<`=A3=9C=99X5p=FC=98=B6=B0r=80O\=1D8=8Cr=04=F5=87=F0}=E6=E0=3D= =03=A7=9E=FF=C7=18k=81=D2=0A= =9B=F8=C3Cv0&l=E275=03R=0E=02=FC=1E!"=F2=F3=03=D6=07=EC=0F8=1F=C0=E2i=0E= T=B2=8D=BF=CE=FC=01=BF9H=99=83(=BF@=88B=08=93B=88A=88CH@HBHA=08[=08X=A7=04= ?C=89=00=B0=F7eP=E2P=12P=C2=E6=E4'!=EFg=F6=80=DF=DE=0A= =E8=86M=FC6 = j=1B=BF-P=C4=DA=0El=9F=85=19=98=B24=03=CB=97=9A=82)=133=B02+=A02;=10=D3!= =87?#KB>=3DSB=9E=83]A^=86MB^=8EE@=9E=87QR=9E=95IO=9E=89AM=9E=9BKE=9E=8B=91= O=9E=99=D1@=9E=8DEU=9E=13=D8=1Cq=D0g=ACgd=E2=07V=FC=F6=C0=0A= ;=1F=C8=D9=CF=B8=81=85=83=9F=91=9FE=9E=C5=9E=D1=9E=C5=9F1=81=A5=9Fe=3D=CB= ~=C6=FB=8C=FF=19y=AC=8D=D5=A4=B8=BD=19w0=FEo=ED=F5=0E=8E=D8=C1=C8 = =1B=E9=1D=18=B1=D1=AC=C1=05B=1F=00=D3;=19=CC=18=19=E0,=078=0B=A8=AA=B8=A4= 4=AE8N=1B=07(f=D0..=01=D1=DA0=02"\=02=D3=06=0041J=07=0Dendstream=0Dendob= j=0D70 0 obj=0D4686 =0Dendobj=0D72 0 obj=0D8183 =0Dendobj=0D74 0 = obj=0D<< /Filter /FlateDecode /Length 75 0 R /Length1 77 0 R >> = =0Dstream H=89=ECWkPTG=16=FE=FA=DE=BE3=C3=88:(=08=BE=E2=8C=A8=88=A2=80d|D=08=88b=A2= <=C4=F11@=14Ey=AA=03=C8CEM=00=9FQTD=13=A3D=D1=A0=F1=BD=84=E0#=9A=A8ID=8D= F'j=D0=F8Db=ACM=D6-=DD=B2=B6*=B5=1BKg=F6=DC=99=D6=18=ABvk=FF=ED=9F=BD=3D= =1F=FD=F5=E9s=FA=9C=EEs=BBo=03=06=A05=CA = #q=CC=B8=E0=01=93=BB=D9z=90=E46!a=BA--=FF=D8=D8=7F=0C=02X=1F@z2}N=91qlDr= =03=C0{Q=FF_3=F3=B3l=DB=1F=0F8=01(=06j=87d=CD*=C9=F4]f=19N=ED(=B29=99=9D= =91=96~=B6=DF=C1=EE=80V=A2=FE=81=D9$=F0j=CF=B7R{0=B5{d=DB=8A=E6=E5=94=EC= =AE=A3=F6$@^5+ozZ=F2=99=94=DE=80=FE/d=7F=D6=966/_=0A= =92&=03=9E=F5=A4o=CCM=B3e=D4XW=DD=A4=F6%@=97=95=9FWX=14S:=F8=14=E0C1j=17= =E6=17d=E4=EF=AB=AA=AA=05=BA=1C = =FBF=8A=13l-=14=E8=94j%=8C$=3D=DD=B5=BC=0D=99R;O(=1A=0E=99=E6=CF=D45=F8=C3= c=B5=8C2"=EA=91=F1=91Scr=98=00M=13k!=B1=04=B7=A67=AD=16=3D=AC=13A=03<3g=B2= K=E7=8F=0Fu=CA\=D1hu=1E=FAV=9E=AD=DB=B45x=B5k=EF=ED=D3=C1=D7=AFc=A7=CE]=BA= =BE=D2=CDh=EA=EE=DF=A3g=AF=80=DE=81}=FA=06=F5=EB=1F=1C=12: = =ECU=F3=C0A=83=87=BC64<=E2=F5=C8=A8a=D1=C3G=C4=8C|=E3=CDQ=A3c=E3=E2=13=C6= $=8E=B5=8C=1B?a=A25)9=E5=ADI=93S=A7LM=C3=F4=F4=8C=CC=AC=EC=9C=193g=D9r=F3= =F2g=17=14=16=15=CF=99;=AFd=FE=82=85o=BFSZV=BEh=F1=92=A5=CB=96=BF=BBbe=C5= =AA=D5k*=D7V=AD[=FF=DE=FB=1B>=D8=B8=A9=FA=C3=CD[j=B6n=FB=A8v=FB=8E=8Fw=EE= =DA=BDg=EF=BE=FDr=DD'=F5=9F6=1C8x=E8=F0gG=8E~=FE=C5=B1=E3'=BE=FC=EA=EB=93= =8D=A7N=9F=F9=E6=EC=B9o=CF_=B0=7Fw=F1=D2=E5=EF=9B=AE\=FD=E1=DA=F5=1B7o=DD= n=BE=D3=F2=E3=DD=9F=C0=D9OP=17=9B=AB=B3}=E4t:=E9=AFQ=FDKmN=B5L=3D=0A= 4=D0B=07=0F=E8=D1=0A= =9E=F4=CE=B5A[=18=E0=85vhO+=EA=83=0E=F0=85=1F:=A2=13:=A3=0B=BA=E2=15t=83= =11&t=87?z=A0'z!=00=BD=11=88>=E8=8B =F4C=7F=04#=04=A1=18=800=BC=0A= 3=06b=10=06c=08^=C3P=84#=02=AF#=12Q=18=86h=0C=C7=08=C4`$=DE=C0=9B=18=85=D1= =88E=1C=E2=91=801H=C4XX0=0E=E31=01=13aE=12=92=91=82=B70 = =93=91=8A)=98=8A4L=C3t=A4#=03=99=C8B6r0=0331=0B6=E4"=0F=F9=98=8D=02=14=A2= =08=C5=98=83=B9=98=87=12=CC=C7=02,=C4=DBx=07=A5=B4=AF=CA=B1=08=8B=B1=04K= =B1=0C=CB=F1.V`%*=B0=0A= =AB=B1=06=95X=8B*=AC=C3z=BC=87=F7=B1=01=1F`#6=A1=1A=1Fb3=B6=A0=06[=B1=0D= =1F=A1=16=DB=B1=03=1Fc'va7=F6`/=F6a?=FE=84:|=82z|=8A=06=1C=C0A=1C=C2a|=86= #8=8A=CF=F1=05=8E=E18N=E0K|=85=AFq=12=8D8=85=D38=83op=16=E7=F0-=CE=E3=02= =EC=F8=0E=17q = =97=F1=3D=9Ap=05W=F1=03=AE=E1:n=E0&n=D1=FEo=C6=1D=B4=E0G=DC=85=9A[=F0R=E7= -=BEC^=EC=BC+=D7:=9A=1DM=8A=8E?=E6=B7x=12=BB/=EDv=FA=CB=8DN=F1=E8=12=9E@= =D9=F9[=B5R=EB=BC=EF=C8=94=97K=99=0A= =1CKY=B9R=A7ItVK%=9A=C3=CC=ACx=F2=9D=8E=16M=13=ED=AD:V-=0D=95=CCR4=F9=DC= B=99=1BI=19=1AM=D9I=A0=CCX(+=13)#)=B4*?=C3=C1Z1=7F=1E=A4=E5=FA=F9<=9B=A4= q=88aZ=E7=F3=87l#(=D7=CF=EDI=92HY=D9H3 = =DB=E7Z=EB=D9=1A=C4=B2=C54=F3p=CAH%=F9=8Dg=7Fv:=D9=02=98=E5=15H`=E5=0D=86= nm=83=FC=8D+W=C6$&=99L=9DcF$=F7=0B=8A=B5$=C5=8C=E8l2=11}=A1=A7>*=8D:i=BF= =97=D1=0E/=D3=98=E8-=D7=A2c=94=9EC=CB=14=D9=83Cg=B8=D3L?=047=077=87=86=84= y=99=BCz=9A=BCLe2=9E=96Ip@c=FA=AD=A5L1=A9{=C4=8E@:=89&=D1=BE=E8=15=D5Nf=DC= =AA=D3kZC/=0D=D2*=B2=DC=DA=D3=AB=DD=90=E0=0B=E1O=C3o#2=FC=02U=A1!=CC=E4=E5= =EFe2=9B=BChT=0EGE=9Cc=0D+=88c=C5=AC=C6Q=C1=8AcY=A1c=B5k\VC[=F2>E=D6=E6=10= =B3J=AD=C1=82=83=11=F9T=B57=93=DD=13=BB=1C=C6jbU=CD=0A= =E7=03=8A`#=ED=D2=94(=FDD=9E=C97=F0=9D=9C=F3#=CEGQ=FE=DC=CA=B8=ACX=D5=BD= le=B2U=92hz=12mi&=13#=A9=C4=19:=06=87=9F=BABq=D2=CF=8F=05=DB=9B}=C3=B5=DC= =F0P1<=D4=1A=F8C=9D=E1!=1B<94Da=CC=871=F2[!=17?=0D=90nx=B3k=ECj=B2c=89=A3= \=8D=95"=88vE01=AA=7F=B2=9C#o=92=F7=C8\6=C8VpY=B2=D2=19=AD2=AB=A2=90?E=A6= =A3=96=0EcN=EE=15:t=FF+=EF=8C=99=E9=C7=A3=9FTH7=9E=06=B0FG`=12+e=0B=93]=C7= 7=E1|C=F7=C2)m=C3=7F=85=9F=CEup=D7i=F3"=D4=BA=FE=D8=E3]=CE=16=87M=9F=AAi= =A2=A6=878=E1=99=FAUP=BF=0D=1E=D5=CE=96'=D0=A7=E2=E5=AF=C8=3D=0E=F5=DD=A0= OBg7=B8=9D=DD=E5vL%=9C#d=12=CA = =95=84=D9=DC.=0D=A1=FE=00=E2=7F#=D8=89=17=8A=FA*=81l=F1=0B=E12=A1=86=B0=9B= p=90p=9E=F0w=C2aB=0B=A1I=E8=AB=B6=15n{=D7=18=BET=EF%=18=84_=F2=850=C1U=D8= =08 B?=8E=90"t=BD = =DDD;A=D4=B5B?=95`&=9Cx=A1=AF=98POsQ=E5=16=F2;=E2w=1F=CC=DB-=03=C9=9Cj=AC= =8B=DD=F3F>=A1/a=03=E9L=A2:=8F=E0=EB=D6s=8Do=13z=FE=C2O=B4[=D75=DF=8D"=DE= 81=BF=F5=EE=F5e4=B6=14)=C6=DB=AB=83=F3:{@9=18=8F=05=D4^JXA}3=08a=1E=D5=AC= =D4=A3=DA5=EF@j=F7=D5Ls=AD=D7=DBn=E0=06=E1=81=C8=CBAu\=D2=B5=B0j5=EB=B0h= ,=B0=A8=B5=DA=A7=D6=CF=A0T=B9d=E7=C5z=AA=B6=D7=C8V=CD=9FY=FA=A7+=065w=16= =A5=12=11t}=B0=889n&$=12=AA=D4q=95F=F7=B8T=8F=15=BE=C3\=E3=ADv=D9=DBE=1E= =E6=BA=D7=86e=FE=9Ek=17=F6j=7FA3=ADA=B4=1A=AB=A2q=AD=D9j)=90r=D9=80=9E=C4= i=EE=18 = =90=C2w=90=AF=1D.=7Fv=F5=DD=17c=BF=8C#"=7F=10=F0V<]=ED=AE=EEw=CE=E5Wm[^=8A= =DF"=E6=AB=AE=E3T~=0E=D9"=7F=17=F9e=B5O=1A=FA=02=CC/ = =DA=9D+=B5v=F1=00=97=FD=11=1A?=15)=9ATe=88=0A= =927=BBm=D5Z=DD=0BR=9C=D8=13K=9F=8D=A1=A9=A3=9B=04=E8&=F1=EFK<=95i=FF=B1= l=A7r=F7=FF=E5=7F^=D4S=F6=1E=DD=E6=14=BA7JT=0Ct=C73=D2ql=A0=FB>s=F5=FA=B1= ^=CF=CF=E2Exv=3Dg=A4=B9Hp=89=BE=D4=EB=04=97I=BEIpN|=8F=E0=0A= =DDQ=8F=0A= =AE!=F9i=C1utc=BD*=B8=07=DDO~=16\=CFd=16.x+t=90"=05=F7$>A=FD=7F=81{P=10\= =9A)8=83Q=CE=13\B=1B=B9Rp=99=E4[=04=E7=C4=8F=0B=AE=C0On=16\C=F2_=05=D7=A1= ;=F7=11=DC=03=FB=F9 = =C1=F5=92=86=DF=13=BC=15=824=F7=05=F7D=90=D6'>=AD(;4>/7=CF=98=9EQ=98=93=95= =9B=91n=9CVb=1C=96=9B^=90a=8C-=9E=9F=9B=93V=9013=E8_=D5W=E9s=14=C7=15=EF= =B7;{KZ=1F`=E3=03kbc=07=82"=B1=1B,=0C6X=E2=08=C82=96,q=19_=F4=CE=B4v=DB=9A= =99=1E=BA{=D0=8A=1C=C8q=1C=E7"8>b|$=90=AB=92=AA|=80=E4C=0A= W=A5=CA=FC = =F9=98=CA=97=B8*=7F@=F8=0F=C8=EB=9E=DD=95,=A8R=F2!=1F=B2[3=EF=BD=EE=D7=EF= =FD^=1F=D3=EF=B9=0B\=B7=DC=834=A01m=0A= =E5=EE=B7=BA=EEA)=92=D8=A5=91=EF=CEj=16=B7X=E4=1E=17=C1=9C=A4=E1=B0=BBO=C4= =8B=927[=DA=DD=ECmqk;w=8E=0E=99=F7=8E=AE=86;=C3=14=A3=D2k=0D=8FO=1D=1A?0= =BE=B5=07d=865=93=80=CA=D5=CD=AB=E5cL*."=B76\=DF=B6=BA=EF=16'=FF=9B(=97=AD= r=E5R=D7K=94=16=A1;'"=DDqc=9C=AC=86=82=FD=D2M=14K=9D=19=13,=A4=9A{t=C8=0A= 3=8C=FAL=0EYw=02=FB=E4=AD=06b)=FC=C4=D3j=D8=9D=D0=C6s=C0=3D=16)=0CI=0B7N= P=83*=9C=1BW=CC=B98=1E=1Du=F5S=A3!]t#=A1=DD=06s%=F3=B9=D2=927=12=8D=A3=0D= =1E=91h3=C8e=EDX2=A5=DC=98=C9=90+;=CFh=EE=96=A5=EB/=B7=B4=8Ew=8D=8C,,,=0C= /t=96=DE=13=E1=ED[=F1=C3J1=11oa=A1v=18=0B&S4=B9=B6=9CRXJ5Qf(=B9=F8=81]=C4= =F78=CA>=16T=0C=F9I,=A9=CE=A2=CCq=BCi=99=C7=A2=CF=C5=12=8B[k.=16s=14=CB0= =8A%=18E;=02=ED=B9X=E6-=DB5=1A=12=DB=13=D4pQ'=B2~fq4=C3=96=16=BE=8D=CEq=D4= =08=B0=B4=93=A8=11bI=E9b=B1h=CA=BAEl=E1=B6=E0=D3=D8=B6=19K=C0-HkX^=EE=C4= Bs=A8=C7=EF=B8=C5=86=8B=85=8BA=C1,n=0F-=0Cc\SX=98=8C=E3gk=1C=8B=D7[g=C4=8C= h"=D2=C0=8EYK{=AD=FEchM=DAy=106=C6=1A"=A8=93mk=8E[;=92=FF=A7=B5=BC=1DVn-= S|<=B4=A5=B0_=D88=E7=AC=86^=15M7=92=B5f%=1D/=91&=B6}ed]=14=0CG=1A=8E=E3=08= j=A3=EF=F6=CCXK=BE]=B3=A1=15=D1=89=CE8=F9=1F!=88=ED=FC=F8=88=C0=C3q=CA=EE= =E4 = =1BQ=1As`=3D=9ByR=9DU=D2vFb=1C=91=DA=A0=B6GZm=81=BE=DC=8E=FF4=A2=D5=F6W"= 5=91=99y=8A,f3kf=84=B4~=B8=9Des=96=1A8Vw|w=E7G=D8=B6=AE'=17=9F=B6=F5d=BC= *=EB=D5 =0A= =AD=95=E5=FD=9C=A2[=FB=D4=F5=93=B2=3D=BF=1A=ED=EC"#=F8_=B0=FFa|=BEx=EA=3D= =BB=0F=FE=1B=DD=B4=08$7_=C2=13u=BB=DF?m=CA=91=C1K=D7=81=0C=C9c=BDZ$%p=F0= *=EE=83=1C=19 U=F2/L$=EE"w=93ud=3D=B9=87=DCK6=90=FB=C8=FD=E4=01=F2 = =D9H=1E=C2=84=D5=C5=B4=F4a=C8C=01=8AP"=BF=872T=A0=0F=FAa=00=AA=98=EC=DC = w=C1=DD=B0=0E=D6=C3=3Dp/l=80=FB=E0~x=80\=82=07a#=FC=00~H>=84=1F=C1=8F=E1= <=FC=04.=C0=DB=F0Sx=07=DE=85=F7=E0}=F8=19=F9=04>=80=8B=F0!|=04=1F=C3'=F0= s=F8=05\=82=CB=F0K=F8=15=FC=BA=94D=FC=0C=DE=AB4=A8=B06^=9B,=D2=9C=06E=95= x-=DD=A2=BA=8Fb=93=E4j=1E/=F3V=C9=13QS&=A8=92=1B=0F=E2=16u=F62M=B3=FBZ=BC= p V<=10Qv=BA=C5s=07i=18=D2=EC=01M=9D = =A1i=1E=EF]Mk=B9I=1A=C74=FF,=0D=1B>=CD=1CN2=CF%=85=A9=90{RD=99i=9E;b=94=B2= 3-=91=9B=E5M=1C}=84&=85=A3=A9=CD=BC2-=B5=CC = =9E=9DV=DC9=89=8A%=93@0L8X?=DE=E41=8B|=EE=99=DC*G-=AA=86=B1=E5!=12=9F=05= =9A=16X=07[=8C-M=8B=0D=FB=1D=8E=D8=1Cl=AA=E5=E6-=B2 = E=16%=05=91=C2=CAY=E0Y=89=98,=82=ACFLI=07=93=08Y=13=83=B2$=D3=E6Ylv=CE=A2= zA=F1=90=1B$=AA%=A4=AE`=8A=E0i=CC2=1A=16=1B=A7=AA=A2D=C0=FD8=A0=1E=93=F9= =94=F4=E1=A4j=1E%=D4(=16=D5<=0B=98=16Q_=C0=E6tW=E8=B7=19gW=CA=AB=D8=8C=CB= !H=A5=F2=ECtB=83Z=D1o=A01=CCwJ=02=17S=F3=C0g%=1Ei=D6=94=D8=D9=E3=EA=8EJ=C2= =9Ay=D5=8B=9D=EC=A9=D6e=EAy=DC=08"=AA=A5=A4^6c=A4b=A8=B1=CC=D6=B3B=D6=F0= =A9;=98q=D5=CC=AB=9E=06=142_=9D=96=05=E3=DB=17=BA=D8Y=B9Z.=96=9D=F034`=91=C7*V=DD=CC=08k=F7Y=1E=97=85=9Fe=ED=01=0F%N=9B=B8=8Dt"#\=1C= =CC=80=8B=13=B8^=F3(=17g:Le=81q=0C]K=AA=D4=80=C7=A5=17=B00 = 4=8F=83=C5r*=C6A=A2=8A,=8C=F5=A2b=BA=AF7S=88$g'r=C0@=C3=B6=C4=BC=98=1E=C0= m=1B=B0vW,a=C6=AA=92=86=19=DA=D5=B3BW=CB=08=05\=F5=10=8F\=19u;l=8EF=CD=80= =15qI}=8Eb=BFdMsr=D1=A2=E4s=03^=B7DIE=04=EFc*.=E7=ADX=C0=F51G=B9=1C=88&&= =E7=01=AEa=A9=C3=0A= =99N=11n%=B3=0E=3D=C1,E=B9+$q=7F=97=B5>zZfMJ=16=97=D1=CF=F9|n=CEw0=DFf9=1E= =D2&=AF=C4X=8AD=A6K=C7=CBg7=98C=A2;=A2i=FC=AAEK=D1%}=3D=FAk=94=9B=D6=97=A3=AB= =D1=8D=C8=99=3Dr=0D.=FF=A9=FAbJN"9=F5=E7=EA=CB{=EF=1C<=96=B6<3a=C9Q#=8D=AD= =AF=8E=B1i=F66=BB=D1t^=1B=FD=BCJ=EAw=D43=8Fo=B7=0A= =DBG-=99H=C9=A1=94=1C=DFa=C9=8E=D4=D4=11l<5V=AD=CE=8D^=1E=9CD=0F{=FDu=83= ~=AA=F8TJv=A6=E4=89=94<=B9=CB=92=3D=BB-=D9=95=92=DD=A6o=ECd5C6=0D=E6=F09= =97=87=BC=B3i=B0R=1E=18,=C3=C0`=16=B6=0D=8E=C09=C8T=F1*=9F=C2k=F2=94s=0E= >=83=AB=CEM(U=A1=EA=0C:#x{?=EDLa=C7=05=E7=8A=F3=19=FC=03nB=7F=F51=D8p1=A2= =07=1E=BD=02=D7=E0=E6=9B=E7'gO\]=DA=F8=C2=E4=F3'=FE8=BA=B4?=A5=D7-=FD=94= =8C=02=E9qc=3D=AE=A3u=1A[=94=D2=C9V=FC=D9=D7=EA=9F=DA=AAH=97=D5=89N=F0=F5= o=CA1s=EB=0Dendstream=0Dendobj=0D75 0 obj=0D4335 =0Dendobj=0D77 0 = obj=0D7798 =0Dendobj=0D79 0 obj=0D<< /Filter /FlateDecode /Length 80 0 = R /Length1 82 0 R >> =0Dstream H=89=ECViTTG=1A=BD=F5^=BF=D7=DDB=D3=D0,-=B6 = =0D=8A=1B=8A=80=E0=02=06$=02=82=88=D0n(=DD=0A= Q=C1=A8=EC=B8"=02"=1A5=EEK=94=98=C4=B8k=8CQ=83=BB1=1A=8D=8A=84=184&. = =C1=99=8C=B38=1EO=0E=A3b=B0{=BE=D7=0D&x=E6=CC=9C3=BF=E6=C7=BC=EA=DB=B7=BE= =AA=AF=EA=D5=AD=E5}=05=06@=85=12=F0H=1C5=DA?p=C1/Y=1A*=A9#$L=C9L=CB9=9B=F4= l=00=C0z=01\=CB=949=05^iK=0Ew=05d=BET=A6I=CF=C9=C8=EC=9Bt=8D=07=84=81=E4= =EF=911k~=FA=DD=C8=F9Md=8F%=FF=90=E9=D3=D2=A6V/=7Fc4 = _I=F5!=D3=A9@=BF=FE=CF=E4+=BF@v=D7=E9=99=05=F3Nf=FC=A9=86=EC=9F=01~=E1=AC= =EC)i=D9=89=D9y=80]=1A=F5=7F53m^=0E{=CA=AAh=80=3D=C9=DF++-s=DA=A8=9B=B5c= =C8=8E=05=14=DE9=D9=F9=05=C1=BE=F3=A2=01=D7=99=E4=FF('oZN=97=D8=13=D4=B7= v<=D9I4N=B0=B5=10=A0=10*=84 = *=E9fc~;=D29R)P=3D=0D=FE_<=E3=0D=B1^=88x=E2=F5=C4"=EA=CDz=C0=F9=82=D7i*=E6= =C0=AC=D5.=B6f=AC=13ADk!1o=F5i=FFP%/=13D=B9B=D9=C1=CE^=E5=A0vt=D28=BB=B8= =BAi;=BAw=D2u=F6=F0=EC=E2=A5=F7=F6=E9=DA=CD=B7{=8F=9E=BDz=FB=F5=E9=EB=DF= / = 0=A8=7Fp=C8=80=81=83=06=87=86=0Dy#=B1X,=F4=EF%=FD= =93-#=E6=A9F=80=089=14P=A2=03=EC`O{=CE=01j8=C2 = =1A8=D3=8C=BA=C2=0DZt=84;:A=87=CE=F0=80'=BA=C0=0Bzx=C3=07]=D1=0D=BE=E8=8E= =1E=E8=89^=E8=0D?=F4A_=F8=A3=1F=02=10=88 = =F4G0B0=00=031=08=83=11=8A0=0C=C1=1B=08G=04=86"=12ob=18=A2=10=8D=18=0CG,= =E20=02=F1=18=89=04=8CB"=92`=C0h=8C=C1X=8C=C3x$c=02&"=05F=980 = =93=91=8A4=BC=85)=98=8AiHG=06=A6=E3m=CC=C0L=CCB&=B2=90=8D=1C=E4"=0F=F9(=C0= l=CC=C1\=CC=C3|,@!=16=A2=08=8BPL=E7=AA=14=8BQ=86%(=C7R,=C3;X=8E=15X=89w=B1= =0A= =AB=B1=06k=B1=0E=EB=B1=01=1B=B1 = =9B=F1=1E=B6`+*=F0>=B6=E1=03|=88=8F=B0=1D=1Fc=07vb=17vc=0F=F6b=1F=F6=E3=00= >=C1A|=8AC=F8=0C=87q=04G=F19*q=0C=C7q=02'q=0A= =A7q=06g=F1=05=CE=E1K=9C=C7=05|=85=8B=B8=84=AFq=19Wp=15U=B8=86j|=83=1A|=8B= =EB=F8=0E=B5=B8=81=9B=F8=1E=B7=F0=03~=C4m=DC=C1]=DC=A3=F3_=8F=FBh=C0Oh=84= =B4=B6=90=15[=EE=C9v=F1e=96F~=87=B9=DE|KP=C8=1E=CB=AEs=CFE=9D=EA=A9=F3ps= =A5s=11=97=8E=04=01=E6r=F1N=CBA=C5=F2=17-=1D=F4=CDS=05=C8=BB=B5~#=0C=C9Q=C3= tz=FD=84>=F4=11(=A1c_"=EAi=EB=CB=A1=8B=B0=97A=CE=04~=9CR=86q=0A= Gs=3D=FD=E0_=EF_=1F=D0/=C8I=EF=D4M=EF=A4/=E1=F1=B2=84=A3Q=89=FA=E6=86=12= =81=BE9=8C=95=99=CB=F9\=01t=10=B6E=CC=EF!=F4Pq=0E=9C=83=CA=93=F3T=F9q~=AA= 0.T=15=CB=C5=AA=AA=C5=CB=9A=CB=9Do=8B=B5N=B5=1E=7F=15=1B=9D=1A=3DZ=B8fe=8B= =CA=ED=B9=C8=06=AAbU=19=1Es=3D=CA=3D=F6x=88Zy=8AbI=9Cg=16\=1D=B3=D4.[=B5= =07=B4=A7=B5U=DA;=DA=BFi=9B=B5r=ADN=EEx=8C=8E=AB=CB^=DD = =1D=A7K=91=DB)=F9=9E<=C7'uq4=E7=86]zi=0A= =AB=CB=0Ds=D2=0C2!=FCe=F8=DF=E7=84w|9(=A0=1F=CB5=99X=1E=F3=F6=0Dv=EA=EF=DB= =3D8$=848d=80=AB=B7=E8=EA=E4"=CA=DD=DC=88=DC=82=F8=DC=9D[=0D=A9=E3=8C=1B= =F7e=97&ED=8EZ:=C3\=BEx!+=0DOR=8CT=C6=0Cg=A5E=8B=F8=E81=93=CC=85=91=A9=9E= =DE=93=86=9A=0BMcI=BB=91=B4=C7Y=B5o=8A(=B8=C8n=B0=07=EC=91=F2=91=EB3&=0A= =8CWw=EC=E8=CB|=D5=03=84=10=F7h!=C6=FD=94=F2=94=AB=1D'p=EE=1AA=E3=EE#=F8= =B8=07=0A= =81=EEQB=94=FB=1Ev=9C=D5)=EB\=9BX=93=D0=E4=FE=CCC=B3_}J]=A5=BE=A3~=A1=16= =D4H=F1\=12=A7=C8=92=BB=BAei]=D4v=D0=CA5v)=9E:=91=F7=95d{=D9d=87=D5I=A2=DB= 4=93h=13=A96=91n&ZE=FA=B4=89=F6m=9D=83@=ABh-=1F=17=3Dk=D7=96=D2=EC=A8=F8= =B8=98=82=85K=8F=A7%=B1m=DC=C8Xs=F1=B2=B9=D1=BCq4+=1F=92=D2=B3=EB[=83Y=F9= =D8 = =B2=E8=FC=95=E6=E2=98x=C1=1AG=08g=A6=F4=10'=AB=C3=FE=01w=855=82|=FA=F4=EC= n=89=0Fo=8E=DDo.j=88V=1B=9C=A5=F0=A9l=0D5L=0A= O=0D=14=04=1D4=E6=A2=172=B5=E1U}=957=93=A6= u=D4=E7$=18m=FB=C4:=8E=F4V=0C=97=98=02=04=DAl=C9_=A8=86=81=C6=FF;=DD=ADh= =EDG=B9=0B=06=07=0DiJ=80=C1=FE=101i=94=C6=D9=C6=C2c=04(O"=A0=8D=A9=ED=D3= V=DC=A11=84=DA=80GB=03=9D=9DZ=BA=B2=9E=B7=EE=FDJ<$=FCL=A1)_=02=85=16=D0=05= =E6=BFI=DBm=89=E9=FE=9F=FE=17=92=F5=AB=FA=07=BA=18R(=A7=FF,=BEJ=DB=9B=A8=A2=F0=9B=85>m=A9=04=95=A5a=CBeoil).HUJ=05=04=04,=B6= =EC4=C04=996#I&=CELl=0B=A8(`"=8A=E2=BEKE=DCp=AB=B8=D5}=DFp=C3}W=D4=0F~=D4= =7F=80=EF=DC=99@)}=9E=AA_L=9E=E4=9E{=CFz=CF=BDg=E6=BC=9C=DB=DCR=CF=A4#=CF= =DEm=C8=E3=02=0F=9B=DCm.=ED=A5=EE=CD.=ED=E3=FA].=ED'=FD=A8K=0F`s=FC=92K=17= p=FD=3D=97.$=FD=8DK=17=D1=F7=1F.]=EC=F1x&=BB=F4@=0C=F3=96=B9t = =E9=996P=F1=171=88B=EFR=97=F6@=F8=9A\=DA=8BA=BE=CD.=ED=E3=FA=0E=97=F6=93= =DE=E7=D2=03P=EA;=E0=D2=05\=FF=CD=A5=0B!=FC^=97.=C2=16=FF8=97.=F6z=FD{\z= = =C2=05{]=BA=84=F4=C1=C5=8A=15=9F=B6XO=E9"=A6=9AZkJ=8D=89=E6=0EQ=97=8A=19= =AA=10=0B3=1BS=9Ab=A8=1B=C2=A2M=B3=E2b=9E=92P=D2J=ABn=8A9RX=CC3=F4LZ(=A9= =98h=B4=D4t\M=89=15z=A2=C5P=92=95b=B6=9E=EE0=B4=D6=B8%=CA=A2=E5=A2z=C6=8C= 3=C2=F6=FFt=91=17=11=0D=AA=A9*F4^yn=FD=FC=BA=B9u=15GBiP[3 = =C5=E8=BD=DC{=BE\5LMO=89=EA=CAiS{=F3z=FBp6=F4=DF=F7s4M=9A)=14=11=CD=98=96= =9E=14-z=CAr=F3fg=AD=B7S=F2=0D=911U=C7=99mBM*=96=16U=C2r=D2=A0*1=D5=08Kw= :y=C6=F1=06=D2=86=1E=CBD-=B3R,=B0l=CF = -=AA=A6L=9E=91=A5=8Bt=86=12=8A=C9$=08=BDEP=9F=8E=F2=F2=8E=D1=A4=D2!R=BA%= =9AUa=A81=CD=B4=0C=AD9cQ=DB=8EG=CFX=B6=92P=DB=D3=86j=9A"=AD=1AI=CD=94 = =A5=B9=E3=CE(nY=E9=9A=AA=AA=B6=B6=B6=CA6=F7=88=A3z=B2=EFUB9=85=00,=CEF=7F= 1!=99=0D=CB=84=04l&=C1Z+=E7*g=820=AE=83=FFu=9C=C7=08=D9T=D2=82=CD|=86p-E= 9E=AEm = =B0=14=84q=9A=B4'=08=18=15=82=05=850O=A1%=9D=16=05=A1=E4Q=CB=B6=84=C1=F5= =0C%=04eR=D2S#=B5U=AE=C4=F9o=CB=AC=A0D=82=F0=D1=A0D=92=B0U=10=90=DA=D0=B1= =83+=9A=04=95=16=D7=CA=083=CB9V=13=C2=CE = =98=0D=1F=A1=A7=CBX=8F=B5"=08_=EC8T=19y=946* t=EB = p=EB=08u=EBP=D1GVl=8DV=C6=9A=90:=FDI=F7=C7_Nk=86=CC=84.wY=CD=08=A6aj=BFz= =FD=ED=A3=E7 = =FD=1F=E7=D3=D7m=D2=A4e=85=BF(m=99=E4=EB2=F6=16)a=F5=BAo=F9=BB=D6=DFN=1D= }=83cF=AE=F7=DCY>=0A= =95=9A6=A5QC=91=BB=CFs=1A=A4=A5=98<=85p=8F=DD=E9=AE=9E=F1=8F"H=CB=FC=C4=18= A=94z=A6=BC=9D=0B=E4=8E=9C=3D'=A4g;O=A6[G=96=CCH=9A=1A=8E=0DEr=0C)=AD=D3= =97p=FD;;=EAm=BFg=A4=F6=CE=EC<=A5d=CCv=D6l=0DC=FA=D1d=96=ED=FAh=A6=AE=E5= =FA=CE=E7G=97kyO=82=BFv=E9=C9=F6jJ=AFvDIi=E5=E8=0Du=A2=EB=BF=8E=ECz=B4h=A3= =06U=FC=B6=C9o%=7F=C7VqT=DE=81=7F#=EB=E05=1Cnb}=F4=F5=F9]v=0B=F6;=D5=CF=B7= n=01{=85B=BEY=8B=F9=16-=C1 = =18=84=00;=80=13q=12N=C6=10=0C=C50=0CG)=82=18=81=91=18=85=D1=18=83=10w3=96= =9D=E3xL=C0DL=C2d>S=CA1=85U=18=C6)=8C=A2=8A=D5Y=CD{}*N=C3=E9|=C2L=C7=99|= =BA=D4=E0,=9C=8Ds0=13=B5=EC*=EAX=BF=B3YCsq=1Ekg>=EF=C2=F9=AC=C2E=BCu=17=B0= =AE=97=E0B=E6=AB=11K=B1=8C=F5=BF=02+=B1=0A= =AB=B1=86]Q=04k=B1=0E=EB=A1x=BC<=B1=A8=BC=97-=F2=D9=A6=E1"=D6m=82=FBO=C9= =A7=DE=C5=F2=AEX<=C1K=98=A7v=DE=80=8D=D8=84=CD=B8=14=97=E1r=E2=D4+p%=B6=B2= c=DA=8E=AB=90E=0EWc=07=AE=C1=B5=D8=89=EBp=3Dv=E1=06=DC=88=9B=D8E=DD=82[q= =1Bn=C7=1D=B8=93}=D4=DD=B8=07=F7b7;=E6=FB=B0=07=F7c/=1E=C0=83x=08=0F=E3=11= =ECco=F5=18=1E=C7=13x=12]x=0A= =FB=F14=9E=C1=B3x=0E=CF=A3=1B/=E0E=F6[/=E3=15=BC=8A=D7=F0:=DE=C0=9Bx=0Bo= =E3=1D=BC=CB=DE=EB}|=80=03=F8=10=1F=E1c|=82Oq=10=9F=E1s|=81/=F1=15=BEf?=F6= -=BE=C3=F7=F8=01?=E2'=FC=8C_p=08=BF=FA=E6=CC]4+=17=D8=E6=199.=18=1A16=18= =0A= =8A`=A84=14=0C=0D=1F=13=0C=0D=1B=1D=0C=0Dm=0F=86=86=8C=0A= =86=A6=90_N~=19=F9=93=C9=9FD=FED=F2'=90?=9E=FC=ED-=87=02-=91=CE@=C0=B3=DB= =F3=A7=C7=17=A8=AA-=E92|EvV=BC=B3=90=1D=9C=15Y=91[=92=DD=92=DB=95=DD=95=EB= =CCv=E6=8Ak=B3=B5=B9=FAl}n=1D=A7]=D9=BF=B2=85=A9H=B7=A7s=7F`k=93=1C69=B3= =8D=CE=D0=E1=0C=AA3D=9D=A1=D9=19=14gX=EF=0C=EB=9C=A1=C9=19=D68Cf=B5=1CV=DB= =B3Y=E3=02l=02=07GDdj=C4=DF=80=88M=F9j:#]=11/o=0F=EF=8Bo=99=A7=DBsx=FB=CE= =85=8D+=BB=3D=18=BD=CA=B4=D6=9A=FCV=1C=FB=91=AB0=CD=8A=E3>=E6=DF=90+=D0=AD= =0Dendstream=0Dendobj=0D80 0 obj=0D3601 =0Dendobj=0D82 0 obj=0D6312 = =0Dendobj=0D84 0 obj=0D<< =0D/Kids [ 5 0 R 48 0 R ] =0D/Count 10 = =0D/Type /Pages =0D/MediaBox [ 0 0 792 612 ] =0D>> =0Dendobj=0D85 0 = obj=0D<< /Filter /FlateDecode /Length 86 0 R >> =0Dstream H=89=ECWko=DB=C8=15=FD=05=FA=0F=FAVy=BBR8/r=D8=07P=AC=D3=B4^$=80=9B=08(=0A= =EFvAS#i6=12i=90=94=15=EF=AF=EF%=E7M=8F=E9=C4I=BF-=12=1B49s=E7>=CE=3D=F7= =CC=0F=EBY2=EF=FF5=BB=19=9A=CB=F9=EC=D5{q(:y/.=EBC=DD=C8=A3=E8=1AY=CE=1B= 9{=F5&=99=A3=F9z;_&=AB=04#=8A=E7=EB=12=F6=AD=CF=FD=AFf>=CBW=19=1B,=0D=0F= =8C=0E=BF1=9B=AF=8F=B3=C5z/=DB=8B=F5=AF3=D8=89=08E=FD=CE=DE=0A= =C1)=ED=0D=CC=D0=8A=D3=14=F5=866=B3=C5=FC\7=1F=DB=BD=10=9D=DE=82I=92=99-= =14=93a=07]1=C2=99=D9=D1=EE=EB=B39=00s=96=DA=D5Y=96=0F=CB=F1*=C7=C4=1E=D0= =ED=85^=9C=B0=9C=9A=C5=98=A1T{=E3=DB=BE=AB=0F=0FU}=94=C5a=D8cV=A3=DCz=92= =A596=AB=8FE=B77=8E$in#=CDa=89r=04=82=C9=CC=EA[=B1=97=D5f=CAq=B2J=C0=FC=C8= =F1=C1"=02=17=FB=0A= =80+8=E6=B7=FCp=F9=E1=CA=AC=A6=9Ca=BD=1A=E7=98kW=FC=E5=97=EF/ = .=CD=FA=84=10=9B=17=C48=D7=BE@=91"yY=99]=98=11}H=92&=CA'=BB=FCJGI=11=E1= =C62,B=C3=AAd=05=86=A9YZ=D5gc=11Bcfu=922e=D3&=BB+>=9AB"=CA=89M6MLB=FC=AA= =CB=AA=ABm=AA1u=A9=A6Y=04=84EY=D6=A7=AA=B3=8E=F0=D4=16=07P=C3tB|=B7o=A5=01= ,xcA=95=A4L[=F7=0B=DF=88=EDA=94=9D=AC+=B3%=CFmZ=A0BHC=CB/=FEO=8BF=DC=8B=A6= =95=D5=CEl=A2=08=DBM=84=A4z=13=818<=A7Z=1B=03=CBl=8E = I<=D6z=B2=03D=9A=9Cf=CC=E54=CDt=F2=03=B8=17z)=19zG-e=94pS=D5=BEI=8C'=0F=9D= =F8=E9=C2=ACG=D4=86=CB=92=CC=B4=86=E7xa=FB=02=0A= =9F=B9=AE=CB=B5=D7=BE=17e}=BC;=88=A3=A8:/7=06=8C=C3=FAe=AA=FD^"=05=E2~_#= =8E=05=B4=9Fh=0C4Yb=E3M)Vu=B3=E5=AD=B7S}=8Ab}=FA"=82=E9=B1=E6a=99=EB=EC=84= 4=B3=91=F7=B2=B5=E0=89e=93=04x=D3=D9T(H,=01=03=9D=A2H>e%;pG=FE=E6=D2=19=0D= :=84=9AGN=10(=D2L@0=E1=91=A0=81n=E2t=8A=83D=9A=00=87=8E=D6=01=12=A2=D1=05= s=81=DB=C3Mk=93=84=D9\=D0\=1FmV=A1ve=C9=19=F9=F0=C0La=D5=87=C7=DA=16=11{= &=07=8C=0C=E1=F8=E0=DE=14=9Dm=85=81=EA=B5=AF9=A2=91=A8Z7=DA8wD=C4=13=93)= =9Fg=BB}=D1M=10l=C8q=86eS=EE=10=C1=B3=0CGX=F6=D4=8A=89=EC=86=80=B0=D9e)=B3= 3-c=1C=C7=B0/=DAn=BAS|=C2q=9DB=88=85%=C3=C4=E8=02=DF=E3=BB=A6.Ek=E7|=86=AC= +4=A5X=A3=DE=07YYW=ADl=BBv=AA=BFIPG=D5=E4=AA=F1=A8=9D=AF=06=9Bh=85=C0=BC= YK=B0=E9=F1,=B7C=0A= =BC2E=F4=E1=B9=11e3"(L=1C3P=A2w=B1 = 9=3De=1A=E7=A1J6\=8C3=03+?=DC=F3^=96=FB = =A8=84=D4}e=D9=C6=E1=95p=CDP!Tv=A2=12M=D1=D9v=E0n=EC=D0L=8F=1D=12=18?=99= )=05k=10=90 = =D5=BEpd=BA=DC=B7=7F|=B0Ht=E2=90=91=94D=88=A3=12g=E3x=EAd!a8=8F=B4=C3=F6= T=F9C=16q=EAB=CD=B4=F6=0C=1D=BF=AA:=B1=83!=BB=AE=AF=81=96=A7=94M=1Am<=0C= =84=E7D=9F=D6 = a6=8BCk=C9=8A'=16=03,=C3Y$=84b=B3=F9~=A2OCb=F1=04N=B4=F3|=F8=BA=CEC = =F5=B4G=86"Y=EF=9A=A2j=8F=B2=EB=C4=C6f=9F=E4=FE|=D5=F3=06=08t=98 = =FD=AE#4k=B1=13=C6=FD=A8=9C = Q9=91=E4=89=03;=D7d=90=04K=EF=8A=A6=93=E5=E9P=98=E9=8D=9C=E8"I=8A#=02J4M= mVG=E72=0E=12=F4h.G=C9=9A=8E=E8=EC=19=B2=F6=17[=CC = =07Kj=F4b=12=E4=FF=A3=A7=89)=B6=CA=1F=13-=A0q02=CE=F2`|&=8C9=84=D1=CC=B8= =E1s^U[=BE=CE=9C=08=A5=99%=BD@=E4N=CF=C4=90=F3:=90=B8=160=86P=15=D6Ss=A5= =08=F9n=1A=BE=BE=A2=F1=D4=06%=EErC=F1=13jc<=F8U=83=12=16=B9=95=B9=C1=8F=88= =D7=CD=98=B1H=11=A1?=A5G1_4c@=8AY=98+-=1FQ=92=B2=9D=00x8=A6=BF=16=E0(K=BC= =0E5=0288=A2=DD=D7=A7=C3f=0A= /$8c_=DC=8B)=00=E0=002Um=BD=C7=8E=92(C=11=00=88=ED=16=E05m=DB=C7=80-=D1=E7= =83kHz=EA=92=CEc=AA=A4=11=ED=E9=F0=8C=C6=F8=8A;=C4=97=C9=E9=BE=86=D4=A7=E5= L=D9=F4um=B9=17=E5G{=E9A=8C=DB=CC=11=96=F0H=0D=EF=EA=E6y=84=FBe|a=98=88p= =D7=0EN=88=FAq=16=87]=DD=C0=1D=F5=B8=8A=DF=1EhPFc8=C9=B9?=AB=90=9BU6)=FF= =A9O=06z=9C=B8=D9=93=D9>=0B=D4~]=FDa=923C>=A9=84#=C1=E8=08=7F=E2"Cm=9Ei=9E= =B2H=EEN=FD=E5=B5=ED=F4=E5.=96=0D_I=F4k^=BDAs=80=D2v=90=B5=04yP = =AES=EFFm=05=CF=1E=E7=99)=8D=F3=94=EB=AF^=8D=C6- = =CF^2=F6#1=10=EE=B5P=F0L{=83=ED=F8=D8=B4W=96I=B7n=C0=AFd!/~^=FF=F8=F4=F1= =E5c=FB=DE=E9=85J`b=13HrdK=CF8E=91=B9=DD>T]=F1i=B2=F8~=89^^=FC'=C7I=88=01= =7F=9CdN=CD=90=CC=0A= =14=9F=EC=CFu=F3=B1=DD=0B=D1=99=E1=99d=C4Jn=9C=A6=FA=00=BF5=DE=8Bb=E3=DD= qb=FDO=02=FA=F4=FA=1F=94=8D=F5=08=D1<=8B=F4=7FY=1F=FB[=94=8B!:=B0=06=05=1A= =1BX=FD"w=89=E2=E6=02=E0=A7=B5=3Dm=B7=B2=14F=F9=BB=CB=8B=E2=0E=CAT>=97LE= 1=C0=D2=C8=96=F8=8D$=0D=C8`t%I=F2=D4S=BA=B9f=1B=1E=94a#=B6=B2=1ADF;=D6=96= =CA)=C2,=CB=1B=F1}=B3X^<=F5?=83=AB=CB=C4=E7=DF=F7=FC=BE=E7[=EC=E9=A9=F6=D5= =1B=AC=E8r=E8=E94=1D=D8`=D67[2=CF=E79=99=93=14=AEu=D0=B7=C7=D9=E2=AA=EA=C4= =0E(m]_=830UdK=D4=EE=19_=C1f=D3C=7FS=DF=B4=E5=9Eq9!=86=E6=0F=B2=ED=D0/=C0= =F5=DF_,)=F4^=B6=B8-Z=11=BE=90]{-=9A=7F=D7=CD=E6=17=ED=A59=07=B1=15!=C6=D8= =E2=F5=F8=A0=1CY'=FE=A4=BE=D1=88=13=8B=BF=86=FB=90=EF=FC=BBzs:=880:=B2b~= hK=9C=AF=92=DE=1A=F4s=DA=EF=EC=BF=F0=E7=82=C6*D=F0~E=86=17d=FC=82=AA=17=B0= =11^@=F0=A0=01G=D1Su=9E=F2=E5/O=9F=08f=82=00=82=08=FF9=91=99=EF=9E=CE=0C= DQ=97p=15=D1=FE=DD=17=8D,n=0F=A2=D5>=1As=B9_=A0=EFB7=82=A3=DE=86G-1W=C1=F9= IUy=0B=DC=05%=CB=E2e=04=0D=E4N=D6`}-wRM#=E7E=E6{=F1=BF=E6^=CB=BF9=14]'=AA=F0|=AAZ=F5=D9j=FBX3{=B1o=FD=8Bj=E8=9D=F9=ADjX=89= =B6=83{=8A=FE=AB=F7VU=D4=15q=0B=F1=07=DF=C3"=A1=DC=87=D6=97=94=89=A4=8F=F9= N=11=D6KZ=F3=BA=D8=BC=15=DB=EEee=BAyL=9D=04=8F=02e=13q=A2=B0*=D1j=A2q=C5= <=E7=FF8=11=D8=BFNu'A=FD=8E#=9B=A2=1B=8F=CF=DF=8Aj=D7=ED''=CF=04t=C9=CB=A0= {=13=C9=A3=B3=91x=EB^C=CE=DF=C2=CF=EBP8=F4W=12=F6=AD=DB=00=DB[=E1]=B11,t= =96=DD=DE=C0=FB7=D1=D40z=CC=AC=B4=EC=D5=DFVL=07=F4=18=D3=CFm=ADze_=DC=0B= c=EEx:t=F2=EE`=D7=D7[=F3=F4=08P0=EF=F9=CB=86Z=9A=3D&85=D9_Bp_=87=10=FA5=E4= =B6DC=9D!=8E=E1K=FF=FE=C3=E98=AE=B7=97=A5)o=AE=8B=A6=1B;C>k=EB=8D/=94=14= l=E5=08=B5tE=1F=C5=E5P=97=B18=E6=DC=97=9B=C5=A7=8B%=1A = =F2=DF=F1P=F7MO1H=B4=C4=1E)-=9F:=1C=A2=F9lpM = =BE=006=93=D2T=FAz=06]=0C=0D`=FF=8E=89P=E6=99=BE=01=11j=18a=895=D3=F9X=7F= a=D7=EB=DE|=18=E9=17o=F2=E9=1E=16=C7[pP=7F=F1 = =A2=B8=BBk=EA;=90=A8=9D0=BA=E5=AE>=BB=B5=AE=DB?9=0D=B4Q,Q=94=E5 = <=18=B6j=FE=00=A8/=87=A7=959=BA=1Fa=C7=BA=ED=9C^WYH=1E=A9=D8=9B=C5V6=C6=E7= T=E9*=B5G=B6=01o=E9=98j3=D9[=B9=AB=E4V=96Eew=94=B5=D8=C2=9Ba=CA=04nk+=A7= vDor`=C9^&8f=DC=CB=DD^8=87=9E=CC=CBh=AA=FA=E3=E0y=12\2=DD=88>=1Ct;"=B5=AB= =BFr=E6 = UWN=D5=02p=EB=EC=1F=E0,=F8=95=11s=F5\=83=BB=B2=DA]=BE=BF$=B8|-=CAF=1C!=03= =F0=E6=87=87N\=F7=AA=AF=A9V=D5=AD=B2=9EX=EB=84S6XO=C1j=9Ac=7F=BE=FF}=3DK= =86=03=DF=FFC=F5=DFy=8E=92=F9;=D8=FB+=FC=FC8=BF=F99=99o=E0=B2@=F8=E0=10=04= p=9C)=B7=E0=F10=FB`=FEH=07=D8=0E=DE=F7=BF=1A1=DB=CE=FE'=C0=00=F7=89T=CB=0D= endstream=0Dendobj=0D86 0 obj=0D2621 =0Dendobj=0D87 0 obj=0D<< /Filter = /FlateDecode /Length 88 0 R >> =0Dstream H=89=ACWmo=A3F=10=FE=05=FC=07t=9F=F0=B5p=BB,/&m=A5=EA=92=F6=AE=A7DJS=A4~= =B0N'b=D6=0E'=1B,=C0=97K=7F}=87]=96}=C1=10':Y=B6=D6=B0/=CF=CC<3=F3=EC=FB= =D4Bv=F7=A9=B7=16=B6=0B=DBzwGwY[|=A3=97=D5=AE=AA=8B=3Dm=EBbm=D7=85=F5=EE= O=DF=C6v=BA=B1]=E4!=1CE=91=9D=AEa]=FA=D8=FD=D4=B6=95=B0m=12;!v=E8=87^=1C= =DA=E9=DEZ9=7F=95-=DD=D2=BAI=AB=DBj=F7=B4@=CE=C5=05=FC=1C=9BlK=17=9F=D3O= =B0m=C0=B7=B5=B0=EF=85=DD^=B9=E5=FC=B6H=BF=CA=03-=E4%8=8A=F9=BB=95=F3=06= =D6=A7=0FE=B3p=C3%=F1=88=B39=96=EB=B6=A8J=F8=8F=90=B3=AE=CAo=B4n=87=B7=99= =18=EC=8A=A6=15=E3j#FE=0F=CF=C0=E2=0B$=AE=8E=04{`=F9=80d_=C9-=9Bb[=16=9B= b=9D=95-=DB=CB%=B1=B7$=84=D8.=F6=A2n=0D[=C1P=B2=F9=ED=03=1D=90=D1Mk=9C=1F= =9Fs<`=AF=143=E1=14/v=0E=E0=E5=B2=DA=17=D9N=BCz,=DA=07=F1=F6=BE(=B3=FAI=BC= YWt=03=90=0BZ=82=BF=90=E31=C7=0E=B0=F4=B95=3D=D4=B4=81=99Y=EFk=C3=91=9D=3D= =CC=EE%=C7=A8=99=AD=FA=BE=0B\=0F5=CBs=9A=F3=7FQ=0F=93=CFA2w=14= =9Anc=94=84=BE=F6Op^=8D=A0=CC8=19=C2=E4U=0C=C7=EA=99/ = =B7=9E=83=8F=83=1A=8A=9F=EB=F0P=88=B5f?=A5Bq=A2=92=F2%q"=C1=E9=1A=E5=BF=AA= F=DDf=F9=F5(a=CE=8D=D4=AA=A7=88R=85=89o=18=1A=AA=9D=C2=B0=13=9F=91=CE=D8= =0C=9A=02=FE=A7=19=C3=FE>V-KY=C3=B2p=C62=19s=E7=9A=96[=C8=BC=B9=9E=F6=E3= =D9=BB:=E1G=B9=07R=E6]=81=CF=AF=E1{eh=0E,=BB=8AY=EBa[qi=1A=A4=E6=8B=CA=BD= ,I = =D5D:=A85=F3?ZW=B4=19=D3=7F=B8%=B0<=10=0F=07MV=D2=0C=84=E4p=DD=98=93X=06= =B7=08>=01=F8=CC$=1A=E5=0Fye=FE=D4-=13=9B=FA=E1=A1\=FDl=FE=F8=13B=CE=D42= H=AD=18c=16M=15@%=FD^=DD=DD=B7=B4=A4u=D6=CA=E06=C7=FB=0Ezc6=C47=0BW=94=C1= =C1=0C=D4=3DU=AE=83z=0C=FD=E0=15=E1=0Bz=AD=AC=C6=F0&;=98=A6=9F=A7=B0@=A4= =A4=D5=15]=8F=D5=A5=1E=80=A5=17=CA=F4=03A=8B=C0=9FFQWu=D8=ACC=BB=9Bf=0D=F7= '=E1AU=FFt=B7=9CS=F2)+s)I=F4[=ADL=A6=9C=AE=8B=BD=B8=E8=E5=C5v=ECp=B0o=BA= "=8F=BD=EE=061=AF^=AA=AF{=F6=E1^=EB=80|IP=D0=C9=17+=E1NG6=1B=84>=F8,=8CI= 7N=F7=96=93B=9E=17=E5=F6=F2=EE=92=F8kpyM=F7P=A2=E1=C9=FB=A7=96=DEf-8=A5=F4= =CA{=BE;=1Av'=CB = d=BBG=B0k=94=F8=3D>=D6=F1=FEH-=C4=0E=BC=FB=00=E8=E1=9CG=1B#=FB=06=D6~=85= =EF'{=F5=19=D9=B9m=C5=84 = =EE=10=0C=D8[=1C=16=0Cw=D6?=E2O=C42=96=A1=EF~jjm=AC=FF=05=18=00.=05=B2=F4= =0Dendstream=0Dendobj=0D88 0 obj=0D1312 =0Dendobj=0D101 0 obj=0D<< = /Filter /FlateDecode /Length 102 0 R >> =0Dstream H=89=CCWmo=DB6=10=FE=05=FA=0FB?=D9]=A5=EA]v=D6=0D]=92u]=91=00Yf`=1F=8C=AE= =A0%=DAa'K=86$7=F1~=FD=8E=A4DQ=94=AC=C4J=BB=ADE=12=8B2=8F=C7=E7=B9{=EE=EE= |=A1Y:=FD=9Fo4['=BA=F6=FA=16'=A8$_=F0E=96d9=D9=E22'=91=9E=13=ED=F5;G=B7=F5= =C5Z7,=D3=B2=83 = =D0=17=11=EC[=DC=D3_=B9=AE=CD=99=99=B9>wu=DF=F1=CD=D0=D7=17[m9=B9=C9=92=C3= "=FB5-=F1=06=E7=C5=D4=9A=9C=9D=C1=AF}=816x=FAq=F1=01=CCz=DC=ACf;t=13=18=8B= =B5=C9=0F=D3=C5=E7=E6D=CD6=E1=C0=90=BF[N^=80=81M=9E=EDw=C5=D4=F0-kR=DE=E1= =A9=01=0E=99=E1dER=94=1F=F8S0=D9=C1=D9=F0=95=99k=BA=93(=C3=EB5=89=08N=CB= =A2^#)7 = =8C=B1=D5l=AD8=E6=CC=A5=E3'o=DA=AEYf=D0=BC[=91=B2=B8=C1=F9=1FY=1E=F3o=D5= &=02=D3=B3=C5=B7~=1C=BA=1CJ=E3=DA=91=98=14=BB=04=1D=AA[2g=F9:=8E=C8=16%=F5= =E3=8B=CA=DD=A0=B2g=F8=B6=E9=C2?=DDp=F8=A9=CCn=FB=8E=0C2=FE=B1=86=8C?=0D@= =D6=F2=E1=08da=0D=D9=CC=F4=DBx=05=02/=D8=E2=1E=C3+=1C=C0+=18=C0=0B|=93=D0= j=C8m=E1=C5]=ACa7=DC=80S=070=CD(\=F4=A8=1C=7F=81(=C5=E7=87=12=9F=83o=FC`= =B7=DA1k=E2=F3=ED@=10P=08=EDO=ED=AD=AE=80=E3R=DD=C9=CE=E6=EF=CE=DAA=D3=82= J=C9=08=C3v+=EFm=FE-=FA=9D=EB,=DE'=F8=D8=C9=CCg=C3=A5;=D8N=BA6;=EE=CDr=92= =90=A2=B4!=D7^M=0DX=05 = =E9=82=C3=178=B2t=C1U=17+i=1E=AB=0EH=0C<=EE@E=06d=80=D7= =14=02=D7Q|=9A=F5$=B3=D7=87=C9w=03x=D9=8F=A7PcS=08=D1K=D5=A2x=E3:=AArHb=FE= =AF(N=1D&=A0=88H=B4ueV=7FJ=F1=83=10=A1;=B2=B9=A3Z=C3Eh=BBOJ=B2K=B0=D4`U=9F= =04=F4B=86=E62=86=A7=C8=90=EF=8B=16=A2=1D=ED=FD=89+=E5Q=A7=3D=17=F9=F0=BC= =DC=F5=D4=DC=95n=F6=A4=DC=ED=B4D=BC=FF=18=97=BDyIJ=92=A5m=9F=FCf=F7=A3=C9= =E3=C9=CD=D3=EC=7FU=FF68=C59*=B1h=97=8B=FD=8A=BA\t#n=D6L=0A= =A5=DA=B4=D8=AD=B08=A9=06=F6=0A= m0=AA=02^=A3=9D=8A=D1=D3=FA=94=BAt*=3D=AE=AFP=15=9ETC=BE6U=D5LRK=03c=A1=1A= wi=AF=D2=CC9=18Ew|=16=AA=C8=EC*=C5=C8=16=D3=0Dyf=A8t=85=A3=E8z=97=A0=B2=C4= J^=9D=D4=B0=04=CF=A9=F1=F2=9D=BB=95=F4Ta_=A1=E8=AF=AE=B2=17$=DD4=EA-7=9B= ,=AF=80=A2=A8=E9=B3{r=AE=BC=C3=CD=F4Z=90=1C=C75=FD=B4=B5Vxu=1D=19=BBSx=F5= =C2=FE=0A= 0=FB=0F=1A=D1=05=1D=8A=06x=1DT=DB=87=A9=C1=C0=FA=B3=FAKz=FA=A6=96=B5=CE=E0= +[#=CA=E8b=A9=02=D1=9E2=9B N=BA=8E1=AE=D1Y=C2tjA=0C=D3=1Fn=BD = :=A1i=DFDf=A2=1CC=3D=E8=0BY)=18=0B=F2wOO=C2k=1D=0B=EBf=91=A4`q=0B=E1=0D=A9= =D0=04/=CCS=3D=E1=FE=A0F=B4;=B6=A7 = =FC~=A5=9A=8F=EA=01z5=AE=9Bk=DD=DEsY=A5=91=05\)e=FFyrS5=86=87=1En=CA=FBL= &=A4=E8=AA=92=A0=18=88B}LGYZ"=922=C6=AA=CD8=DF>Q=9F=F8c=8F>y=DE=E8=0Eu=CE= CTf=F3=A7=1D=BD=FEH=9D=B8I=F6=85=9A=CCs=85=A1=A0=95=16=97S=C3=F1-=A0K=A9= =A5r=F76=98W(=8E=FB=C8=AAp=05&=1A~6=B8=9Ds=BC=C8=F7 = j=87=A6=FFT8=0D=B7=12i=83=05}O=894=AAM=86#P=16]=C7=F9=A1=C4=E7=B4=E3=B0L= {rv=06=D8=ED=0B=B4=C1=AA?=AD=AC=18=A8=11=CB=C9=0B0Q=E6(-=D6=99@=00b=D1=A6= = =D3=9B=A6=D9=96=A0=A4=1Bq(=87=C6'G=F9=A1=89=BBM=8E=AB`&i=03=A2=08=EC=14=DF= O=8DP1=CBu=88=F6M=EC=0A= p=AE=D2=86.e=96=B2<=A63=99=EA=8BR=BB=99=03J=13=C6=F9=CC=B3=FDn=A0=A1n%W=05= x=0C=F8=98=DC=E8=E2=8E=88=B7wH4}+=8C=C5i=11J=92=A67=00=84=1Ak=EB=04Gl|=81= g=0F`=E7=8C=055=E7=AC=9C=00=E3,=8C=F9=BDeVj(m[=C4`=0F3=94=BB=A3=BCTU=E0=18= 3=8D\=08=C3`=8E1#=E5=00=F5=DA=16"P=8Fu=CB'2S=B9=C0M=7F-f=D8Z=C5=0D=98e=CC= T=03R=0F3bt=EAa=A6]=E0=8D=AA=8E=03)!=CF=D3=15I=17=D9{=FC=A0vT=CD=083=D8Q= =91=94=CA=DB=A7=81~=AC=D3+K:}6P=A0=94=0C7l=AB=AB=D3=D7Y=BCW=1B:=D7=14=85= =EC-=A09=EB=B48=8Dp2i=B6=07t=FE=CD=C0=CD_1=E1;=D2=DC=DA=E3=86=96<=DB^=92= =0D=95=C2=96O=BE=8C=D9`=ED=E1t=C8=D5=C7Q*=8F=7F=8C=96o=3DbB=96=E2|=97=E3= =BE=96O=EE=0FP=15=F31=07=A2+=D2B=A3H*IB=BA=DF=AE = [=DB5=C3=99=8D=1BX|Y=08&=E7=A8=C0=EF@=B3=D4 =17=BD=F2 = %<=1C$F=EC=A0=9F=92=AF=D0=07=C4=A4=D8%=E8=D0=D4=8B=0A= )=B8@=8D=938]X=B7O=9A=EC=C0C=A5=9A=D5=A1d=F3=3D=96i=D9s=CB=D3=17=11=9DV=18= F=96=CE>=F8=0E=00=EB=87.=93=9E-Lc=B8=A0=8D=FB=C5=ED=85=EBD=97=B8i=E5iCp=83= J=88=97=D4LW=DC=BA%=AC=BB3=CFg=D6=03=B0=1A=CC=9D=CA;=97~=EF=E7=85f=B1=03= o=7F=E1=9D=F2=BDn[=FA5=EC=FD=0C?=1F=F4=E5GK=8Fu-tg=CC!=B8=C0V=E3n=C1=C7D= =FB=BD~=08X=C22=EF=E9=AF=1Ckk=ED=1F=01=06=00x=FB=A2i=0Dendstream=0Dendob= j=0D102 0 obj=0D1852 =0Dendobj=0D103 0 obj=0D<< /Filter /FlateDecode = /Length 104 0 R >> =0Dstream H=89=C4W=DBn=DB8=10=FD=02=FD=03=D1'9=88TJ=94d;=AD=81"=C9f=8B"=01=8A=AC=DE= T=A3Pd=DAf!K=06%=E7=82=C5=FE=FB=0E=87=BA=C7vR4h=11D7=923=E7=9C=19=CE=D0=E7= =A1A=89=FA=93+=C3!=82=18=EFoy=1A=97=E2=9E_=E4i.=C5=86=97R$D=0A= =E3=FD=95K=1C=12.=89Em=EA=04A@=C2=04=D6=85=0F=EA"=891E3S2e=F6=D8'=BE=EB=AB= [=B81"=F3Nda=FE=99?=8E=A8yv=06=97]=11=AF=F8h=1E~=01=9B=9E=B6iLm=D7W=86=16= =869=1B=85?Zo=86c=83=B3=B1=1E=8B=CCw#k=C2l=D6=DA=B4|J=CD=85(=B6i=FCT=C0=1B= =8E=8A=AC~Z=E3=14=FD=B1l=C6c=B9=DAmxV=0E@=B8=AE=C2=ACQX=C7P=C4=B5=A1T=14= =A5=86=90/G=16=88b=8F=01=1A8=A2=A6]=CFyWy = *S=16=F3l=CF=01c=96=AB=EFh=B2C=08W=FD=04%=F0> 4n =D1 = c}J=C1=AB(=E1=B3"=E5WzW=A4=B4=83Z=16=CBe=DA=0A= p=01G=0C=FD =95K=9Ehw=AC=9A=EA=D9A=E3=CE=FC=D4W=97=DA~=0BSd=0A= =C2=F7=E1=EA=0E=91=CB=E1jt=AD=C7=CE=F4=98=B7=CF=F2 = =B3,=87V=E0=1D=3DK=CD=B9=C9=17=BB=94=F7=9D3=DB=AFe=FA=04"L=06"t=85D=F9=9C= =FEr=D7=9E:=CD=F8=C7#=CCO=D5=985=D6B=01(=BC=0F=8Cz=0D=A6C=1B=86v=DD]=C9|= s)V*z=3DL~W=B3#=D1=88=AAp=00=ED=D3=91=05K = =17=DC=8A=7Fc=EBPX:=D4>=F4=DD;=DDp~>=12=B2=93c=DBPd%=97[=C9=9B|-=D7|_=1A= =C7E]&V=9D"=D0&w=DCn=DD,=96O=F5=E7l=B7=B9=E3rX#&}dl=1F=EA=EBA=A2yc=C8=A0= n@=CF=E3=82_=E5r3L=F2=A6=FC=1C=0D=89N=87ND=1C=BA?$=11=C4=C4r}=0A= =12=F7Y8=BA=F2=BCB=E3=AA=0Ei=01U=11=AA=94=02=02=B5N=8D=F7=C6z/=BC/=0A= =05=08U2w=F5=19=A4=12=B4=1C_=95=98z]=E4|=B9,=B0=05G=EA=DD=F9>=1FA{0=C9=D9=0C1=B5P=D0=E6C=B3=87= =C2k=12=9ED=E0=9C=0E=FE=91=17=C1=C5=CF=B1=B0=AEpD7=9DH=E1=7F=EE=C7=AA=E6= ZN'=A4=BF=E0=0E=16=FF=8B=15=E4T]]=BC2=BCz=FF=9Dj=CE=DF`=D3=9ADUS=B0=9C=E6= d=04<=DC=C7R=C4w)W=81"'=DFF=07t=E9=E0=F5=DF=02,b=9Da|D" = =AF=E1=83=8E=D1=E9=E3=FCC=171=7F,e=9C`&=91=A4]=80=EF=90k=0D%=B5=F8=D5$=DE= JtT{v=CB=EF=B9,x=84=AC=FA=E8=A5=1EB=B4E=0E=1F=D6b=B5=86=06=A4=C0=CB=85~@= V8#=96H%=CF`b=CA=97%=AE=12=0B=FEGx=B1=D9=D7xq=0D("=9DS=CC=EDS=DB=C6=8B=C3= A=D9C=13=FA=FA=06'=085a#=8ABd=AB?=C2=CC=03f=B2=14=A5=C8=B3H=EF=14oH=AD=1A= =D6xU8V2=DFm[~=DE=EF=DD/7=F16=AA=7FM=E8m=3D=EF=E2M=F2=0C=D2L=CB=CF=E3d=AD= =EE=08=B8=8F=B7=C4=04=C4=1Fm=C4=FE=BD=CA=9Bd=AE+=B9Su=01U=FF=A9=A7&=0F=EB= =BF=0B=92=F9cV=FD=D44C^=94=90(=17=B7=17=CCM=A0=E1I=AE=9A=16|9=7F*=F9=D7=B8= =84=B4=CA=EC=ECN[=A7=8Du6=F1|=B4=1E=80=D5`=EAV0<5=EF=AF=D0=A0=E8=F0=F6o8= =BA=80=9F=07=E2Pr=03k=7F=C0=FF=17=12=CD)Y=10c=CC&=08=088l=0C=0D=0B=1ES=E3= =9F=FA%=C0=C3=08=A2W=17=C9=8D=A5=F1=BF=00=03=00j=E1=A7=9A=0Dendstream=0De= ndobj=0D104 0 obj=0D1117 =0Dendobj=0D105 0 obj=0D<< /Filter = /FlateDecode /Length 106 0 R >> =0Dstream H=89=ECW=DBn=9CF=18~=02=DE=01=F5=8AM=02=993=90=A4U=1B=BB9)Q"g=A5^Xi=85wg= m=12=0C=16=E0=D8=EE=D3w=0E=0C=0C=B0=C6=D8=A1wQS/=BB=FC=E7=FF=FBO/=D7=0Ep= =E5=7F=E5=A9=03=DD=D4u=9E=1E=F1,=A9=D3=EF=FC=A0=C8=8A2=3D=E7u=99n=DC2u=9E= =BEB.t=D7;=D7=07=01=80=8C1w=BD=11|=EB+=F9=A7t=9DX=89=89=DD=18=07!u)=A2=F2= c}=EE=1C{=17EvsP=F0=DD=AEZ=17o=F8=F5=0A= =04=D0{=F6l=05=BC=CB*9=E5=AB/=EBwB8=D1=C2=1D=88=03=10a,=85n=1D=EF=D7=D5=FA= k=A7=D9=01A=0CY=A8=DF=1D{=BF=AC=FC=08=07x$=DF'q=1C=C4=DE=A9p=A2Z=F9T=D1=A4= =B9y:=93=14=FA=B1>=E3=E6q#=F9=D3M=CA=F3Z=F2=00=E0=15;=F3.iy=8Br=CBK=F3=05= =A3=95/=C2=10=84=CA=80=BC8O=93L8=15=98_?$=DFx#=EB=B2j=15I=B1=FA=FDI=9A7=F1= =10=9E=E8 = =B0=C6O=1F=12=1D=05=1F=05Dz=AC=FC=1D=F9=A9%N=FA)=94=DF=EEek=D0=9D~=D26=D0= =8D=9F=E2;=91=AE=EA=17=C6U=F5e=E0=AC~j=9D=D5=8E=9A=84=92=C6=BD=F7=EE=FA=91= =97d=D9=C7=9CW=9F=84=16=9Dv=DCP1M=A5!=F1=FB=10=12=B4=83K=95=FE=CB=FF=E9=F3= "=0B2=DE=E1=90W=B0=1A=DEg=FA=1D=D9'w=00C=1F=82@=E40t}=A8?%=CD=87b{=99=F1= =BEr=1CP=DBj=1F=F78=A2=DB=AD9=F6=B2=B4=AA?=EE=DE=E65?=E5e%0=F2=A4=C3M]}=E2= =E5_"I=BD=9F=93=CA=D4=92Q=0Fc=DB=89=17=13=81{=D2=B7=1B=06=C8=18=FEf",=8F= =FA=12=A1U=B9=C2=81b#p=D2=A4=FF{R=A6=C9I&@=D2=AF=F68=C0x(=0E=EFS=F5~=90=01= L{=A1=1CD=ABgrd=A3g=A2=A1xki=E1=04z&=90w=ECA=95=8BA=FC=DB=F4=8FR=3D=00=ED= P+=B6=90=F0BH>=1C=D4=0D=0C = k=EDz>L=9E=15=D3{=A5=AF=93y=EC=9D=F2=9C=97I=DD=95ub=1Ed=AC=AD=02=1F=B4o8= =17r=9D=DBd=8F=DB=DEo=B7=1B'bm=F3=019=88=D4P=C2r=1A=F5=B5=B8=3D1=A3=D1%=88= [=A4=0F`=D3=D3x/h=C6=E3=E6`=D7lO=0B=D343=A6=9D=04=D8=F3=11=C0,=EE=07=A7=9A= '=9B=B3n~=A8=12=D2M=85yWi=96=B5=0D=A6m=EB%=BF(y%=86=08=DF=9A=9F=AE=D2=FA= l=84=14h=B5,k=EA%=E5M+_=06=A4=8F = L=BA=94=DC'=EC=84=EA=FE=D9=0B=BB=EC=89=03=8CM=C5=DBn=C0ho=BC=C3=1F=EF=8B= =E9=B76=90o=CDC=95=A4M3=EF=C6x/^=A3%=E9!!=12=F3`=14=A2WC?=E2=89fi=8DK=D3= k=D7=C5x^Gv=E9Lv=CDA=DFV[=C5=13=BD=B6=A8=DC=A9`=98=1F=AC=1A=1A=A4%=B2-;=D4= =A3=16H7=95=AE=3D=93=DFo=CC=F0=89=EE9=CA=18{=FF=00=13=1B*=DC=1F=9E~Q=FD=D2= =AEgV#=15^$=F6=D2x{=1BE=B6G=FFO=1B=3D=F6=0A= =E1=ED=BE=ED=13E=02^=BD=D5=F3=F6i=B0=D7=8D=B0=9B=06V=B95n=B0i7=C2 = 7=D8=9E=8A=D2^=A8=D7=A0=19=08=01=C0=90D=B2=C9=8B=05CU=AC8L=D4UB=E4_D=C5^= $O=13=8F=E7=AA=1D=0B=06B=016s=84=11=D1=80=E4p=88=02=16=A3v=92=08=EF$=B0=C4= =F5=02=00%j=84=083=9A=A1=13=05=18=84=C6Q=F7=FC=A6=11=0B=19=08=8DXLQl=C4B= !=A0=A1=DD]=E6=9B:-=F2=86=03=C4,6=1C(=8A=91=E2=10=FB=A60=C4=E0=CE=DD=F2]= =9A=A7=92=A9jL=02=88=E2n=A8=F9=98=05=14GjE"B=97=CE=A1=BF=BA=ED_=C8=C4=B9= t=FB=EB=9F(d=8A=1Ek=98= 7=F4=D6=99=DA=147=14Uo=8A=1B=C4=A1=E2=11=AD@T=B7=E1=11G=EB=B6=B5=08E=D4X= =84=99=AE@=14 = =0C"C=9D=E6=86=16=C3=96=16"mL[=A6=E9=E7=83=CFo=EF=D8?c=DD=9C=DCX=CC=B2=08= =A8=A6=F4z=FED=EEo=16=D7+=1F=AA=D1=F2=F7=CAW=FD=18=A3=C1X=E9M=95=C7=C3=A9= bv=9B=3D=92Pt/I=F6=1Eu=DD=88hE=85#Q=EDR5W=906=0E=B1=C5$=D1=C5=02=85=97=0B= =D48{=0Fu=0F,% =C6K=05=0A= =DE=0FQS=92=C8b!=87=E3=EC=3D4P=F0=E1=92=06=EE=8D=93=F7=C0@=8Ds=87=EE=EB=9C= =FA=1Cg=CEZ=F7=EF=17=A6q=05=CF=13%N=CB=DEB=E83=D8_Y=0DA=B8=8F=F9=F1p=11=B5= =DE]=B7S=80=10=3D=B8=98Y!=D5=03=14=B7=97=08=1B=94sA4k=D6Sc=F7=F7=B6=B5Cq= vI=0E=1A=C9=0F=C9=F4C=FA1j=95G3=94=E3h1=CDT=A1=CB(=8Fg(=A7=0D=E32=FA=99\= =DB=8DzQ=16w=EB=0F=17=8D|=DCE=1E=C2=BB=B5=8B=CDgA=EF=11$=B6=F7x=86~D=16=F4= =1E=E1=B0=D3Nfh'K=E6^=9Fl=AD=FE=19=C0Gl=C9=DC=A3=C8=CA=FD=0C=E4=A3x=C9=DC= c`=E7=1E=CD@>=86K=E6=1E=A3.=F7b+=B9[;^2=F7=98=D8=B9G3=90=8F=19=98T=DEN=E2= ;U=87]=DA=C5=8Ex=B7=E2=08=05=D3~=CFW=1D=F7r>c=CE=10=B0=90jq.u=8A=C3=19=8A= Q=B8=94=D7=04=F7r=3D=A3=CE = ](=D7=84u=B9=C6=0D=C8A=A7=18=C5,=D2=8A=0D=97z=A0D/=05Q=A0=F5=FF=D1=9C=9C= 0=C4=CC=9C=9C=98=D1X=1D{=A0wrn=F9i=C9y{HF=A4=3D$c=84=F5YkH1l=C4b=8Ab#=96= =12=AAoS=18@=8A=DB=DBtS=E4U=9D=E4u=C3=01hL=0C=07=A2P=9F=A88=88=08k=EF=D4= =8B"=BB=C9=8B=F34=C9Z=E3=A9e|=A8=8D'=3D=E3K~Q=F2=8A=E7u=9A=9FN=B9@=03=F1= +3\=A4Q=80pg=14=C10j=A2=C3$WCzrS=F3=AA!=179=C6=86=9C=11=99=E9+=B9*=0A= =A7Mr=DDbg=AC@=94=E1=C6=0A= A=0C=9B=08=01a=BC=A1M=B2=AC%=86=04=19b=D4=D8=D1=0F'=AC4=14=A0=86=82=F2=0D(= =E3=81=A2=F6=C5=94e=90=12=81=1Fm=BF=E4Z=F3J=06=E6=E0=E8=00=A3=CD!=DF=94=FC= \=87=EA=A5=F0=EASR=D7=BC=CC=83=FC=A4=072+=80=8E=98]V=B0U=E3=F9s=ED=00=05= =BB=A3=D7=1A=D5W.=04=EE=07=C1=FBU=FC=FF=CE=3D=FE=02=DC=AD=EB=848R=B0=14[= =F0=B9Ce7=92=8F=99=F3=D9|aj=E9W=18=96=7FJ=EE=EC=9C=FF=04=18=00 = RW=A5=0Dendstream=0Dendobj=0D106 0 obj=0D1823 =0Dendobj=0D107 0 = obj=0D<< /Filter /FlateDecode /Length 108 0 R >> =0Dstream H=89=D4W=EB=8E=DB=C6=15~=02=BD=03=FFU=9BV=CA=CC=99=1B = 4@`=BBu=128=88=E1=0A= =E8=8Fu=02p=A5=D1.=03.=B9=A5=B4^=EF=DBw87=CEp)j6=11=0A= =14=86mR<=97=EF\=E6=9Co=DEl=16(=EB=FFt=B7=0B=9CU=D9=E2=DBO=B2.=8F=D5=17=F9= =B6=AD=DB=AE=BA=97=C7=AE=DAf]=B5=F8=F6=9F=90=E1l=B3=CFVh=8D0=E7<=DBl=95=DE= =E6=A9=FF=A7=CB=16=856Sd=05Y=0B=961`=FD=7F=9B=FB=C5=F2=03=81=AB=CD=EFJ=9F= =1A=FD=05=ACQNH=AF=B6[,=BF3=DF=AC=ED=05Z=ABO=EE[Y=D7=BF4=F2=F0=B1=AD=9F=8D= =14=B1R|M1=17V=EA=FB=B1=056Xw=AE=9D"^+=E4N=F1=9D=F9=C6=ED=B7=15=B6_W=D4=00= =ECe=B0=91=11S=F0=FE=1A=EBG=DF=BE=BEFO%*=D0=EA=F3K)%}~U=A4=FA#=CA=F4=03=06= =B1f=19-=C0=E5=16"7ae|=3D0=A1kPJy=A15=FE=84s=CA=B5=A1=C1;I=F0=CE=C8%\=F3= =C8/M=F0+p/}=D2=F5=B8Ts=CEs=1A'=9D%=B8/=D0=FA2=DE=01=91Q=D6=F9y=F7=80=8A= =D9=9A=BF=C6?@=E8\$8=87=FC2=9E=A9=EE=90=C0y=9E=E0=9C=F2K=D5=1DX=11=D7=BD= Hp=CF=D9=A5=EA.=F2Q=DD1J=F0=9F_&=F7=04=8Ds=8F=F1y=EF=04_=AA=EB = =8C=BB=1E'=8C=BA=DE=FEE=BCS6=8E>a=D4=11v=A9=DA=13=FE=A2=F6 = #=8F=88=93=B5_=11lV=DA=0A= =9B=ED=984=F7=D4=E4Q = =84=1E%=1AD=CA=E0=C3=A6p=82:=E8=7Fj=F4=02=8F=00$=8C>LL=ED.=04=80=E6=A3=1C= $=0C@=CC=8AY=FF=E9kO=E0=C8w=C2=FC=C39^=CFG=9F=EE=BD=18=D7?e=00"z=19=EF=80= =A3=D2C=CA=F0=03~=A9=D8=81=8C=EA=0E = =E3=0F=E8=85=EA=0E<=AA;$=8C>=10=17=AB;=E4=A3=BAC=C2=F0=83=E2Bu'(=AE{=CA=E0= =C3=17=AB;=81q=DD=13f=1E!=17=AA;aq=DD=13=C6=1D=E1=17=AB;=11=E3=BA'=CC:=92= =CF=D7=FD5[=AF=88+=9F0=ED(:W=F9W=F8=A7=D8=90=E6=00B=C2=C0=A30_=FC=D7=00=A0= =E6=CE2=00 = S=8F=B2s=1D=F0=1A=08=9C=8Er@=EC=E0C=03=04=C0=14=0C=04=A7=AB=1F=98F@=89=D1= =DB=DCU=07=E7=8C=D3=DE=D86=EB=FD2=A4=FC>e=0B=BC=CE=A9=1As=06Vfd{=DB9=D3=E1= i=8CB=14Z=16=AD=0B = ^=F6x'=AD0a*=F9V=98Q=06=D60#=B9=EB=F9l=DB6=87c=D9=1C=AD=06*r=E14=A0=C0Z=81= DH=1E=CA=E3Qv=CD=1C=1C=B2V=B7=DA=FC%=1C=8C=0A= /L=10=CE'=E0tr+=AB/=B2s=1A=02=11=AF=C1=FB$i=F3=0A= =8E=D78=DC=B5=8F=F5=CE=C1G>^@=98Xq$x=E1=C4=E5=D7=07=B9u=D1b=8E=BDA=8F=CDN=1EU=9B=947=B5\;=17=18=E7>=04$=88 = =97E=E1=BE)=0F=D5=B6=AC=EBg?E=04=10=0B=0BD=91[X=A1=AB=EA8=17B=9C=CD?6=04= =10=1Ez=0B=D0dou=F2=F0X=1F=E7=DB%=94o=F7=FE|=B2=E0|=0A= >=D1.=A5?=FC,(in!=AB=E8=DC=E8=CDv=D5=97=EAP=B5=CD=DC=99 = =11=8E=1B=9Fh(z=01=D3=B6=88=B2=89#=F1~.<=14=9D=F9v=B6=C3=E3=F0l=9EuS=00=CE= =FD=B9=1C=CEN=08=F8=A15=BDaR=A7m#-=B6=E2=C2=1CHu=01U=81s-=DE=C9=07U=19=D9= =1C=AB=E6v.=E1,jt=97p=02=E0=FB=95=A9{=DAD=C6=0F=F2?=8F=B2=D9=CA=B9=D4=D0= =C8=B8I=8D=CE8=E3=AE=B5=950=9E=AA|]=0F=B3=B0(=FC,=14nb=85=86=F1_\s=13=8D= =D5=E2FS=D3=ADl=CC=BC=1F=A61=B8d=87=C7=C5=A7L=04)+=B8=CD=03=10=E4=9D=1F=EE= =AA=FDQ=EE=86=D0li=FA=D0=08Ll=91Z=EE=FD=B9u}=1A=03 = =ABN=C0=F5S=81=FD=19=A09=9D=C8=D9C{=A8=8E=EA=0C=1C=D6=86U=C0Kbc=1A=C6=B1= =1Bu=07=B5=D4=B0'=15}=7F=BDm=E5~=7F=D8=B4?=C8=AF=C6=06=B1D'=1F=A8=EE=F7=91= u=05=8D=E5=9E=02}T6=9A=F6=BE*=EB=9F=DB]lA=ACO=1AP=E0\}>=10{=1F=A3=F6+^=17= =D8=7F=FDf=AC9=B0=AFkE=BFV=EArE=96=BF=D9=FF=95%=B4=FC=DB=D5J=89=A8=B7=F7= =E6=85=AA=EB=8CX*p=8F=F5=E3=E1=EA=D7=CDO=83=AB=BE=1C=96y=D1=C1=E5g=D5=AB= '=D3=B9p=C7=1E=E2X=C3=9C\/=DF)=D7=EF=AC=AF=DCJ=AC=88j=CB=1E=FC=0A= =8C=B7=DEJ>&=97Af=F1=19r=89Q=7F=C1P;=C91U=CC=FD=F2=19=B3Z=8C=B1=B9=93PKD= =AF=87=EA=F1=E5=DF=A3=BBV=B0= =A1'=AFZ=84=F4=FD=D4=EB=0Dl=08=98_.=C1U+=DC.=BB=F2=E8V(=04=AB=88"a=A4=FD= ~=B9=97=87Cy=EBi=16=1F=B8=82v=A2=97F=B8=8FJ=CF@=A7Y=D3=D4=12=07=8C=07=06= =82H1=B1=C4=EB=EA0K=DDptE=F1=DC=06=E5=C1]I=90=A9=05^5Gy+=ED=3D=E2=C5=B2=0D= =A9=D8=B5=DA=B6H=FD=ED=DB@=EF=B9=C2S=0FZ`=B7rC=1C=9F=97w=D5=ED=9D=F4=D0=81= =0E=17=04J=C8=14=DBk=BB=9D=BF=18=02=CA=83=BC=B8=0B=82fN1=F8=F9=0BB=14=AD= ' = S=C43f=D7=9E=A4=9E`=88a?=05=0Cq=8AX=C4T=C1=11=8B=93<(=14=B6<=E8Txx=FA=F2= =A0=F8=B1=B7=0B=85=C0S=97=87=AEl=0E=F7=D5=D1r"}!#=FE=D2db=D6=D40d=CD=FB=AA= ;=1C?_%=F3=96=0C=FA&Q=87S~}=E8p=CC=18H=7F=E0=8D=DD=EFN=F3=85=A5=DF=EBN=CF= E=BB=9AQ=AA=C6{>=F8=F6Cl.=DA=DE#=E2=A2=8EJ=C0=0F=FA"=AF=98=E6,=DDc=ED=9F= =F7=EAFk=1Foe#=BBRSy=FB=8B=1E4=11}Y=A8i=FA=92*M1=92=E5=87=98g=AC=C0j=86\= =C4=A7GL=A7=87=CF=A4=07=BCa=F3qe&=B7=12=E8=E7=CD/=FB=1F=83=D90=E0=CFC=DA= =F5=A2rAh=9B=F2=A6=96qx=10~=9F!=A8=D7=B6az.h=B2G|=D7=04q=E4s=16=AA=90V=E2= =F0=85=C0=C8=A8=BA=FFxj{=AD=16P=CF=03W=0C!=D5+q=ED`=E8=D9=17=AD=12=9A=B0= =8D =0F=C6L=E9=DAA=CFq=FB=AC=A6=B4}=0A= =1A=EBKY?j=AD=91=88I=C7J=1D=B35_>=DD=C9=C6=18=AE=86=86l=BC=D6=BEk=EF=8D=A8= Pq;=1F=AD{*F1=11a=18nr?zn=CCu=BF$2=E3k=D5=AA=EC*=A0=95=8CFo$z=83=AB=81y=00= =C3W=1Ay=F0=0B=1A=FFB=8BP=9F=E6=D1=9B=88=DEx=F4=16a=A2=11&=1Aa=A2=1AS=9F= ;l=C2=DA|=C86=DF=A8=B0(=8E=C4P=F8F"X$=0F=C3"b=1C=04=E1/~=89=E0=91=08=1E=89= =E0=11=88=DE"L$=C2=04=11&=88R=05Q=AA = J=15DX=80=8E=AEJT=04G=E0=95,=0E=0B=ECH=E3=FF-=8DCl = D=AAe=F9=04=8D{h=EB=E7=A6=BD=AF=CA=DA=A1=9E"Q4=82=92H=A2=14=ED=A2/H=94^=CD= 9=F7=C1*=8Cl=82F=DDT=CE=F8$o=18Q=9DT=DE=10=06=11=F0=06S+=16=D4=CA"=0A= s=BAm=BBN=1E=1E=DAf=D7=EFR=CB=95(=F2=810b=0A= =ACny=04y-5=E3f=19[=C8=04=836=9B=A2=DF#=C6=F6?=A1=DFI=8CJ=9F=16=CA=DDeI=95= =EE=F0Qv=FFV%=8F=B7=B4=DA=13> =0Dstream H=89=AC=97=DBn=1B=C9=11=86=9F@=EF=C0=DCQ=CEr=B6=CF=87=8B=00=8Bda=D8=8B=00= 1=02=02=B90=F6=C2=96)=99Y=99=14Hz=1D=BF}=FAP=DD=D3=3D=B4=C8=1A=A8=B0=C0J= =D6=F4=F4=FFw=9D=FA=9B=BF=AFo=D8"=FEwx=B8=E1=8B=ED=E2=E6=E7=7Fo=1E?=9C=B6= =7Fn=FE=B1=7F=DC=1F=B6_6=A7=C3=F6nq=D8=DE=FC=FCZ,=F8b}=BFX=B1=81qc=CCb}=17= =DE[=7F=8B=FF;,n|=DA=C6/=BC=1C=AC^h=A1=E3=8F=F5=97=9B=E5=C7=0F=C7=CD=ED=FA= =BFa=03=957=B8=11Cx=DD=C6=F7>=DD,=FF=96=9F=C1=E67lpRJx&=F23=F9=A3go=FA=3D= =D9=A0]}=F6=AA=DF=93=0F=BC=EA=BD_nw=B7=AB=A0?=D8=ECl=15=DE=1Bd=90=FA}=FD= [=B3=9F=1E<=AF=1E_M}4Z=FF=CC=CF=0C<[q8=DDJ=0C*=EE=D0=9Cc<#=8B=EF=87=15=E9= A=C8=8A=1Ew=AD=B3_'q=11>=C7=A3=8D=CB=FF=E2=9AXOJ)=19=EB=E9=C6=C4= =AA=89=85=94~=F1n=10z=A1=0C=8F?b-=E9=BC=A9=3D=AF=C4Z=7F=9C=857=B4)=D5=F7= =D7=DE=06=CB=FBc=C49=B7=AD=B4AH=8BT=FB4=EA25Pc=C0"=0C(1\=D6o=12t=D5=81=D6= =93=E8;=84=83=BC=9A=CA=82U=AD>=97=08=03=EEj=0E=E6=18=F0f=E8B=C0=D5u=0B=82= =19=C2=18=08=EE;=03=88=16=10=C2=11=C6@(>=89=01=A2=12=85=A6=AC=03a=BA:=10= =1Ca=C0R=D6=81p=93:=10=02a=C1S=D6=81d]=1D=08D/HNY=07RN=EA@ = zA*=CA:=90=BA=AF=03D/HCY=07=D2N=EB=C0#,8=D2:=F0]=1DHv=DD=80b=94u=A0=C4=A4= =0E$=A2=1D=95=A4=AC=83=F0=E7=CE=00=A2=10=95=A6=AC=03e&u = =113QY=CA:P=AE=AF=03=C4=E5=AC=AD=03D/hAY=07Zvu=A0=10=BD=A0=15e=1D= h=3D=A9=03=85=B8=17=B4=A1=AC=03m=BB:P=88=99=A8=1De=1D=186=A9=03=85@e=C3)= =EB=C0=88=BE=0E=10=CDh=E4=95:Xi=1F=8E=B5=8AgC=91"=931=0A= =CAf=07=88V=E0\=A6=10(Y|=BF=88T=85=A9=EA=1A=D1=07=E5=FB=82H]=B9=E6=F4=1A= =C3=E9=DA_=14=C7=7F(Y>=0A= #.=02=EER=B9=92H=FB6=E7=1AC=E6L=D1H=0B=DE=A4=1B=D1oB=18=AAS=0B=D9=E5=1A=F3= 1=A0=88r-L=93k=C4=85',Y=AE=85ksm0_ = =9E(=D7=92=8D=B96=88=FBEr=B2\K=D1=E6=DA`=BE9$Q=AE=A5=1Esm=10E&=0DY=AE=A5= =EDr=8DB=FC=CB=B9=9E=C5=F7c=B6-=0A= =EE=AFe{=0ETr=9F=EF$=D0=C7=90=BD=B8=9C=F0YX=CF=F3=0FPG=D4=BA=D2=D7=B2>=8B= =EAUwz=C4@W=96,=F1=CA=99=EE=F4=98/=0A= O=98{=CD=FA=DC#=E6=AB=E6d=B9=D7=B2=CF=3D=E6[B=11=E6^=EB.=F7=0EQ=F9=DA=90= =E5^=DB.=F7=0E1h=B5=A3=CC=BD=EFr=EF=10=95o=18Y=EE=8D=E8r=EF0=DF=0F=F2r=EE= #=BD=8B=8C=EF=C1=C8=1C=82=97=A2|=108D=07=16=88=0FC=90=84=E0=1BuD=FF=15=88= =A7P=CF=04=DF=E8c>a=B4=7F^|=1E=C1=8F=C2=1E=D1z=00=F1/=97=F6=93=9C{D=E7%=88= =7F=B1t"=F8F=18=F1=E9=02=10=FFri9=C9=B5=C7|=BA(=8A\'=82o=84=F1=10=FFri7=CD= 5=A2=C2=13=C4=BFX:=11=FC(=CC=19=A2=C4=A5`=17'=0B^<=08=0B=DD=EBc=BE"=14M=B1= I=3D)=B60g=11=EAV=90=8C=B5=00=E6iB=B6=F2=88N=93=DEQ=8Du=C5y/=8F=B8=DD=94= P=97b?G]=DA=B3=E4c=C0R3=AA=8BE=199=CD?=A2=EF=94=B54=EA=CEO=F3=CF=11=1FU=9A= =91]=EB=BA=9F=F3=9Cc=C8Rx=A2=FCku=D6=FC=1C=03=97=9A=0C,=B4=99=F6?G4=A0v4= =FD=AF=FDY=FFs=14=DC=92=F5=7F=80=DB^=1E=D1~F^=E8=FF=88=B6 = j#=DC=CE![=EE=0B,s=8E=81K=1EZ=90=EB=E1=E5|=CFEn=C2=D6=00=86.3=DD=13y=D0=A6= 3 = =10S=80=9B=D4=864=FA.7bk=01=03=BA>7"=89=07=C1=DC=A4=0E=04=02=04=84=10T=FA= RM=EB@`x[9=BA:H=00=DA=1A=C0=A0=AFUdu = =9C=3D=AB=03=04=11H=C6=E8=EA@=F2=E9<=10=88=A1$=05=D5<=90=F2l=1EH=0C=91j=C2= y M?=0F$=0A= J=E9=E6=81=F4g=F3@"=EEE=C5=08=E7=81=E2=D3y = =11=DD=10.=B3K=FA=E8=0F=83=F0=E7^=1B=03=C6=FA=DA(=C0=CB[6M=80B=DC = =CA]=99=05x=03=DEL=A2=AF0h=C8=AF=0D=02=B4=01-=C4=B4=0D=15=A2=0D=B5=BC8=07= =F0=F2=CA=F7=DA=18.5=82=AC=03=B5=D5g=05=80(=7F=ED=1C]=07=1A=C6=A75=80 = 3=C3=C9=F4=85=3D+=01=04=99=19=C5/=B6=E1=CA=B0AJ@=D4=88=AA3(=95=81=0F=8D=01= =B4=88=A8=8C=17=EF=14=8CZ=E51p=06=80J=E4 = =12j=95G4"=E0)=91:=F0i5=80=E8=C6=02=A74=0E=80N=AB=01=C4u=90=D0=94H=1D=D8= =B4=CA#=88=A8=80)=91=83H=A6U=1E1=06=00K=89=D4=81K=AB=01=C4=18(PJ=E3=00=A8= =B4=180=18"=14d=FD_=98=B4=CA#`=AC=00)=91=03=D3=F4=BFA=DCD=80=A3D=EA=BE=EF= =7F=83=A11F=D9=FF@=A3=D5=00=A2=01=13=8A^P=9F=C7=A2U=19=D1{=05DI=C4=81D=8B= =BE=C5c(=89|=E6=D0=AA=8EA@~=B5=F1gSh=D5=C7`=A0=BC=DC=F7=F3=18=B4*#Z=1E=00= =94=A6=E2=0B=81V=033=F0=93=C6=01=F0g5=80=E8=B9=04=9FD=EA@=9FU=1E=C3=BE=80= =9E=CF:x=01{J=CF=81g=B9C=D2=A7t=96=0A= =3D[u<|=92=18=08=E4=D9=AA=A3=D9=93D<=83g=AB=8FGO=0A= =03=99;[}=C4=1C=88=E4I"=9E=B1=B3UG=0C=01=00O=12=03=81:[u=0Cu'=EE$=11=CF=D0= =D9=EA#F=00`'=85=81=CC=9C=AD>=06{=05M=DF=03r6=EA=1E1u=00:I=0C=98=AE=EF=3D= b=EAd=E6$=11=F7=D3=BE=F7=88=CA=07=E4=A40=90y=B3=D5=C7 = =AF=BC=D0=F7=B3p=B3=15=C6=A0=AE=BE=DC=F2si=B3=95=C7=F0=AE=BB=D8=F33a=B3=15= G4=1C=E0=E6=CB=D5=815Gy=C1=10=1D=17i=93@;=A0f+=8C=C1=DC=04=9B=14=B5=0E=A4= =D9=EAc`7=B3&=85=81=0C=9A=AD>=A2=D9#j=92=88g=CEl=D5=11=AD=0E=A4=F9=8C=81= =0E3=E70=A6=B5=05\=05C=F4}=82L+=87=97=D3v=C1=CC=D6=00=A2=F9=0A= g=D2x=88=A4=D9=18=E0=18=D0=CD=A8I=A3=0F=B0=D9Z=C0=D0.=D0&=89=07=E0=CD=D6= =02b=16$=E0=A4=D1=07=E4l=0D`=88=17=98=93=C6C=A4=CE=D6=00=06z3v=D2=E8=03x= =B6=16=10#=A1=90'=89=07`=CF=D6=02b=1E$=F8=A4=D1=97g=F3=80c=E8W=13=CE=83D= =A0=8D=01=81=01`K7=0F=0A= =84=B6=16=10#=A9P(=89=07=E0=D0=D6=02b$%=10}^=7F=1E=8A=B6=DA=88YTX=94B=1E= h=B4u=80=C1pwe=16=CC=05=D2V=1F=D1=85=85H =0C=14&m=1D = =80wCx=BD=CC=D3_=BA=BDc=A1=D6g=EF=97=AF=C3<=F9=E9v=15/e=B9ti=AA= =8C=DB=84=BEu=15=0B~M=A1=0A= =08=E9yx=3D=14M=DA&>y=93=05T=15=D0=E3[=AFzq=DE=18{=BF|{=BB=0A= K=83=F0n=13=AE=1D=F8=3D=DC*=F0=DB=F1is=B7=BD=FF^=1F=84=A9W=D6=7F=FD=F2qs= =08=FFbl=19=06:=FC=B5=D8/F=B8o=C3=B0=BA=14=86=8F=DB=D3=ED*=FCa=B0=CBP=9E= =9F=8E=A3fh=B4V?=AFy=FA?=E1=E5=B2=DB6=0CD=D1/=F0?h=99=04=B0=C1=97^@7mZ=14= -=12=A0H=BD3=B2=90e=06u=A1=C8=82=A4=D4=C8=DFw(=F11c=D3=CE"FF"=A9=AB=AB!=E7= =8C=D9=1C=F6r=AF=BB^=0F=BA=1D=87[=88=D5=CD=CA=0Dz|=F7=C3=AB=DD=CEd=BC=9D= Qu=9D=AE=FA=01=BF=F0=EA=9Cp=CD=0F=B9=A8=94=08=98=92=A5= =11=AE=81V=E4=D0=FC=9B=D3=E6=9Ck=85UN=FA=B2=F6=AAA'=FD=D0d4=CF=B8]S=8A(=FD= =DE?=DD{=DC+=03=D02=9EF=CC=A8=AB=A6~k*C=E3=AB+=BBH=91=F7=FC=E1=B3Q=15!=1B= =95U=C3=88=1Ax@=F3=C1=E6=A7\=EB=0D=97=D2=EF=A4T=F8=EE=0Cg:`a=AD=077=9E=85= =BE@=B0=CCu~=B8K=E9=F5K=A3q'=14=A58E{=15Oq=12=DA=19?=B8L=9D=F5=F8=01=F5=A1= =1D=F6=C3=A8=DB=DA=93s4}S=B2=BF=CD=86=BD=96=06=E2$=0D=A6O=14N=19%]=DE=12= d>t=F0]=FB=B3=B4=B1=E4=9F=9E=93=BF=CD=9BI4=17i=10]f=91s=B7=D9=8F=BA=AF=C6= =B7^[r=E5=BE*=F0=92)=F4,=9Bp2=9Fs=C8=CC^=EBa=04=1C=82'JQ=7F=D5u=AF_=01=9F= =E0=CA=178]~U#,=DD=AE=DA=ED=C5r=93=958=0Fr3=EE=DBz=C1=A6=0A= =F4=F4=1D=0C=82=F2sL8K=1Ea=EE_=F8=FB=99l=9EY=B2K=1690=94=A9P=00B=AF=8B=14= =1A=C1=E9=DFf=F1=DB=05=99=A9Y=D3=02=D3O=AF=17/=8B=FF=02=0C=00=EC=9Am=0F=0D= endstream=0Dendobj=0D110 0 obj=0D3768 =0Dendobj=0D111 0 obj=0D<< = /Filter /FlateDecode /Length 112 0 R >> =0Dstream H=89=CC=97=DD=8E=1B=B9=11=85=9F`=DEAw=BBAv=B4$=8B=BF=17=01=12;p=B07=B90=FC= =02=DA=99=96=DDY=CD(=91d=EF:O=1Fv7=8B*=B64=3D=A5u=01=1B=18=B0=0D=A8=D9=E7= =90=A7=AA=F8=F5=9B=0Fwj5=FC9|=BC=D3=AB~u=F7=E3=FBn=B79=F5_=BA=B7=FB=DD=FE= =D0?u=A7C=FF=B0:=F4w?=BE3+=BD=FA=B0]=DD=AB=B5=D2=DE=FB=D5=87=87=BC=EE=C3= =AF=C3_=87=D5]=1A_=93V = =D6=C1=AD=9Cq=C3?=1F=9E=EE=BE=7F=DFmw=DD=C3=A9{|=F7=A7=0F=FF=CA=AF=B1=D3= k=EE=FCZE=80a=F5=E3=DD=F7=7F=99~+=12wj=9D=B4=0F=E5=B7C=F7=A5;=1C=BB7_O=DD= =9B=FEt=9C=9E=84=F2d=1Cd=A6=E7=FE:=7FG6=89=EFx=D7=AERk\=F4=F7=E9=07_~=B8= =D7auo=D6vP=1F~=D6=D3=CF=A1=AE=CB=96=D1=F3=9F=DB=A5=CDo=BF=DD=B2=AE=EE`\= 5=9C=AF=B5=16=86=F3=CD=874=FE=A8V=E3=7F=B4 = =D9=B8S=01=CF=D6424=99=9A=87=06=BB6=C3";=AE=F8=06q=EB=A7=17U=F5=C8Pw = !=ED=1B=DD=C4=D0=0Dz,=C3=97=A4=E7Q-=89G=DB=1E=BAV=0C=FD=B4|=EA7=E8=1B=15= =1Au=F7=BA=BA=D1^j=F7=C6=A4=D9=EE=3DC=1F=92=D8=EE=9Di=D4=03C=DD=8Beo=C2<= {F=CD=9B(=97}j=B27=8C~=07%=96=3D=E8Y=F6=C62=F4=8DX=F6`=9B=EC=0D=A3=F2=C1= =89e=0F~=96=BDaT>=04=B1=EC!6=D9=03c=EA@=12=CB=DE=AAY=F6=A0_=D7=B7Z,{=0BM= =F6=C0=A8|k=C5=B2=B7n=96=3D=00C=DF=8BeoC=9B=3D=A3=EFl=94=CB>=CD=B3gL]=A7= =C4=B2w=A6=C9=DE2*=DF=81X=F6=CE=CE=B2=B7=8C=CAwN,{=E7=9B=EC-=A3=F2]=10=CB= =DE=C5Y=F6=961u]=12=CB=DE=EB6{F=E5y=B3=94=FD=BD=8Bk=3D|=08=DC=EB=B5=1B>8= X=CC=A7`=3D=F4=C1=F0=F7h=83=83=BA=1A=86C=B0=F9=00=8B=F9o=A2N=E3=A9>=07ya= =FC=E4=92=D2=B7=B19=01=C7=81^=97=16=E5=F9=BC=1F4=95f=CC^=1D=F5zy=EF|=F1=D4= f=EF=18=C3=D7=E4=DA=13=11=CF=E4N=A59=ACm=BC=D4=CE=0D=CC2=E7=C0=B6=15=CA<= S;=95=E6pv=10=CB=DC=C46s=CF=18=F9& = e=9E=89=9DJs=18_=8Be=0E=A6=CD=DC3=9A=0D@(=F3L=EBT=9A=F3u=E1=C52=870=CB=9C= =F3y=11=973=BF=05=EFS=93:=A3=D3=ADz-=F5[=18oBu=E2=80=D1q=D6,=07=7F=8B=FE= =04=EBg=FD=C0!|=F7Z=FA=B78=98p=9D8=E00~=10+=80=02=ECD=9FC=F9I=B0=06=0A= =B2=13=07=8C*tZ=AC=06=0A= =B4=13}=06=E68+X=03=05=DB=CF=0E"=E7[=C3=8B=D5@=01w=A2=CF=F9=D6=88=925=90= f5=10=19}=E8=95X=0D=14x'=FA=8C.=F0=B0\=03=F7n=DC=D4@=FC=B7=E0~T=93=03F=17= = =EC=E7=FC=8C=10=EC=A3:=E7S=A3=A0=BE=90=FA=84=FA=A8=CF=F9=D4=18@=7FA=FC6=D0= /=C2=89=F3=851a=BE=88t=A2=99'F=D5=8F=90/!=3DB>=0A= s=BE.&=C4=17=91=06=9Aub =CF=08=F8"=D2=9Ed=CD=F9=B0 = bY=17=BCGq=CEgM=12=CAz=84{=14f=B4vA{=11iC=B3=D6=8A=D1_`=CDk=83=E5=06=B8=B7= =13=E6=A0>=E3j=03/Tl=105Q=E6|X$=F7=DA@g=8B[=15=C6wU}F=9BY=A3=04G=BA=05h=A2= =E7|]=D8 = =A6=EER=9B<=E7=D3"H^=A8=99=AD=89<=E3F=B3=19=83=C4=D4=9D6M=FE=9A=03uF=F2J= w=CD=98=D7=9Aq=BB9g=C4=D4}=DB=F9=9A=F1a=E5B=14=CC=DF%=D2=FE=9AC=94=CA=CA= =E5=EFu=DB=FF=9A=D1~=1E^=E9=FF=81i=F3=AA0Rm6s=0B=D8z=87=A0=AC5=E3=F2=CB=0F= =E55F=00k=A79@=E59tk=A7Q = =E1=C0=F9F=DEp=18=D3=8F=A3@B=3DNs=80=1A`=8C=02=9D=A6Q = =E0=C0=A88=CB=DFp@=D7=18=19u=B0=F3=FC=0D=07wm=94=CA=7FdN*=CF=01=DE`=85=F2= 71\=E4=CF=18=05=A0=94T=FE=A0=E7=FDo=18=FD=0FF=A6=FF=01.=FA=DFp=10=D8=89=F5= ?=F8Y=FF3P=00=82T=FFC=BA=E8=7F`=0C = =AB=C4=FA=DF=EAy=FF=03c=00YX=E8=7F>=05[=DB*s = =D4-=B7>_<=A8=8B=A3gT=BE=8D=8B=BD=CF=97O~~=EE=8C=C2wz=B9=F1=D9=F2=CE=98y= =E3=01=A3=F2=1D,=F4=3D_=DC=A6F=D9r=E8=CF=1B=A1=9Es=C1=CD=83=B7=8C;=C7=C5= (=D5s^=E9Y=F6=96q=EBx-=A4n=C2q=D8=D8I=F6=FFH= =A6U=9E=03=C6A=B0=FF=11K=AB=01F=FF#=93=CA8(LZ=0Dp=A0=18=96=FB=FF6 = =AD=CA=8C=C9=834*"^h=B4=EAsP<=BE=D6=FB=B7=A2hUgL=1E=E4P = y=E4=D0=A2o=14=87=83a=B9=EFo=83=D0=AA=CC=C1=DF=89@e*=1E = =B4=1A`=F4=1C=E2=A7=8C=83=82=9F=D5=00=A3=E7F=F6=14R/=ECY=E5=19=8D=87=E0=F9= =A2=83=06<=B3=99[=D8=D3=00=D2=ACQ=8C=FBo=C4O=A3=C4=D8=93=CAs=E8=B7=E0=A7= =84=83=81=3D=A9<=87~'=FC=94P/=ECI=0Ch=C6=14@=FC=14pP=D8=93=1A`=0C=83=11?= %=D4=0B{Ry=C6(@=FC=94p0=B0'=95=E7=C0=F7=84=9F=12=EA=85=3D=A9=01=C6-=84=F8= )=E0=A0=B0'5=C0=E1_#=D3=FF=C8=9ET=9E=D1=FF=88=9F=12=0E|=DB=FF=9A=03=DFA=AA= =FF=91=3D=89=01=C3=E8=7F=C4O=01=07=85=3D=A9=01=0E=FF=C2B=FF=DF=C6=9ET=99= =03=BEn=B9=F5ofO=AA=CF=C1=DF=B8=D8=FB=B7=B2'Ug=C0/=E2=E77=CB#{R}=0E=FE=C2= B=DF=DF=C6=9ET=991q=0A= ~=0A= T<=B2'5=C0=989=88=9F=02=0E=0A= {R=03=8C=A93=E2=A7=84zaO"=0F=8C=96G=FC=BC=EE=E0[=D8S+=04Z=03=8C = 0=B2=E74=00=A5=F0=93:`=CC=00=C4O!=13=03=81R=07=8C9P=08T=C8@=81P=EA=811=0B= =10BeL=14=0E=A5=1E=18Sa=E4P!=03=05E=A9=03FW"=8A=0A= =99=18h=948=B0=0C=18(4*d=A0=00)=F5=C0=F8=1E@ = =951Q=98=94z`=0C=A8=91I=85=0C=C0=C5\=B0=8C=C9=84X*d=C2=B7s=C12&S!S!=03=E9= b.X=C6lB8=951Q=F8=94z`=CC=A6=91O=17=0C=DC=86=A8T=9CA=0A= =88=A8"=FA=85R=A9=05=C6T*=94*=E2`=02Ub=C01=86=12=82=AA=84=03dUj=811=93FV= =15=D1=1Fp=95=8A3=86Q=C1U=99=1E@b=A5=1E=18=E3=08=89U=C6D=81V=EA=811=90Fh= =152P=B8=95:(=E3H=9D=1Dx=93=F4=E4=00=17=A7)=C3q=A2=C5=BA=F6=9F=DDo'=14=CC= =A79,=C9=FFS^e=FF=BF=AE=EE=F4:=DA|=17O=CEV?=0DO=8E?=C7=F1=E5=E3"=AF=DC=F8= =A8Z=E7MZ|=F4a=B3{=F8=BC=DB=9C=BA=B2=C4D=E7q=89=0D!=8DK=A0y=FB=E9=13>=8C= N=C6=F7=EB=80V=1CD=AC=D5=D5=A1{=DA=F4=CF=8F=DD=A1,=B1N=D5%=DE=9A=C9=92]=1B= P=11=97=EC=B7K^=F4Z=E7=F7_z=D1=EE=BCW=18E.=BC<=F6_=FAc=BF=7F=FE=A1,=81h=1D= .q=C1=C7=B2=D7=E0=93=C1%?=7F-=87=AE=95=CE=AA=D3=A9G=A3]y}~=85=C7g=FF=F1= =C3=D2=1E=F5Z=E5=17s=F7H=9F%=E7=ED=92=AD=E7=ED=F4=B5=F3=FE=F7~=F7=F5y=FF= =D4ov(=A0=AD=A9=02=CA=E3=81=D3@=F7?=9FrF=DD=E3=F2=B1=D0=15=D3=B1=0CoW=D9= '=9Ez=CA=E7V=8EE=85=80=CFn=1E=1F=FB=E7=8FX=BB=F8=F2!=B1d=A0=BC=9BF:}=DC=8D= [4)a=A1C~=E1e=FC=FA=BB#=9A=B6=AA=9E=A3=03=B8=E2=E3=B4=FF=3DG=0E&=85=FA^c= =AE=9C=F8=D3=FEx=C2|B=885=9F=A0=A6=A7M=E3=E2=D8=7F|=EE=B7=FD=C3=E6=19=17= =E5=C6<=07=E4=8C-=01=B5=A1=1E=FBS.=DC=E3r=13}c=81=DD=8F=1D=AD=EB=0Et=B8=DA= EC=85=D5=FD=C2=B9=1E=BD=8Be=BF4=A1=F7=DDv=D7=3D=9C=BA=C7w=D8=A7=B1=EE=16= =82E=EBt$m=B6=A7:.=F4=F0=C5=84=8F=EB=F2=B8i=DC=1F?=F5=DB=13=A9=B0L=AA=0A= =9C=C7=1BK{HW=8Aj{=D8u=0F=BF=D4T=DCy=97.=E0.= iE=1D=BB=FF|=EE=9E=1F=BA=F5=C2=0Dj=1B=F3?m=97=86a=9B=F9=D7=FD=E7y=DA=D7.= =E5=DC=F2=DF=D5A=A1=829?=9E=FC=95=C6=D9=EEw=BB=FD=AFK=C7m=9A=9B=8A=8C,=AD= =CF=F5=A4 = =16/=ED=81<=9F=86=03=C1.=0B=E7y=02=BE=CC=13h6=B9=DB=EF=EB=81=E7G=AA=99=EC= l2S=BB=F7=B4X"=97v3=97=D5=13=B6=D6=C7+=D5=91=E3=DB=0C]=B5^=F2=DB=F6=D6=DF= =F2=AD3,Y=9A=98=ED=0E=A7=89=F9=D2=1D=D56=D9=1FuG]G=1F=89;=8A=8E=9B=FF=97= ;=EA=05=D0=B3=13=D0\Nl;=D0=FB=F0=F4=00z=8F=DD=F3#=864=E9=8F!YDCh=1A=A2?=D6= =B7=9F=9B=07=E0=DA=88=CF=C5=D8=7F=D9=EC=BAz8=D7bm=CF=E6<=BF=B5S=95Rs=F3=E8= +=B5=D5?=E7s=DC=EC=FA=FF=96;=ED=A5=F3=B1/M=DB=0C=86=BA=EC=16=0C\=EB=A7=B7= =EF=DF=E2v=13=D4=E6=CB=0F=84+=F7=EB=A1=FB=D8=1F=CF7=F2=B5=DD=C2=F5"=9Ef=3D= "=B9=BF=D6H=B99=16=9B=BA=F5M=9B=FA=E5\iXS=AE=E7I5=DD=9C=E3=00=BB=08=B6=AF= =EFU=E5=A3=EC~=DA=C4=95g=9F=F6=8FK=D3=A2N=C3:'4=9C=C1*=DF9=F8N?=AC=C0=C9= y=E8O=9F=9E=BAS=FF=80=AD=0A= =B6=9E=9F1=E1=7F=BCW=DBn=DBF=10=FD=02=FD=03=1F%7b=B8=B37=B2@=81=C2=B7=A4= =86=8D=06=B6=1F=0A= 8=0E=E0=DAt=AD=C6=96=02I=8E=95=BF=EF=EC=95=CB=95=CCl=D0m=1FlP=E4=CC=CE=ED= =EC=CC=19w=EB=C2=AB=FA=F20=BB}=18J=07=F4L=FC_0=C73}GBZ=B1k=03=FA=E3=F7s=04= =B8.=FE=DBc(0=DF=F76=DFBt=D7[=89WES4=B4=A0=04=8B=F64=1A=7F6*=CC=A8(=AF=89= p=D8=FB=A5w\=FF=DB=D1=E6=CBbn=C3y{L=AD=08RO=E1E~=8D=D5=BBoW=E3=80=C9V=E3= 7=93)=A5=08=FB=F1fr}y=12=9C'K|=EF=F2}=18=BBZw=DF~=8AmI=97Gb=BE=08=FBeJ=04= =AE=9C=A87=85=92=A9p=94=0Cp=11=EB;=19iz=E0=F9=8F=A4)=F0=EB=83_ = =CF=0C=C6=C3=D8x=ED=E5=06r5=EE=93=FE=CE =D7=AD=F6^=8B=FD=0A= =F39=ADU^?M0nQJ=C5=BEM=86=DD!=D0ej+=87A=8C=A7fFwz$=FC:=EC=81=B1=FC=C9=BA= =F29=AC=F7;=F3=03=0B=81=12=98=A1=E7=C7=E7U=DFAuU=14=80Gu=98=D6=8Fq=C5B=AC= =AB=AB=D1e=16=FAY=AF=82=AC_!=A4=A6=04=E9=E3=F8=FDVV=88x=3D=BA=F0=84=F5=03= v=81)=D7=A1=E9'=DD=CC=E6w=D8=EF=ED=0B=9C=D2=F6)=90R=13v=A5= :q=E4=05=F6=EB=BE=0F=BB=A2=18=9FF=08=E75=AA=85=F0=DE=18=019pq=C4=AEo=1B=DF= =ED=193E=10=A6=B2U=A1=1F=08=A1%=F6H`=08e=DDLh=CFP=AF&=AE=F5=10=D2=18=1D=AA= =AF=D6=D3=BF=F4=007=D2=CE=BCL0=8F=13<=97m=AEq=DE=99'$=C1=BE=C0=D2e=F3@F=F9= '=90=E0AM=B3=D9ox=94=01=F6}=FBP=F1|=19=00RG=19=E0 = =1E@6=0C=00=8B1=D0$=D8=E7=191=00"=C2=00T = =1E=C8l=18@=1E=D8=CF=00$`=10=9A=8C=18@=FE=16e =A1=0D)=FE=98=CB>=8D0=00 = =18D=FA=971=03<=C6@B'=A4"=1B=06=A8=8C1P=9B=D3*?=C3=99j=BC=DA=BC=D3=D4=0F= =9C=05=B7Xi=CE=17/=CE=18pj=E972|a9/R^=BF=0D=FC=E6=F69=D9=F8e=80Ip=CB@=C8= =A5=E7m{7@=BC=A1=B7=05=04=C4=1B=A0=DB\d=B5k=BF\=1Ar6=B4ZB=CFk=BBZ=EA=D3=B9= _=D1=80H=B1cE=EB=E8=C3=D0=D6=F0=8A=F3=1C=C0;O=9Bf=87=F3=F7=8B=E5=D3=B0=E7= =A1=B4=F5\=BB[=D7=B5+N#vy~|p=E1O=AE=99?=B9FO=8Dp=B8=1D=AD=1Fn=063HveP/[=C4= =AF=A1=04v=B91=BB8=B8p8=A1=82=FBjrn=17@=A4I=82x=F1=D5=97=D6=AD=8B=98T=BF= t1=B7=88=96=04=0F=F7=C2=0F=8B=97U=F2=C6e=06&=B8=FB=E6I}=B4Y=88=90=BB=0E-= `=CB=F6k=BB\=B5=FB=DF=D6=ED=FEl=BD=EA=F3=C3=BAc=F5=83=9B=C5=16=AB=EC=AFZ= =DD=D2${=84=B2Ot=B2=13J"=99KS=02=A1=B0=8C=92H=92=85N=06=C6E=1A=9F=CCb=D9= =90=C9=C0x=9D`=9C[=1A=98=C1=BEh=CA=9E=F9=04=1EC$/3Y=AF=EB=A8=EEI\=BA=C9=93= { q=EESx4@=95)z=A01=EAI=02=F2pv=E7=B1=CEy=1C}=02{=00=91=AB=F6 = =B7j=9F=C2=A1=EBz=10=FA=BE=FD}=9F=3D=C6=C5O!=D0=94=90=C1=9E=93n=1E=E2=DA= 'q7J3E=CF=E2=E2CB=DF=A1=D8w=F2D/=E2=DA=D3=EA=D5=81=1A=CFR=C6-=DB=B4T=A3=9B= =A1=90:C=8F6_n=E6w=FD!H=CB=94=C9yJ!=B2=D9=1F=7F=B0=E3*\=85C=BF=1A=BF=99L= q=A0=96r|=B6=B8{~|^M=AE/O=BA=03=15_=D1Q=1B=A4=99=C3?=02=17=AF=E7=C7=D1)=D8= =9A=EAu=E7=C2=E1d=CA=ABj=FC=BEo=0DYS=10=DC^?=06R=12=FF=ED=0A= =19=FA=BA=C53jZ=D21=12=A0=C9=14=151=08E=CA=EC[U=0F=FB8[=B9'E5=91=83=BB_=CB= =C5=D3=0E=CD=8E=EE=FA=176a=91=BB=14:=90=ED=BD=1E=EE=F84=E21=BC1=D0=08=C9= =CC=E6?&3=E0=97=9B=84=A9=E2=C8=0CdY=CC4=9F=E9=EC=D3D>=93=C9=B8=A54=9D}=9E= Ni2=B9`XM=E7ABo=B5=AC&=93=03=96=D8t=1E=90=84=E9=A2=89M=1E=07=1C=B7 = =1CH@=81=E56=99\=A0=F1=3D =AC^=D3=9BL=0EX=86=138=90=80D=CBp2=B9 = =B7p=900g=1D=C9=19=F0=E1=87yN=D0=8D=12(=B6=E39Y<=80=AD~=98=D0=10=1D=D5=C9= =E2=01=8B=81=00 =97=C1=B1=9D,=1E=88=18=07=90p=17=A8=CC=88=83f=0B=07 = =97=81U=F9p=C0=B6=E7b=C2=BA=C3 = =1F=0E=18=DD=C2A=C2=CA=C1X>=1C0=1E=E3=80=DA=DBXy=FA=075=B7=0E8U=FD=C05Wn= =BC=A2=A2O=A8=89=0A= =15=80T=0A= =CA.=10=FC=FA=A2=B8=1B=AD=A4=E3u=C5=ED=A2=BD=BF=9F=DD=CE=DA=F9ze=95=187<= S) =06F=CB=85Q,=EE] = =D8=8Bj%=A7=EC4*3=FA=F0J=8A=C6=C9Z=1A=AE=A3F=DF=AD0P=01V=B8=01=EA(j1=9B{= Y=EE=0F=06!=98=91ub=0F=ED=E6g=93=17=E2=F3B=9A=8Ai=05-:=C5=01=C7)=9AcxGD=03= Z=EF=B2]=ADg=F3=BF=0E=CE=0F(=DC=1E=B6=B7=C8+1d|=B3=FFm=DD~=B8Y=AF=DB=E5=BC= =9C=FF=19g=9C=D6=8C=9Bb5=E6,=E3=85=EE=D4G=97=A3J=17=E1=FC=9D)=F4KA=AA=E2= =0Cu=FF=C6=BF=93=E2=EA=BA*=EE=8A=91=A4=FA=AAr=E4=96O#=0E=A5y|=1C]=B8=1F=1A= C=06)=EA=DF=B2=1D=DD=8F=FE=11`=00=EB0N=CA=0Dendstream=0Dendobj=0D112 0 = obj=0D4619 =0Dendobj=0D113 0 obj=0D<< /Filter /FlateDecode /Length 114 = 0 R >> =0Dstream H=89=AC=97[o=DBV=16=85=7F=81=FF=83=1E=A5t=C4=9E=FB=05=98=02E=DC6=99=A2}i= =FC=E6i=015f=1A=0Dl+=90=956=F9=F7C=9E=9B=0E)[\=846=0A= 4=B4xY=8Bg=EF=BD=F8=9D=D77Wl=D1=FF=B7=FF=EB=8A/=B6=8B=ABo=7Fk=EF7=87=ED=DF= =ED=F5=EE~=B7=DF>=B4=87=FD=F6=FDb=BF=BD=FA=F6'=B1=E0=8B=9B=0F=8B5k=187=C6= ,n=DEw=F7=DD=FC=D3=FFo=BF=B8=F2=E11~=E1ec=F5B=0B=DD=FFs=F3p=B5=FC=B4=BB=FF= z=BDk?|x=BA=D9=BDm=BF=ACn=FE=D7=3DK=C6g]=B9=FE=AA=EE=01wW=CB=EF=E3=99=A4= r=C5=9AN=C3=A6s?]=BF=1B=DE=C7=CB}=B7=CB=1FVk=A1=D9=F2=ED=EA=F7=9B=9F=BBK= T=B9D=F1=F2=80W=C3=87=F3=86=97=87=DF.=B7=EF=AE=DF=FDg=B5=D6=8C-=9F>=B5=EF= =BB#'=1B=B9|=DA|}=CA=C7=1B=9B=8FZuz=B4i=C7=DA=A6=11z(-=CB{u=F7=C8t=EE=97= x=CE=A5sk=99=DEz-=A2=F9=FE=1A=17=AF1=CF=DD=BF=E9=CF=F5=05QJ=C9=BE = W&.=0C[=84=03=CEd=D3=15=83=89&=D6=82=9B|C=AE`=A9=1B=E7aM5S=FD=95=B7=CB=7F= =AD=D6R=F6/g=C3=BB=9D=13=E9j-P=15)=9EWi'U=94=C1U=B4j=9E=13Q=93"=C6=81=0A= 6=B9=99=FF=1E=CE=C7=15@T=BC}^e=F2E=04g=B0=8A=E0=FE=19=89=CD=A4=84=14ho = =C5=06=0A= ]o7vz=A9DW=C6gJ^=E6=E5y-S=F7=F1=F2=DF=C3=C1_sW&=AC=1B#=19=A6=E8=D7x=8D*=13= =E6=8F=C1=F1=DD8=95=AAs?~=F9=B4y=BC=1B=8Ew?o/=E4=D9qno=97_V=EB=90=1C=7F=AC= =D6=DD=1Bt=8B!=C5(B=C41=19_=8D=9F=14=9C=A7d=1C{=AF=CE}=F3=F2}=B7!R=FBZ=98= = =FF=EB=EE=EE=F3=FD=E7=A7=A1=87nycYl=1D=A5=FF=15=DA=0C=1E<(=03OW=89=97S/$= =B6}6=B1=3D=98=D8=87=8Fm=CE=DE=C3~=F3=F8=F4=B0=3D=1C=DA=BB=F82f=F9=D0>=3D= m=FE:=C9d=85=07=B2)=81l=A3=A7:=90=D3'=CC=9EYr=F3=DC=B9/Sa=CDe=DF=EE=AAk`= =11=FB]=0C=94^=88m=1Fn=D2&=7Fo/=B2 = E=AD/=01}=E9=C8=C4u=C8=ACJ_=03=FAQ=9B=CA=82=F1=CD=C0=81=05=1CX=DD=D0=19p= n=D4=03=9C=01=16=98=91=CBZ=8C;A=02= =9D=A0=E5d'=CC=F1=A0|m@=01=80=A0=F5d#=CC1`=F9=90=92=14=90=08=DAMv=C2=1C=0B= ^=0D=0C=00=81`=18e#=98n=0B;\=03`=1A=8C=98=E8=83nO=93=B6=A7=FD=0A= C=C0=C8=FA=1D=A7R6=9A=00=9A1o3=94=CC=D6/=02Va=8A=BA=86=F6=0Bq=80=88=D4=95= =AB=DE^=03=9FF=AE=FDYq8=8D=B8=E5Gad=A3=E2=C2=D0=90H=FB=BA=E6=1A=E8}=C1=14= =8D=B4=E0U=B9=81=8E=17=C2P=BD=B5=90u=AD=0D=F0=F9=13=8A=A8=D6=C2=1Ckm=00=06= =15=96=AC=D6=C2=D5=B56=C8^=CC=13=D5Z=B2c=AD=0D=D0d=92=93=D5Z=8AA=AD=81T=93= =92=A8=D6R=1Fkm=81O=AB4d=B5=96=B6=AE=B5E=B6[=EE|=ADgD=A9=F4=C7j[=A0=C7=15= =9B=AA=F6=0Cq=C5}=FC&%} = =C8=958_=F09=EA=8A=C7=7F=92:=C2=B5z=AA=EAs=F4=8D=1A=BC=3D@=B5=CA=92=15^9= 3x{dg=E3 = k=AF=D9=A0=F6=0Eh{=CD=C9j=AF=E5=A0=F6=0E=E8|=AD=08k=AF=F5=A0=F6=0E!iCV{m= =07=B5w@=CAkGY{?=AC=3D=C2=D0=8C=AC=F6F=0Ck=0F=CC=9D=91=E7k=BF=D6=E1=85z|= =EF=8C=CC!x)=F2=9E=C0=CD=80=F8.=04I=08=FE=A8=EE=81o^=86x=0A= =F5H=F0=95>=B2=89=D0=FEe=F1y=04_ = #=BB=87=08=F1=97K=FBQ=CD=3D0=F7=01=E2/=96=0E=04_ =03=CD=96 = =FEri9=AA5g=08=C5kq=B6=D9fP=BC=0A= =0F=AA=F5!=98wT=A3&<=1F=CA=03=BD.=99:=B7=F8s=08=8F=DB=F0"=B5=01=A0=E7=A5= dT=C3.=95=1C7=00=90=F8R[=1Au=E3O=EA=8F=EC,=1CY=D4=06=C6=AE=E49=90=B5=AA=C3= #=1Au%=C4=B8=FE=1C=98?E=17=F6j=1C=F6=DDg=0C0`=04=8D=BA=3D=99=7F=0E=C4=AE= rd=F3=AF=D9p=FE9=D0=FD=9AS=CD=BF=16'=F3=CF=01=E4=D1=8Al=FE=B5=1E=CF?=07=06= P=1B=9A=F9=D7=F6d=FE=050=80=DA=93=CD=BFa=C3=F9=17=C0=F8=19~f=FE=D7=DA6=9E= w=EB=D3=03=E7=1C=DA=E4>=03,=17=08p=F1=AE=04\7=9737=17=B1=08=B5=01`=08y$n= "=0F=DA=0C=0D=00=DB=1EnB=19h=F4]=0C=E2=DA=02=90=04=DC=C7 &=F1 = =98=1B=F5=81=04fA=08A=A5/=D5=B8=0F$=02=83=CA=D1=F5=810|h=00=98=04a=15Y=1F= =08g=C7} =11 c=8C=AE=0F$=1F=E7=81=04=C6Q=0A= =AA<=90=F2$=0F$0=8ER=13=E6=814=C3<=90=C0WQZ=BA<=90=FE$=0F$=F0]T=8C0=0F=14= =1F=E7=81=82=D8=F0l=1E=C0[=B3=EE=E7=A16=B0/Sz*=0A= py=CB=C6=05P=08=98=BA=89,=C0=0Dx3^}`=0A= 5=9F=0A= =02=D8=80=16b<=86=0A= =18C-=CF=E6=00.=AF=FCP=1B=01c#=C8&P[}=D2=00=08=99v[=03=B2 = 4=8C=8Fz@=03_d=C3=CF=E8=F7x=A82=1EvV=E6=10"=CB&=80=18=08x=D8=D9=17t|X=E4= =81$=C8pH=E4=A0=A7=C3"=8F=C0qDC"=F5=C4=86=C5=00=00=04=19=0Ci=1C$2,=06=80= =0A= XH=A4=9E=B8=B0=C8=03I=90=A1=90=C8AO=85E=1E@=81=84=84D=EA=89 =8B=01 = =862=10=D28HD=98=0D=18=84H=05=D9=FCg=1E,=F2=08=8Dj=CA=F9=0F4X=E4=11=16=B5= =84=F3=9FY=B0=18=00=FA?=83 = =8D=83D=82=C5=000=01=01=03=CF=A8=CF=E3=C0=AClg@ =89x=A2=C0=A2=8F# = =89|d=C0=A2=0E=CC]=06@=0A= =F9L=80E=1F=01Py~=EE=E7=F1_Q=C6=E1=8F=A6=E33=FDe=03=0E=E0=AE=8C~4=0E=12=FB= =15=03=00s=05=F0{Q=FD=02=F2=93=9E7=D9=07=02_=1D=FBIg=A9=C0=AFVG=D8+=A2=1F= =89=81=8E=FBju=04=BC=02=F9=91=88G=EC=AB=F5=81=F9K=E0Ga = R_=AD=8F=90O=C7}$=E2=11=FAju=00{=12=F6=91=18=E8=98=AFR=F7@=00D=EA#=11=8F= =C8W=EB=03=F3=9F=A0=8F=C2@$=BEZ=1Fd>=12q9=9E{=8F0=97&=9B=FB=9E=F7ju=E0=EB= =13=89=8FD=DC=8F=E7=DE#=BC=C5=C8=E6>=D2^=AD=0FL^=CF{/=8A=CF=82=BD=A3=B0`= =C0=D0%=DC#=D0=8E=ACW=CB#=B4=E9=CE=CE=FCL=D4=AB=C5q=D8=BB\=3D=91^-=0F=B2= =1E=81v=07z=B500=EA=11=F5(z=3Dq^=AD=8F=A0f$=3D=0A= =03=11=F3j}`=D8z=D0#=11=17vTv=0EL=9CQ=FC=CC=C4=AD=0Dkdoa=1D=1E=8A3=A6=B5= =19\=05G!=D3=CA=E6r=D2=CE=98Y=1B=98=C1=994=1Ez=D2=AC=0D=E0=A8I=A3=9F`=B3= =B60=836I<$=DE=AC-=00Y=10=80=93F?!gm=00=08=83=CC=9C4=1Ez=EA=AC=0D = =C8=1D=B1=93F?=81geA=00=91=90=C9=93=C4Cb=CF=DA=02=02=BF=82*=0F2~=D6=06=80= @=CA=FCI=E3=C1=0C=F3@=00=81=94=10=94F=DF=9F=E4=81=00f!S(=89=87=C4=A1=B5=05= =04=84=E5=D9<=98=87=A2=B56=02=C1z*=0A= f=D3h=E5@"4=EC&=B2`.=90=D6=FA=C0=14f"%0=90=99=B4v=00=8Ca=80R=0A= =F9=1EKkm=04=88#=97=92t=7F&=D3=DA=02=82=C6 = MI<$8=AD-=00!=10=E8=94F?=F1im=00=88=80=0C=A8/y=18 = jgg=0E=A5=1A=99|=00q=10=10U=FB=EC=9D=82Q=B3=BC=02f1=03*=91=83=9EP=8B<=C2= =C7=11O=89=D4=13=9F=16=03=08=1F'8=A5q=90=E8=B4=18=00=E2 = =A0)=91zb=D3"=8F=90q=02S"=07=3D=99=16y=84=8B#=96=12=A9'.-=06=80=18=C8PJ=E3= Qi1=00=CC=7F@R"u9=9C=7F=8D=10=B1=A6=9C=FF@=A4E=1E=E1aK8=FF=99G=8B=01 = =802=8C=D28H4Z=0C=00=01=14P=F4=8C=FA<=16-=CA@=F2d=10%=11O$Z=F4=11=08wS=B3= ?=97C=8B:0w=19B)=E43=85f}=03@x@P=12=F1=9EA=8B2=82=DF=11@i:>=13h1=80=D0w=C2= O=1A=07=89?=8B=01`=E8=03|=12=A9'=FA,=F2=C0=C8g=F4|=D1=C1%=EC=A9|=E2Ya=80= =CF=7F=A0OE=87=9E=95:=F0=F5=CF=F0Ia=A0'=CFJ=1D=C8=9F=C4=9E=14=E2 = <+}=84=FC=13z=12=18H=DCy=D4=B7@=02=05=F2=A4=10O=D8Y=A9=03)=94=C1=93=C2@O= =9D=95:=90=00=89;)=C4=13tV=FA@=04d=EC$0=90=98=B3=D2=07=BE=FD=81:)=C4=E5x= =EE-=90:=19:)=0C=98=C1=DC[ = u=12sR=88=FB=F1=DC[=84{=18=D9=DC'=DE=AC=F4=81=DC =C4=F9=92=F8<=DC<=0A= ; = p2p^=AE=9Dh=B3=92=07=12'=F1=E6=E5=EA=116+q=84y=F8=F9=81=9F=CD=9A=95<=90w= =816/=D7=EEQ=B3=12=06=82.=C1&A=AFg=D2=AC=F4=81=A0=CB=ACI` = =81f=A5=0FD]@M=0A= =F1=C4=99=95z=8A:qF=DD=CBp=93`=194=7F=DC=EFw=FBx=9FJ6B=14G=13=DF=0D=9E84= =B8o=FFn=F7O=ED=EB=AF=87=F6=F5=F6=F0=14=AF=94=E9Jw=EC=A1=EF=C7=CF=08=00=1B= =CF=BD=19*W=9D=F7=CD=CB=CA=B7=DD=DA=AC=BB7k=EC=F2=8F=D5=DA=C9F.=F5=EA=F7= =9B=9F=AB=07=89=A6;o=D3=A3^=8D=1FUD=DE=0CM=0F=AC=FD=10=D6=9F=BB=1E=B9M=FF= =B0=FE=C7=B7c=BF=D5=0D#=19^Y=B8]nVk=1D=9C=DEo=1F=DB=CD>=FF=F5~=F7=F0=E7=F6= qs=D8=EE=1E=F3O=BB=0F=DD=11c=9D=B7=F4=C3=E6=F1.=1F>}=DC~8=B4=E5=CF~=FD=C7= w=86=A37+=B6l=F2=1F7=1F=B7O=F9=B8=0D=D5N=7F|=DA=1C=0E=ED=BE=DC~=BC=EA=F3= =E3]{h=DF=1F6=7F=DE=B7=ABu=F7=F2=8DY=FE=F3=B1}<>=BE=BE=A5=F3z=F8=D8=E6=9F= =AE=7F=BB=8E=B7=D8=E5=A7=DD=FD=D7=C7=DD=C3vs?=AA=8E=B1qE=07=EB=F6l=11~=19= m=83l:=BB=16=8D=E2=A9&_=0637=EC=D1=8B=18=9E=87A=10=CE=C5=F1B=F6N>=DE!=1B= =82-D=F7Q=CE=DA=C8=CEI:*a=CD"=C6Fmd=DF=A4=13=F8=02=F2=B7=DDB=AE=85f=9D=8D= =BE)=CE=F9=B0=B6=98@6ONR;=10l=D0=01=1C=D9Bqz=17r=E8=02hD=A1@=17=D3=9B=19= =AD=EBf=E0=C8N=CA=E8=86j=08:|=1E=BC;=C0=17=FD=B54=E2iKV=C4=91]T=07u=E4=83= =E5=D0=C7=FFi/=BB=DD6=92#=0A= ?=81=DE=C1=97=B4=B1$=A6=FF=BB=81=04X=C46b,=D6@=B0=F1=9D=B2=17=8CMy=15H=A2= = =CA=88=FD=F6=E9=E9=AE=1Ev7=FF=CED=B5=17=B6(=91=C3sf=AAN=F5W=C8>=A5a=1F=97= =1F=83i=FB=0FY=A8,W=FF)=D7=F6=1F0=08=94=87=FB=0F=AF=01=ADh=D3a=80,7=E2=CF= =F0=A1Z=1F=C8=96=A3=F9=F2H=0B=DB$=0F=8C=03m=B9=F2=A8}=93=03 = =0C=03=1D=F8r`=DA=D3@"=BB=06=FFi`=DA=D3@=02i4=E8i0=C3=85m]=00=90`=1C=D7L= 0=BE=CD=000=13L=F8=13=B2=187=B9=DA=87=02f=82=95|Y=B4=AA=C9=A2=02F=81=D5\= Y=B4=B6=C9=A2=02=B2h=1D_=16=ADo=FAO=01=FDg=03{=0A= \=BB!=A8=D0l=80G]=04=95=A9=CA=8F?=C6=8B>6=1B=E5=19=B10=92=95$=FBo=CA=F39= =C4`:=A8=F6=0A= =7F=ED=F6Rz=C4=EF=BF?=8E=9Be=B3{=8DO'=BF=FBs{=D1P/l=AD=E5=AB!=DB=AC=D6=AD= =FDUA=94=AB=AE=17=EF=D3=EE9,~*=FB=E1=C7=ED=97ow=DFv=EDr=18=EF)=DF=BD=9F=BC= =FCK=1A{=FA=C9=8A=D5=B0=DF=17=E5=E9]=F2z=F1./=AB=1F=BAmT=1CYF=A7=87=B5=12= v=7F=07=D5=9A=BB=FBv_^no=CA=AB=F4~=BE=B7=FB=CDn=B7=FE:}||=D2=F5=87=F2=CB= Mz"=E5=97=EF=8FO=F1=A2=CD=97=ECr=BD=9B=AE-=DF=F9=B8=BD=FB=F1=B0=BD=BF]=DF= uw=A0l=9D=9D7=A7=9F=C1=E2=D7=B6=ED=A3B=BE=F9=A5\=E9=B1TH=F6B=1E;z(=0D=06= @@=EC=CA=B8=C7=B8=E3=D1=9B=DA=E7=E2f*\=AD=0B=1C=C0B=E6=BC=BD\=9A=B8k=AF=0E= =8C=1C=A1=C7=BC=9E=14=9F1=EFD\=C3=DA=87=8E,=A3=C22=A9;=D7=DD<=B2=04=08=EF= =98=EE^=C6E=AC=BB{=E0=E9K1=F0=A8K=D9=DF=3D@=1CRq=D5^=EA=BE=F6=08=F5K=C3=A4= n=FB=DAK = =A8;=B6=DA=87=BE=F6=D2=02;=E0=C0S{%=FA=DA#=A4=A3$W=ED=95=EAk=AF=80=E4)=CD= =A4n=FA=DA+=A0=F3=95=E5=AA=BD=F2}=ED50=F5T=E0=A9=BD=1E=FA=DAk=E0=C4=D1=82= =AB=F6Z=F6=B5=D7@=E7k=C5=A4=AE=FB=DAk=A0=F3=B4=E1=AA=BDv=07=B5=07zO{=A6=DA= =87=BE=F6=06=A0=1C3p=D5=DE=88=BE=F6=06=98;F2=A9=AB=BE=F6=06=E8|=A3=B9jol= _{=03t=BEq<=B57=FE=A0=F6@=E7=9B=C0U{;=F4=B5=B7=C0yo=05=93=BA=ECko=81=F3=DE= *=AE=DA[=D3=D7=DE=02=C9=B3=96=A7=F6=D6=F5=B5=B7@=E7Y=CFV=FBpP{`=EA=B9=D3= =DB=D52=1E=C6i=B3[=8A=BC=07B=BC?=A8=F1~b'=C8l=C2!=CB=86P=C9z=A6=E5=17=AF= =1C=D26=06=80=04=94=15=8D=C9=80=F6=DD3=00b = L8=AB=8F=AF=9BN4=DA=C0=F0=17^=AC=CE=DF=3D=AE=1E=FA=FA=03=03P=0E=9AG]=8A=B6= =F4=C8=AA'-=D7=BDK=D5=D7=1DY=F64S=DD=A5m=EA=EE=91E=CF=B1=D5]=FA=AE=EE=1E= Y=F5=02S=DD=D5=D0=D4=DD=03=C8=A1=04[=DD=95=EC=EA=EE=915S1=D5]=99=B6=EE=C8= =92g=D9=EA=AE\_w = s=CA=9F=AF=FB=9C=3D/=B4=95G@=7F=B8T=F99=B4/B>=BA&=0B=018=F0=B4<_=FCY=CB=96= =C8G=D7=DE=00=00=3D=DA\=EA=809=16=AC=EE=9F=01p=E8h=C7=D6=04=DA=DB=FE=19=00= =13@=07=C6>0=C3A=1F=00=ADh=04[=1F=18=D5=F7=81=18=80#=C0h=C3=88^=C6=F8=D6= =01p=08=98=8B=87=D0=AC=05=ACo=C5=08=A4=C8=06=E6.=F1=1F<=11m=EC=84=BE=10@= =1C=ACd:=0B=AD=B2=AD8p = =94=CD=89E=DF=CA=83=12=00Q=B0=EE|=1A=97y=C8=8C=BB=C8=9CED=A8lA@k=88=8B(=1A= =8A=ED=97=ED =B9 &yd =D1y=0Bbr`l%=0Fd@=D8=B0=E2S=F7=B9 = &=03=C0<=16!/a<=0E=E4=E0=9B=FA#k=88=94l=EAJ=B7=F5G6=91=B86=F2=D5?=AD=03=93= <=B2=888=CDW=7F=E9]S=7F = =C4O=0D=03c=FD=95h=F2/=81=00*=C9=96=FFH=F7M=FD%=10@e8=F3=AFl=95=7F=89,D=8E= 1=FF*=B4=F9=97=C0F=A4=07=CE=FCk=D1=E4_=02=F9=D7=EA|=FE=E1#0=FEy=AF=AC=90= }=C0\=8C>.=EE=86=E6=D1+=A0=F3=B5=BF=94}\>S=F5=A4=8E=D0=97=B8=18|X=DEd=80= =D8=EB=03=E8e=D4=F9=DC=E3=E2:T=CA@=E6Ld%=B6=8E7=CE=B4=85=072g=BCg=CC=9C=1D= DS{=E0=D0=B3=82O]=BA=B6=F4=08uj=C18s=AD=A9r=AF=81=DCY=EB=CE=D6=7FiU=81=DE= hc=06=F7=8A=E0=0BG=0B=0D,a#=FAF=FE=E2=E2=DEF=1Ea=CF=8C=BE,=0E"=F76=F2=08= y&=F4eQ=CF=DC=DB=18=00bH=E8=CB=E1 = soc=00D_=16=F5=CC=BD=8D<=C2=9E=19}Y=1CD=EE=AD=E5=0Dp=FCf=F4eQ=CF=DC=DB=18= @=C83=A3/=87=83=CC=BD=8D=01 = =FF#=FA=B2=A8=AB=83=FC=1B=1C}Y=1C=D86=FF=06=00=80=8C=BE,=EA=E1 = =FF=06=18@=84=BE=1C=0E2=F76=06@=F4=3D=A9>=8B{=1Be=00=00=08}=19=C43=F76=FA= =C0=E8=C9=E8=CB = =9F=B8=B7V=B7=08z=8A=F3=C1=9F=CB=BD=8D>=02=A0=EAL=EEgqo=A3=8C=90gB_=8E=8E= '=EEm=0C=00-O=E8=CB=E1 = soc=00D_=16=F5=CC=BD=B5=BC=03F>=A1/=8B=03=D3=E6=DE=01#?=A3=EF = =F5=FF=9F{=BD)(-=1C=90=BF=C4=BD~(=CE9=D0=B7v=80=B0'=A1/=93=89=91~k=07@=10= =88~=99=0C=10=00W=1E<@`=05=80yL=10=03=D7=1E=00=08K=0C=CCd=800=B8v=00D=B2= `0=93=89=91=84k=07@*=89=84=99=0C=10=0C=D7=1E=10=1A#=18=E61A<\{=00R=99x=98= =C9=80:=98=0B=1E8=1D=0A= =123=99=B0=ED\=F0=00=19=11=153=19=08=07s!=00s=A1=801=8F = b=E3=DA=030=17=12=1B=9F10=0F=8Fkq =0C=05=8FY=F4=89=90k=0B=00=A9=11!=B38=C8= =90\=1B@HM\=1C=08=B39=B9=B6=00=A41q2=8B=FE=88=CA=B58=10DBe=9E=0C=14Z=DE{= =90=03=10=C4B=CB<&=08=98k=0F=08=B1=0A= >=03=C4=CC=B5=03 = =8D=85=99=99L=18=DD:=00=0E&=C2=E6=93=06*r=9E=83=CDN=90=05`=1E$f=B6=AE=D8= =E6`=E6I=1E=C1U=02f&=07#0O=F2@=18=89=96=99=D4=89=96=8B=011=03=95y=1C=10*= O=06=10J=1D9=99I=9D8y=92G=10=95 = =99=C9=C1=08=C9=93<0=02=88=90=99=D4=89=90'=03=08=9A=12=1E=F38 = <=9E=0C=00=F9Ol=CC=A4=AE=DA=FC=0B = =FF=05=8C=99=1C=D8*=FF=02=E1r=C7=98=FFB=C5=C5=80=9C=81=C4<=0E=08=89'=03(= =0F=9FQ=9F=C7=C3=9320y=0A= =0C=B3=88=13=0CO=FA=C0=E8!=12f=91=CF$<=A9=CF=C0`=0E=F9=82=C1=93>=CA=C0,=E2= #=03O=CA8=00=F3t|=01=E0b@=CD=A0_=1E=07D=BF=93=01 s }=99=D4 = }'y=84=BC=89{=99=1C=98*=F7=0A= =87=DE=93=EA=15=F4F=1Bs=B8=D7=8C_=9C}=A0=E4k=14=1B=F6V=EA3=C0=97=C3=C0H=BD= =95:=90~=E2^=0Eq=82=DEJ=1F=E1n=C2^=06=03=C4=BC{}=0D$0Q/=878!o=A5>=03z9=0C= =8C=C4[=A9=E3=CC=CB!N=C0[=E9=CF@^=06=03=C4=BB=95>J=BC=1C=E2=AA=CF=BD=9E=01= =BC=1C=06l=93{=8D=F3.=87x=E8s=AF=81=DC=17=DCe0@=AC=BB=D77(=ED=9E=12=9F=87= =BA=95=F0=0C=D8}=B96=91n%=8F=B3=EE=CB=D53=E8V=E2=C0=C0)=A8=FBb=F5=C2=B9=95= <0o=12=E9=BE\{=C4=DCJ=18A=EC=0C=BA=0C=BD^(=B7=D2G@=9B8=97=C1=00A=EE^=DF=02= =9C=9D0=97C=9C=18=B7RG = =9B(=97=C3=80i=F2n=11=C6=CE=90{\=BC"=DC9x=9B=891[=002=9F=F8V=85=D5=CB=11= =BF=10nm=00=C8}A\=1E=0F#=E4=D6=06=10=C2=CF=94=CB=A3O=9C[[@0=9F@=97=C5=03= =A1nm=01=18C=89uy=F4=89vk=03=C0=1C*=B8=CB=E3a=04=DE=CA=80=03=06=11=11/=8F= >1om=01=98F=05zY<=10=F6=D6=16=80y=90=B8=97G_=1D=CC=03=07=CC=83=82=BE<=1E= l;=0F=1C=B2y8=BEyP=F8=B7=B6=00=8C=A4=02=C0,=1E=08=81k=0B=C0HJ=0C|Z=7F=1E= =05=D7=DA=C0,*=18=CC!O = \;@6=10=7Fa=16=CCe=E1J=DF=03=B3=A8=C00=83=81=82=C3=B5=03`=14%=1E=E6=90=D7= =A1=D5=06=B0=88=90=98=A5=FB=0B=14=D7=16=801X=A8=98=C5=03qqm=01=18=84 = =8Cy=F4 =8Dk=03=C0 = ,l=CC=E3=C1=B4s=C0=03c=90=F0=98G=DF=1F=0C=02OcP=9E=B1=10TzrB=A7K=1E=B7w?= =DEn777=BBO=DB=0F=9B=EF=F9rEv=FC>=14?7_=1C=8D=C6=AFu=F4=DE=C7=FC=9E=DE=8B= =9EdI=D2=F6t=FBo=1A=BD=E3 = =E9=D3=13=CBv=AF=17=EF^/=CD0,>=BC=FE=FD=D3/{=CD+Q=FBy=D3z=15+1=BDw=BDx=FE= c=13=BF"=1AQ=8B=DD=B7=FB=D7=CBx=DD=CA-=B67=E5=8F=E9=FD=FC=C7=FB=CDn=B7=FE= =BA=C9=8A=EB=87/=CDG=F2=CB=CD=D3=D3=F6i=FA=E5=FB=E3S=BCd3}p=BD+=AF=FE=88= =8F=96^~=1E=9F=F6=ED=E7=DB=CD=C3=F3.=7F=F5^|]=A4=C7=B2=C6k=FF=13=FF=FD=F2=EA=FA=F7=E1=D5=97WWN=A5= =F9n=E28=B8=BF=CA=B6=E2=CB=BB=AB=7F=96_R=0Ff0=1A=FF{=DA\=DD\=FDO=80=01=00= =A5=E5=D9s=0Dendstream=0Dendobj=0D114 0 obj=0D5967 =0Dendobj=0D115 0 = obj=0D<< /Filter /FlateDecode /Length 116 0 R >> =0Dstream H=89=AC=97=DBn=1C=C7=11=86=9F=80=EF=B0w!=1Dp=DD=E7=03=02=03=86=14=E4`=C4= @ = =10=C8=85=EC=0B=9A=1CJ=93=90\aw#Yy=FAtOW=F7V=0F=97=CB=1A=B1`@=12=BC=3D=FD= =FF=D3=7FU=CD=D7o=AE=CE=C4*=FF=B7=FDp&W=E3=EA=EC=FBw=C3=FD=F5~=FC<=BC=DD= =DCo=B6=E3=C3=B0=DF=8E7=AB=EDx=F6=FD_=D4J=AE=AE=EEV=97b-=A4snuu=93=9E=BB= =FA=92=FF=D8=AE=CE=E2=B4M\E=BD=F6ve=95=CD=7F]=3D=9C=9D=BF=1B=EE=EE=87=9B= =FDp=FB=F3=C5=D5=BF=D36=E6=B0=8D1F=E7m=CE\^=9C=9F=9F=FE!=8D[=AB=BCG\=97-= =BE=CBOb=DD=A6&=AD=C6Z?=14 = pz&=D6Q:=9F=0D=DE=9E=9Do=87=CF=C3v7=BC=F9=BA=1F=DE=8C=FB]Y=A9aeX=A7=9D=EB= =CA=1F=E7=BB=A0=DF=C8/=A1=ACX?y=87&x=F4e=94=C5=07=F7=FE=FC=CF=17=97V=88=F3= =BF]=FCz=F5=D3A=F3Lb?=DF=F5^=E5Z=04=AD=CBo=EF=CF=AF=1F7=FB=8F=C36m=13=F4= Z=A7=13=98=92=187=8F=F3=1D=F1c3=A7=E9=F5=ED=E1=B7=7F=94=DF=1C=FCv=A9=D5=DA= =E4#=BE=84=BF=F3=9A=DFkZ=CF=9CL=0CS=BA=C2=D7=D4T=D9=D4=9F8=1A)=F2=13fZ=FE= =C7=DE=83(=9BS=94=A5=F4X=D7=10tU)=E7=D7Kk[6j=EAR=13=E4=A1=13^/o=E7=87.-A= =DE=05=A6=B7=0Fb=FE=F6=9E = =1F=E5=C9=B7Oe=A9=89=06=94=D0=F3=F7=0F/=1BP=F2t=FAK=0C(=B7=EE=8B^=10=F4=F5= =E9=F8=97=E8=9B=D8=A9K=82=BA=3D=9D=FE=12u/goO=E8y=15=F8=E2=8F=A6S=8F/=AB= k=C1=96=BD=96=B3=EC5=E1=ED=B5b=CB^=EB.{M=98{=DA=B0e=AF=DD,{Mh}=ED=D9=B2=D7= =A1=CB=DE=10=FANG=B6=EC=8D=98eo=08=9D=97>=A5\ooT=97=BD!T=9E=D1l=D9=1B;=CB= =DE=10=B27=8E-{=E3=FB=EC = 3=DF=04=BE=EC=E3<{=C2=DC=B1=82-{+=BB=EC-=A1=F2=ADb=CB=DE=9AY=F6=960w=ACe= =CB=DE=BA.{=EB=08=EA=9E-{=1Bf=D9[B=E5=DB=C8=96=BD=13}=F6=84=CAw=92-{=A7g= =D9;=C2=DCq=86-{g=BB=EC=1D=01=B5=9Dc=CB=DE=F9Y=F6=8EP=F9.=F0e=1F=BB=EC=1D= =81=F4=BD8=95=FD=A5=F3E=FFR=96=CB =89=F9=13@=E5=19=98=FF=9Cl=10=1AP=CA = =D3M=88=D5=FCk=CEA*=87=F5 =C3=17ni\=FA =A2=F0 = x=CAE=D7=C6=93=F2=F4+=97=97X=9Ar=D9=0C=B9iy=C4c=9F=BD'4=80J=B5=C7"=AE$=8E= =DD=13=E6n=B9=9C=F1=88=EBY=E6=84=AA=CBw3=1Eq=873=0F=94=1B=A6g=CB\=85>=F3= @=B9bF=A6=CC=B5=C0=99=07=CA=FDJ=B2e=AEU=9Fy = =0C=DC|'=E3=11=B7]=E6=84![.d<=E2~=969=013=F2}=8Ci=C0=EA=D8=A5Nh=B5r=1Dc=92= 72N_=AB=E6 =12:._=C8=B8=F4=130=F9N=9F0=E5=CB=95=8C=CB=813=B3=13 = =0C=FA|)=E3=D2=0Fnv=02=84=D6+=D72&=07V=CCk=80r=CF=90l5`=F5=BC=06(=F7=0C=C3= X=03=D6=CEk=800=04=F2=E5=8CK=DF=CFj@=0A= =CAE7=0A= F=D2tBw=06(=BC=FF=E2=F7g=89=BE=9AU=A1=14=84FpF1=D2=AE=B3v=DD[ = t=82s=A7:=E12=DD=C9=8Ct~=BAw,=B9t=04=01=16=08=A5(=A5O#i=BA|=BD=FE=C2=11=CB= =81=82=BC$ = =904=E5=CA=C3=E4=C0:$O=B9o=B8=B8=E6S=0F=AA4U5@=B9u=C4r=E5=E2q=A0D=C0=F9K= =CA=BDC)6um=FA=FC =1D=A0=D2%=91/=FF=E9=06=D0=E4 = =D5=AF=BC=E1=CB_=05=DF=E5=AF=08=83X=0B=C1=98=BF=96]=FF+B=03j=C5=D6=FF = =EA=BB=FC=15=E5=1Eb9=FB_;=D4=FF=8AP=FD=DA3=F6=BF=8E}=FF+B=FD=1B=C1=D9=FF= Fv=FD=AF=080d=F4=E9=FE'_=86=D2=FFF=CA=84=DE3=F6=C5=D6=A7=8B{=D1=1F=3D=E5= 2=14^=EA}=BA<05=A8k=0A= =81=C9=17=1B=9F,o=95=EA=1AO=13=1A=CF=EA=D3}O=177=11)=13>y=D6)=BE=9E=B3=DE= v=C1k=CA=FD#=04=C6=9EsBv=D9=13z=CEI>u=E5=FB=E8 = =8D=E7=D2=FD=87o=E6:=8B=FA=DE=10*=DF9=7F2=FF=8C=BD=E9=97=0C=BD=C9=C6=12=EE= u=B6=92=B44=14=F6=CC=E8=EB=14=1B=F7by=0A= =FA=01=FAr8=C8=DC=8B=E5 = =9F>@_=0Eu=E0^l=80p=FF=AA=E8=CB=E0=00=B8=17=1B=A0=B0gF_=0Eu=E0^,OaO@_=0E= =07=99{=B1<=E1=F3=07=E8=CB=A1=0E=DC=8B=0C=D8=05=E8=CB=E0=00=B8=17=1B=A0=B0= =A7=E2=E9=FF=CA=BDX=9E=D0=FF=15}9=1C=B8=BE=FF-=1D}9=D4=E3=93=FE=B7=0B=D0= =97=C1=01p/6@E=DF=E7=D4=97q/V^=80=BE=AF=17=07=EE=C5=FAt=F4}=BD|=E1^=A4=EE= =16=A0=EF=AB=E5+=F7b}=C2w=7FB=DF=D7=8Bg=EE=C5=CA=14=E8.=E8=CBP=F1=95{=B1= =01=0A= {=03=FA28=00=EE=C5=06(=EC)=99=D4=81{=B1<=A1=F0+=FAr8=B0}=DF{:=FA=1EW=FFv= =EE=B5=AA=A2=B4=F4T=EE5=BE:=E7@_=EC=80=82~=80=BEL&2=FDb=07=84=8F=0F=D0/=93= =01=00`=EC=81=F0=FD=A9=00=CCc=02=18=18{=A0@hf`&=03=80=C1=D8=01=85C=01=83= =99Ld=12F=0E=02a*=03 3=19=00=18=C6=1E(4=060=CCc=02x=18{ = t=E5=C4=C3L=06=F4=93=B9=10=08]Y=91=98=C9=84=EB=E7B = =F4$P1=93=81=F8d.D=C2W=A2=821=8F `c=EC=81=F0=8D=98=D8=F8=84=81ex=8C=C5 = =0DY=F1=98E=1F=08=19[ =80=12=102=8B=83=02=C9=D8=00a TH=E6pP9=19[ = =CC=83=89=93Y=F43*cqB#=02*=F3=F4@=A5=E5=83=07%(=17=15=A0e=1E=13=00=CC=D8= =03=A1=11'`f2=00=CC=8C=1D=10=BA=B123=93 = kz=07=84f=04l~=D6=00"=E7%=D8=AC=03X=A0=10kf=E6=048=8A=8F=99=9B<=05=15=01= =98=99=1Cd`n=F2=04J=04ZfR=07Zn=06=08=90XQ=99=C7=01=A0r5 = =A3`=E2d&u=E0=E4&O=98=02=15=92=99=1CdHn=F2=84=06=04BfR=07Bn=06=16=E01=8F= =03=C0=E3f=80B=A6=8A=AD=FF+=1B7y=0A= =96Z=CE=FE=9F=C0=B8=C9=13=FA=1F=A8=98I=3D=F6=FD/ =FD_=91=98=C7=01 = q5=A0=A8<|B}=19=0F7=E5=050=CC"=0E0=DC=F4=E9$=CC"_H=B8=A9/=C0`=0E=F9=8A=C1= M=9F=CA=C0,=E2=99=81=9B2a=E2=00=00=F3T|=05=E0f=80B=E0@=BF<=0E=80~=9B=01=C2= =D4=99=D0=97I=1D=D0=B7=CA=EB=05=DC=CB=E4=C0=A2=BE=D7t=E8}V=1DAo=B2=B1=84= {=95=AE=1C=9DP=84=88=BEJ=B0q/=96=A7=907=A0/=87=83=CC=BDX=9E=D0=86=80=BE=1C= =EA=C0=BD=D8=C0=02=F4ep=00=DC=8B=0C=18*=FAr=A8=03=F7b=F9=05=E8=CB=E1 = s/=96'L=01@_=0Eu=E0^l=800=07*=FA28=00=EE=C5=06(=EC=ADx=FA=BFr/=96=A7=90=B7= e=EB=FF=89{=B1<=1D}9=D4=E3=93=FE7=0B=D0=97=C1=01p/2` = =FD?=A1=EFs=EA=CB=B8=17+S=A0=DB=9En=FD=C5=DC=8B=F5)=E8=1DN=F6=FER=EE=C5=EA= =0B=D0=F7=D5=F2=95{=B1>=15}_/=9E=B9=17+=D3=D1=97=A1=E2+=F7b=03=0B=D0=97=C1= =01p/6@E_=0Eu=E0^,O=989=15}9=1C=D8=BE=EF=1Da=E2=00=FA=1EW=FFv=EE=95=A2=A2= t=02=01"=F7=96=E1=CB=85=BE=D8=01=85=BC=01}=99Ld=FA=C5=0E(=F0]=E8=97=C9=00= =000=F6@!p=00`=1E=13=C0=C0=D8=03a L=0C=CCd=000=18; L=84=8A=C1L&2 = c=07=84=A1=00$=CCd=00`=18y=F0=84=9E=AC0=CCc=02x=18{ = P=C1=C4=C3L=06=F4=93=B9=E0)W=02=CB9=17&*=C6=0E(w=02=CF8=17*=18c=0F=84=D9= T=C1=98=C7=04=B01=F6@=98M=13=1B=9F0=B0=0C=8F=B18a(U^=EF=AB=9E=14=D1=E7g=F2=BFEPfu=F5eu=A6=D6Zx=0F=D6Vw=9B=FB= =FB=CD=97]}=C2=99=EC=E0&=0B=1A+=F4=F4=80=EE=1E=18=A7=B5=E9=F7=94=94=AB=9B= =1B=EF=E3=B4V=AC=A3=D2=B2=AE=DD=7F=1C=EA=C6V&=0C*=1Bk=A5=C3=B48=15=9F=0E= =B5cWo=DF=BD=85=9D=A5k=1Bk=1B=AAk=99=16=D7=B57=9B=87O=FF=DD=0F=B7=D5=8Av= =AAYI=BE=A6'Lg=BB=1C=CAs=B6=E7=8E=CB=D9=1D\=08Y=1D=A7=E27u=F1v=B8=19=C6=CF= =C3=B6>aBhO=18 = ggr=BB=C0=03=C3=EF=9F=B6=C3n=D7|=0Bw=F0=92=EE=AA=C7l=D7=D3=96=DE=EA=B6=B9= =F3=0E=EC=E0C=B9=AEg-=B46u=AD=B4!@2=DEEU=D7~=DA=DC=7F}=DC<=8C=D7=F7=EBV,= 2=B4=A7=84=D7=E5`=9A=F57=D7=BB=F1=E6=FA=FE=FEk]=AE=8A=9F=E9-=84=83=97=C5= =E1=FF=BDm=9C=AE?m=E3=E9=8D';8=FB=FD=F5=7F=86S=F9=A8=A7=F9=88=A8e;=BB`=F5= =91=8A=82|Z=95=A4=80=DA=CE=E9=0D=C1s:=95=DA=A8=AB=87=94=CE=F5=87V=02=A1U= =95=F6=C6=C2=FA=90=12mG~=B7o=F1=A7=FC=9B=1F=E1,T=ADH=A7~=F0sw?=DC=EC=C7=CD= #<=A2=91#+<=E4=7Fx=E4}Rx=BC=BD=B8=F4>=FD=E3=F6=F6=E2=D7=AB=9F=A6=13=D5=C1= =D4.=95=D9=3D=BC=08*M=ADZN*=C6=1A=94=F6=FEH=DD=C8?=D4"=D3F=B4=B3=B7=BA=1E= )=AE=C7=FD=E6d=1Bu=FB=1E=B2=D2=EA0=87=D2=97=FFHT=0F=9B]m=D0=A4=D6=0EEy=A1= =E0 = =95=16m=E7=DD=F8=E1q=BCK=F5=F8=D8=1E2r=CAJL=AB/=9D)=BB_=CA=D2=7F=F9=A9=DF= =C6}=1Bs=D2=1F=C2Ji=C5#=8E~9=DF=7F=1CO=CE=C5>=DCo=98=8BY=DC=AA=C3=CB=1A+= =8F=18=19=EE=EER=D1=C0=FA"^=D6=17O=93=11=BC~s=D7=DE=D2=8A=D6"i.=D6=CD;=D7= =8F=E3>=0D=81=F1=7F=E3=E3=87S=FE=D3TJu=FF=CA=B9~=AC=BC=FACl=E5ul=96=F6=CE= S=D5=FEr=D1>=AC^=D5i=A4|<6=AB=FF=D4ZN=A8C=CB=A9:=8C=F0=94No=F7=D8F=A9=F4= =87Q=EA=8D?=E2y=F7q=BC=DB=1F=A6b9=BCi=D4iud=F9=FDpX}=AC=8F=FB=C3+}=9C7v=07= =DF=C6=C2=A7=BC=EF=B7O=9B=DD=98=87=CB=8E8]=CAp=A9=C3KG4=BD=EA=81w=9F=8Ca= {=B7=D9>=9C=AA=12}=ACJ=A6o=A9m=FD=AF=E2=B1"=B9=1D?=8F;4=18=E1`&=EB=DE=05= =D8=1D?=F1[=FD=12=C9=E4=3D=C0)=06%=ED=91=A9=F5=D7u=A1)=F5=94=E8=CA=C0=A8= X=17=F5DS=CAO(=F5n=B8)=CF=19=A0=BA=94dhT=F7C=B7gO|=FFl=9F=D7=9F7=B7e=9D=86= u=89=1B=0F{=FC8=DF=E3=F0=DB=FB=84=8D=97!=9D=E8=F9=FFY/=A3=DE=A6a = =8E=7F=82|=87>=B6=85T=F69Nl=89'=18=DA=846 m}=1B = A=9A=A1=C2=DAJm'=E0=DBs=B6=E3=C4N=D3=D8=D5=F2=B0.=DD=92=FC|=F7?=9F=FF=F7= m=96R=E5=EF=A6X=0C=EA=04p=D7=D3=0C_^=AC=FA=F7=EF=93H=9D=CC=CF=07= 2=7F=CB=C0=CF=04m3q;=94=ED=B7=B3=14=DF=82=E8=EB=19Q_8!S=14=EF=E5=F9=E5=E0= =AFE=95g=9D=18I=9BL~=01=9E=9F-=B2=C6_BW%w=05W=B3=148A=BD=FC=D0=F1=08k1=9D= =D0=B1=014b>N=D5=86K=B9=CE=9Fj=BA=F5e=E3=95=EB=EF=E8=84=EB+=E7=FE=C6=CA=EA= =B8=D1u=DA=9Bgi=AEk=AF5=8C]e=84[=D0'e=E8=FC=EF=D6=1F=91=D2\=98=D5=A7`"T=F7= Po=F4=F2=A5}=CD=88E)S=B3=15SG=FD=A6=D1ah=C2=A3T=9A'=B8=1D=CA^=C5=C7=B3=C0= =C2Y=04=1C;=DAXd=AEw=AA=85=F3=088=CF=CD=13=E3=F0s=DD=04j|=1E=81/=F8b<=BA= =10=AE=EEE=04^=0E=C3=9Bn=12B=03=1E=B9=96+=C2\=A0,=94=F5x4pWsJ#=F0,=0F=95= {<>=F3=92N#v=1Bp1^=F4=85W=F14=A2=E6@=D0=F1=A2=97^=AB=A1=11=DA32=9E=F6=8C= =FA=DA=CB=08<=8C=A7=3Dc=9E=F6=10Qz,=0Bj=7F=C1=8Eg=B9=A7>D=A8=CF=8A=A0=FA= =97,@d-=3D=A2=E10=19=14=FF=02:=8EXN=BB=05q=DE=93=F8=9E=17=C7&k=E8=D4Q=FF= a=87c=E7a=B9=BB=A9=FE=FA'=BAhK=E1=C4=BCz=C6=B2]=0D>>=0Dstartxref=0D61992=0D%%EOF ------_=_NextPart_002_01C20D9E.520490E0-- ------_=_NextPart_000_01C20D9E.520490E0-- From owner-ips@ece.cmu.edu Thu Jun 6 22:13:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26056 for ; Thu, 6 Jun 2002 22:13:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g56LnpU13013 for ips-outgoing; Thu, 6 Jun 2002 17:49:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g56Lnmw13007 for ; Thu, 6 Jun 2002 17:49:48 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g56LndtK031430; Thu, 6 Jun 2002 23:49:39 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g56Lnck57270; Thu, 6 Jun 2002 23:49:38 +0200 To: "CAVANNA,VICENTE V (A-Roseville,ex1)" Cc: ips@ece.cmu.edu, "THALER,PAT (A-Roseville,ex1)" , "CAVANNA,VICENTE V (A-Roseville,ex1)" MIME-Version: 1.0 Subject: RE: iSCSI CRC inconsistency X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 7 Jun 2002 00:49:34 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 07/06/2002 00:49:37, Serialize complete at 07/06/2002 00:49:37 Content-Type: multipart/alternative; boundary="=_alternative 0074C74CC2256BD0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0074C74CC2256BD0_= Content-Type: text/plain; charset="us-ascii" I did it already for CRC - it will appear tomorrow on 12-97 - Julo "CAVANNA,VICENTE V (A-Roseville,ex1)" 06/07/2002 12:08 AM Please respond to "CAVANNA,VICENTE V (A-Roseville,ex1)" To: "THALER,PAT (A-Roseville,ex1)" , Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, "CAVANNA,VICENTE V (A-Roseville,ex1)" Subject: RE: iSCSI CRC inconsistency Julian, I concur with Pat's request for explicit mapping of the bits of the remainder polynomial to the bits of the CRC. I had pointed out the need for such explicit mapping, to resolve ambiguity in the process, in a memo on Aug 22, 2001. In that memo I also objected to the bit reflection but I later retracted that objection. I also outlined, in a memo on Nov. 27, 2001, how I would describe the CRC process at the transmitter and receiver to resolve the ambiguity. The particular step in the process that Pat pointed out is missing from the iSCSI spec, is the reversing of bits (bit reflection) within each byte of the remainder of the modular division. As Pat pointed out, the examples shown in the spec *do* assume this bit reversal, but the process steps in the spec seem to indicate no bit reversal. The wording that Pat is recommending seems accurate to me and is a good alternative to what I had suggested. Regards, Vince -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Wednesday, June 05, 2002 10:29 AM To: Julian_Satran@il.ibm.com; pat_thaler@agilent.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI CRC inconsistency Julian, Yes, magic number is stated in polynomial order and the accompanying text says that so I have no problem with the magic number text. It is only the description of how the CRC is placed into the message that needs correction/clarification. As you say, hypothetical wire order is not relevant. We need to specify with respect to iSCSI's defined word order. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 05, 2002 10:21 AM To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI CRC inconsistency Pat, I was referring to a hypothetical wire order and that matches the order I stated in the first list element. I will try to map it to the word order as the wire order is not relevant anyhow. The magical number is however a polynomial and not a word mapping. Julo pat_thaler@agilent.com 06/04/2002 11:31 PM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: iSCSI CRC inconsistency Julian, There is an inconsistency in the description of the CRC32. In 11.1, the final paragraph on page 207 is incorrect. The paragraph says: - The CRC bits appear after the message bits with x^31 first followed by x^30 etc. (when examples are provided, the value to be specified in the examples follows the same ordering as the rest of this document). At the top of the next page, it describes the magic number CRC check where one runs the CRC generator over the data or header plus the received digest and gets the magic number: - A receiver of a "good" segment (data or header) including the CRC built using the generator 0x11edc6f41 will get the value 0x1c2d19ed as its CRC (this is a polynomial value and not a word as outlined in this draft). The point of the magic number algorithm is that it uses exactly the same algorithm to check the CRC that was used to generate the CRC. When running the check, the received CRC is run through the generator with the same bit order as the covered data. Therefore, this check only works right when the CRC is appended to the data using the same bit ordering within a word as was used when sending the covered data through the CRC generator. The examples in B.4 show the bits ordered as they should be and page 207 is inconsistent with them.. Specifically, data bits go through the generator from byte 0 to byte 3 of the word with each bit going through bit 7 to bit 0. Therefore, paragraph on how the CRC bits are placed in the field should be: - The CRC bits appear after the message bits with the x^31 coefficient in bit 7 of the first byte (byte 0) of the digest continuing to through the byte the x^24 coefficient in bit 0 of byte 0, continuing with the x^23 coefficient in bit 7 of byte 1, etc. (When examples are provided they show the CRC as it appears in the PDU with the bit significance used throughout this document. That is, bit 7 of each byte is interpreted as most significant though it is the coefficient of the lowest order CRC term in the byte.). I have checked and this order matches the examples in B.4. Regards, Pat Message-ID: From: "CAVANNA,VICENTE V (A-Roseville,ex1)" To: 'Julian Satran' , 'Mark Bakke' Cc: "CAVANNA,VICENTE V (A-Roseville,ex1)" , "'Pat.Thaler@d12relay01.de.ibm.com'" , "'ips@ece.cmu.edu'" Subject: RE: iSCSI CRC: A CRC-checking example Date: Wed, 22 Aug 2001 11:42:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C20D9E.520490E0" Julian and Mark and others, After I took into account the bit "reflection" and the byte order (Big Endian on Bytes and Little Endian on bits) I did finally obtain, using polynomial math, the (corrected) results you show in the CRC examples. The results have also been confirmed independently by an implementor here at Agilent. I am the one who originally suggested to Julian that we specify the CRC algorithm the same way as in ethernet even though for iSCSI it is not really important to initialize the CRC register to all 1s and to complement the CRC before transmission since there are other means to detect extra or missing PDU bytes. However I had not realzied until recently that conformance with the ethernet algorithm implies bit reflection. I had not been aware that in ethernet the bits are sent out on the serial link with the least significant bit first AND that the corresponding message polynomial is formed from the bits in the sequence that they appear on the serial link; thus the need for bit "reflection". Now that I understand the need for bit reflection (taken into account in the rocksoft parameterized CRC generator by setting the in and out reflection flag parameters to TRUE) I am not sure I agree that we want it in iSCSI. The penalty for full conformity with ethernet seems too great. If people feel strongly that we must keep the bit reflection I think that to make the existing documentation clear and unambiguous we would need to explicitly show the mapping of bits in the iSCSI PDU to coefficients of the message polynomial that represents the iSCSI PDU. We would also need to show the mapping of the CRC bits to the coefficients of its representative polynomial. If you don't agree I will elaborate further later this week to try to convince you. My objective is to be able to easily and unambiguously describe the polynomial math behind the algorithm; right now, with the bit reflection and without the explicit mapping it is awkward. Vince Message-ID: <01A7DAF31F93D511AEE300D0B706ED920CF705@axcs13.cos.agilent.com> From: "CAVANNA,VICENTE V (A-Roseville,ex1)" To: 'Luben Tuikov' Cc: "'ips@ece.cmu.edu'" , "THALER,PAT (A-Roseville,ex1)" , "CAVANNA,VICENTE V (A-Roseville,ex1)" Subject: Re: iSCSI v8 CRC32c Date: Tue, 27 Nov 2001 19:39:49 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C20D9E.520490E0" Luben, Your questions may have already been answered by Paul Koning who has apparently reviewed your code in detail but attached, as I promised, is a Mathematica worksheet (pdf format) that produces results consistent with the iSCSI spec. You do not need to know the syntax of Mathematica in order to follow the process, as I have inserted lots of comments. The example I describe uses, as data, 32 decrementing bytes. This is one of hte test cases in the iSCSI document. I have added an undetectable error pattern which does not change the results obtained at the receiver. I think it would be useful to include, in the iSCSI document, such an undetectable error pattern. I am considering writing an informative Internet Draft describing the process. I would incorporate the contents of the attached worksheet and also explain the theory behind the process. This should answer such questions as why is the expected remainder at the receiver the constant 1c 2d 19 ed in hex. If you or others have suggestions let me know. For those not interested in the math I summarize the process below. Vicente Cavanna Agilent Technologies The symbols I use: ------------------ G is the iSCSI CRC32c polynomial. L32 is the order-32 poly represting all 1s. F is the poly representing 32 decrementing bytes which I will use as my test data. ReflectedF is the poly representing F, after reversing the order of bits within each byte. R is the remainder of the division performed at the transmitter. ReflectedR is the poly obtained by reversing the order of bits within each byte of R. FCS is the complement of ReflectedR. This is the CRC that you would compare with the iSCSI document. In the case of this example of 32 decrementing bytes the FCS is a7 e4 e4 ae in hex. M is the transmitted message before injecting errors. Error is the error pattern that I add to M. I use G+x^5*G after applying reflection. Any linear combination of Gs will similarly be undetected. M* is the received message. ReflectedM* is M* with the order of bits within each byte reversed. Rec is the computed CRC at the receiver. You would expect 1c2d19ed in the absence of errors or if error pattern is undetectable as is the case in my example. The process, for the case of no errors, is as follows: ------------------------------------------------------ At the transmitter: ---------------------- F is the data. Reverse bits within each byte of F to obtain ReflectedF. Shift ReflectedF left by 32 positions. Add 1's to most significant 32 bits of the result (implemented by initializing CRC register to 1's). Divide by G to obtain the 32 bit remainderR. Note that R is not the CRC shown in iSCSI document! Reverse bits within each byte of R to obtain ReflectedR. Add 32 1's to the result to obtain the FCS (implemented by complementing). This is what is shown in the iSCSI document and, for this example, is a7 e4 e4 ae in hex. Form the transmitted message, M, by shifting F left by 32 positions and adding FCS. Note that M is derived from F rather than from ReflectedF even though the FCS is computed from ReflectedF. M* is hte same as M since we are not introducing errors here. See the Mathematica worksheet for the case with (undetectable) errors. At the receiver: ---------------- Receive M* Reverse bits within each byte of M* to obtain ReflectedM*. Shift the result left by 32 positions. Add 1's to most significant 32 bits of result (implemented by initializing CRc to 1's). Divide by G to obtain the remainder, Rec. The result (for the case of no errors) is expected to be the constant 1c 2d 19 ed in hex. In the Mathcad worksheet I actually introduce an undetectable error pattern, G+G*x^5, which I reflect and add to M to obtain M*. The rest is the same. Note that the error must also be "reflected". See the worksheet for details. <> #### TestingCRC32cDecrBytePattern.pdf has been removed from this note on June 07 2002 by Julian Satran --=_alternative 0074C74CC2256BD0_= Content-Type: text/html; charset="us-ascii"
I did it already for CRC - it will appear tomorrow on 12-97 - Julo


"CAVANNA,VICENTE V (A-Roseville,ex1)" <vince_cavanna@agilent.com>

06/07/2002 12:08 AM
Please respond to "CAVANNA,VICENTE V (A-Roseville,ex1)"

       
        To:        "THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>, Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu, "CAVANNA,VICENTE V (A-Roseville,ex1)" <vince_cavanna@agilent.com>
        Subject:        RE: iSCSI CRC inconsistency

       




Julian,
I concur with Pat's request for explicit mapping of the  bits of the remainder polynomial to the bits of the CRC. I had pointed out the  need for such explicit mapping, to resolve ambiguity in the process, in a memo  on Aug 22, 2001. In that memo I also objected to the bit reflection but I  later retracted that objection. I also outlined, in a memo on Nov. 27,  2001, how I would describe the CRC process at the transmitter and receiver  to resolve the ambiguity. The particular step in the process that Pat  pointed out is missing from the iSCSI spec, is the reversing of bits (bit  reflection) within each byte of the remainder of the modular division. As  Pat pointed out, the examples shown in the spec *do* assume this bit reversal,  but the process steps in the spec seem to indicate no bit reversal. The wording  that Pat is recommending seems accurate to me and is a good alter! native to  what I had suggested.
Regards,
Vince
-----Original Message-----
From: pat_thaler@agilent.com  [mailto:pat_thaler@agilent.com]
Sent: Wednesday, June 05, 2002 10:29  AM
To: Julian_Satran@il.ibm.com;  pat_thaler@agilent.com
Cc: ips@ece.cmu.edu
Subject: RE:  iSCSI CRC inconsistency


Julian,
 
Yes,  magic  number is stated in polynomial order and the accompanying text says that so I  have no
problem with the  magic number text.
 
It is only the  description of how the CRC is placed into the message that needs  correction/clarification.
As you say,  hypothetical wire order is not relevant. We need to specify with respect to  iSCSI's defined
word  order.
 
Regards,
Pat
-----Original Message-----
From: Julian Satran  [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 05, 2002  10:21 AM
To: pat_thaler@agilent.com
Cc:  ips@ece.cmu.edu
Subject: Re: iSCSI CRC  inconsistency



Pat,  

I was referring to a hypothetical wire  order and that matches the order I stated in the first list element.  
I will try to map it to the word order as the  wire order is not relevant anyhow.
The  magical number is however a polynomial and not a word mapping.  

Julo


pat_thaler@agilent.com  

06/04/2002 11:31 PM
Please respond to pat_thaler
       
        To:         Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu  
        cc:         
         Subject:        iSCSI CRC  inconsistency

        


Julian,

There is an inconsistency in the description of the  CRC32. In 11.1, the final paragraph on page 207 is incorrect. The paragraph  says:
- The CRC bits appear after the message bits with x^31  first
followed by x^30 etc. (when examples are provided, the value
to be  specified in the examples follows the same
ordering as the rest of this  document).

At the top of the next page, it describes the magic number  CRC check where one runs the CRC generator over the data or header plus the  received digest and gets the magic number:
- A receiver of a "good" segment  (data or header) including the
CRC built using the generator 0x11edc6f41  will get the value
0x1c2d19ed as its CRC (this is a polynomial value and  not a
word as outlined in this draft).

The point of the magic number  algorithm is that it uses exactly the same algorithm to check the CRC that was  used to generate the CRC. When running the check, the received CRC is run  through the generator with the same bit order as the covered data. Therefore,  this check only works right when the CRC is appended to the data using the  same bit ordering within a word as was used when sending the covered data  through the CRC generator. The examples in B.4 show the bits ordered as they  should be and page 207 is inconsistent with them..

Specifically, data  bits go through the generator from byte 0 to byte 3 of the word with each bit  going through bit 7 to bit 0. Therefore, paragraph on how the CRC bits are  placed in the field should be:
- The CRC bits appear after the message bits  with the x^31 coefficient in bit 7 of the first byte (byte 0) of the digest  continuing to through the byte the x^24 coefficient in bit 0 of byte 0,  continuing with the x^23 coefficient in bit 7 of byte 1, etc. (When examples  are provided they show the CRC as it appears in the PDU with the bit  significance used throughout this document. That is, bit 7 of each byte is  interpreted as most significant though it is the coefficient of the lowest  order CRC term in the byte.).

I have checked and this order matches the  examples in  B.4.

Regards,
Pat



Message-ID: <FEEBE78C8360D411ACFD00D0B74779719A892C@xsj02.sjs.agilent.com>
From: "CAVANNA,VICENTE V (A-Roseville,ex1)" <vince_cavanna@agilent.com>
To: 'Julian Satran' <Julian_Satran@il.ibm.com>, 'Mark Bakke'         <mbakke@cisco.com>
Cc: "CAVANNA,VICENTE V (A-Roseville,ex1)" <vince_cavanna@agilent.com>,         "'Pat.Thaler@d12relay01.de.ibm.com'" <Pat.Thaler@d12relay01.de.ibm.com>,         "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
Subject: RE: iSCSI CRC: A CRC-checking example
Date: Wed, 22 Aug 2001 11:42:50 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;        boundary="----_=_NextPart_003_01C20D9E.520490E0"



Julian and Mark and others,

After I took into account the bit "reflection"  and the byte order (Big Endian on Bytes and Little Endian on bits) I did finally obtain, using polynomial math, the (corrected) results you show in the CRC examples. The results have also been confirmed independently by an implementor here at Agilent.

I am the one who originally suggested to Julian that we specify the CRC algorithm the same way as in ethernet even though for iSCSI it is not really important to initialize the CRC register to all 1s and to complement the CRC before transmission since there are other means to detect extra or missing PDU bytes. However I had not realzied until recently that conformance with the ethernet algorithm implies bit reflection. I had not been aware that in ethernet the bits are sent out on the serial link with the least significant bit first AND that the corresponding message polynomial is formed from the bits in the sequence that they appear on the serial link; thus the need for bit "reflection".

Now that I understand the need for bit reflection (taken into account in the rocksoft parameterized CRC generator by setting the in and out reflection flag parameters to TRUE) I am not sure I agree that we want it in iSCSI. The penalty for full conformity with ethernet seems too great. If people feel strongly that we must keep the bit reflection I think that to make the existing documentation clear and unambiguous we would need to explicitly show the mapping of bits in the iSCSI PDU to coefficients of the message polynomial that represents the iSCSI PDU. We would also need to show the mapping of the CRC bits to the coefficients of its representative polynomial.

If you don't agree I will elaborate further later this week to try to convince you. My objective is to be able to easily and unambiguously describe the polynomial math behind the algorithm; right now, with the bit reflection and without the explicit mapping it is awkward.

Vince 

Message-ID: <01A7DAF31F93D511AEE300D0B706ED920CF705@axcs13.cos.agilent.com>
From: "CAVANNA,VICENTE V (A-Roseville,ex1)" <vince_cavanna@agilent.com>
To: 'Luben Tuikov' <ltuikov@yahoo.com>
Cc: "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>, "THALER,PAT (A-Roseville,ex1)"         <pat_thaler@agilent.com>, "CAVANNA,VICENTE V (A-Roseville,ex1)"         <vince_cavanna@agilent.com>
Subject: Re: iSCSI v8 CRC32c
Date: Tue, 27 Nov 2001 19:39:49 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;        boundary="----_=_NextPart_002_01C20D9E.520490E0"



Luben,

Your questions may have already been answered by Paul Koning who has apparently reviewed your code in detail but attached, as I promised, is a Mathematica worksheet (pdf format) that produces results consistent with the iSCSI spec. You do not need to know the syntax of Mathematica in order to follow the process, as I have inserted lots of comments.

The example I describe uses, as data, 32 decrementing bytes. This is one of hte test cases in the iSCSI document. I have added an undetectable error pattern which does not change the results obtained at the receiver. I think it would be useful to include, in the iSCSI document, such an undetectable error pattern.

I am considering writing an informative Internet Draft describing the process. I would incorporate the contents of the attached worksheet and also explain the theory behind the process. This should answer such questions as why is the expected remainder at the receiver the constant 1c 2d 19 ed in hex.  If you or others have suggestions let me know.

For those not interested in the math I summarize the process below.

Vicente Cavanna
Agilent Technologies

The symbols I use:
------------------

G is the iSCSI CRC32c polynomial.

L32 is the order-32 poly represting all 1s.

F is the poly representing 32 decrementing bytes which I will use as my test data.

ReflectedF is the poly representing F, after reversing the order of bits within each byte.

R is the remainder of the division performed at the transmitter.

ReflectedR is the poly obtained by reversing the order of bits within each byte of R.

FCS is the complement of ReflectedR. This is the CRC that you would compare with the iSCSI document. In the case of this example of 32 decrementing bytes the FCS is a7 e4 e4 ae in hex.

M is the transmitted message before injecting errors.

Error is the error pattern that I add to M. I use G+x^5*G after applying reflection. Any linear combination of Gs will similarly be undetected.

M* is the received message.

ReflectedM* is M* with the order of bits within each byte reversed.

Rec is the computed CRC at the receiver. You would expect 1c2d19ed in the absence of errors or if error pattern is undetectable as is the case in my example.

The process, for the case of no errors, is as follows:
------------------------------------------------------

At the transmitter:
----------------------

F is the data.

Reverse bits within each byte of F to obtain ReflectedF.

Shift ReflectedF left by 32 positions.

Add 1's to most significant 32 bits of the result (implemented by initializing CRC register to 1's).

Divide by G to obtain the 32 bit remainderR. Note that R is not the CRC shown in iSCSI document!

Reverse bits within each byte of R to obtain ReflectedR.

Add 32 1's to the result to obtain the FCS (implemented by complementing). This is what is shown in the iSCSI document and, for this example, is a7 e4 e4 ae in hex.

Form the transmitted message, M, by shifting F left by 32 positions and adding FCS. Note that M is derived from F rather than from ReflectedF even though the FCS is computed from ReflectedF.

M* is hte same as M since we are not introducing errors here. See the Mathematica worksheet for the case with (undetectable) errors.

At the receiver:
----------------

Receive M*

Reverse bits within each byte of M* to obtain ReflectedM*.

Shift the result left by 32 positions.

Add 1's to most significant 32 bits of result (implemented by initializing CRc to 1's).

Divide by G to obtain the remainder, Rec. The result (for the case of no errors) is expected to be the constant 1c 2d 19 ed in hex.

In the Mathcad worksheet I actually introduce an undetectable error pattern, G+G*x^5, which I reflect and add to M to obtain M*. The rest is the same. Note that the error must also be "reflected". See the worksheet for details.

 

 <<TestingCRC32cDecrBytePattern.pdf>>



#### TestingCRC32cDecrBytePattern.pdf has been removed from this note on June 07 2002 by Julian Satran

--=_alternative 0074C74CC2256BD0_=-- From owner-ips@ece.cmu.edu Fri Jun 7 01:18:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07765 for ; Fri, 7 Jun 2002 01:18:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g574TW101060 for ips-outgoing; Fri, 7 Jun 2002 00:29:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g574TUw01056 for ; Fri, 7 Jun 2002 00:29:31 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g574TOUN032914; Fri, 7 Jun 2002 06:29:24 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g574TMk63972; Fri, 7 Jun 2002 06:29:23 +0200 To: "Michael J. S. Smith \(iReady\)" Cc: ips@ece.cmu.edu, "Michael J. S. Smith \(iReady\)" MIME-Version: 1.0 Subject: Re: iSCSI: A list of all normative sentences X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 7 Jun 2002 07:29:19 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 07/06/2002 07:29:23, Serialize complete at 07/06/2002 07:29:23 Content-Type: multipart/alternative; boundary="=_alternative 00182794C2256BD1_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00182794C2256BD1_= Content-Type: text/plain; charset="us-ascii" I will try to go over command in either 12-97 or 12-98 - Julo "Michael J. S. Smith \(iReady\)" 06/07/2002 03:25 AM Please respond to "Michael J. S. Smith \(iReady\)" To: "Michael J. S. Smith \(iReady\)" , Julian Satran/Haifa/IBM@IBMIL, cc: Subject: Re: iSCSI: A list of all normative sentences Julo: I just got your email that you are preparing to post 12-97. I have a request/suggestion. I am going through the list of MUSTs, SHOULDs, and so forth to check they are normative (that each term is defined, and defined before it is used for example). I use a spreadsheet and the concordance and check each term. When I went through the list, I found one issue that was global. Let me use an example to illustrate this issue. Take, as our example, the second appearance of MUST after all the MUSTs that appear in the change material: [Quote] For this reason the task management command MUST carry the current CmdSN as a marker of their position in the stream of commands. [End quote] Let's follow the terms and their definitions: The use of the term command is explained in section 2.1 (we are only interested in this explanatory section, not the definition of command, for what follows): [Quote] In this document "iSCSI request", "iSCSI command", request, or (unqualified) command have the same meaning. Also, unless otherwise specified, status, response, or numbered response have the same mean- ing. [End quote] and CmdSN is defined in 2.2.2.1: [Quote] Commands in transit from the initiator to the target are numbered by iSCSI; the number is carried by the iSCSI PDU as CmdSN (Command- Sequence-Number). [End quote] However when we get to "the task management command", there is no definition of task management command (search on task management command). By using the equivalence of command and request, the reader could deduce (carrying section 2.1 in memory) that Task Management Command is also equivalent to Task Management Request and therefore guess (but not through logical deduction) that: Task Management Function Request is equivalent to Task Management Command, which is defined in 2.5.1.3 This issue (the equivalence of request, command" and "status, response") occurs so often that it's hard to discriminate issues that are clearly equivalent and gray areas (such as the preceding example). One more example. Consider the MUST after the preceding example: [Quote] An iSCSI target MUST be able to handle at least one immediate task management command and one immediate non-task-management iSCSI request per connection at any time. [End quote] Here, in this sentence, command and iSCSI request are exactly equivalent (by 2.1), but the sentence appears difficult to parse and possibly implying otherwise by focusing the reader's attention on the difference between "task management command" and "non-task-management iSCSI request" rather than, for example, "task management command" and "non-task-management command". Alone these examples are trivial, but collectively they cause a compounded problem for a reader. Is it possible to standardize on the consistent use of request or command (not both), and the consistent use of status or response (not both), perhaps in 12-97? Normally this type of editorial change might happen at the final edit stage, but this issue is holding me up in checking some of the more arcane technical issues also. Aloha Mike Smith CTO, iReady ----- Original Message ----- From: "Michael J. S. Smith (iReady)" To: ; ; Cc: Sent: Thursday, May 30, 2002 4:13 PM Subject: iSCSI: A list of all normative sentences > I wrote a Perl script to extract a list of all sentences from an > RFC/draft that contain the normative words: MUST, SHOULD, and so on. > Such a list seems more useful than the concordances that I have been > sharing so far (it was actually a suggestion John made a while back). > Parsing the text is not as easy as it sounds and I am still improving > things. The current tool works pretty well on the text Internet drafts, > and is still useful on the PDF from Julo's website > (http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-12-95.pdf). > Here (below) is the output for12-95. This information is useful (to me > anyway) in order to focus on the areas where the draft is normative. > I'll try and include some more useful things like section numbers and so > forth, but it seemed like time was of the essence to get the draft > cleaned up going in to last call - so I included what I currently have. > Ignore the HTML markup (we just use that internally). > > Mike Smith > CTO, iReady --=_alternative 00182794C2256BD1_= Content-Type: text/html; charset="us-ascii"
I will try to go over command in either 12-97 or  12-98 - Julo


"Michael J. S. Smith \(iReady\)" <msmith@iready.com>

06/07/2002 03:25 AM
Please respond to "Michael J. S. Smith \(iReady\)"

       
        To:        "Michael J. S. Smith \(iReady\)" <msmith@iready.com>, Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>
        cc:        
        Subject:        Re: iSCSI: A list of all normative sentences

       


Julo: I just got your email that you are preparing to post 12-97. I have
a request/suggestion.

I am going through the list of MUSTs, SHOULDs, and so forth to check
they are normative (that each term is defined, and defined before it is
used for example). I use a spreadsheet and the concordance and check
each term. When I went through the list, I found one issue that was
global.

Let me use an example to illustrate this issue. Take, as our example,
the second appearance of MUST after all the MUSTs that appear in the
change material:

[Quote]
For this reason the task management command MUST carry the current CmdSN
as a marker of their position in the stream of commands.
[End quote]

Let's follow the terms and their definitions: The use of the term
command is explained in section 2.1 (we are only interested in this
explanatory section, not the definition of command, for what follows):

[Quote]
In this document "iSCSI request", "iSCSI command", request, or
(unqualified) command have the same meaning. Also, unless otherwise
specified, status, response, or numbered response have the same mean-
ing.
[End quote]

and CmdSN is defined in 2.2.2.1:

[Quote]
Commands in transit from the initiator to the target are numbered by
iSCSI; the number is carried by the iSCSI PDU as CmdSN (Command-
Sequence-Number).
[End quote]

However when we get to "the task management command", there is no
definition of task management command (search on task management
command). By using the equivalence of command and request, the reader
could deduce (carrying section 2.1 in memory) that Task Management
Command is also equivalent to Task Management Request and therefore
guess (but not through logical deduction) that: Task Management Function
Request is equivalent to Task Management Command, which is defined in
2.5.1.3

This issue (the equivalence of request, command" and "status, response")
occurs so often that it's hard to discriminate issues that are clearly
equivalent and gray areas (such as the preceding example).

One more example. Consider the MUST after the preceding example:

[Quote]
An iSCSI target MUST be able to handle at least one immediate task
management command and one immediate non-task-management iSCSI request
per connection at any time.
[End quote]

Here, in this sentence, command and iSCSI request are exactly equivalent
(by 2.1), but the sentence appears difficult to parse and possibly
implying otherwise by focusing the reader's attention on the difference
between "task management command" and "non-task-management iSCSI
request" rather than, for example, "task management command" and
"non-task-management command".

Alone these examples are trivial, but collectively they cause a
compounded problem for a reader. Is it possible to standardize on the
consistent use of request or command (not both), and the consistent use
of status or response (not both), perhaps in 12-97? Normally this type
of editorial change might happen at the final edit stage, but this issue
is holding me up in checking some of the more arcane technical issues
also.

Aloha

Mike Smith
CTO, iReady



----- Original Message -----
From: "Michael J. S. Smith (iReady)" <msmith@iready.com>
To: <hufferd@us.ibm.com>; <Julian_Satran@il.ibm.com>; <ips@ece.cmu.edu>
Cc: <msmith@iready.com>
Sent: Thursday, May 30, 2002 4:13 PM
Subject: iSCSI: A list of all normative sentences


> I wrote a Perl script to extract a list of all sentences from an
> RFC/draft that contain the normative words: MUST, SHOULD, and so on.
> Such a list seems more useful than the concordances that I have been
> sharing so far (it was actually a suggestion John made a while back).
> Parsing the text is not as easy as it sounds and I am still improving
> things. The current tool works pretty well on the text Internet
drafts,
> and is still useful on the PDF from Julo's website
>
(http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-12-95.pdf).
> Here (below) is the output for12-95. This information is useful (to me
> anyway) in order to focus on the areas where the draft is normative.
> I'll try and include some more useful things like section numbers and
so
> forth, but it seemed like time was of the essence to get the draft
> cleaned up going in to last call - so I included what I currently
have.
> Ignore the HTML markup (we just use that internally).
>
> Mike Smith
> CTO, iReady

--=_alternative 00182794C2256BD1_=-- From owner-ips@ece.cmu.edu Fri Jun 7 07:28:35 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23288 for ; Fri, 7 Jun 2002 07:28:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57Aoga26010 for ips-outgoing; Fri, 7 Jun 2002 06:50:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from best.eurologic.com ([213.190.135.5]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57Aoew26006 for ; Fri, 7 Jun 2002 06:50:40 -0400 (EDT) Received: from there (wombat [192.168.7.41]) by best.eurologic.com (8.9.3+Sun/8.9.3) with SMTP id LAA21920; Fri, 7 Jun 2002 11:50:19 +0100 (BST) Message-Id: <200206071050.LAA21920@best.eurologic.com> Content-Type: text/plain; charset="iso-8859-1" From: Ken Sandars Organization: Eurologic Systems To: Bill Studenmund , Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys Date: Fri, 7 Jun 2002 10:49:31 +0000 X-Mailer: KMail [version 1.3.1] Cc: , , References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Thursday 06 June 2002 11:57 pm, Bill Studenmund wrote: > On Thu, 6 Jun 2002 pat_thaler@agilent.com wrote: > > Bill, > > > > If x-keys are used for this then they should be given proper x-key names: > > x-reversed.dns_name.key_name > > > > It is a bad precedent to ignore domain naming in some of the first > > x-keys. People wouldn't want the dns name to be a vendor name in this > > case but perhaps a neutral party such as SNIA or UNH would be willing to > > have its domain name used for such keys (and they have nice short DNS > > names). > > True. Point taken. Any volinteers? > I agree that proper vendor-specific x-keys should use the reverse-dns format as stated. However, in this case the proposed keys are generic (for the good of all) and I'd hope are consistent. Can we have a set of "well-known" X-keys which just start "X-"? It certainly is a legal format according to the spec. Support of course would be completely optional for these. -- Ken Sandars Eurologic Systems Ltd ksandars@eurologic.com From owner-ips@ece.cmu.edu Fri Jun 7 07:30:27 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23308 for ; Fri, 7 Jun 2002 07:30:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57BLEp27178 for ips-outgoing; Fri, 7 Jun 2002 07:21:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from best.eurologic.com ([213.190.135.5]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57BLCw27173 for ; Fri, 7 Jun 2002 07:21:12 -0400 (EDT) Received: from there (wombat [192.168.7.41]) by best.eurologic.com (8.9.3+Sun/8.9.3) with SMTP id MAA22210; Fri, 7 Jun 2002 12:21:03 +0100 (BST) Message-Id: <200206071121.MAA22210@best.eurologic.com> Content-Type: text/plain; charset="iso-8859-1" From: Ken Sandars Organization: Eurologic Systems To: Robert Snively , "Ips Reflector (E-mail)" Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys Date: Fri, 7 Jun 2002 11:20:15 +0000 X-Mailer: KMail [version 1.3.1] References: <2F37CED150E21640A9C6E75B8BE6AF830A4CBD@hq-ex-4> In-Reply-To: <2F37CED150E21640A9C6E75B8BE6AF830A4CBD@hq-ex-4> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi Bob, No, that's not what I'm suggesting. I was not looking at affecting anything at the SCSI layer. This proposal is purely communicating information between the iSCSI (transport) layers. I wouldn't expect this information to necessarily be passed to the SCSI layer on either target or initiator. This information was intended to be used at the iSCSI layer to "tune" iSCSI behaviour, and to provide additional information to the management component of each implementation. The latter reason is more important as it can assist in maintaining an iSCSI SAN, and this is where I'd like to see this end up. Cheers, Ken On Thursday 06 June 2002 4:32 pm, Robert Snively wrote: > I am not in favor of replicating a standard > SCSI function that is not part of the link > protocol outside the SCSI command set. What this > does is fragment the driver designs in a way that > might prevent the usual SCSI driver interoperation with > parallel SCSI, SBP, FC, and SRP SCSI devices. > You would then need non-standard SCSI drivers for > iSCSI devices. > > Bob > > > -----Original Message----- > > From: Ken Sandars [mailto:ksandars@eurologic.com] > > Sent: Thursday, June 06, 2002 8:43 AM > > To: Ips Reflector (E-mail) > > Subject: iSCSI: Some proposed vendor-specific (X-) keys > > > > > > Hi all, > > > > Can all you implementers out there consider this proposal > > please? This is > > intended to be an aid to interoperability. Obviously once the spec is > > approved and everyone is fully complient there will be no > > need for this. > > > > This proposal is in no means intended to go into the > > specification (unless > > people REALLY want it), so feel free to skip this message now ;-) > > > > I suggest three vendor specific declarative keys which > > MAY/SHOULD be sent > > during the login phase (during the operational parameter > > negotiation stage): > > > > X-vendor > > X-product > > X-revision > > > > These all contains strings, eg: > > > > X-vendor=fredsIscsiShop > > X-product=YetAnotherIscsiTarget > > X-revision=1.003 > > > > These keys follow the SCSI inquiry command fields in terms of > > names, and are > > used to identify the iSCSI node's information. > > > > What does this achieve? I'm looking for an opportunity to > > provide automated > > interoperability between systems which are not yet fully complient. > > > > But I hear you think, "But why don't they just fix them?", > > and I have to > > agree. > > > > However, there are a number of iSCSI products which work > > wonderfully well > > already out there (as long as you don't excite one of their > > quirks). If you > > find out what you are connecting with during login, you can > > decide what > > things you should or shouldn't do with it. > > > > > > -- > > Ken Sandars > > Eurologic Systems Ltd > > ksandars@eurologic.com -- Ken Sandars Eurologic Systems Ltd ksandars@eurologic.com From owner-ips@ece.cmu.edu Fri Jun 7 10:53:54 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29177 for ; Fri, 7 Jun 2002 10:53:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57E4Cx04935 for ips-outgoing; Fri, 7 Jun 2002 10:04:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g57E48w04925 for ; Fri, 7 Jun 2002 10:04:08 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g57E42p04986 for ; Fri, 7 Jun 2002 10:04:02 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g57E41c04965; Fri, 7 Jun 2002 10:04:01 -0400 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with SMTP id g57E40n14330; Fri, 7 Jun 2002 10:04:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15616.48464.636340.349187@pkoning.dev.equallogic.com> Date: Fri, 7 Jun 2002 10:04:00 -0400 From: Paul Koning To: ksandars@eurologic.com Cc: wrstuden@wasabisystems.com, pat_thaler@agilent.com, dyoung@rhapsodynetworks.com, bmastors@allocity.com, ips@ece.cmu.edu Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys References: <200206071050.LAA21920@best.eurologic.com> X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Ken" == Ken Sandars writes: Ken> On Thursday 06 June 2002 11:57 pm, Bill Studenmund wrote: >> On Thu, 6 Jun 2002 pat_thaler@agilent.com wrote: > Bill, > > If >> x-keys are used for this then they should be given proper x-key >> names: > x-reversed.dns_name.key_name > > It is a bad precedent to >> ignore domain naming in some of the first > x-keys. People >> wouldn't want the dns name to be a vendor name in this > case but >> perhaps a neutral party such as SNIA or UNH would be willing to > >> have its domain name used for such keys (and they have nice short >> DNS > names). >> >> True. Point taken. Any volinteers? >> Ken> I agree that proper vendor-specific x-keys should use the Ken> reverse-dns format as stated. However, in this case the proposed Ken> keys are generic (for the good of all) and I'd hope are Ken> consistent. Ken> Can we have a set of "well-known" X-keys which just start "X-"? Ken> It certainly is a legal format according to the spec. Support of Ken> course would be completely optional for these. I am strongly opposed to any of this. Clearly there's no way to stop people at foo.com defining an x-com.foo.whatever, but I DO NOT like the idea of giving this notion any semblance of official sanction by creating "standard" X- keys to do what's proposed here. paul From owner-ips@ece.cmu.edu Fri Jun 7 12:11:28 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02436 for ; Fri, 7 Jun 2002 12:11:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57FhiN11720 for ips-outgoing; Fri, 7 Jun 2002 11:43:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57Fhbw11694 for ; Fri, 7 Jun 2002 11:43:37 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g57FhTI0035326; Fri, 7 Jun 2002 17:43:29 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g57FhT780252; Fri, 7 Jun 2002 17:43:29 +0200 Subject: Re: iSCSI: response reason To: Cc: ips@ece.cmu.edu, "Julian Satran" X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Fri, 7 Jun 2002 17:07:29 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 07/06/2002 18:43:29 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk thanks - it is fixed in 12-97 - Julo "Eddy Quicksall" cc: Subject: iSCSI: response reason 06/06/2002 11:28 PM Please respond to Eddy Section 6.5 Digest Errors uses the phrase "iSCSI response reason" and refers to section 9.4.3. But there is no such term used in that section. There is, however, a term used called "iSCSI service response". But, section 6.5 is not talking about that. I believe section 6.5 is talking about the heading "reason" that appears in the 1st column of the table in section 9.4.6.2. So to clarify things, how about changing the table heading in 9.4.6.2 to say "iSCSI Condition" and section 6.5 to say "iSCSI Condition (Section 9.4.6.2 Sense Data)? The term "iSCSI Condition" is also compatible with the same term used in the 2nd paragraph of 9.4.6.2. Eddy From owner-ips@ece.cmu.edu Fri Jun 7 12:19:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02754 for ; Fri, 7 Jun 2002 12:19:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57Fhew11708 for ips-outgoing; Fri, 7 Jun 2002 11:43:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57Fhbw11693 for ; Fri, 7 Jun 2002 11:43:37 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g57FhUfq050612 for ; Fri, 7 Jun 2002 17:43:30 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g57FhU7122876 for ; Fri, 7 Jun 2002 17:43:30 +0200 Subject: iSCSI 12-97 To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Fri, 7 Jun 2002 18:36:18 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 07/06/2002 18:43:30 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk is out From owner-ips@ece.cmu.edu Fri Jun 7 12:19:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02775 for ; Fri, 7 Jun 2002 12:19:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57G71G13375 for ips-outgoing; Fri, 7 Jun 2002 12:07:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57G6ww13369 for ; Fri, 7 Jun 2002 12:06:58 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g57F5Mu16941; Fri, 7 Jun 2002 11:05:22 -0400 Message-ID: <3D00DA1D.1AFD5842@splentec.com> Date: Fri, 07 Jun 2002 12:06:53 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: iSCSI , Julian Satran Subject: iSCSI: ordered command delivery at the target Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit To achieve ordered command delivery (2.2.2.1), the Target will most likely put the requests it gets from the Initiator into an ``incoming'' priority queue by CmdSn, after connection allegiance has been noted. The priority queue is at session level, by reason of iSCSI/SCSI and CmdSN. Currently offset 24 is used for CmdSN (Requests) and for StatSN (Responses) which is a good thing (since they are exclusive). From all the Requests, only Data-Out and SNACK, reserve offset 24, which would break insertion into the ``incoming'' priority queue. Since SCSI Command (Request) is assigned CmdSN as well as ITT, why not stupulate that Data-Out has to carry the same CmdSN as the task to which they belong (by ITT). This would alleviate the target from searching all of its queues for the ITT in order to extract the CmdSN, and then put the Data-Out PDU into the ``incoming'' priority queue by the found CmdSN. This _simplifies_ the Target, and makes no load on the initiator since the initiator can just copy the CmdSN on subsequent Data-Out. Effectively, this just helps insertion into the Target's ``incoming'' priority queue. Also, I see no reason not to make SNACK a command and assign it a CmdSN. If the Initiator is certain that the command it is referencing has completed (e.g. StatusACK) then SNACK can be an immediate command (I = 1), thus it will be put at the front of the ``incoming'' priority queue (effectively ignoring CmdSN), and delivered for execution right away. The Target implementation will then only search execution/outgoing queues by ITT (StatusACK) and be able to find the task by ITT. (1) Otherwise, CmdSN will just put it right after the ITT which bears the same CmdSN, iff ITT hasn't been sent for execution. Then the ITT is posted for execution and the Target will have to search only the execution/outgoing queues just as mentioned in (1) above. Yes, I know that CmdSN has no meaning after the command has been passed to the device server at the Target. Thus the more reason to make the Initiator copy CmdSN for Data-Out and SNACK***. *** So, if the task has been delivered for executon at the Target, then the Data-Out will _naturally_ be put at the FRONT of the ``incoming'' priority queue (since the task is in another queue and CmdSN has advanced), thus effectively making it immediate, which is the desired effect. If the task has NOT been posted for execution at the target, the Data-Out will be queued right after it. Comments? -- Luben P.S. Anyone implementing iSCSI Connection load balancing at the initiator would've certainly considered this since it would also make the target execution engine simpler. (They go hand-in-hand.) From owner-ips@ece.cmu.edu Fri Jun 7 12:21:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02996 for ; Fri, 7 Jun 2002 12:21:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57Fhb911686 for ips-outgoing; Fri, 7 Jun 2002 11:43:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57FhXw11680 for ; Fri, 7 Jun 2002 11:43:33 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g57FhRI0035322 for ; Fri, 7 Jun 2002 17:43:27 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g57FhQ761532 for ; Fri, 7 Jun 2002 17:43:26 +0200 Subject: Re: iSCSI: A list of all normative sentences To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Fri, 7 Jun 2002 09:06:32 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 07/06/2002 18:43:26 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I looked it over and my optimism evaporated. I made here and there a change from command to request - but I won't be able to do it safely without breaking semantics. Initially I intended to keep commands for SCSI and requests for iSCSI. But the boundary is not clear and I suggest we leave the text as it is. Julo ----- Forwarded by Julian Satran/Haifa/IBM on 06/07/2002 09:03 AM ----- Julian Satran To: "Michael J. S. Smith \(iReady\)" 06/07/2002 07:23 cc: ips@ece.cmu.edu, "Michael J. S. Smith \(iReady\)" AM From: Julian Satran/Haifa/IBM@IBMIL Subject: Re: iSCSI: A list of all normative sentences(Document link: Julian Satran - Mail) I will try to go over command in either 12-97 or 12-98 - Julo "Michael J. S. Smith \(iReady\)" To: "Michael J. S. Smith \(iReady\)" , Julian m> cc: Subject: Re: iSCSI: A list of all normative sentences 06/07/2002 03:25 AM Please respond to "Michael J. S. Smith \(iReady\)" Julo: I just got your email that you are preparing to post 12-97. I have a request/suggestion. I am going through the list of MUSTs, SHOULDs, and so forth to check they are normative (that each term is defined, and defined before it is used for example). I use a spreadsheet and the concordance and check each term. When I went through the list, I found one issue that was global. Let me use an example to illustrate this issue. Take, as our example, the second appearance of MUST after all the MUSTs that appear in the change material: [Quote] For this reason the task management command MUST carry the current CmdSN as a marker of their position in the stream of commands. [End quote] Let's follow the terms and their definitions: The use of the term command is explained in section 2.1 (we are only interested in this explanatory section, not the definition of command, for what follows): [Quote] In this document "iSCSI request", "iSCSI command", request, or (unqualified) command have the same meaning. Also, unless otherwise specified, status, response, or numbered response have the same mean- ing. [End quote] and CmdSN is defined in 2.2.2.1: [Quote] Commands in transit from the initiator to the target are numbered by iSCSI; the number is carried by the iSCSI PDU as CmdSN (Command- Sequence-Number). [End quote] However when we get to "the task management command", there is no definition of task management command (search on task management command). By using the equivalence of command and request, the reader could deduce (carrying section 2.1 in memory) that Task Management Command is also equivalent to Task Management Request and therefore guess (but not through logical deduction) that: Task Management Function Request is equivalent to Task Management Command, which is defined in 2.5.1.3 This issue (the equivalence of request, command" and "status, response") occurs so often that it's hard to discriminate issues that are clearly equivalent and gray areas (such as the preceding example). One more example. Consider the MUST after the preceding example: [Quote] An iSCSI target MUST be able to handle at least one immediate task management command and one immediate non-task-management iSCSI request per connection at any time. [End quote] Here, in this sentence, command and iSCSI request are exactly equivalent (by 2.1), but the sentence appears difficult to parse and possibly implying otherwise by focusing the reader's attention on the difference between "task management command" and "non-task-management iSCSI request" rather than, for example, "task management command" and "non-task-management command". Alone these examples are trivial, but collectively they cause a compounded problem for a reader. Is it possible to standardize on the consistent use of request or command (not both), and the consistent use of status or response (not both), perhaps in 12-97? Normally this type of editorial change might happen at the final edit stage, but this issue is holding me up in checking some of the more arcane technical issues also. Aloha Mike Smith CTO, iReady ----- Original Message ----- From: "Michael J. S. Smith (iReady)" To: ; ; Cc: Sent: Thursday, May 30, 2002 4:13 PM Subject: iSCSI: A list of all normative sentences > I wrote a Perl script to extract a list of all sentences from an > RFC/draft that contain the normative words: MUST, SHOULD, and so on. > Such a list seems more useful than the concordances that I have been > sharing so far (it was actually a suggestion John made a while back). > Parsing the text is not as easy as it sounds and I am still improving > things. The current tool works pretty well on the text Internet drafts, > and is still useful on the PDF from Julo's website > (http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-12-95.pdf). > Here (below) is the output for12-95. This information is useful (to me > anyway) in order to focus on the areas where the draft is normative. > I'll try and include some more useful things like section numbers and so > forth, but it seemed like time was of the essence to get the draft > cleaned up going in to last call - so I included what I currently have. > Ignore the HTML markup (we just use that internally). > > Mike Smith > CTO, iReady From owner-ips@ece.cmu.edu Fri Jun 7 12:24:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03076 for ; Fri, 7 Jun 2002 12:24:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57G3Tj13108 for ips-outgoing; Fri, 7 Jun 2002 12:03:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57G3Rw13104 for ; Fri, 7 Jun 2002 12:03:27 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g57G3GeE009970; Fri, 7 Jun 2002 18:03:16 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g57G3C737754; Fri, 7 Jun 2002 18:03:12 +0200 To: Ken Sandars Cc: bmastors@allocity.com, dyoung@rhapsodynetworks.com, ips@ece.cmu.edu, owner-ips@ece.cmu.edu, pat_thaler@agilent.com, Bill Studenmund MIME-Version: 1.0 Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 7 Jun 2002 19:03:09 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 07/06/2002 19:03:15, Serialize complete at 07/06/2002 19:03:15 Content-Type: multipart/alternative; boundary="=_alternative 005744C5C2256BD1_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005744C5C2256BD1_= Content-Type: text/plain; charset="us-ascii" Isn't "generic vendor keys" an oxymoron? My English was never at Orwelian levels - Julo Ken Sandars Sent by: owner-ips@ece.cmu.edu 06/07/2002 01:49 PM Please respond to Ken Sandars To: Bill Studenmund , cc: , , Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys On Thursday 06 June 2002 11:57 pm, Bill Studenmund wrote: > On Thu, 6 Jun 2002 pat_thaler@agilent.com wrote: > > Bill, > > > > If x-keys are used for this then they should be given proper x-key names: > > x-reversed.dns_name.key_name > > > > It is a bad precedent to ignore domain naming in some of the first > > x-keys. People wouldn't want the dns name to be a vendor name in this > > case but perhaps a neutral party such as SNIA or UNH would be willing to > > have its domain name used for such keys (and they have nice short DNS > > names). > > True. Point taken. Any volinteers? > I agree that proper vendor-specific x-keys should use the reverse-dns format as stated. However, in this case the proposed keys are generic (for the good of all) and I'd hope are consistent. Can we have a set of "well-known" X-keys which just start "X-"? It certainly is a legal format according to the spec. Support of course would be completely optional for these. -- Ken Sandars Eurologic Systems Ltd ksandars@eurologic.com --=_alternative 005744C5C2256BD1_= Content-Type: text/html; charset="us-ascii"
Isn't "generic vendor keys" an oxymoron?  My English was never at Orwelian levels - Julo


Ken Sandars <ksandars@eurologic.com>
Sent by: owner-ips@ece.cmu.edu

06/07/2002 01:49 PM
Please respond to Ken Sandars

       
        To:        Bill Studenmund <wrstuden@wasabisystems.com>, <pat_thaler@agilent.com>
        cc:        <dyoung@rhapsodynetworks.com>, <bmastors@allocity.com>, <ips@ece.cmu.edu>
        Subject:        Re: iSCSI: Some proposed vendor-specific (X-) keys

       


On Thursday 06 June 2002 11:57 pm, Bill Studenmund wrote:
> On Thu, 6 Jun 2002 pat_thaler@agilent.com wrote:
> > Bill,
> >
> > If x-keys are used for this then they should be given proper x-key names:
> > x-reversed.dns_name.key_name
> >
> > It is a bad precedent to ignore domain naming in some of the first
> > x-keys. People wouldn't want the dns name to be a vendor name in this
> > case but perhaps a neutral party such as SNIA or UNH would be willing to
> > have its domain name used for such keys (and they have nice short DNS
> > names).
>
> True. Point taken. Any volinteers?
>

I agree that proper vendor-specific x-keys should use the reverse-dns format
as stated. However, in this case the proposed keys are generic (for the good
of all) and I'd hope are consistent.

Can we have a set of "well-known" X-keys which just start "X-"?

It certainly is a legal format according to the spec. Support of course would
be completely optional for these.


--
Ken Sandars
Eurologic Systems Ltd
ksandars@eurologic.com

--=_alternative 005744C5C2256BD1_=-- From owner-ips@ece.cmu.edu Fri Jun 7 12:58:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02437 for ; Fri, 7 Jun 2002 12:11:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57FW5V10878 for ips-outgoing; Fri, 7 Jun 2002 11:32:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57FW1w10867 for ; Fri, 7 Jun 2002 11:32:01 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id IAA29838; Fri, 7 Jun 2002 08:31:52 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Jun 2002 08:31:52 -0700 Message-ID: <2F37CED150E21640A9C6E75B8BE6AF830A4CC4@hq-ex-4> From: Robert Snively To: "'Ken Sandars'" , Robert Snively , "Ips Reflector (E-mail)" Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys Date: Fri, 7 Jun 2002 08:31:45 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk Ken, In my experience, "vendor specific" is a synonym for "non-interoperable". Realistically, if there is any tuning to be done with respect to the iSCSI transport behavior, then it should be done through standardized mechanisms during the login, not through vendor specific mechanisms. The management component already has standard mechanisms for determining such information, including MIBs and CIM objects. The operational components already have standard mechanisms for determining such information, including SCSI INQUIRY commands. I cannot see how this additional (non-standard) mechanism for capturing this information is going to help iSCSI achieve its goals. Those legacy devices that are being supported by non-standard programs and non-standard protocol events are simply NOT compliant iSCSI devices. If anyone cares about using them in an iSCSI environment, they must be upgraded to iSCSI compliance. Bob > -----Original Message----- > From: Ken Sandars [mailto:ksandars@eurologic.com] > Sent: Friday, June 07, 2002 4:20 AM > To: Robert Snively; Ips Reflector (E-mail) > Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys > > > Hi Bob, > > No, that's not what I'm suggesting. I was not looking at > affecting anything > at the SCSI layer. This proposal is purely communicating > information between > the iSCSI (transport) layers. I wouldn't expect this information to > necessarily be passed to the SCSI layer on either target or initiator. > > This information was intended to be used at the iSCSI layer > to "tune" iSCSI > behaviour, and to provide additional information to the > management component > of each implementation. The latter reason is more important > as it can assist > in maintaining an iSCSI SAN, and this is where I'd like to > see this end up. > From owner-ips@ece.cmu.edu Fri Jun 7 12:58:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02438 for ; Fri, 7 Jun 2002 12:11:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57FhiU11721 for ips-outgoing; Fri, 7 Jun 2002 11:43:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57FhZw11684; Fri, 7 Jun 2002 11:43:35 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g57FhSI0023824; Fri, 7 Jun 2002 17:43:28 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g57FhR769770; Fri, 7 Jun 2002 17:43:28 +0200 Subject: RE: iSCSI: keys/parameter dependence To: "Robert D. Russell" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Fri, 7 Jun 2002 16:23:57 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 07/06/2002 18:43:28 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk The text should read now: If DataSequenceInOrder is set to Yes, a target may retry at most the last R2T, and an initiator may at most request retransmission for the last read data sequence. For this reason if ErrorRecoveryLevel is not 0 and DataSequenceInOrder is set to Yes then MaxOustandingR2T MUST be set to 1. Julo "Robert D. Russell" To: ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence Sent by: owner-ips@ece.cmu .edu 06/06/2002 06:07 PM Please respond to "Robert D. Russell" Julian: I came across another dependency in draft 12-96 (but it has been in the drafts for some time): The end of section 11.20 says: "If ErrorRecoveryLevel is not 0 and if DataSequenceInOrder is set to Yes, a target may retry at most the last R2T, and an initiator may at most request retransmission for the last read data sequence. MaxOutstandingR2T MUST be set to 1 in this case." It is unclear to me from reading this just what the "in this case" refers to -- does it mean: 1) if MaxOutstandingR2T is not 1 then the target may not retry and the initiator may not request retransmission. or 2) the combination ErrorRecoveryLevel > 0 and DataSequenceInOrder=Yes requires MaxOutStandingR2T=1. If the first interpretation is correct, then this is not really a dependency between the keys, but a subtle restriction on behavior from a certain combination of keys. If the second interpretation is correct, then this is a dependency between keys. Whichever interpretation is correct, I would suggest that the statement in section 11.20 be reworded to make the interpretation unambiguous. Thanks, Bob Russell From owner-ips@ece.cmu.edu Fri Jun 7 12:58:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02435 for ; Fri, 7 Jun 2002 12:11:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57FheI11707 for ips-outgoing; Fri, 7 Jun 2002 11:43:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57Fhaw11690 for ; Fri, 7 Jun 2002 11:43:36 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g57FhTfq050608; Fri, 7 Jun 2002 17:43:29 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g57FhS735514; Fri, 7 Jun 2002 17:43:29 +0200 Subject: RE: iSCSI: keys/parameter dependence To: "Robert D. Russell" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Fri, 7 Jun 2002 16:52:46 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 07/06/2002 18:43:29 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Bob, Some comments in text. Regards, Julo "Robert D. Russell" To: Julian Satran/Haifa/IBM@IBMIL Subject: RE: iSCSI: keys/parameter dependence 06/03/2002 04:41 PM Please respond to "Robert D. Russell" Julian: I must not be understanding what people mean by "batching", a term that does not appear in the standard but which is apparently not prevented by the standard. So let me ask the question as follows: In draft 12-95 section 4.2.1 "List negotiations" it says: "The responding party MUST respond with the same key and select first value that it supports (and is allowed to use for the specific originator) selected from the originator list." As an aside, I believe the English in this should be changed slightly (without changing the intent) to read: "The responding party MUST respond with the same key and the first value that it supports (and is allowed to use for the specific originator) selected from the originator's list." +++ thanks - fixed +++ Also in draft 12-95 section 4.2.2 "Simple-value negotiations" it says: "For simple-value negotiations, the responding party MUST respond with the same key." For both of these quotes I have the same question -- when MUST this response be given? My interpretation is that it MUST be sent as soon as possible (which would be on the next PDU sent by the responder after receiving a PDU with C bit set to 0). Is this correct? +++ not necessarily - although this is the way many will do it +++ If my interpretation is not correct, then exactly when MUST the response be sent -- i.e., how long can the responder delay before it MUST respond to a key (obviously it must respond to the PDU, but I mean only the offered keys here). For example, having just received a large number of new offers in a PDU with the C bit set to 0, can the responder then send back the appropriate response PDU with no response keys, and continue doing so until what? +++ I think we don't need an additional rule for forcing a negotiation to close> We can leave this to implementers. It does not look like we will have an interoperability issue here. The initiator has the F bit to signal when he thinks he is done and I assume it will give up if the target keeps sending empty PDUs. We may want to add a rule about not sending an excessive number of empty PDUs when the received C is 0 " +++ If the answer to this last example is "yes", then I have another: When a responder gets a large numer of new offers in a PDU with the C bit set to 0, can it send back no responses but rather a disjoint set of new offers (i.e., keys that were not sent to it)? +++ yes +++ Another way to ask my general question is the following -- can a responder to an offer of a key=value delay sending its response to that key indefinitely? +++ not indefinitely +++ I believe this was discussed on the mailing list a long time ago, and that my interpretation was confirmed then, but I cannot find anything in the current wording of the standard which says this. +++ I don't recall a discussion in this specific terms and in this respect we never changed the draft +++ Regardless of which interpretation is correct, it would be very helpful to state it in the standard -- otherwise we will certainly have some people choosing the other interpretation -- it appears to be already happening! Thanks, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Fri Jun 7 13:11:25 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04366 for ; Fri, 7 Jun 2002 13:11:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57GiTS15743 for ips-outgoing; Fri, 7 Jun 2002 12:44:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from astutenetworks.com (2.astutenetworks.com [216.142.74.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57GiRw15739 for ; Fri, 7 Jun 2002 12:44:27 -0400 (EDT) Received: from amirdesktop (dhcp62 [172.21.2.62]) by astutenetworks.com (8.11.6/8.11.2) with SMTP id g57GiF724571; Fri, 7 Jun 2002 09:44:15 -0700 From: "Amir Shalit" To: "Luben Tuikov" Cc: "iSCSI" , "Julian Satran" Subject: RE: iSCSI: ordered command delivery at the target Date: Fri, 7 Jun 2002 09:44:14 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3D00E1F9.E2F94CA4@splentec.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit It does it for new commands but not for existing once like what you are suggesting. It's all about "delivery". Amir -----Original Message----- From: luben@ns.splentec.com [mailto:luben@ns.splentec.com]On Behalf Of Luben Tuikov Sent: Friday, June 07, 2002 9:40 AM To: Amir Shalit Cc: iSCSI; Julian Satran Subject: Re: iSCSI: ordered command delivery at the target Amir Shalit wrote: > > It will not work. If you issue a write command for multiple Terabytes (it's > allowed) > CmdSN may wrap before you are done with the command. > > Amir The target takes care or CmdSN wrapping for outstanding ITT, by virtue of MaxCmdSN and ExpCmdSN. If it didn't, all would go up in smoke! Please read the draft! Anyway... Comments? (on the original posting). -- Luben From owner-ips@ece.cmu.edu Fri Jun 7 13:11:26 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04379 for ; Fri, 7 Jun 2002 13:11:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57GxgI16592 for ips-outgoing; Fri, 7 Jun 2002 12:59:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f133.pav2.hotmail.com [64.4.37.133]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57Gxew16588 for ; Fri, 7 Jun 2002 12:59:40 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 7 Jun 2002 09:59:34 -0700 Received: from 207.46.137.8 by pv2fd.pav2.hotmail.msn.com with HTTP; Fri, 07 Jun 2002 16:59:34 GMT X-Originating-IP: [207.46.137.8] From: "Bernard Aboba" To: philmac@research.bell-labs.com Cc: ips@ece.cmu.edu Subject: Re: Security -13 draft Date: Fri, 07 Jun 2002 09:59:34 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 Jun 2002 16:59:34.0350 (UTC) FILETIME=[B30046E0:01C20E44] Sender: owner-ips@ece.cmu.edu Precedence: bulk Good points. I will work on consolidating the iSCSI authentication text, and adding mention of CHAP to section 5.8.3. >From: Philip MacKenzie >To: Bernard Aboba >CC: ips@ece.cmu.edu >Subject: Re: Security -13 draft >Date: Wed, 05 Jun 2002 13:36:24 -0400 > > > A -13 version of the security draft is available for your examination >at: > > > > http://www.drizzle.com/~aboba/IPS/draft-ietf-ips-security-13.txt > > > > Since this is potentially the version that will go to WG last call, a >careful reading is encouraged. > > >This seemed odd to me: > >SRP is given what seems like an offhand comment in >section 5.8.3, which seems totally incongruous to the >laborious SRP implementation details given in >section 5.10 and Appendix A. > >Why all the details for something that's just mentioned >in passing as an alternative authentication method? >Also, why in section 5.8.3 is CHAP not mentioned, given >that it is the MUST implement method? > >-Phil > _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From owner-ips@ece.cmu.edu Fri Jun 7 13:12:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04408 for ; Fri, 7 Jun 2002 13:12:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57Geeu15496 for ips-outgoing; Fri, 7 Jun 2002 12:40:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57Gebw15488 for ; Fri, 7 Jun 2002 12:40:37 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g57Fcsu17055; Fri, 7 Jun 2002 11:38:54 -0400 Message-ID: <3D00E1F9.E2F94CA4@splentec.com> Date: Fri, 07 Jun 2002 12:40:25 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Amir Shalit CC: iSCSI , Julian Satran Subject: Re: iSCSI: ordered command delivery at the target References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Amir Shalit wrote: > > It will not work. If you issue a write command for multiple Terabytes (it's > allowed) > CmdSN may wrap before you are done with the command. > > Amir The target takes care or CmdSN wrapping for outstanding ITT, by virtue of MaxCmdSN and ExpCmdSN. If it didn't, all would go up in smoke! Please read the draft! Anyway... Comments? (on the original posting). -- Luben From owner-ips@ece.cmu.edu Fri Jun 7 13:12:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04429 for ; Fri, 7 Jun 2002 13:12:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57H2UG16779 for ips-outgoing; Fri, 7 Jun 2002 13:02:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f206.pav2.hotmail.com [64.4.37.206]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57H2Rw16773 for ; Fri, 7 Jun 2002 13:02:27 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 7 Jun 2002 10:02:21 -0700 Received: from 131.107.3.92 by pv2fd.pav2.hotmail.msn.com with HTTP; Fri, 07 Jun 2002 17:02:21 GMT X-Originating-IP: [131.107.3.92] From: "Bernard Aboba" To: ssenum@cisco.com, xuebin.yao@intel.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: CHAP Question Date: Fri, 07 Jun 2002 10:02:21 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 Jun 2002 17:02:21.0962 (UTC) FILETIME=[16E7D6A0:01C20E45] Sender: owner-ips@ece.cmu.edu Precedence: bulk >In the draft 12-96, it refers to [RFC 1994] for CHAP. However, there >are >also [RFC 2433] (MS-CHAP v1) and [RFC 2759] (MS-CHAP v2) >which claimed consistent of [RFC 1994]. > >Anyone knows if they are compatible or not? Could implementer choose >to >use either version, and would that cause interoperability issue? RFC2759 (which supercedes RFC 2433) is consistent with RFC 1994 in the sense that the same fields are used. However, MS-CHAP-V2 provides mutual authentication using very different algorithms than RFC 1994. So MS-CHAP-V2 is not interoperable with either MS-CHAP-V1 or RFC 1994 CHAP. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From owner-ips@ece.cmu.edu Fri Jun 7 13:13:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04441 for ; Fri, 7 Jun 2002 13:13:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57GUWj14830 for ips-outgoing; Fri, 7 Jun 2002 12:30:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from astutenetworks.com (2.astutenetworks.com [216.142.74.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57GUPw14819 for ; Fri, 7 Jun 2002 12:30:25 -0400 (EDT) Received: from amirdesktop (dhcp62 [172.21.2.62]) by astutenetworks.com (8.11.6/8.11.2) with SMTP id g57GU7723390; Fri, 7 Jun 2002 09:30:07 -0700 From: "Amir Shalit" To: "Luben Tuikov" , "iSCSI" , "Julian Satran" Subject: RE: iSCSI: ordered command delivery at the target Date: Fri, 7 Jun 2002 09:30:05 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3D00DA1D.1AFD5842@splentec.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit It will not work. If you issue a write command for multiple Terabytes (it's allowed) CmdSN may wrap before you are done with the command. Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Luben Tuikov Sent: Friday, June 07, 2002 9:07 AM To: iSCSI; Julian Satran Subject: iSCSI: ordered command delivery at the target To achieve ordered command delivery (2.2.2.1), the Target will most likely put the requests it gets from the Initiator into an ``incoming'' priority queue by CmdSn, after connection allegiance has been noted. The priority queue is at session level, by reason of iSCSI/SCSI and CmdSN. Currently offset 24 is used for CmdSN (Requests) and for StatSN (Responses) which is a good thing (since they are exclusive). >From all the Requests, only Data-Out and SNACK, reserve offset 24, which would break insertion into the ``incoming'' priority queue. Since SCSI Command (Request) is assigned CmdSN as well as ITT, why not stupulate that Data-Out has to carry the same CmdSN as the task to which they belong (by ITT). This would alleviate the target from searching all of its queues for the ITT in order to extract the CmdSN, and then put the Data-Out PDU into the ``incoming'' priority queue by the found CmdSN. This _simplifies_ the Target, and makes no load on the initiator since the initiator can just copy the CmdSN on subsequent Data-Out. Effectively, this just helps insertion into the Target's ``incoming'' priority queue. Also, I see no reason not to make SNACK a command and assign it a CmdSN. If the Initiator is certain that the command it is referencing has completed (e.g. StatusACK) then SNACK can be an immediate command (I = 1), thus it will be put at the front of the ``incoming'' priority queue (effectively ignoring CmdSN), and delivered for execution right away. The Target implementation will then only search execution/outgoing queues by ITT (StatusACK) and be able to find the task by ITT. (1) Otherwise, CmdSN will just put it right after the ITT which bears the same CmdSN, iff ITT hasn't been sent for execution. Then the ITT is posted for execution and the Target will have to search only the execution/outgoing queues just as mentioned in (1) above. Yes, I know that CmdSN has no meaning after the command has been passed to the device server at the Target. Thus the more reason to make the Initiator copy CmdSN for Data-Out and SNACK***. *** So, if the task has been delivered for executon at the Target, then the Data-Out will _naturally_ be put at the FRONT of the ``incoming'' priority queue (since the task is in another queue and CmdSN has advanced), thus effectively making it immediate, which is the desired effect. If the task has NOT been posted for execution at the target, the Data-Out will be queued right after it. Comments? -- Luben P.S. Anyone implementing iSCSI Connection load balancing at the initiator would've certainly considered this since it would also make the target execution engine simpler. (They go hand-in-hand.) From owner-ips@ece.cmu.edu Fri Jun 7 13:13:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04475 for ; Fri, 7 Jun 2002 13:13:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57Gv5c16416 for ips-outgoing; Fri, 7 Jun 2002 12:57:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57Gv1w16408 for ; Fri, 7 Jun 2002 12:57:01 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g57FtEu17152; Fri, 7 Jun 2002 11:55:14 -0400 Message-ID: <3D00E5CD.BD11E848@splentec.com> Date: Fri, 07 Jun 2002 12:56:45 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Amir Shalit CC: iSCSI , Julian Satran Subject: Re: iSCSI: ordered command delivery at the target References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Amir Shalit wrote: > > It does it for new commands but not for existing once > like what you are suggesting. It's all about "delivery". Even the more reason to implement this. Once a command has been delivered for execution to the device server, this means that Data-out pdu's (if any) have already been delivered (i.e. the command with its data (if any) has been delivered to the target). Thus no new ones are coming, thus, CmdSN may wrap around that CmdSN (submitted task). As for SNACK -- it will become a command if assigned CmdSN. (i.e. no reference to tasks, since they are refered to by SNACK->ITT). And for SNACK of type DataAck, this can be Immediate since the Target is keeping the whole thing into a ``pending (data) ack'' queue. Anyway... Comments? (on the original postng) -- Luben From owner-ips@ece.cmu.edu Fri Jun 7 13:14:12 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04526 for ; Fri, 7 Jun 2002 13:14:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57Gua416382 for ips-outgoing; Fri, 7 Jun 2002 12:56:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57GuXw16374 for ; Fri, 7 Jun 2002 12:56:33 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g57GuReE012210; Fri, 7 Jun 2002 18:56:27 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g57GuQ7130988; Fri, 7 Jun 2002 18:56:26 +0200 To: Luben Tuikov Cc: Amir Shalit , iSCSI , luben@ns.splentec.com MIME-Version: 1.0 Subject: Re: iSCSI: ordered command delivery at the target X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 7 Jun 2002 19:56:23 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 07/06/2002 19:56:26, Serialize complete at 07/06/2002 19:56:26 Content-Type: multipart/alternative; boundary="=_alternative 005CACEFC2256BD1_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005CACEFC2256BD1_= Content-Type: text/plain; charset="us-ascii" Luben, Amir is right. The text says explicitly that CmdSN has no significance whatsoever after delivery to SCSI (when the task is instantiated). ITT is the only means to identify safely a task. As for the difficulty of search for the ITT - that is all a question of implementation prowess (i.e., it should not e as difficult as you make it sound). Julo Luben Tuikov Sent by: luben@ns.splentec.com 06/07/2002 07:40 PM Please respond to Luben Tuikov To: Amir Shalit cc: iSCSI , Julian Satran/Haifa/IBM@IBMIL Subject: Re: iSCSI: ordered command delivery at the target Amir Shalit wrote: > > It will not work. If you issue a write command for multiple Terabytes (it's > allowed) > CmdSN may wrap before you are done with the command. > > Amir The target takes care or CmdSN wrapping for outstanding ITT, by virtue of MaxCmdSN and ExpCmdSN. If it didn't, all would go up in smoke! Please read the draft! Anyway... Comments? (on the original posting). -- Luben --=_alternative 005CACEFC2256BD1_= Content-Type: text/html; charset="us-ascii"
Luben,

Amir is right. The text says explicitly that CmdSN has no significance whatsoever after delivery to SCSI (when the task is instantiated).
ITT is the only means to identify safely a task. As for the difficulty of search for the ITT - that is all a question of implementation prowess
(i.e., it should not e as difficult as you make it sound).

Julo


Luben Tuikov <luben@splentec.com>
Sent by: luben@ns.splentec.com

06/07/2002 07:40 PM
Please respond to Luben Tuikov

       
        To:        Amir Shalit <amir@astutenetworks.com>
        cc:        iSCSI <ips@ece.cmu.edu>, Julian Satran/Haifa/IBM@IBMIL
        Subject:        Re: iSCSI: ordered command delivery at the target

       


Amir Shalit wrote:
>
> It will not work. If you issue a write command for multiple Terabytes (it's
> allowed)
> CmdSN may wrap before you are done with the command.
>
> Amir

The target takes care or CmdSN wrapping for outstanding ITT,
by virtue of MaxCmdSN and ExpCmdSN.
If it didn't, all would go up in smoke! Please read the draft!
Anyway...

Comments? (on the original posting).

--
Luben

--=_alternative 005CACEFC2256BD1_=-- From owner-ips@ece.cmu.edu Fri Jun 7 13:53:42 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05755 for ; Fri, 7 Jun 2002 13:53:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57HDO817517 for ips-outgoing; Fri, 7 Jun 2002 13:13:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57HDMw17512 for ; Fri, 7 Jun 2002 13:13:22 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 559BDD37B; Fri, 7 Jun 2002 11:13:21 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 72ED64BE; Fri, 7 Jun 2002 11:13:13 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 07 Jun 2002 11:13:04 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Jun 2002 11:12:32 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E3AE4@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: eddy_quicksall@ivivity.com, ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Date: Fri, 7 Jun 2002 11:12:30 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy, If one uses a message sync and steering that relys on the transport segments carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path MTU changes one would want to change the PDU data length to fit the new path MTU. Pat -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Wednesday, June 05, 2002 12:24 PM To: ips@ece.cmu.edu Subject: iSCSI: changing MaxPDUDataLength Does anybody know a case where it is necessary to support a new PDU data length during full feature phase? Eddy mailto: Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Fri Jun 7 13:54:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05795 for ; Fri, 7 Jun 2002 13:54:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57HJqW17916 for ips-outgoing; Fri, 7 Jun 2002 13:19:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from emulex.emulex.com (emulex.emulex.com [138.239.112.1]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57HJnw17908 for ; Fri, 7 Jun 2002 13:19:49 -0400 (EDT) Received: from xbl.ad.emulex.com (xbl.ma.emulex.com [172.16.12.11]) by emulex.emulex.com (8.9.1a/8.9.1) with ESMTP id KAA28060 for ; Fri, 7 Jun 2002 10:19:43 -0700 (PDT) Received: by xbl.ad.emulex.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Jun 2002 13:19:42 -0400 Message-ID: <3356669BBE90C448AD4645C843E2BF289B8DC3@xbl.ad.emulex.com> From: "Williams, Jim" To: ips@ece.cmu.edu Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys Date: Fri, 7 Jun 2002 13:19:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > Oh boy, now I'm well and truly frightened. > > I read your message as saying that there isn't going to be > interoperability for several years. So rather than create a serious > incentive for implementers to fix their defects, we should implement a > way to have them report which collection of defects they implement so > we can invoke workaround collection #42. Of course, the larger the > collection of crocks we work around, the larger the number of bugs in > implementations that everyone else will have to work around. > > In the words of a well known American, "Just Say NO". > > paul I am not sure if I agree with the conclusion or not, but I have some concerns about the reasoning behind it. 1. If history is a guide regarding standards of this complexity, then it will likely take some years to resolve all the interoperability issues. So what is the best thing to do in the mean time? Is it to make the interoperability issues as painful as possible as an incentive to fix them quickly? Or is it to make working around as easy as possible so as to foster development of a market and create a financial incentive to fix them at all. 2. I don't think it's valid to assume that interoperability problems are necessarily due to defects in the implementation. In fact, those are probably the easier ones to address. The harder ones are due to defects in the standard itself. Suppose vendor A and vendor B don't interoperate, but the standard is sufficiently ambiguous that both are fully compliant. The next rev of the standard needs to fix this, but what is vendor C to do in the mean time? Also if the standard itself has some defects that need to be worked around by vendors, likely different vendor's work arounds will not be fully interoperable for some period of time. Of course, if the standard is perfect, things are a lot easier. But I am reluctant to assume that as a given. From owner-ips@ece.cmu.edu Fri Jun 7 13:55:39 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05867 for ; Fri, 7 Jun 2002 13:55:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57HTZd18624 for ips-outgoing; Fri, 7 Jun 2002 13:29:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57HTWw18620 for ; Fri, 7 Jun 2002 13:29:32 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 0FA0B30706; Fri, 7 Jun 2002 13:29:31 -0400 (EDT) Date: Fri, 7 Jun 2002 10:27:25 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Robert Snively Cc: "'Ken Sandars'" , "Ips Reflector (E-mail)" Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys In-Reply-To: <2F37CED150E21640A9C6E75B8BE6AF830A4CC4@hq-ex-4> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Fri, 7 Jun 2002, Robert Snively wrote: > The management component already has standard mechanisms > for determining such information, including MIBs and CIM > objects. The operational components already have standard > mechanisms for determining such information, including > SCSI INQUIRY commands. I cannot see how this additional > (non-standard) mechanism for capturing this information is > going to help iSCSI achieve its goals. Question about the operational components being able to determine this info. iSCSI is, in terms from SAM-2, a Service Delivery Subsystem (SDS). While many implementations act as scsi servers (disks & tapes, etc.), that's not part of the spec. So I'm confused how an SDS answers a SCSI INQUIRY. I thought that was the domain of the device(s) at the other end of the connection, not the domain of the connection itself. Take care, Bill From owner-ips@ece.cmu.edu Fri Jun 7 13:55:53 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05889 for ; Fri, 7 Jun 2002 13:55:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57Hi9C19515 for ips-outgoing; Fri, 7 Jun 2002 13:44:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57Hi6w19508 for ; Fri, 7 Jun 2002 13:44:06 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g57GgJu17404; Fri, 7 Jun 2002 12:42:19 -0400 Message-ID: <3D00F0D6.320F25D9@splentec.com> Date: Fri, 07 Jun 2002 13:43:50 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Julian Satran CC: Amir Shalit , iSCSI Subject: Re: iSCSI: ordered command delivery at the target References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian Satran wrote: > > Luben, > > Amir is right. The text says explicitly that CmdSN has no significance whatsoever after delivery > to SCSI (when the task is instantiated). > ITT is the only means to identify safely a task. As for the difficulty of search for the ITT - > that is all a question of implementation prowess > (i.e., it should not e as difficult as you make it sound). Julian, I'm talking about Data-Out PDU's. CmdSN is NOT advanced for Data-Out PDU's, only _copied_ from the original task/command. A task CANNOT be delivered to the device server without all data being available at the target, being the case that there could be a huge network (Ethernet) latency. Once all data has arrived, then the task is delivered to the device server (LL SCSI) and CmdSN becomes irrelevant. Furthermore, CmdSN is NOT advanced on sending Data-Out pdu's -- it is just copied there from the original task/command. The whole point of this is making inserting into the ``incoming'' priority queue ordered. When the task is moved into a ``pending for more data'' queue, this would naturally make the Data-out PDUs immediate PDUs, as they should be. When Data-Outs arrive at the target, CmdSN has advanced by at least k*** since the task has been just _received_, and any ``older'' Data-Out PDUs (carrying the same CmdSN) will go to the front of the ``incoming'' queue and be seen immediately. *** If k = 0, then the task is still in the ``incoming'' queue and the Data-Out is sorted right after it -- same effect. Furthermore, the target will NOT allow CmdSN wrapping for an outstanding task (one for which data is being delivered, I->T, in order to be sent to the device server (SCSI), _only_ after which CmdSN becomes irrelevant, but this means that all data was delivered....). Do you see it? -- Luben P.S. CmdSN wrapping MUST not depend on the choice of maximum data segment. The suggestion I posted preserves this reservation. From owner-ips@ece.cmu.edu Fri Jun 7 14:18:55 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07317 for ; Fri, 7 Jun 2002 14:18:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57Ht3j20316 for ips-outgoing; Fri, 7 Jun 2002 13:55:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from best.eurologic.com ([213.190.135.5]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57Ht0w20311 for ; Fri, 7 Jun 2002 13:55:01 -0400 (EDT) Received: from there (wombat [192.168.7.41]) by best.eurologic.com (8.9.3+Sun/8.9.3) with SMTP id SAA25583; Fri, 7 Jun 2002 18:54:45 +0100 (BST) Message-Id: <200206071754.SAA25583@best.eurologic.com> Content-Type: text/plain; charset="iso-8859-1" From: Ken Sandars Organization: Eurologic Systems To: pat_thaler@agilent.com, ni1d@arrl.net, bmastors@allocity.com Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys Date: Fri, 7 Jun 2002 17:53:56 +0000 X-Mailer: KMail [version 1.3.1] Cc: ips@ece.cmu.edu References: <1BEBA5E8600DD4119A50009027AF54A00C5E396B@axcs04.cos.agilent.com> In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00C5E396B@axcs04.cos.agilent.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi Pat, Paul, Bob, There is no disputing the fact that identifying brokeness and fixing it is the right way to go. Now while it's nice to lend our mental muscles to the task of identifying these problems, it's pretty difficult to compel other vendors to fix something which is broken wrt to the spec, when it works with some other products in the marketplace. The unfortunate reality is that certain problems have been long identified (over half a year in some cases), and remain unfixed. Our approach is to implement the spec. As we encounter problems we fix our broken bits and notify the partner of the issue - in most cases this has worked well and they have fixed their problems too. However, we are compelled to put work-arounds in our system in order to interoperate with those who have have fielded systems which remain broken. At this stage, unless the intiator is known, we turn all the work-arounds on. This has an impact on performance. We'd like to avoid this. We want to see iSCSI run at the speed of a thousand startled gazelles. We want to see all iSCSI offerings interoperate. We don't want to see the management of these things as a nightmare. I think the use of the proposed keys will only assist implementers by providing additonal information - which can be used or ignored. Oh, and we won't send them from our target if the initiator doesn't send them, as there may be some initiator which doesn't handle the X- keys! (I have further comments inline): On Thursday 06 June 2002 11:31 pm, pat_thaler@agilent.com wrote: > Paul, > > I agree. This would also create a testing nightmare for initiator > developers. If the initiator has adapts itself for n targets then > it has n different personalities that all need to be tested. > As Bob Mastors said, it's already in there, so it's being done. And testers are meant to have nightmares! It's their job ;-) > We have interoperability testing to help us find and fix > spec ambiguities that cause interoperability problems. > Yep - we find them, and they ignore them, so this doesn't get us over the finish line. > The way to build market for iSCSI is to have interoperability - > not to have cases wher Brand_x Target doesn't work with Brand_y > Initiator because Brand_y doesn't have the tweak profile for > Brand_x. > As I noted above, we interoperate, but at the cost of performance. > Regards, > Pat > > -----Original Message----- > From: Paul Koning [mailto:ni1d@arrl.net] > Sent: Thursday, June 06, 2002 1:06 PM > To: bmastors@allocity.com > Cc: ksandars@eurologic.com; ips@ece.cmu.edu > Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys > > >>>>> "Bob" == Bob Mastors writes: > > Bob> I like it. Otherwise the user has to configure the initiator > Bob> with the target type and the target with the initiator type. It > Bob> is unlikely that this problem will disappear for a long time if > Bob> ever. As the threads on the C bit has shown there will be lots > Bob> of ways to implement the spec and probably no device will > Bob> correctly support all possibilities. I am already putting "if > Bob> (vendor)" code in my implementation. Maybe in a few years I will > Bob> not need it. But until then it would be nice if I could > Bob> dynamically determine vendor information for iscsi so the user > Bob> does not have to configure it. > > Oh boy, now I'm well and truly frightened. Welcome to my nightmare! > > I read your message as saying that there isn't going to be > interoperability for several years. I'm a lot more optimistic than that - these problems should be gone within a year of the draft becoming a standard. In the meantime, we DO interoperate, just in a hobbled mode for unknown initiators. > Sorather than create a serious > incentive for implementers to fix their defects, Can you suggest what this incentive might be? > we should implement a > way to have them report which collection of defects they implement so > we can invoke workaround collection #42. Of course, the larger the > collection of crocks we work around, the larger the number of bugs in > implementations that everyone else will have to work around. > Sounds messy to me. It comes down to this: we work by default in a mode to achieve maximum interoperability, albeit at the expense of some performance/reliability features. If an initiator lets our target know what it is, and we recognise its lack of the known quirks, we remove the work-arounds. Our tester's nightmares, our developer's pain to identify and create work-arounds, and at no cost to the standards track. And it's all optional. > In the words of a well known American, "Just Say NO". OK - but think carefully before following the advice of famous Americans - didn't some other well known American spell tomato with an 'e'? ;-) > > paul Cheers, Ken -- Ken Sandars Eurologic Systems Ltd ksandars@eurologic.com From owner-ips@ece.cmu.edu Fri Jun 7 14:19:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07335 for ; Fri, 7 Jun 2002 14:19:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57I5ir21088 for ips-outgoing; Fri, 7 Jun 2002 14:05:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from med.corp.rhapsodynetworks.com (64-160-62-201.rhapsodynetworks.com [64.160.62.201] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57I5ew21070 for ; Fri, 7 Jun 2002 14:05:40 -0400 (EDT) Received: by med.corp.rhapsodynetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Jun 2002 11:05:33 -0700 Message-ID: <45BEF1D68145D51186C100B0D0AABE659E0154@med.corp.rhapsodynetworks.com> From: Dennis Young To: "'Robert Snively'" , "'Ken Sandars'" , "Ips Reflector (E-mail)" Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys Date: Fri, 7 Jun 2002 11:05:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Bob, Regarding the management component, it is very useful to have the vendor product name and revision number available as part of the iSCSI login negotiation, this would allow the developer/administrator to save the login trace to syslog or something similar for immediate or future analysis or bug reporting. Without this information embedded in the trace, it would be very difficult to go back to the old log and know for sure which revision of the product you were dealing with. Accessing iSCSI MIB requires a separate step, path, management tool. Some low end products may not provide it at all. And most importantly, it won't help you if you have to analyze some old traces. Think of this scenario, suppose you are building an iSCSI HBA and you need to do login interoperability testings with 10 different iSCSI targets, wouldn't it be nice that all you have to do is to run the tests and save the login traces, knowing that the product id and revision is embedded in the trace. I feel that this kind of information should definitely be there, if X key is not appropriate, I would suggest to use regular key. Regards, -Dennis >-----Original Message----- >From: Robert Snively [mailto:rsnively@Brocade.COM] >Sent: Friday, June 07, 2002 8:32 AM >To: 'Ken Sandars'; Robert Snively; Ips Reflector (E-mail) >Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys > > >Ken, > >In my experience, "vendor specific" is a synonym for >"non-interoperable". Realistically, if there is any tuning >to be done with respect to the iSCSI transport behavior, then >it should be done through standardized mechanisms during >the login, not through vendor specific mechanisms. > >The management component already has standard mechanisms >for determining such information, including MIBs and CIM >objects. The operational components already have standard >mechanisms for determining such information, including >SCSI INQUIRY commands. I cannot see how this additional >(non-standard) mechanism for capturing this information is >going to help iSCSI achieve its goals. > >Those legacy devices that are being supported by non-standard >programs and non-standard protocol events are simply NOT >compliant iSCSI devices. If anyone cares about using them >in an iSCSI environment, they must be upgraded to iSCSI >compliance. > >Bob > > > >> -----Original Message----- >> From: Ken Sandars [mailto:ksandars@eurologic.com] >> Sent: Friday, June 07, 2002 4:20 AM >> To: Robert Snively; Ips Reflector (E-mail) >> Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys >> >> >> Hi Bob, >> >> No, that's not what I'm suggesting. I was not looking at >> affecting anything >> at the SCSI layer. This proposal is purely communicating >> information between >> the iSCSI (transport) layers. I wouldn't expect this information to >> necessarily be passed to the SCSI layer on either target or >initiator. >> >> This information was intended to be used at the iSCSI layer >> to "tune" iSCSI >> behaviour, and to provide additional information to the >> management component >> of each implementation. The latter reason is more important >> as it can assist >> in maintaining an iSCSI SAN, and this is where I'd like to >> see this end up. >> > From owner-ips@ece.cmu.edu Fri Jun 7 14:19:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07380 for ; Fri, 7 Jun 2002 14:19:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57HiC119526 for ips-outgoing; Fri, 7 Jun 2002 13:44:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g57HiAw19518 for ; Fri, 7 Jun 2002 13:44:10 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g57Hi4p09506 for ; Fri, 7 Jun 2002 13:44:04 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g57Hi4c09497; Fri, 7 Jun 2002 13:44:04 -0400 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with SMTP id g57Hi4h23927; Fri, 7 Jun 2002 13:44:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15616.61667.735021.435265@pkoning.dev.equallogic.com> Date: Fri, 7 Jun 2002 13:44:03 -0400 From: Paul Koning To: luben@splentec.com Cc: ips@ece.cmu.edu, Julian_Satran@il.ibm.com Subject: Re: iSCSI: ordered command delivery at the target References: <3D00DA1D.1AFD5842@splentec.com> X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Luben" == Luben Tuikov writes: Luben> ... Luben> From all the Requests, only Data-Out and SNACK, Luben> reserve offset 24, which would break insertion into the Luben> ``incoming'' priority queue. Luben> Since SCSI Command (Request) is assigned CmdSN as well as ITT, Luben> why not stupulate that Data-Out has to carry the same CmdSN as Luben> the task to which they belong (by ITT). Let's defer all further packet format changes to iSCSI V2. paul From owner-ips@ece.cmu.edu Fri Jun 7 14:27:27 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07633 for ; Fri, 7 Jun 2002 14:27:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57HwK520523 for ips-outgoing; Fri, 7 Jun 2002 13:58:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57HwGw20512 for ; Fri, 7 Jun 2002 13:58:16 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Jun 2002 13:58:00 -0400 Message-ID: From: Eddy Quicksall To: "'Luben Tuikov '" , "'Amir Shalit '" Cc: "'iSCSI '" , "'Julian Satran '" Subject: RE: iSCSI: ordered command delivery at the target Date: Fri, 7 Jun 2002 13:57:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Luben The Device Server may need to use the iSCSI SDS to get the data ... so all data-out PDUs may not have been delivered yet. Does that make a difference to your case? Eddy -----Original Message----- From: Luben Tuikov To: Amir Shalit Cc: iSCSI; Julian Satran Sent: 6/7/02 12:56 PM Subject: Re: iSCSI: ordered command delivery at the target Amir Shalit wrote: > > It does it for new commands but not for existing once > like what you are suggesting. It's all about "delivery". Even the more reason to implement this. Once a command has been delivered for execution to the device server, this means that Data-out pdu's (if any) have already been delivered (i.e. the command with its data (if any) has been delivered to the target). Thus no new ones are coming, thus, CmdSN may wrap around that CmdSN (submitted task). As for SNACK -- it will become a command if assigned CmdSN. (i.e. no reference to tasks, since they are refered to by SNACK->ITT). And for SNACK of type DataAck, this can be Immediate since the Target is keeping the whole thing into a ``pending (data) ack'' queue. Anyway... Comments? (on the original postng) -- Luben From owner-ips@ece.cmu.edu Fri Jun 7 14:37:46 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08095 for ; Fri, 7 Jun 2002 14:37:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57IRk422586 for ips-outgoing; Fri, 7 Jun 2002 14:27:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57IRiw22582 for ; Fri, 7 Jun 2002 14:27:44 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g57ITMu17687; Fri, 7 Jun 2002 14:29:22 -0400 Message-ID: <3D00FB14.5189539B@splentec.com> Date: Fri, 07 Jun 2002 14:27:32 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eddy Quicksall CC: "'Amir Shalit '" , "'iSCSI '" , "'Julian Satran '" Subject: Re: iSCSI: ordered command delivery at the target References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Eddy Quicksall wrote: > > Luben > > The Device Server may need to use the iSCSI SDS to get the data ... so all > data-out PDUs may not have been delivered yet. Does that make a difference > to your case? Eddy, By ``device server'' I mean ``device controller'' which will most likely do bus mastering on the PCI bus to obtain the data from the host's memory. So, I'd put all data in the target node's host memory. Else, what you are suggesting, the device server will time out immediately... network (Ethernet) latencies... -- Luben From owner-ips@ece.cmu.edu Fri Jun 7 17:23:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13412 for ; Fri, 7 Jun 2002 17:23:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57KtHo01740 for ips-outgoing; Fri, 7 Jun 2002 16:55:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57KtEw01725 for ; Fri, 7 Jun 2002 16:55:14 -0400 (EDT) Received: from hq-ex-c3.brocade.com (hq-ex-c3 [192.168.126.211]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id NAA29587; Fri, 7 Jun 2002 13:54:51 -0700 (PDT) Received: by hq-ex-c3.brocade.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Jun 2002 13:55:21 -0700 Message-ID: <2F37CED150E21640A9C6E75B8BE6AF830A4CCB@hq-ex-4> From: Robert Snively To: "'Bill Studenmund'" , Robert Snively Cc: "'Ken Sandars'" , "Ips Reflector (E-mail)" Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys Date: Fri, 7 Jun 2002 13:54:48 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk Comments below. > From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] > On Fri, 7 Jun 2002, Robert Snively wrote: > > > The management component already has standard mechanisms > > for determining such information, including MIBs and CIM > > objects. The operational components already have standard > > mechanisms for determining such information, including > > SCSI INQUIRY commands. I cannot see how this additional > > (non-standard) mechanism for capturing this information is > > going to help iSCSI achieve its goals. > > Question about the operational components being able to determine this > info. iSCSI is, in terms from SAM-2, a Service Delivery > Subsystem (SDS). > While many implementations act as scsi servers (disks & tapes, etc.), > that's not part of the spec. > You are clearly correct. By operational components, I mean those that are performing SCSI operations. The service delivery system (iSCSI) is already neatly standardized and has no need to identify vendor and model, since by being iSCSI it has already specified its interoperability requirement. > So I'm confused how an SDS answers a SCSI INQUIRY. I thought > that was the > domain of the device(s) at the other end of the connection, > not the domain > of the connection itself. From owner-ips@ece.cmu.edu Fri Jun 7 17:24:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13471 for ; Fri, 7 Jun 2002 17:24:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57KgOC01015 for ips-outgoing; Fri, 7 Jun 2002 16:42:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57KgKw01004 for ; Fri, 7 Jun 2002 16:42:21 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id NAA28505; Fri, 7 Jun 2002 13:41:49 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Jun 2002 13:41:49 -0700 Message-ID: <2F37CED150E21640A9C6E75B8BE6AF830A4CC9@hq-ex-4> From: Robert Snively To: "'Luben Tuikov'" , Julian Satran Cc: Amir Shalit , iSCSI Subject: RE: iSCSI: ordered command delivery at the target Date: Fri, 7 Jun 2002 13:41:44 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk Caution: Device Server is a reserved keyword in SCSI. It is the mechanism which interprets a SCSI command, allocates data buffers, requests and performs the data transfer, and sends appropriate completion information. Those folks who are explaining that CmdSN is only used to capture the order of delivery of commands with respect to other commands are correct. The actual interpretation of the command, choice of execution order, data request order, and a stack of other things are at the whim of the Device Server, regulated only by those ordering attributes specifically requested by the originator of the request, the Application Client. Such actions are usually heavily overlapped for different tasks and are likely to be performed out of order. That is why the CmdSN is not used to identify those other actions. Instead, the ITT is used to identify the components of a task. References: SAM-2, iSCSI, SPC-2. Bob > I'm talking about Data-Out PDU's. CmdSN is NOT advanced > for Data-Out PDU's, only _copied_ from the original task/command. > > A task CANNOT be delivered to the device server > without all data being available at the target, > being the case that there could be a huge > network (Ethernet) latency. Once all data has > arrived, then the task is delivered to the > device server (LL SCSI) and CmdSN becomes irrelevant. > > Furthermore, CmdSN is NOT advanced on sending > Data-Out pdu's -- it is just copied there > from the original task/command. > > The whole point of this is making > inserting into the ``incoming'' priority > queue ordered. > > When the task is moved into a ``pending for more data'' queue, > this would naturally make the Data-out PDUs immediate > PDUs, as they should be. When Data-Outs arrive at the > target, CmdSN has advanced by at least k*** since the task has been > just _received_, and any ``older'' Data-Out PDUs (carrying > the same CmdSN) > will go to the front of the ``incoming'' queue and be seen > immediately. > > *** If k = 0, then the task is still in the ``incoming'' queue > and the Data-Out is sorted right after it -- same effect. > > Furthermore, the target will NOT allow CmdSN wrapping > for an outstanding task (one for which data is being delivered, I->T, > in order to be sent to the device server (SCSI), _only_ after which > CmdSN becomes irrelevant, but this means that all data was > delivered....). > > Do you see it? > > -- > Luben > P.S. CmdSN wrapping MUST not depend on the choice of > maximum data segment. The suggestion I posted preserves > this reservation. > From owner-ips@ece.cmu.edu Fri Jun 7 17:24:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13489 for ; Fri, 7 Jun 2002 17:24:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57KnWI01409 for ips-outgoing; Fri, 7 Jun 2002 16:49:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57KnUw01405 for ; Fri, 7 Jun 2002 16:49:31 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id NAA29068; Fri, 7 Jun 2002 13:49:20 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Jun 2002 13:49:20 -0700 Message-ID: <2F37CED150E21640A9C6E75B8BE6AF830A4CCA@hq-ex-4> From: Robert Snively To: "'Dennis Young'" , Robert Snively , "'Ken Sandars'" , "Ips Reflector (E-mail)" Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys Date: Fri, 7 Jun 2002 13:49:15 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk > > Regarding the management component, it is very useful to > have the vendor product name and revision number available > as part of the iSCSI login negotiation, this would allow > the developer/administrator to save the login trace to syslog > or something similar for immediate or future analysis or > bug reporting. Without this information embedded in the trace, > it would be very difficult to go back to the old log and > know for sure which revision of the product you were dealing > with. Not a function of the login. This is a function of the MIB at the management level and of the SCSI Inquiry at the driver level. Unless of course you don't believe in standard internet and storage management protocols :-) > > Accessing iSCSI MIB requires a separate step, path, management > tool. Some low end products may not provide it at all. > And most importantly, it won't help you if you have to analyze > some old traces. > Are there actually devices in an iSCSI environment that will have no MIB? > Think of this scenario, suppose you are building an iSCSI HBA > and you need to do login interoperability testings with 10 > different iSCSI targets, wouldn't it be nice that all you have > to do is to run the tests and save the login traces, knowing that > the product id and revision is embedded in the trace. > Nope. I know who they are by their MIB or CIM information. > I feel that this kind of information should definitely be there, > if X key is not appropriate, I would suggest to use regular key. I feel that this information is already there and creating a redundant and non-standard mechanism for replicating this information is a real problem. From owner-ips@ece.cmu.edu Fri Jun 7 17:26:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13590 for ; Fri, 7 Jun 2002 17:26:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57L3KN02181 for ips-outgoing; Fri, 7 Jun 2002 17:03:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57L3Iw02176 for ; Fri, 7 Jun 2002 17:03:18 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 587503070A; Fri, 7 Jun 2002 17:03:17 -0400 (EDT) Date: Fri, 7 Jun 2002 14:01:08 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Dennis Young Cc: "'Robert Snively'" , "'Ken Sandars'" , "Ips Reflector (E-mail)" Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys In-Reply-To: <45BEF1D68145D51186C100B0D0AABE659E0154@med.corp.rhapsodynetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Fri, 7 Jun 2002, Dennis Young wrote: > Hi Bob, > > Regarding the management component, it is very useful to > have the vendor product name and revision number available > as part of the iSCSI login negotiation, this would allow > the developer/administrator to save the login trace to syslog > or something similar for immediate or future analysis or > bug reporting. Without this information embedded in the trace, > it would be very difficult to go back to the old log and > know for sure which revision of the product you were dealing > with. True. Very true. > Accessing iSCSI MIB requires a separate step, path, management > tool. Some low end products may not provide it at all. > And most importantly, it won't help you if you have to analyze > some old traces. Plus it's a piece of separate information that must manually be assosciated with the trace. > Think of this scenario, suppose you are building an iSCSI HBA > and you need to do login interoperability testings with 10 > different iSCSI targets, wouldn't it be nice that all you have > to do is to run the tests and save the login traces, knowing that > the product id and revision is embedded in the trace. More to the point, if I have a customer come to me with a problem, if these keys are in the login sequence, I can have the customer tcpdump the session and send it to me. Info about exactly what rev of my product and of the other side are in that dump. It means there's one file to send in for analysis. > I feel that this kind of information should definitely be there, > if X key is not appropriate, I would suggest to use regular key. Sounds like there is enough interest that regular keys might be warranted. > Regards, > -Dennis > > >-----Original Message----- > >From: Robert Snively [mailto:rsnively@Brocade.COM] > >Sent: Friday, June 07, 2002 8:32 AM > >To: 'Ken Sandars'; Robert Snively; Ips Reflector (E-mail) > >Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys > > > > > >Ken, > > > >In my experience, "vendor specific" is a synonym for > >"non-interoperable". Realistically, if there is any tuning > >to be done with respect to the iSCSI transport behavior, then > >it should be done through standardized mechanisms during > >the login, not through vendor specific mechanisms. Robert, What about the case(s) Luben describes, where due to problems in the spec, two different implementations that both follow the spec don't interoperate? The case of compliant-non-interoperability? I don't think anyone on this list wants that, but from what Luben says, we have it now. I gather that you believe that if we add these keys, we will be opening the door to an interoperability mess. I believe that is not correct; we either have a spec that permits compliant-non-interoperability, or we don't. I do not believe that adding or not adding these keys will change that. All adding these keys will do would be to make it easier for iSCSI code to cope with discovered compliant-non-interoperability; for them to encourage it would mean that the working group has stopped improving the spec. Also, what do we do with installed systems? Say we find and correct a problem. Until our end users upgrade field-deployed systems, the problem continues. Are the sysadmins of our customers going to be happy if we try to force them to upgrade production "seems-to-work" systems, just because we found a bug in the spec? My experience as a sysadmin and with sysadmins is that they will say rude things to us and ignore us. That's not a good way to sell iSCSI systems. :-| ** Summary ** Let me see if I can wrap this thread up a little so that we can get closer to closure. There is a suggestion that we add common-use keys to indicate vendor, model, and revision. The initial suggestion was for X-foo keys. This format violates our standard for how X- keys work, so an alternate of X-someone.short.foo was put forth. Dennis suggests above just making them standard (I'm assuming Declarative) keys. Some of us (including myself) see diagnostic value in having these keys in common use. One tcpdump of a session includes info about what was talking to what. Some people are concerned that adding these keys will permit or tacitly encourage us to slide into a mode where we paper over interop problems rather than fix them. I think implicit in this point of view is that we don't have major interop problems now. Others (including myself) believe that the WG and the iSCSI vendors will do the right thing and not lazily slide into that mess. So we have a proposal with 4 options and two motivations: Proposal for keys: 1) Do nothing; don't encourage common-use keys 2) Add X-vendor, X-product, and X-revision to the common venacular. They would of course be "vendor specific," just a number of vendors would use them. 3) Some short-named vendor come forward and add names in its space that everyone use. Like say X-edu.unh.vendor, X-edu.unh.product... 4) Make them standard keys, like Vendor, Product, Revision. I'd vote they are delcarative and per-direction. And if you talk to something that doesn't understand them, you'll be talking to vendor "NotUnderstood". :-) Motivations A) makes it easy to identify vendor/product/rev. All you have to do is capture a session (tcpdump/ethereal), and you have it. Info is in one place. B) Identify system on other side of connection/session to turn on/off quirk support. My thoughts: I like either option 3) or 4). I'd prefer 4, but I realize this is late in the game for the standard, so 3) might be best for now. I think Motivation A is a damn good one, and reason enough to add these key. For Motivation B, as above, I don't think they will get us into messes we aren't already in, so they are fine. Take care, Bill From owner-ips@ece.cmu.edu Fri Jun 7 18:07:11 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14669 for ; Fri, 7 Jun 2002 18:07:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57LRQ003403 for ips-outgoing; Fri, 7 Jun 2002 17:27:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from med.corp.rhapsodynetworks.com (64-160-62-201.rhapsodynetworks.com [64.160.62.201] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57LROw03398 for ; Fri, 7 Jun 2002 17:27:24 -0400 (EDT) Received: by med.corp.rhapsodynetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Jun 2002 14:27:18 -0700 Message-ID: <45BEF1D68145D51186C100B0D0AABE659E0158@med.corp.rhapsodynetworks.com> From: Dennis Young To: "'Robert Snively'" , "'Ken Sandars'" , "Ips Reflector (E-mail)" Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys Date: Fri, 7 Jun 2002 14:27:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Please see comments below. >-----Original Message----- >From: Robert Snively [mailto:rsnively@brocade.com] >Sent: Friday, June 07, 2002 1:49 PM >To: 'Dennis Young'; Robert Snively; 'Ken Sandars'; Ips Reflector >(E-mail) >Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys > > >> >> Regarding the management component, it is very useful to >> have the vendor product name and revision number available >> as part of the iSCSI login negotiation, this would allow >> the developer/administrator to save the login trace to syslog >> or something similar for immediate or future analysis or >> bug reporting. Without this information embedded in the trace, >> it would be very difficult to go back to the old log and >> know for sure which revision of the product you were dealing >> with. > >Not a function of the login. This is a function of the >MIB at the management level and of the SCSI Inquiry at >the driver level. Unless of course you don't believe in >standard internet and storage management protocols :-) If this information helps in documenting and communicating potential login problems, why not include it in the login? Again, without this information, it is very difficult to correlate a old trace with the product/revision of a remote device. > >> >> Accessing iSCSI MIB requires a separate step, path, management >> tool. Some low end products may not provide it at all. >> And most importantly, it won't help you if you have to analyze >> some old traces. >> > >Are there actually devices in an iSCSI environment that will >have no MIB? > >> Think of this scenario, suppose you are building an iSCSI HBA >> and you need to do login interoperability testings with 10 >> different iSCSI targets, wouldn't it be nice that all you have >> to do is to run the tests and save the login traces, knowing that >> the product id and revision is embedded in the trace. >> > >Nope. I know who they are by their MIB or CIM information. > >> I feel that this kind of information should definitely be there, >> if X key is not appropriate, I would suggest to use regular key. > >I feel that this information is already there and creating >a redundant and non-standard mechanism for replicating this >information is a real problem. > I agree that this information is already there, I am not suggesting to replicate, but just provide another means to present it to the client. Regards, Dennis From owner-ips@ece.cmu.edu Fri Jun 7 18:07:25 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14685 for ; Fri, 7 Jun 2002 18:07:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57LQNw03364 for ips-outgoing; Fri, 7 Jun 2002 17:26:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57LQLw03359 for ; Fri, 7 Jun 2002 17:26:21 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel11.hp.com (Postfix) with ESMTP id 65185600164; Fri, 7 Jun 2002 14:26:15 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id OAA27083; Fri, 7 Jun 2002 14:28:02 -0700 (PDT) Message-ID: <008f01c20e69$f3595c70$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: , "Julian Satran" Cc: References: Subject: Re: iSCSI: response reason Date: Fri, 7 Jun 2002 14:26:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, I was about to send a message to you on this myself. I think it's better to leave the wording in 12-96 as is, and change the "Reason" to "Response reason" in the table in section 9.4.6.2. The problem with the changed wording in 12-97 is that it still does not mention the sense key, and states something that isn't accurate (for ex., there is no 'Sense of "protocol service CRC error" ', the SPC-3 name for it is "CRC error detected"). The more descriptive "reason" terminology is an iSCSI notion we had adopted quite a while ago. I reason I had used "Response reason" as in index into the said table is to avoid repeating the CHECKCONDITION/Key/ ASC/ASCQ information everywhere - but I had overlooked that the table doesn't use "response reason". I'd recommend fixing just that. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Julian Satran" To: Cc: ; "Julian Satran" Sent: Friday, June 07, 2002 7:07 AM Subject: Re: iSCSI: response reason > thanks - it is fixed in 12-97 - Julo > > > > "Eddy Quicksall" > om> cc: > Subject: iSCSI: response reason > 06/06/2002 11:28 > PM > Please respond to > Eddy > > > > > > Section 6.5 Digest Errors uses the phrase "iSCSI response reason" and > refers to section 9.4.3. But there is no such term used in that section. > > There is, however, a term used called "iSCSI service response". But, > section 6.5 is not talking about that. > > I believe section 6.5 is talking about the heading "reason" that appears in > the 1st column of the table in section 9.4.6.2. > > So to clarify things, how about changing the table heading in 9.4.6.2 to > say "iSCSI Condition" and section 6.5 to say "iSCSI Condition (Section > 9.4.6.2 Sense Data)? > > The term "iSCSI Condition" is also compatible with the same term used in > the 2nd paragraph of 9.4.6.2. > > Eddy > > > > From owner-ips@ece.cmu.edu Fri Jun 7 18:09:10 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14733 for ; Fri, 7 Jun 2002 18:09:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57LkWu04281 for ips-outgoing; Fri, 7 Jun 2002 17:46:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57LkUw04277 for ; Fri, 7 Jun 2002 17:46:30 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel12.hp.com (Postfix) with ESMTP id 9D7CFE0036D; Fri, 7 Jun 2002 14:46:24 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id OAA00285; Fri, 7 Jun 2002 14:48:12 -0700 (PDT) Message-ID: <00a101c20e6c$c46a68c0$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Luben Tuikov" , "Julian Satran" Cc: "Amir Shalit" , "iSCSI" References: <3D00F0D6.320F25D9@splentec.com> Subject: Re: iSCSI: ordered command delivery at the target Date: Fri, 7 Jun 2002 14:46:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Amir and Julian are correct. I see a lot of mistaken notions in this note, and IIRC, this was discussed several times in the past. The SCSI Architecture Model defines the data transfer protocol services that are invoked by the SCSI ULP to drive the data transfers - thus technically letting an instantiated SCSI task to perform data transfers. CmdSN is relevant only *before* the task is instantiated. BTW, initiator ULP timeouts are exactly meant to take care of the "network latency" issues. AFAICT, assigning CmdSN to SNACK would lead to a lot more complexity (issuing SNACKs to recover lost SNACKs and....), and I don't see what the issue is now. Needless to say, I would not recommend either of these. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Luben Tuikov" To: "Julian Satran" Cc: "Amir Shalit" ; "iSCSI" Sent: Friday, June 07, 2002 10:43 AM Subject: Re: iSCSI: ordered command delivery at the target > Julian Satran wrote: > > > > Luben, > > > > Amir is right. The text says explicitly that CmdSN has no significance whatsoever after delivery > > to SCSI (when the task is instantiated). > > ITT is the only means to identify safely a task. As for the difficulty of search for the ITT - > > that is all a question of implementation prowess > > (i.e., it should not e as difficult as you make it sound). > > Julian, > > I'm talking about Data-Out PDU's. CmdSN is NOT advanced > for Data-Out PDU's, only _copied_ from the original task/command. > > A task CANNOT be delivered to the device server > without all data being available at the target, > being the case that there could be a huge > network (Ethernet) latency. Once all data has > arrived, then the task is delivered to the > device server (LL SCSI) and CmdSN becomes irrelevant. > > Furthermore, CmdSN is NOT advanced on sending > Data-Out pdu's -- it is just copied there > from the original task/command. > > The whole point of this is making > inserting into the ``incoming'' priority > queue ordered. > > When the task is moved into a ``pending for more data'' queue, > this would naturally make the Data-out PDUs immediate > PDUs, as they should be. When Data-Outs arrive at the > target, CmdSN has advanced by at least k*** since the task has been > just _received_, and any ``older'' Data-Out PDUs (carrying the same CmdSN) > will go to the front of the ``incoming'' queue and be seen immediately. > > *** If k = 0, then the task is still in the ``incoming'' queue > and the Data-Out is sorted right after it -- same effect. > > Furthermore, the target will NOT allow CmdSN wrapping > for an outstanding task (one for which data is being delivered, I->T, > in order to be sent to the device server (SCSI), _only_ after which > CmdSN becomes irrelevant, but this means that all data was > delivered....). > > Do you see it? > > -- > Luben > P.S. CmdSN wrapping MUST not depend on the choice of > maximum data segment. The suggestion I posted preserves > this reservation. > From owner-ips@ece.cmu.edu Fri Jun 7 18:09:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14746 for ; Fri, 7 Jun 2002 18:09:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57LZbn03800 for ips-outgoing; Fri, 7 Jun 2002 17:35:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57LZaw03796 for ; Fri, 7 Jun 2002 17:35:36 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 75D7030706; Fri, 7 Jun 2002 17:35:35 -0400 (EDT) Date: Fri, 7 Jun 2002 14:33:27 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Robert Snively Cc: "'Ken Sandars'" , "Ips Reflector (E-mail)" Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys In-Reply-To: <2F37CED150E21640A9C6E75B8BE6AF830A4CCB@hq-ex-4> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Fri, 7 Jun 2002, Robert Snively wrote: > > Question about the operational components being able to determine this > > info. iSCSI is, in terms from SAM-2, a Service Delivery > > Subsystem (SDS). > > While many implementations act as scsi servers (disks & tapes, etc.), > > that's not part of the spec. > > > > You are clearly correct. By operational components, I > mean those that are performing SCSI operations. The > service delivery system (iSCSI) is already neatly standardized > and has no need to identify vendor and model, since by > being iSCSI it has already specified its interoperability > requirement. That comment reflects a very nice ideal. My concern is that I'm not sure we're there. What about Luben's comments that there are existing interoperability problems among compliant systems? AS I understand him, compliant *iSCSI* systems. ?? Also, I think there is one general problem with the spec, that I have no idea how to fix. When I was first reading the spec, it came across as a document that makes perfect sense once I understand it, but it's rough getting that initial understanding. My technical writing skills aren't up to the task to do anything different, and I expect someone will make some $$ off of an intro book. So I accept it as it is, or make minor suggestions. But the problem (as a number of recent threads have shown :-) is that people who are looking at the spec for the first time don't necessarily come to understand the spec the same way that the longer-term WG members do. The longer-term members see the written spec as a clear reflection of their idea of the spec, so they don't see the problems. They've been to plug-fests, and so they have a lot of commonality in their mental ideas of what the spec is. When a choice comes up, they naturally choose the same way as the other longer-term members, and they don't always see that they've made a choice. Now that's not meant as a criticism of the WG or of Julian. As issues have come up, Julian and the group have worked on clarifying issues. The problem is that a question has to come up before the clarification happens. Once we get past last-call, this process will stop until the next version. So what do we do? Do we really expect we will stop finding problems after last-call? If not, do we work with what we have, or not? Adding vendor/product/revision tags is one way to help implementations deal with what we have until the next version of the spec can fix problems. Take care, Bill From owner-ips@ece.cmu.edu Fri Jun 7 19:13:36 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16484 for ; Fri, 7 Jun 2002 19:13:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57MiBp06812 for ips-outgoing; Fri, 7 Jun 2002 18:44:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57Mi9w06807 for ; Fri, 7 Jun 2002 18:44:10 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 5BE7E30706; Fri, 7 Jun 2002 18:44:09 -0400 (EDT) Date: Fri, 7 Jun 2002 15:41:59 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Robert Snively Cc: "'Dennis Young'" , "'Ken Sandars'" , "Ips Reflector (E-mail)" Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys In-Reply-To: <2F37CED150E21640A9C6E75B8BE6AF830A4CCA@hq-ex-4> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Fri, 7 Jun 2002, Robert Snively wrote: > > Regarding the management component, it is very useful to > > have the vendor product name and revision number available > > as part of the iSCSI login negotiation, this would allow > > the developer/administrator to save the login trace to syslog > > or something similar for immediate or future analysis or > > bug reporting. Without this information embedded in the trace, > > it would be very difficult to go back to the old log and > > know for sure which revision of the product you were dealing > > with. > > Not a function of the login. This is a function of the > MIB at the management level and of the SCSI Inquiry at > the driver level. Unless of course you don't believe in > standard internet and storage management protocols :-) No one is saying take this info out of the MIB, just that we see a value for having the info available in another place as well. We're defining the iSCSI protocol, and if we feel it needs to do something, we certainly can (and IMHO should) add it. And we already have added convenience keys, namely initiator and target alias. > > Accessing iSCSI MIB requires a separate step, path, management > > tool. Some low end products may not provide it at all. > > And most importantly, it won't help you if you have to analyze > > some old traces. > > > > Are there actually devices in an iSCSI environment that will > have no MIB? Yes, there most certainly WILL be devices in an iSCSI environment w/o SNMP support. Any device running a general-purpose OS can't be depended on to have SNMP support. For Linux and the *BSDs, there is no guarantee that the snmp support will be running, nor that it has support for the iSCSI MIB. For Windows, I expect the same will be true (well, we can't depend on the snmp agent running). Given that there are a number of admins who consider SNMP to be a pox and a security liability (doesn't matter if you or I agree or not, they don't like it), depending on SNMP being around seems an un-robust thing to do. > > Think of this scenario, suppose you are building an iSCSI HBA > > and you need to do login interoperability testings with 10 > > different iSCSI targets, wouldn't it be nice that all you have > > to do is to run the tests and save the login traces, knowing that > > the product id and revision is embedded in the trace. > > Nope. I know who they are by their MIB or CIM information. The customer-relations side of me immediately thinks, "that's nice, but will my customers do that?" While getting the vendor and product might not be hard, I have little confidence in them getting the revision. > > I feel that this kind of information should definitely be there, > > if X key is not appropriate, I would suggest to use regular key. > > I feel that this information is already there and creating > a redundant and non-standard mechanism for replicating this > information is a real problem. Why? Well, I get the non-standard part. But what is the problem with duplicating the information? Especially in a manner that those implementations that don't like it can ignore it? Take care, Bill From owner-ips@ece.cmu.edu Fri Jun 7 19:14:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16522 for ; Fri, 7 Jun 2002 19:14:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57MgkB06749 for ips-outgoing; Fri, 7 Jun 2002 18:42:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57Mghw06744 for ; Fri, 7 Jun 2002 18:42:44 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g57MhHu19027; Fri, 7 Jun 2002 18:43:17 -0400 Message-ID: <3D013697.120A6A6F@splentec.com> Date: Fri, 07 Jun 2002 18:41:27 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Mallikarjun C." CC: Julian Satran , Amir Shalit , iSCSI Subject: Re: iSCSI: ordered command delivery at the target References: <3D00F0D6.320F25D9@splentec.com> <00a101c20e6c$c46a68c0$edd52b0f@rose.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Yes, I'm clearly wrong about this. Sorry to waste your time with this. "Mallikarjun C." wrote: > > Amir and Julian are correct. I see a lot of mistaken notions in this note, > and IIRC, this was discussed several times in the past. > > The SCSI Architecture Model defines the data transfer protocol services > that are invoked by the SCSI ULP to drive the data transfers - thus technically > letting an instantiated SCSI task to perform data transfers. CmdSN is relevant > only *before* the task is instantiated. BTW, initiator ULP timeouts are exactly > meant to take care of the "network latency" issues. > > AFAICT, assigning CmdSN to SNACK would lead to a lot more complexity > (issuing SNACKs to recover lost SNACKs and....), and I don't see what the > issue is now. > > Needless to say, I would not recommend either of these. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com From owner-ips@ece.cmu.edu Fri Jun 7 19:26:40 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16699 for ; Fri, 7 Jun 2002 19:26:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57NCsn07998 for ips-outgoing; Fri, 7 Jun 2002 19:12:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from med.corp.rhapsodynetworks.com (64-160-62-201.rhapsodynetworks.com [64.160.62.201] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57NCqw07993 for ; Fri, 7 Jun 2002 19:12:53 -0400 (EDT) Received: by med.corp.rhapsodynetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Jun 2002 16:12:46 -0700 Message-ID: <45BEF1D68145D51186C100B0D0AABE659E0159@med.corp.rhapsodynetworks.com> From: Dennis Young To: "'Bill Studenmund'" Cc: "'Robert Snively'" , "'Ken Sandars'" , "Ips Reflector (E-mail)" Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys Date: Fri, 7 Jun 2002 16:12:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Bill, Well summarized. I prefer 4 also, but if it is too late for adding regular keys, then 3 will do. Regards, -Dennis >-----Original Message----- >From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] >Sent: Friday, June 07, 2002 2:01 PM [snip] >** Summary ** > >Let me see if I can wrap this thread up a little so that we >can get closer >to closure. > >There is a suggestion that we add common-use keys to indicate vendor, >model, and revision. The initial suggestion was for X-foo keys. This >format violates our standard for how X- keys work, so an alternate of >X-someone.short.foo was put forth. Dennis suggests above just >making them >standard (I'm assuming Declarative) keys. > >Some of us (including myself) see diagnostic value in having >these keys in >common use. One tcpdump of a session includes info about what >was talking >to what. > >Some people are concerned that adding these keys will permit or tacitly >encourage us to slide into a mode where we paper over interop problems >rather than fix them. I think implicit in this point of view is that we >don't have major interop problems now. > >Others (including myself) believe that the WG and the iSCSI >vendors will >do the right thing and not lazily slide into that mess. > > >So we have a proposal with 4 options and two motivations: > >Proposal for keys: > >1) Do nothing; don't encourage common-use keys >2) Add X-vendor, X-product, and X-revision to the common >venacular. They > would of course be "vendor specific," just a number of vendors > would use them. >3) Some short-named vendor come forward and add names in its space that > everyone use. Like say X-edu.unh.vendor, X-edu.unh.product... >4) Make them standard keys, like Vendor, Product, Revision. >I'd vote they > are delcarative and per-direction. And if you talk to something > that doesn't understand them, you'll be talking to vendor > "NotUnderstood". :-) > >Motivations > >A) makes it easy to identify vendor/product/rev. All you have to do is >capture a session (tcpdump/ethereal), and you have it. Info is in one >place. > >B) Identify system on other side of connection/session to turn on/off >quirk support. > > >My thoughts: > >I like either option 3) or 4). I'd prefer 4, but I realize >this is late in >the game for the standard, so 3) might be best for now. > >I think Motivation A is a damn good one, and reason enough to add these >key. For Motivation B, as above, I don't think they will get us into >messes we aren't already in, so they are fine. > >Take care, > >Bill > From owner-ips@ece.cmu.edu Fri Jun 7 19:50:08 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17199 for ; Fri, 7 Jun 2002 19:50:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g57NIZ008211 for ips-outgoing; Fri, 7 Jun 2002 19:18:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g57NIXw08207 for ; Fri, 7 Jun 2002 19:18:33 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g57NK4u19202; Fri, 7 Jun 2002 19:20:04 -0400 Message-ID: <3D013F36.3CEB198F@splentec.com> Date: Fri, 07 Jun 2002 19:18:14 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Bill Studenmund CC: Robert Snively , "'Ken Sandars'" , "Ips Reflector (E-mail)" Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bill Studenmund wrote: > > > That comment reflects a very nice ideal. My concern is that I'm not sure > we're there. What about Luben's comments that there are existing > interoperability problems among compliant systems? AS I understand him, > compliant *iSCSI* systems. ?? I haven't checked for those lately, (especially in the login procedure), but any time you see ``MAY'' or ``may'' in the draft and a target and initiator arrive at different outcomes _just_ by taking one or the other route, you have ``compliant-non-interoperability'' (as you coined the term). > My technical writing skills aren't up > to the task to do anything different, and I expect someone will make some > $$ off of an intro book. There are books that talk about iSCSI now. I bet that just one month after iSCSI becomes a standard, you'll see 10 books on iSCSI, 5 for Unix/Linux (2 of them with CDs + implementations) and 5 for Windoze. I can think of at least one Linux Guru who's known to write books like that (for a month's time) and who might be considering this. > But the problem (as a number of recent threads have shown :-) is that > people who are looking at the spec for the first time don't necessarily > come to understand the spec the same way that the longer-term WG members > do. The longer-term members see the written spec as a clear reflection of > their idea of the spec, so they don't see the problems. They've been to > plug-fests, and so they have a lot of commonality in their mental ideas of > what the spec is. When a choice comes up, they naturally choose the same > way as the other longer-term members, and they don't always see that > they've made a choice. This basically is the old conundrum: How does one express one's ideas in the most unambiguous way? We don't know of a better way than formalism (i.e. mathematics). This is the reason I've been asking to be more formal in the draft. And I'm not just whining, as I've made it clear that I can volunteer time. This is why 4.1 and 1. exist in their current form. This is also why I've been trying to get the CRC algorithm in 11.1 become more formal, which would make it more clear and straightforward to implement. And this is why I'd like to see someone draw the decision graphs for the login/text stage/negotiations for the T and I -- then any problems will be evident. And this is why Robert of UNH started the variables' dependency charts. > So what do we do? The rest of us (certainly me) cannot do anything. I can just wait. (I can only correct spelling mistakes and missed periods, and such, like this one ) It would be interesing to see the development of iSCSI and the reaction of the rest of the industry and (closer to my heart) the Linux community once iSCSI becomes a standard. -- Luben From owner-ips@ece.cmu.edu Sat Jun 8 01:18:15 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22862 for ; Sat, 8 Jun 2002 01:18:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g584f0819437 for ips-outgoing; Sat, 8 Jun 2002 00:41:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g584evw19431; Sat, 8 Jun 2002 00:40:57 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g584ejfq005276; Sat, 8 Jun 2002 06:40:45 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g584dil73706; Sat, 8 Jun 2002 06:40:00 +0200 To: "Mallikarjun C." Cc: Eddy@Quicksall.com, ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: response reason X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 8 Jun 2002 07:39:41 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 08/06/2002 07:40:00, Serialize complete at 08/06/2002 07:40:00 Content-Type: multipart/alternative; boundary="=_alternative 0018AD23C2256BD2_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0018AD23C2256BD2_= Content-Type: text/plain; charset="us-ascii" Mallikarjun, The reference was clearly wrong (your note make it sound it was right). I will fix the wording to match SPC with iSCSI. Julo "Mallikarjun C." Sent by: owner-ips@ece.cmu.edu 06/08/2002 12:26 AM Please respond to "Mallikarjun C." To: , Julian Satran/Haifa/IBM@IBMIL cc: Subject: Re: iSCSI: response reason Julian, I was about to send a message to you on this myself. I think it's better to leave the wording in 12-96 as is, and change the "Reason" to "Response reason" in the table in section 9.4.6.2. The problem with the changed wording in 12-97 is that it still does not mention the sense key, and states something that isn't accurate (for ex., there is no 'Sense of "protocol service CRC error" ', the SPC-3 name for it is "CRC error detected"). The more descriptive "reason" terminology is an iSCSI notion we had adopted quite a while ago. I reason I had used "Response reason" as in index into the said table is to avoid repeating the CHECKCONDITION/Key/ ASC/ASCQ information everywhere - but I had overlooked that the table doesn't use "response reason". I'd recommend fixing just that. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Julian Satran" To: Cc: ; "Julian Satran" Sent: Friday, June 07, 2002 7:07 AM Subject: Re: iSCSI: response reason > thanks - it is fixed in 12-97 - Julo > > > > "Eddy Quicksall" > om> cc: > Subject: iSCSI: response reason > 06/06/2002 11:28 > PM > Please respond to > Eddy > > > > > > Section 6.5 Digest Errors uses the phrase "iSCSI response reason" and > refers to section 9.4.3. But there is no such term used in that section. > > There is, however, a term used called "iSCSI service response". But, > section 6.5 is not talking about that. > > I believe section 6.5 is talking about the heading "reason" that appears in > the 1st column of the table in section 9.4.6.2. > > So to clarify things, how about changing the table heading in 9.4.6.2 to > say "iSCSI Condition" and section 6.5 to say "iSCSI Condition (Section > 9.4.6.2 Sense Data)? > > The term "iSCSI Condition" is also compatible with the same term used in > the 2nd paragraph of 9.4.6.2. > > Eddy > > > > --=_alternative 0018AD23C2256BD2_= Content-Type: text/html; charset="us-ascii"
Mallikarjun,

The reference was clearly wrong (your note make it sound it was right). I will fix the wording to match SPC with iSCSI.

Julo


"Mallikarjun C." <cbm@rose.hp.com>
Sent by: owner-ips@ece.cmu.edu

06/08/2002 12:26 AM
Please respond to "Mallikarjun C."

       
        To:        <Eddy@Quicksall.com>, Julian Satran/Haifa/IBM@IBMIL
        cc:        <ips@ece.cmu.edu>
        Subject:        Re: iSCSI: response reason

       


Julian,

I was about to send a message to you on this myself.

I think it's better to leave the wording in 12-96 as is, and
change the "Reason" to "Response reason" in the table in
section 9.4.6.2.

The problem with the changed wording in 12-97 is that
it still does not mention the sense key, and states something
that isn't accurate (for ex., there is no 'Sense of "protocol
service CRC error" ', the SPC-3 name for it is "CRC error
detected").  The more descriptive "reason" terminology is
an iSCSI notion we had adopted quite a while ago.

I reason I had used "Response reason" as in index into the
said table is to avoid repeating the CHECKCONDITION/Key/
ASC/ASCQ information everywhere - but I had overlooked that the
table doesn't use "response reason".  I'd recommend fixing just
that.

Thanks.
--
Mallikarjun

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

----- Original Message -----
From: "Julian Satran" <Julian_Satran@il.ibm.com>
To: <Eddy@Quicksall.com>
Cc: <ips@ece.cmu.edu>; "Julian Satran" <Julian_Satran@il.ibm.com>
Sent: Friday, June 07, 2002 7:07 AM
Subject: Re: iSCSI: response reason


> thanks - it is fixed in 12-97 - Julo
>
>
>
>                       "Eddy Quicksall"
>                       <Eddy@Quicksall.c        To:       Julian Satran/Haifa/IBM@IBMIL
>                       om>                      cc:       <ips@ece.cmu.edu>
>                                                Subject:  iSCSI: response reason
>                       06/06/2002 11:28
>                       PM
>                       Please respond to
>                       Eddy
>
>
>
>
>
> Section 6.5 Digest Errors uses the phrase "iSCSI response reason" and
> refers to section 9.4.3. But there is no such term used in that section.
>
> There is, however, a term used called "iSCSI service response". But,
> section 6.5 is not talking about that.
>
> I believe section 6.5 is talking about the heading "reason" that appears in
> the 1st column of the table in section 9.4.6.2.
>
> So to clarify things, how about changing the table heading in 9.4.6.2 to
> say "iSCSI Condition" and section 6.5 to say "iSCSI Condition (Section
> 9.4.6.2  Sense Data)?
>
> The term "iSCSI Condition" is also compatible with the same term used in
> the 2nd paragraph of 9.4.6.2.
>
> Eddy
>
>
>
>

--=_alternative 0018AD23C2256BD2_=-- From owner-ips@ece.cmu.edu Sat Jun 8 03:39:40 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02838 for ; Sat, 8 Jun 2002 03:39:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5873Fv24122 for ips-outgoing; Sat, 8 Jun 2002 03:03:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5873Ew24118 for ; Sat, 8 Jun 2002 03:03:14 -0400 (EDT) Received: from twestrelay04.boulder.ibm.com (twestrelay04.boulder.ibm.com [9.17.194.55]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g58738g5164312 for ; Sat, 8 Jun 2002 03:03:08 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by twestrelay04.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g587371192990 for ; Sat, 8 Jun 2002 01:03:07 -0600 X-Priority: 1 (High) Importance: Normal Subject: iSCSI: Some proposed vendor-specific (X-) keys To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Sat, 8 Jun 2002 00:01:15 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 06/08/2002 01:03:07 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk This thread is wasting bandwidth on this reflector. Items of non direct impact on the draft, should be taken to another venue. I suggest the SNIA IP Storage Technical Working Group. It was quite a while ago when we decided that the iSCSI Spec did not want to have profiles. If profiles, or any agreement on X-, is an implementation issue which, again, is approprate for SNIA. Please take the issue there. I encourage you all to control your selves and focus on fixing only broken items, we need to reach closure on the spec. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Sat Jun 8 11:07:28 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07841 for ; Sat, 8 Jun 2002 11:07:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g58EWMn18233 for ips-outgoing; Sat, 8 Jun 2002 10:32:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mtv01owa01.mindtree.com ([202.56.254.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g579IDw22896 for ; Fri, 7 Jun 2002 05:18:14 -0400 (EDT) Received: from mtv01ex01.mindtree.com ([172.20.32.4]) by mtv01owa01.mindtree.com with Microsoft SMTPSVC(5.0.2195.4453); Fri, 7 Jun 2002 14:45:49 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Target Session Identifying Handle Date: Fri, 7 Jun 2002 14:45:49 +0530 Message-ID: <8FE7FF0CFEFE3243998E86D27FE33466320318@mtv01ex01.mindtree.com> Thread-Topic: Target Session Identifying Handle Thread-Index: AcIOA+mk+jeV/QnfR42rUSlstyjD/w== From: "Mandava Srikanth ( Trainee )" To: X-OriginalArrivalTime: 07 Jun 2002 09:15:49.0629 (UTC) FILETIME=[EA2CCAD0:01C20E03] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g579IFw22899 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Julian, plz ignore my earlier mail(with subject "Target Session Identifying Handle") . what i meant was that the wording of the paragraph (about TSIH in Section 1 of iSCSI-12.txt (page 25) appears to make contradictory statements regarding the generator of TSIH. I suggest that it may be changed to make it clear that it is the target that generatess the TSIH and sends it to the initiator and that for a new session the TSIH is null. ---Mandava Srikanth From owner-ips@ece.cmu.edu Sat Jun 8 11:07:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07854 for ; Sat, 8 Jun 2002 11:07:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g58EWCx18220 for ips-outgoing; Sat, 8 Jun 2002 10:32:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mtv01owa01.mindtree.com ([202.56.254.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g577Kvw07732 for ; Fri, 7 Jun 2002 03:20:58 -0400 (EDT) Received: from mtv01ex01.mindtree.com ([172.20.32.4]) by mtv01owa01.mindtree.com with Microsoft SMTPSVC(5.0.2195.4453); Fri, 7 Jun 2002 12:48:35 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Target Session Identifying Handle Date: Fri, 7 Jun 2002 12:48:35 +0530 Message-ID: <8FE7FF0CFEFE3243998E86D27FE33466320317@mtv01ex01.mindtree.com> Thread-Topic: Target Session Identifying Handle Thread-Index: AcIN84lcMGLyYpe5S3qzgORZfjD/kw== From: "Mandava Srikanth ( Trainee )" To: X-OriginalArrivalTime: 07 Jun 2002 07:18:35.0620 (UTC) FILETIME=[89943240:01C20DF3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g577L3w07735 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Julian, While reading iSCSI-12.txt i came across a paragraph in Section 1 (Page 25) which says that Target Session Identifying Handle (TSIH) is generated by target during session establishment.But the remaining paragraph gives us an impression that it is generated by the initiator.I assume that the TSIH is generated by the initiator. I think the statement in the paragraph must be changed to "the initiator generates it during session establishment". Mandava Srikanth Mind Tree From owner-ips@ece.cmu.edu Sat Jun 8 11:07:54 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07870 for ; Sat, 8 Jun 2002 11:07:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g58ERWp18028 for ips-outgoing; Sat, 8 Jun 2002 10:27:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from quicksall.com ([63.119.175.45]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g56KSqw08341 for ; Thu, 6 Jun 2002 16:28:52 -0400 (EDT) Received: from EDDYREMOTE [24.61.64.49] by quicksall.com with ESMTP (SMTPD32-6.06) id A54E1470110; Thu, 06 Jun 2002 15:25:50 -0500 Reply-To: From: "Eddy Quicksall" To: Cc: Subject: iSCSI: response reason Date: Thu, 6 Jun 2002 16:28:58 -0400 Message-ID: <002701c20d98$ca27c7f0$6403a8c0@EDDYREMOTE> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C20D77.431627F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C20D77.431627F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Section 6.5 Digest Errors uses the phrase "iSCSI response reason" and refers to section 9.4.3. But there is no such term used in that section. There is, however, a term used called "iSCSI service response". But, section 6.5 is not talking about that. I believe section 6.5 is talking about the heading "reason" that appears in the 1st column of the table in section 9.4.6.2. So to clarify things, how about changing the table heading in 9.4.6.2 to say "iSCSI Condition" and section 6.5 to say "iSCSI Condition (Section 9.4.6.2 Sense Data)? The term "iSCSI Condition" is also compatible with the same term used in the 2nd paragraph of 9.4.6.2. Eddy ------=_NextPart_000_0028_01C20D77.431627F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Section 6.5 Digest=20 Errors uses the phrase "iSCSI response reason" and refers to section = 9.4.3. But=20 there is no such term used in that section.
 
There = is, however, a=20 term used called "iSCSI service response". But, section 6.5 is not = talking about=20 that.
 
I = believe section=20 6.5 is talking about the heading "reason" that appears in the 1st column = of the=20 table in section 9.4.6.2.
 
So to = clarify=20 things, how about changing the table heading in 9.4.6.2 to say "iSCSI = Condition"=20 and section 6.5 to say "iSCSI Condition (Section 9.4.6.2  Sense=20 Data)?
 
The = term "iSCSI=20 Condition" is also compatible with the same term used in the 2nd = paragraph of=20 9.4.6.2.
 
Eddy
------=_NextPart_000_0028_01C20D77.431627F0-- From owner-ips@ece.cmu.edu Sat Jun 8 11:10:58 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08045 for ; Sat, 8 Jun 2002 11:10:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g58EcYt18482 for ips-outgoing; Sat, 8 Jun 2002 10:38:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g57JQvw26349 for ; Fri, 7 Jun 2002 15:26:57 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g57JQpp13165 for ; Fri, 7 Jun 2002 15:26:51 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g57JQpc13156; Fri, 7 Jun 2002 15:26:51 -0400 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with SMTP id g57JQo229443; Fri, 7 Jun 2002 15:26:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15617.2298.647935.378333@pkoning.dev.equallogic.com> Date: Fri, 7 Jun 2002 15:26:50 -0400 From: Paul Koning To: Jim.Williams@emulex.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys References: <3356669BBE90C448AD4645C843E2BF289B8DC3@xbl.ad.emulex.com> X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Jim" == Williams, Jim writes: >> Oh boy, now I'm well and truly frightened. >> >> I read your message as saying that there isn't going to be >> interoperability for several years. So rather than create a >> serious incentive for implementers to fix their defects, we should >> implement a way to have them report which collection of defects >> they implement so we can invoke workaround collection #42. Of >> course, the larger the collection of crocks we work around, the >> larger the number of bugs in implementations that everyone else >> will have to work around. >> >> In the words of a well known American, "Just Say NO". >> >> paul Jim> I am not sure if I agree with the conclusion or not, but I have Jim> some concerns about the reasoning behind it. Jim> 1. If history is a guide regarding standards of this complexity, Jim> then it will likely take some years to resolve all the Jim> interoperability issues. So what is the best thing to do in the Jim> mean time? Is it to make the interoperability issues as painful Jim> as possible as an incentive to fix them quickly? Or is it to Jim> make working around as easy as possible so as to foster Jim> development of a market and create a financial incentive to fix Jim> them at all. Clearly I'm looking for the former. From Ken's comments, it's already true that some implementers are taking much too long to fix interop problems. Anything that lengthens the MTTR is in my opinion a bad thing. I can think of a large number of complex protocols that have adopted this hard nosed attitude. The routing protocols; IPsec/IKE; ATM PNNI... none of these send vendor IDs and none of them allow this sort of stuff. Putting in lots of variable workarounds is a recipe for low quality. You end up with a lot more code, its specifications are very ill defined (because by definition it deals with malfunctioning implementations), and your test matrix just keeps growing and growing... Does that make workaround easier? Maybe, for a few months. Does it foster development of a successful market for the technology? That's not clear at all. Jim> 2. I don't think it's valid to assume that interoperability Jim> problems are necessarily due to defects in the implementation. Jim> In fact, those are probably the easier ones to address. The Jim> harder ones are due to defects in the standard itself. Suppose Jim> vendor A and vendor B don't interoperate, but the standard is Jim> sufficiently ambiguous that both are fully compliant. The next Jim> rev of the standard needs to fix this, but what is vendor C to Jim> do in the mean time? Also if the standard itself has some Jim> defects that need to be worked around by vendors, likely Jim> different vendor's work arounds will not be fully interoperable Jim> for some period of time. I expect you're right to say that some interop problems will be due to standards defects. That makes it all the more important to deal with those directly and promptly, rather than put in as many workarounds as there are implementations of the standard. Jim> Of course, if the standard is perfect, things are a lot easier. Jim> But I am reluctant to assume that as a given. Yes. If the standard is correct, then conformance implies interoperability. Unfortunately, few standards are that good. And, even more unfortunately, modern standards processes explicitly discourage that level of quality in protocol standards. paul From owner-ips@ece.cmu.edu Sat Jun 8 11:10:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08081 for ; Sat, 8 Jun 2002 11:10:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g58EVLu18186 for ips-outgoing; Sat, 8 Jun 2002 10:31:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from stargate-1.corp.iready.com ([65.115.68.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g570PTw20630 for ; Thu, 6 Jun 2002 20:25:30 -0400 (EDT) Received: from MikeS8100Laptop (dhcp1-104.corp.iready.com [192.168.1.104]) by stargate-1.corp.iready.com (8.9.3/8.9.3) with SMTP id RAA03885; Thu, 6 Jun 2002 17:23:19 -0700 Message-ID: <04f001c20db9$d15896f0$6801a8c0@MikeS8100Laptop> From: "Michael J. S. Smith \(iReady\)" To: "Michael J. S. Smith \(iReady\)" , , References: <002c01c2082f$8ef744d0$6801a8c0@MikeS8100Laptop> Subject: Re: iSCSI: A list of all normative sentences Date: Thu, 6 Jun 2002 17:25:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julo: I just got your email that you are preparing to post 12-97. I have a request/suggestion. I am going through the list of MUSTs, SHOULDs, and so forth to check they are normative (that each term is defined, and defined before it is used for example). I use a spreadsheet and the concordance and check each term. When I went through the list, I found one issue that was global. Let me use an example to illustrate this issue. Take, as our example, the second appearance of MUST after all the MUSTs that appear in the change material: [Quote] For this reason the task management command MUST carry the current CmdSN as a marker of their position in the stream of commands. [End quote] Let's follow the terms and their definitions: The use of the term command is explained in section 2.1 (we are only interested in this explanatory section, not the definition of command, for what follows): [Quote] In this document "iSCSI request", "iSCSI command", request, or (unqualified) command have the same meaning. Also, unless otherwise specified, status, response, or numbered response have the same mean- ing. [End quote] and CmdSN is defined in 2.2.2.1: [Quote] Commands in transit from the initiator to the target are numbered by iSCSI; the number is carried by the iSCSI PDU as CmdSN (Command- Sequence-Number). [End quote] However when we get to "the task management command", there is no definition of task management command (search on task management command). By using the equivalence of command and request, the reader could deduce (carrying section 2.1 in memory) that Task Management Command is also equivalent to Task Management Request and therefore guess (but not through logical deduction) that: Task Management Function Request is equivalent to Task Management Command, which is defined in 2.5.1.3 This issue (the equivalence of request, command" and "status, response") occurs so often that it's hard to discriminate issues that are clearly equivalent and gray areas (such as the preceding example). One more example. Consider the MUST after the preceding example: [Quote] An iSCSI target MUST be able to handle at least one immediate task management command and one immediate non-task-management iSCSI request per connection at any time. [End quote] Here, in this sentence, command and iSCSI request are exactly equivalent (by 2.1), but the sentence appears difficult to parse and possibly implying otherwise by focusing the reader's attention on the difference between "task management command" and "non-task-management iSCSI request" rather than, for example, "task management command" and "non-task-management command". Alone these examples are trivial, but collectively they cause a compounded problem for a reader. Is it possible to standardize on the consistent use of request or command (not both), and the consistent use of status or response (not both), perhaps in 12-97? Normally this type of editorial change might happen at the final edit stage, but this issue is holding me up in checking some of the more arcane technical issues also. Aloha Mike Smith CTO, iReady ----- Original Message ----- From: "Michael J. S. Smith (iReady)" To: ; ; Cc: Sent: Thursday, May 30, 2002 4:13 PM Subject: iSCSI: A list of all normative sentences > I wrote a Perl script to extract a list of all sentences from an > RFC/draft that contain the normative words: MUST, SHOULD, and so on. > Such a list seems more useful than the concordances that I have been > sharing so far (it was actually a suggestion John made a while back). > Parsing the text is not as easy as it sounds and I am still improving > things. The current tool works pretty well on the text Internet drafts, > and is still useful on the PDF from Julo's website > (http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-12-95.pdf). > Here (below) is the output for12-95. This information is useful (to me > anyway) in order to focus on the areas where the draft is normative. > I'll try and include some more useful things like section numbers and so > forth, but it seemed like time was of the essence to get the draft > cleaned up going in to last call - so I included what I currently have. > Ignore the HTML markup (we just use that internally). > > Mike Smith > CTO, iReady From owner-ips@ece.cmu.edu Sat Jun 8 11:53:55 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08432 for ; Sat, 8 Jun 2002 11:53:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g58FHaM20015 for ips-outgoing; Sat, 8 Jun 2002 11:17:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g58FHXw20005; Sat, 8 Jun 2002 11:17:33 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g58FHQfq035330; Sat, 8 Jun 2002 17:17:26 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g58FHQe114594; Sat, 8 Jun 2002 17:17:26 +0200 To: Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: response reason X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Sat, 8 Jun 2002 18:12:04 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 08/06/2002 18:17:26, Serialize complete at 08/06/2002 18:17:26 Content-Type: multipart/alternative; boundary="=_alternative 00538097C2256BD2_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00538097C2256BD2_= Content-Type: text/plain; charset="us-ascii" OK - Julo "Eddy Quicksall" Sent by: owner-ips@ece.cmu.edu 06/06/2002 11:28 PM Please respond to Eddy To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: iSCSI: response reason Section 6.5 Digest Errors uses the phrase "iSCSI response reason" and refers to section 9.4.3. But there is no such term used in that section. There is, however, a term used called "iSCSI service response". But, section 6.5 is not talking about that. I believe section 6.5 is talking about the heading "reason" that appears in the 1st column of the table in section 9.4.6.2. So to clarify things, how about changing the table heading in 9.4.6.2 to say "iSCSI Condition" and section 6.5 to say "iSCSI Condition (Section 9.4.6.2 Sense Data)? The term "iSCSI Condition" is also compatible with the same term used in the 2nd paragraph of 9.4.6.2. Eddy --=_alternative 00538097C2256BD2_= Content-Type: text/html; charset="us-ascii"
OK - Julo


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

06/06/2002 11:28 PM
Please respond to Eddy

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        <ips@ece.cmu.edu>
        Subject:        iSCSI: response reason

       


Section 6.5 Digest Errors uses the phrase "iSCSI response reason" and refers to section 9.4.3. But there is no such term used in that section.
 
There is, however, a term used called "iSCSI service response". But, section 6.5 is not talking about that.
 
I believe section 6.5 is talking about the heading "reason" that appears in the 1st column of the table in section 9.4.6.2.
 
So to clarify things, how about changing the table heading in 9.4.6.2 to say "iSCSI Condition" and section 6.5 to say "iSCSI Condition (Section 9.4.6.2  Sense Data)?
 
The term "iSCSI Condition" is also compatible with the same term used in the 2nd paragraph of 9.4.6.2.
 
Eddy

--=_alternative 00538097C2256BD2_=-- From owner-ips@ece.cmu.edu Sat Jun 8 11:55:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08447 for ; Sat, 8 Jun 2002 11:55:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g58FHap20017 for ips-outgoing; Sat, 8 Jun 2002 11:17:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g58FHYw20008; Sat, 8 Jun 2002 11:17:34 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g58FHRfq035332; Sat, 8 Jun 2002 17:17:27 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g58FHRe114596; Sat, 8 Jun 2002 17:17:27 +0200 To: "Mandava Srikanth ( Trainee )" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: Target Session Identifying Handle X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Sat, 8 Jun 2002 18:15:58 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 08/06/2002 18:17:27, Serialize complete at 08/06/2002 18:17:27 Content-Type: multipart/alternative; boundary="=_alternative 0053DC37C2256BD2_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0053DC37C2256BD2_= Content-Type: text/plain; charset="us-ascii" it is generated by the target and used by the target. The initiator just copies it in the header. Julo "Mandava Srikanth ( Trainee )" Sent by: owner-ips@ece.cmu.edu 06/07/2002 10:18 AM Please respond to "Mandava Srikanth ( Trainee )" To: cc: Subject: Target Session Identifying Handle Julian, While reading iSCSI-12.txt i came across a paragraph in Section 1 (Page 25) which says that Target Session Identifying Handle (TSIH) is generated by target during session establishment.But the remaining paragraph gives us an impression that it is generated by the initiator.I assume that the TSIH is generated by the initiator. I think the statement in the paragraph must be changed to "the initiator generates it during session establishment". Mandava Srikanth Mind Tree --=_alternative 0053DC37C2256BD2_= Content-Type: text/html; charset="us-ascii"
it is generated by the target and used by the target. The initiator just copies it in the header.

Julo


"Mandava Srikanth ( Trainee )" <mandava_srikanth@mindtree.com>
Sent by: owner-ips@ece.cmu.edu

06/07/2002 10:18 AM
Please respond to "Mandava Srikanth ( Trainee )"

       
        To:        <ips@ece.cmu.edu>
        cc:        
        Subject:        Target Session Identifying Handle

       


Julian,
While reading iSCSI-12.txt i came across a paragraph in Section 1 (Page 25)
which says that Target Session Identifying Handle (TSIH) is generated by
target during session establishment.But the remaining paragraph gives us an
impression that it is generated by the initiator.I assume that the TSIH is
generated by the initiator.

I think the statement in the paragraph must be changed to "the initiator
generates it during session establishment".

Mandava Srikanth
Mind Tree

--=_alternative 0053DC37C2256BD2_=-- From owner-ips@ece.cmu.edu Sat Jun 8 16:32:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11426 for ; Sat, 8 Jun 2002 16:32:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g58Jsdh28905 for ips-outgoing; Sat, 8 Jun 2002 15:54:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g58Jsbw28899 for ; Sat, 8 Jun 2002 15:54:37 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Sat, 8 Jun 2002 15:54:36 -0400 Message-ID: From: Eddy Quicksall To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Date: Sat, 8 Jun 2002 15:54:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Thanks, As a target, I won't be able to let it change until all of the outstanding commands are finished (running with ErrorRecoveryLevel>=1). This is because I must use the PDU size to compute the offset from a SNACK's BegRun/RunLength. So, I plan to not give the text response for a MaxPDURecvDataLength in FFP until I get back an ExpStatSN == next StatSN. This will cause a delay of unknown time before the PDU size can actually change ... do you see any problem with this? Eddy -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Friday, June 07, 2002 1:13 PM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Eddy, If one uses a message sync and steering that relys on the transport segments carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path MTU changes one would want to change the PDU data length to fit the new path MTU. Pat -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Wednesday, June 05, 2002 12:24 PM To: ips@ece.cmu.edu Subject: iSCSI: changing MaxPDUDataLength Does anybody know a case where it is necessary to support a new PDU data length during full feature phase? Eddy mailto: Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Sat Jun 8 23:06:46 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16081 for ; Sat, 8 Jun 2002 23:06:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g592GiE10775 for ips-outgoing; Sat, 8 Jun 2002 22:16:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g592Ggw10766 for ; Sat, 8 Jun 2002 22:16:42 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g592GSeE030386; Sun, 9 Jun 2002 04:16:28 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g592GSe30820; Sun, 9 Jun 2002 04:16:28 +0200 To: Eddy Quicksall Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu, pat_thaler@agilent.com MIME-Version: 1.0 Subject: RE: iSCSI: changing MaxPDUDataLength X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sun, 9 Jun 2002 05:16:26 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 09/06/2002 05:16:29, Serialize complete at 09/06/2002 05:16:29 Content-Type: multipart/alternative; boundary="=_alternative 000C0BC9C2256BD3_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 000C0BC9C2256BD3_= Content-Type: text/plain; charset="us-ascii" That is not completely accurate. The only problem is when PDU size decreases and then SNACK must be for all data. Target can also keep a mapping of numbers/to offsets (the list should be small and if it gets long ask for ack (A-bit). Julo Eddy Quicksall Sent by: owner-ips@ece.cmu.edu 06/08/2002 10:54 PM Please respond to Eddy Quicksall To: pat_thaler@agilent.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Thanks, As a target, I won't be able to let it change until all of the outstanding commands are finished (running with ErrorRecoveryLevel>=1). This is because I must use the PDU size to compute the offset from a SNACK's BegRun/RunLength. So, I plan to not give the text response for a MaxPDURecvDataLength in FFP until I get back an ExpStatSN == next StatSN. This will cause a delay of unknown time before the PDU size can actually change ... do you see any problem with this? Eddy -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Friday, June 07, 2002 1:13 PM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Eddy, If one uses a message sync and steering that relys on the transport segments carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path MTU changes one would want to change the PDU data length to fit the new path MTU. Pat -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Wednesday, June 05, 2002 12:24 PM To: ips@ece.cmu.edu Subject: iSCSI: changing MaxPDUDataLength Does anybody know a case where it is necessary to support a new PDU data length during full feature phase? Eddy mailto: Eddy_Quicksall@iVivity.com --=_alternative 000C0BC9C2256BD3_= Content-Type: text/html; charset="us-ascii"
That is not completely accurate.
The only problem is when PDU size decreases and then SNACK must be for all data.
Target can also keep a mapping of numbers/to offsets (the list should be small and if it gets long ask for ack (A-bit).

Julo


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

06/08/2002 10:54 PM
Please respond to Eddy Quicksall

       
        To:        pat_thaler@agilent.com
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: changing MaxPDUDataLength

       


Thanks,

As a target, I won't be able to let it change until all of the outstanding
commands are finished (running with ErrorRecoveryLevel>=1). This is because
I must use the PDU size to compute the offset from a SNACK's
BegRun/RunLength.

So, I plan to not give the text response for a MaxPDURecvDataLength in FFP
until I get back an ExpStatSN == next StatSN.

This will cause a delay of unknown time before the PDU size can actually
change ... do you see any problem with this?

Eddy

-----Original Message-----
From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]
Sent: Friday, June 07, 2002 1:13 PM
To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu
Subject: RE: iSCSI: changing MaxPDUDataLength


Eddy,

If one uses a message sync and steering that relys on the transport segments
carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path
MTU changes one would want to change the PDU data length to fit the new path
MTU.

Pat

-----Original Message-----
From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com]
Sent: Wednesday, June 05, 2002 12:24 PM
To: ips@ece.cmu.edu
Subject: iSCSI: changing MaxPDUDataLength


Does anybody know a case where it is necessary to support a new PDU data
length during full feature phase?

Eddy
mailto: Eddy_Quicksall@iVivity.com

--=_alternative 000C0BC9C2256BD3_=-- From owner-ips@ece.cmu.edu Sun Jun 9 14:58:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06395 for ; Sun, 9 Jun 2002 14:58:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g59IGJa22048 for ips-outgoing; Sun, 9 Jun 2002 14:16:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g59IGIw22044 for ; Sun, 9 Jun 2002 14:16:18 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g59IGCp05458 for ; Sun, 9 Jun 2002 14:16:12 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g59IGBc05440; Sun, 9 Jun 2002 14:16:11 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g59IG7h02483; Sun, 9 Jun 2002 14:16:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15619.39785.706000.438864@gargle.gargle.HOWL> Date: Sun, 9 Jun 2002 14:16:09 -0400 From: Paul Koning To: luben@splentec.com Cc: wrstuden@wasabisystems.com, rsnively@Brocade.COM, ksandars@eurologic.com, ips@ece.cmu.edu Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys References: <3D013F36.3CEB198F@splentec.com> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 7 June 2002) by Luben Tuikov: > Bill Studenmund wrote: > > > > > > That comment reflects a very nice ideal. My concern is that I'm not sure > > we're there. What about Luben's comments that there are existing > > interoperability problems among compliant systems? AS I understand him, > > compliant *iSCSI* systems. ?? > > I haven't checked for those lately, (especially in the login procedure), > but any time you see ``MAY'' or ``may'' in the draft and a target > and initiator arrive at different outcomes _just_ by taking one > or the other route, you have ``compliant-non-interoperability'' > (as you coined the term). That is not true at all. "MAY" is fine if either choice results in behavior that is acceptable to the other side. In fact, that's the only place where a standard is allowed to use it. Sometimes, achieving that requires that side A communicates its choice to side B; in other cases it doesn't. A very simple example is the use of MAY in the rules for responding to protocol violations. Since those cases don't occur in the first place in conforming implementations, neither choice can possible result in compliant non-interoperability. If the spec allows a choice -- either with MAY or with MUST -- but the conforming other end will for one of those two choices -- then the spec is broken, pure and simple. paul From owner-ips@ece.cmu.edu Sun Jun 9 14:58:08 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06408 for ; Sun, 9 Jun 2002 14:58:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g59ICFZ21842 for ips-outgoing; Sun, 9 Jun 2002 14:12:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g59ICDw21838 for ; Sun, 9 Jun 2002 14:12:13 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g59IC7p05427 for ; Sun, 9 Jun 2002 14:12:07 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g59IC6c05409; Sun, 9 Jun 2002 14:12:06 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g59IC4g02413; Sun, 9 Jun 2002 14:12:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15619.39542.115000.725317@gargle.gargle.HOWL> Date: Sun, 9 Jun 2002 14:12:06 -0400 From: Paul Koning To: wrstuden@wasabisystems.com Cc: dyoung@rhapsodynetworks.com, rsnively@Brocade.COM, ksandars@eurologic.com, ips@ece.cmu.edu Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys References: <45BEF1D68145D51186C100B0D0AABE659E0154@med.corp.rhapsodynetworks.com> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 7 June 2002) by Bill Studenmund: > ... > What about the case(s) Luben describes, where due to problems in the spec, > two different implementations that both follow the spec don't > interoperate? The case of compliant-non-interoperability? Those are defects in the spec; if those cases are real then the spec must be fixed prior to being released. > I gather that you believe that if we add these keys, we will be opening > the door to an interoperability mess. I believe that is not correct; we > either have a spec that permits compliant-non-interoperability, or we > don't. I do not believe that adding or not adding these keys will change > that. That's not what I said. What I said is that adding these keys will weaken the incentive to fix the interoperability problems, which will harm the success of iSCSI. > Also, what do we do with installed systems? Say we find and correct a > problem. Until our end users upgrade field-deployed systems, the problem > continues. Are the sysadmins of our customers going to be happy if we try > to force them to upgrade production "seems-to-work" systems, just because > we found a bug in the spec? My experience as a sysadmin and with sysadmins > is that they will say rude things to us and ignore us. That's not a good > way to sell iSCSI systems. :-| So what makes iSCSI different from the dozens of protocols that have been created in the past that do not do this? > Some people are concerned that adding these keys will permit or tacitly > encourage us to slide into a mode where we paper over interop problems > rather than fix them. I think implicit in this point of view is that we > don't have major interop problems now. I never said that we do not have major interop problems. Maybe we do, maybe we don't. If we do, how about exposing them explicitly and FIXING THEM? > Others (including myself) believe that the WG and the iSCSI vendors will > do the right thing and not lazily slide into that mess. I have seen protocols that implement this sort of feature, and based on that experience I am not as optimistic as you are. > So we have a proposal with 4 options and two motivations: > > Proposal for keys: > > 1) Do nothing; don't encourage common-use keys > 2) Add X-vendor, X-product, and X-revision to the common venacular. They > would of course be "vendor specific," just a number of vendors > would use them. > 3) Some short-named vendor come forward and add names in its space that > everyone use. Like say X-edu.unh.vendor, X-edu.unh.product... > 4) Make them standard keys, like Vendor, Product, Revision. I'd vote they > are delcarative and per-direction. And if you talk to something > that doesn't understand them, you'll be talking to vendor > "NotUnderstood". :-) I am in favor of 1, and object strongly to 2, 3, and 4. paul From owner-ips@ece.cmu.edu Sun Jun 9 20:18:11 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09122 for ; Sun, 9 Jun 2002 20:18:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g59NtnO04748 for ips-outgoing; Sun, 9 Jun 2002 19:55:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from fep03-mail.bloor.is.net.cable.rogers.com (fep03-mail.bloor.is.net.cable.rogers.com [66.185.86.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g59Ntlw04740 for ; Sun, 9 Jun 2002 19:55:47 -0400 (EDT) Received: from splentec.com ([24.43.247.111]) by fep03-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.04.13 201-253-122-122-113-20020313) with ESMTP id <20020609235541.THRE4340.fep03-mail.bloor.is.net.cable.rogers.com@splentec.com>; Sun, 9 Jun 2002 19:55:41 -0400 Message-ID: <3D03EAFD.8A57F280@splentec.com> Date: Sun, 09 Jun 2002 19:55:41 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Paul Koning CC: Jim.Williams@emulex.com, ips@ece.cmu.edu Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys References: <3356669BBE90C448AD4645C843E2BF289B8DC3@xbl.ad.emulex.com> <15617.2298.647935.378333@pkoning.dev.equallogic.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep03-mail.bloor.is.net.cable.rogers.com from [24.43.247.111] using ID at Sun, 9 Jun 2002 19:55:41 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Paul Koning wrote: > > Yes. If the standard is correct, then conformance implies > interoperability. Unfortunately, few standards are that good. And, > even more unfortunately, modern standards processes explicitly > discourage that level of quality in protocol standards. Oh my! I absolutely didn't know this. Worse than that I thought that the exact opposite would be true. Well then, this nullifies everything I've posted to IPS. Just one thing to mention, though: Writing a ``computer program'' to implement Protocol X explicitly formalizes Protocol X. Should the industry adopt a certain company implementation's behaviour, then Protocol X has been formalized industry-wide, which I thought was the document's function. -- Luben From owner-ips@ece.cmu.edu Sun Jun 9 20:18:35 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09137 for ; Sun, 9 Jun 2002 20:18:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g59NUer03905 for ips-outgoing; Sun, 9 Jun 2002 19:30:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from fep04-mail.bloor.is.net.cable.rogers.com (fep04-mail.bloor.is.net.cable.rogers.com [66.185.86.74]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g59NUbw03900 for ; Sun, 9 Jun 2002 19:30:38 -0400 (EDT) Received: from splentec.com ([24.43.247.111]) by fep04-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.04.13 201-253-122-122-113-20020313) with ESMTP id <20020609233028.QQFP8996.fep04-mail.bloor.is.net.cable.rogers.com@splentec.com>; Sun, 9 Jun 2002 19:30:28 -0400 Message-ID: <3D03E508.563A2CE1@splentec.com> Date: Sun, 09 Jun 2002 19:30:16 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Paul Koning CC: wrstuden@wasabisystems.com, rsnively@Brocade.COM, ksandars@eurologic.com, ips@ece.cmu.edu Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys References: <3D013F36.3CEB198F@splentec.com> <15619.39785.706000.438864@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep04-mail.bloor.is.net.cable.rogers.com from [24.43.247.111] using ID at Sun, 9 Jun 2002 19:30:28 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Paul Koning wrote: > > Excerpt of message (sent 7 June 2002) by Luben Tuikov: > > I haven't checked for those lately, (especially in the login procedure), > > but any time you see ``MAY'' or ``may'' in the draft and a target > > and initiator arrive at different outcomes _just_ by taking one > > or the other route, you have ``compliant-non-interoperability'' > > (as you coined the term). > > That is not true at all. "MAY" is fine if either choice results in > behavior that is acceptable to the other side. In fact, that's the > only place where a standard is allowed to use it. Sometimes, > achieving that requires that side A communicates its choice to side B; > in other cases it doesn't. That is not true at all. Paul, you are NOT reading the whole sentence. Here it is again: Any time you have ``MAY'' or ``may'' in the draft _AND_ a target and initiator arrive at different outcomes just by taking one or the other route, there will be ``compliant'' interoperability problems. Those two messages show exactly what I have in mind: http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10158.html http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09751.html This has since been fixed in the draft. > A very simple example is the use of MAY in the rules for responding to > protocol violations. Since those cases don't occur in the first place > in conforming implementations, neither choice can possible result in > compliant non-interoperability. Using this kind of ``proof'' you can easily prove anything... > If the spec allows a choice -- either with MAY or with MUST -- but the > conforming other end will for one of those two choices -- then the > spec is broken, pure and simple. Paul, only ``MAY'' allows a choice. ``MUST'' doesn't. I'd rather ONLY see ``MUST'' and ``SHOULD'' in a spec. And no, it is not so simple. Finding problems like those involves drawing a decision graph and enumerating the final nodes/states and then comparing if you get the same ``number'' for a target and initiator taking different route on MAY. This is described in the literature. -- Luben From owner-ips@ece.cmu.edu Sun Jun 9 22:15:39 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11354 for ; Sun, 9 Jun 2002 22:15:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5A1UHj08231 for ips-outgoing; Sun, 9 Jun 2002 21:30:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g59JPCw24445 for ; Sun, 9 Jun 2002 15:25:12 -0400 (EDT) Received: from MikesDellLatitude ([64.161.27.215]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GXG00G6KDXZ00@mta6.snfc21.pbi.net> for ips@ece.cmu.edu; Sun, 09 Jun 2002 12:25:11 -0700 (PDT) Date: Sun, 09 Jun 2002 12:23:39 -0700 From: "Michael J. S. Smith (PacBell)" Subject: variable CDB length To: ips@ece.cmu.edu, "Michael J. S. Smith (iReady)" Message-id: <0aa201c20feb$297415c0$6401a8c0@iready.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <3D013F36.3CEB198F@splentec.com> <15619.39785.706000.438864@gargle.gargle.HOWL> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7BIT I'm trying to bound some of the iSCSI structures. This email is regarding the AHS for extended CDBs. The following (page 37 of the PDF, page 7 in the draft page numbering) is from ftp://ftp.t10.org/t10/drafts/spc3/spc3r07.pdf. SPC-3 contains the third-generation definition of the basic commands for all SCSI devices. {Date: 2002/05/03, Rev: 07, Status: Development, Project: 1416-D, File: spc3r07.pdf (2697091 bytes)} (see http://www.t10.org/drafts.htm#CMNDSETS) [quote] Command descriptor block (CDB): The structure used to communicate commands from an application client to a device server. A CDB may have a fixed length of up to 16 bytes or a variable length of between 12 and 260 bytes. [end quote] I can't find another reference within the 442 pages of the 07 draft of SPC-3 to the 260-byte maximum length for a variable-length CDB. 1. Is the 260-byte figure in the definitions section of the 07 draft of SPC-3 correct? 2. Is it intended that the maximum length of ExtendedCDB field in the iSCSI Extended CDB AHS comes from SPC-3? I searched the mail archive and I did find a discussion between Julo and Bob on the AHS format, but can't find a definitive answer to the last question. Aloha Mike Smith CTO, iReady From owner-ips@ece.cmu.edu Mon Jun 10 00:30:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13453 for ; Mon, 10 Jun 2002 00:30:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5A3XHB12511 for ips-outgoing; Sun, 9 Jun 2002 23:33:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5A3XFw12507 for ; Sun, 9 Jun 2002 23:33:15 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel8.hp.com (Postfix) with ESMTP id CC5BEA00162 for ; Sun, 9 Jun 2002 23:33:05 -0400 (EDT) Received: from swathi (pal1nai162118.nsr.hp.com [15.244.162.118]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id UAA13341 for ; Sun, 9 Jun 2002 20:34:53 -0700 (PDT) Message-ID: <001c01c2102f$87efeb30$76a2f40f@rose.hp.com> From: "Mallikarjun C." To: References: Subject: Re: iSCSI: response reason Date: Sun, 9 Jun 2002 20:33:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Mallikarjun, > > The reference was clearly wrong (your note make it sound it was right) On the contrary, the point of my note was that it orginally was incorrect, and so also was 12-97 (your note at the bottom says it's "fixed" in 12-97). > will fix the wording to match SPC with iSCSI Thanks, it has to be consistent with SPC-3 - including the sense key information for all references to sense code information. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Julian Satran" To: "Mallikarjun C." Cc: ; ; Sent: Friday, June 07, 2002 9:39 PM Subject: Re: iSCSI: response reason > Mallikarjun, > > The reference was clearly wrong (your note make it sound it was right). I > will fix the wording to match SPC with iSCSI. > > Julo > > > > > "Mallikarjun C." > Sent by: owner-ips@ece.cmu.edu > 06/08/2002 12:26 AM > Please respond to "Mallikarjun C." > > > To: , Julian Satran/Haifa/IBM@IBMIL > cc: > Subject: Re: iSCSI: response reason > > > > Julian, > > I was about to send a message to you on this myself. > > I think it's better to leave the wording in 12-96 as is, and > change the "Reason" to "Response reason" in the table in > section 9.4.6.2. > > The problem with the changed wording in 12-97 is that > it still does not mention the sense key, and states something > that isn't accurate (for ex., there is no 'Sense of "protocol > service CRC error" ', the SPC-3 name for it is "CRC error > detected"). The more descriptive "reason" terminology is > an iSCSI notion we had adopted quite a while ago. > > I reason I had used "Response reason" as in index into the > said table is to avoid repeating the CHECKCONDITION/Key/ > ASC/ASCQ information everywhere - but I had overlooked that the > table doesn't use "response reason". I'd recommend fixing just > that. > > Thanks. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > ----- Original Message ----- > From: "Julian Satran" > To: > Cc: ; "Julian Satran" > Sent: Friday, June 07, 2002 7:07 AM > Subject: Re: iSCSI: response reason > > > > thanks - it is fixed in 12-97 - Julo > > > > > > > > "Eddy Quicksall" > > Satran/Haifa/IBM@IBMIL > > om> cc: > > Subject: iSCSI: response > reason > > 06/06/2002 11:28 > > PM > > Please respond to > > Eddy > > > > > > > > > > > > Section 6.5 Digest Errors uses the phrase "iSCSI response reason" and > > refers to section 9.4.3. But there is no such term used in that section. > > > > There is, however, a term used called "iSCSI service response". But, > > section 6.5 is not talking about that. > > > > I believe section 6.5 is talking about the heading "reason" that appears > in > > the 1st column of the table in section 9.4.6.2. > > > > So to clarify things, how about changing the table heading in 9.4.6.2 to > > say "iSCSI Condition" and section 6.5 to say "iSCSI Condition (Section > > 9.4.6.2 Sense Data)? > > > > The term "iSCSI Condition" is also compatible with the same term used in > > the 2nd paragraph of 9.4.6.2. > > > > Eddy > > > > > > > > > > > > From owner-ips@ece.cmu.edu Mon Jun 10 10:33:56 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05880 for ; Mon, 10 Jun 2002 10:33:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5ADldv16467 for ips-outgoing; Mon, 10 Jun 2002 09:47:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5ADlaw16461 for ; Mon, 10 Jun 2002 09:47:36 -0400 (EDT) Received: from loddon.br.itc.hp.com (loddon.br.itc.hp.com [15.145.8.166]) by bramg1.net.external.hp.com (Postfix) with SMTP id 6F1DA193 for ; Mon, 10 Jun 2002 15:47:35 +0200 (METDST) Received: from 15.145.8.166 by loddon.br.itc.hp.com (InterScan E-Mail VirusWall NT); Mon, 10 Jun 2002 14:47:35 +0100 (GMT Daylight Time) Received: by loddon.br.itc.hp.com with Internet Mail Service (5.5.2655.55) id ; Mon, 10 Jun 2002 14:47:35 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC104FF1FC6@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: ips@ece.cmu.edu Subject: iSCSI: CHAP-Slight Re-Phrase! Date: Mon, 10 Jun 2002 14:47:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian et al, I may have misinterpreted section "7.2.1 CHAP Considerations" (Third Paragraph) but may I suggest replacing the word "of" with "by" as it makes more sense. Matthew "Moreover, in this case IKE authentication with group pre-shared keys SHOULD NOT be used unless it is not essential to protect group members against off-line dictionary attacks of other members." "Moreover, in this case IKE authentication with group pre-shared keys SHOULD NOT be used unless it is not essential to protect group members against off-line dictionary attacks BY other members." From owner-ips@ece.cmu.edu Mon Jun 10 10:36:26 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06081 for ; Mon, 10 Jun 2002 10:36:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AE1PZ17244 for ips-outgoing; Mon, 10 Jun 2002 10:01:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AE1Nw17239 for ; Mon, 10 Jun 2002 10:01:23 -0400 (EDT) Received: from cceexg11.americas.cpqcorp.net (cceexg11.americas.cpqcorp.net [16.110.250.125]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 05BEFC5D for ; Mon, 10 Jun 2002 09:01:17 -0500 (CDT) Received: from cceexc17.americas.cpqcorp.net ([16.110.250.84]) by cceexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Jun 2002 09:01:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: iSCSI variable CDB length Date: Mon, 10 Jun 2002 09:01:07 -0500 Message-ID: <78AF3C342AEAEF4BA33B35A8A15668C6019E22CD@cceexc17.americas.cpqcorp.net> Thread-Topic: iSCSI variable CDB length Thread-Index: AcIQH0lWMOySNpHGT82GQVWwjRz6UwAZ0omA From: "Elliott, Robert (Server Storage)" To: X-OriginalArrivalTime: 10 Jun 2002 14:01:08.0073 (UTC) FILETIME=[44CD4D90:01C21087] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g5AE1Nw17240 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Michael J. S. Smith (PacBell) [mailto:smithmjs@pacbell.net] > Sent: Sunday, June 09, 2002 2:24 PM > Subject: variable CDB length > > I'm trying to bound some of the iSCSI structures. This email > is regarding the AHS for extended CDBs. > > The following (page 37 of the PDF, page 7 in the draft page > numbering) is from ftp://ftp.t10.org/t10/drafts/spc3/spc3r07.pdf. > [quote] > Command descriptor block (CDB): The structure used to communicate > commands from an application client to a device server. A CDB may > have a fixed length of up to 16 bytes or a variable length of > between 12 and 260 bytes. > [end quote] > > I can't find another reference within the 442 pages of the 07 > draft of SPC-3 to the 260-byte maximum length for a > variable-length CDB. > > 1. Is the 260-byte figure in the definitions section of the > 07 draft of SPC-3 correct? The variable length CDB structure (spc3r07 table 7) has an 8 byte header, with a one byte ADDITIONAL CDB LENGTH field indicating the additional size in bytes. That field must be a multiple of 4, so the maximum value is 252, restricting the maximum CDB length to 260 bytes. > 2. Is it intended that the maximum length of ExtendedCDB > field in the iSCSI Extended CDB AHS comes from SPC-3? The iSCSI AHS carries bytes 16-259 of a variable length CDB. The 2-byte AHSLength field needs to contain a value big enough to hold the CDB. It should be 8 less than the ADDITIONAL CDB LENGTH field in the CDB itself. > ... > Mike Smith > CTO, iReady -- Rob Elliott, elliott@hp.com Industry Standard Server Storage Advanced Technology Hewlett-Packard From owner-ips@ece.cmu.edu Mon Jun 10 10:36:53 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06123 for ; Mon, 10 Jun 2002 10:36:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5ADq3816705 for ips-outgoing; Mon, 10 Jun 2002 09:52:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5ADq1w16699 for ; Mon, 10 Jun 2002 09:52:02 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5ADpr7n018100; Mon, 10 Jun 2002 15:51:54 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5ADprD73312; Mon, 10 Jun 2002 15:51:53 +0200 To: "Robert D. Russell" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: MaxRecvPDULength question X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Mon, 10 Jun 2002 16:51:48 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 10/06/2002 16:51:53, Serialize complete at 10/06/2002 16:51:53 Content-Type: multipart/alternative; boundary="=_alternative 0047568EC2256BD4_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0047568EC2256BD4_= Content-Type: text/plain; charset="us-ascii" Bob, I can do that too - and if we wait for consensus for a name - well that will be forever. So if at least one more person wants the change and nobody is against we will have it as you wish if not then not. Julo "Robert D. Russell" 06/10/2002 10:42 AM Please respond to "Robert D. Russell" To: Julian Satran/Haifa/IBM@IBMIL, cc: Subject: Re: MaxRecvPDULength question Julian: It has been stated several times that at this late stage we should not be requesting changes that are just preferences. Nevertheless, due to apparent misunderstandings of its meaning, the key named MaxRecvPDULength in draft 12 is apparently going to have its name changed in draft 13. Fine. No problem. However, to remove all possibility of future misunderstandings, why don't we give it a name that says precisely what it is: MaxRecvDataSegmentLength That way, the first sentence in the third paragraph of section 9.7.1 would begin: "DataSegmentLength MUST not exceed MaxRecvDataSegmentLength for the direction it is sent ..." which seems to me to be the classic definition of a maximum. The issue of changing the name from MaxRecvPDULength started with an e-mail sent by Luben Tuikov on 21 May (who, by the way, did NOT want to change the name, just its meaning), and was followed by a short flurry of e-mails under the thread "MaxRecvPDULength question". Some of the names suggested on that thread were: MaxRecvDataLength (21 May by Paul Konig) MaxRecvDataSegmentSize (21 May by Pat Thaler) MaxRecvDataSegSize (21 May by Pat Thaler) MaxRecvPDUDataSize (22 May by Pat Thaler) and what got into the draft was this last suggestion by Pat. I don't believe there was a consensus for this choice (probably, as was stated by Pat several times, because most people don't really see the need for a renaming and didn't bother to participate in the thread). Therefore, I would ask you to reconsider the new name and ask for consensus on the new choice. I believe the name MaxRecvDataSegmentLength is so closely linked to the name DataSegmentLength that its meaning should be clear to even a first-time reader, especially given the statement in section 9.7.1 quoted above. Furthermore, there clearly is the concept of DataSegmentLength elsewhere in the standard -- every PDU has a DataSegmentLength field. I could find no concept of PDUDataSize (or even "data size") elsewhere in the current draft. Whether or not this renaming happens (again), I believe there should be the following rewordings to be more precise in order to avoid any ambiguities and/or future misinterpretations. The first sentence in section 9.10.5 should be changed to read: "The DataSegmentLength in a Text Request MUST NOT exceed the iSCSI target's MaxRecvDataSegmentLength (a per connection and per direction negotiated parameter)." and the first sentence in section 9.11.6 should be changed to read: "The DataSegmentLength in a Text Request MUST NOT exceed the iSCSI initiator's MaxRecvDataSegmentLength (a per connection and per direction negotiated parameter)." Finally, two sentences in section 11.13 should be changed to read: "The initiator or target declares the maximum DataSegmentLength in bytes it can receive in an iSCSI PDU." and "The transmitter (initiator or target) is required to send PDUs with a DataSegmentLength not exceeding MaxRecvDataSegmentLength of the receiver." Thank you for your consideration, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 --=_alternative 0047568EC2256BD4_= Content-Type: text/html; charset="us-ascii"
Bob,

 I can do that too - and if we wait for consensus for a name - well that will be forever.
So  if at least one more person wants the change and nobody is against we will have it as you wish if not then not.

Julo


"Robert D. Russell" <rdr@io.iol.unh.edu>

06/10/2002 10:42 AM
Please respond to "Robert D. Russell"

       
        To:        Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>
        cc:        
        Subject:        Re: MaxRecvPDULength question

       



Julian:

It has been stated several times that at this late stage we
should not be requesting changes that are just preferences.

Nevertheless, due to apparent misunderstandings of its meaning,
the key named MaxRecvPDULength in draft 12 is apparently going
to have its name changed in draft 13.

Fine.  No problem.

However, to remove all possibility of future misunderstandings,
why don't we give it a name that says precisely what it is:

MaxRecvDataSegmentLength

That way, the first sentence in the third paragraph of section
9.7.1 would begin:

"DataSegmentLength MUST not exceed MaxRecvDataSegmentLength
for the direction it is sent ..."

which seems to me to be the classic definition of a maximum.

The issue of changing the name from MaxRecvPDULength started with an
e-mail sent by Luben Tuikov on 21 May (who, by the way, did NOT want
to change the name, just its meaning), and was followed by a short
flurry of e-mails under the thread "MaxRecvPDULength question".

Some of the names suggested on that thread were:
 MaxRecvDataLength        (21 May by Paul Konig)
 MaxRecvDataSegmentSize   (21 May by Pat Thaler)
 MaxRecvDataSegSize       (21 May by Pat Thaler)
 MaxRecvPDUDataSize       (22 May by Pat Thaler)

and what got into the draft was this last suggestion by Pat.

I don't believe there was a consensus for this choice (probably, as
was stated by Pat several times, because most people don't really see
the need for a renaming and didn't bother to participate in the thread).
Therefore, I would ask you to reconsider the new name and ask for
consensus on the new choice.

I believe the name MaxRecvDataSegmentLength is so closely linked to the
name DataSegmentLength that its meaning should be clear to even a
first-time reader, especially given the statement in section 9.7.1
quoted above.

Furthermore, there clearly is the concept of DataSegmentLength elsewhere
in the standard -- every PDU has a DataSegmentLength field.
I could find no concept of PDUDataSize (or even "data size") elsewhere in
the current draft.


Whether or not this renaming happens (again), I believe there should be
the following rewordings to be more precise in order to avoid any
ambiguities and/or future misinterpretations.

The first sentence in section 9.10.5 should be changed to read:

"The DataSegmentLength in a Text Request MUST NOT exceed the
iSCSI target's MaxRecvDataSegmentLength (a per connection and per
direction negotiated parameter)."

and the first sentence in section 9.11.6 should be changed to read:

"The DataSegmentLength in a Text Request MUST NOT exceed the
iSCSI initiator's MaxRecvDataSegmentLength (a per connection and per
direction negotiated parameter)."

Finally, two sentences in section 11.13 should be changed to read:

"The initiator or target declares the maximum DataSegmentLength in
bytes it can receive in an iSCSI PDU."

and

"The transmitter (initiator or target) is required to send PDUs with a
DataSegmentLength not exceeding MaxRecvDataSegmentLength of the receiver."
Thank you for your consideration,


Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774

--=_alternative 0047568EC2256BD4_=-- From owner-ips@ece.cmu.edu Mon Jun 10 11:38:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09195 for ; Mon, 10 Jun 2002 11:38:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AEu8F20639 for ips-outgoing; Mon, 10 Jun 2002 10:56:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AEu7w20635 for ; Mon, 10 Jun 2002 10:56:07 -0400 (EDT) Received: from fowey.BR.ITC.HP.COM (fowey.br.itc.hp.com [15.145.8.186]) by bramg1.net.external.hp.com (Postfix) with SMTP id 86A8C116; Mon, 10 Jun 2002 16:56:06 +0200 (METDST) Received: from 15.145.8.186 by fowey.BR.ITC.HP.COM (InterScan E-Mail VirusWall NT); Mon, 10 Jun 2002 15:56:06 +0100 (GMT Daylight Time) Received: by fowey.br.itc.hp.com with Internet Mail Service (5.5.2655.55) id ; Mon, 10 Jun 2002 15:56:06 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC104FF1FC8@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'Sanjay Goyal'" , "'roweber@acm.org'" Cc: "'ips@ece.cmu.edu'" Subject: Recall: iSCSI: SCSI Cmd PDU larger than 48 bytes Date: Mon, 10 Jun 2002 15:55:58 +0100 Expiry-Date: Wed, 12 Jun 2002 15:54:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) would like to recall the message, "iSCSI: SCSI Cmd PDU larger than 48 bytes". From owner-ips@ece.cmu.edu Mon Jun 10 11:41:20 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09351 for ; Mon, 10 Jun 2002 11:41:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AEsF020482 for ips-outgoing; Mon, 10 Jun 2002 10:54:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AEsEw20477 for ; Mon, 10 Jun 2002 10:54:14 -0400 (EDT) Received: from loddon.br.itc.hp.com (loddon.br.itc.hp.com [15.145.8.166]) by bramg1.net.external.hp.com (Postfix) with SMTP id DB50425E; Mon, 10 Jun 2002 16:54:12 +0200 (METDST) Received: from 15.145.8.166 by loddon.br.itc.hp.com (InterScan E-Mail VirusWall NT); Mon, 10 Jun 2002 15:54:12 +0100 (GMT Daylight Time) Received: by loddon.br.itc.hp.com with Internet Mail Service (5.5.2655.55) id ; Mon, 10 Jun 2002 15:54:12 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC104FF1FC7@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'Sanjay Goyal'" , "'roweber@acm.org'" Cc: ips@ece.cmu.edu Subject: RE: iSCSI: SCSI Cmd PDU larger than 48 bytes Date: Mon, 10 Jun 2002 15:54:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2108E.AE11AE70" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2108E.AE11AE70 Content-Type: text/plain; charset="ISO-8859-1" Sanjay Adding Immediate data will cause the iSCSI Cmd PDU to be greater than 48 bytes Matthew Burbridge -----Original Message----- From: Sanjay Goyal [mailto:sanjay_goyal@ivivity.com] Sent: Wednesday, January 30, 2002 2:33 PM To: 'roweber@acm.org' Cc: ips@ece.cmu.edu Subject: iSCSI: SCSI Cmd PDU larger than 48 bytes what is the probability that the SCSI Cmd PDU will be more than 48 bytes? the cases are: 1. Bi-Di command 2. CDB larger than 16 bytes Regards Sanjay G ------_=_NextPart_001_01C2108E.AE11AE70 Content-Type: text/html; charset="ISO-8859-1"
Sanjay
 
Adding Immediate data will cause the iSCSI Cmd PDU to be greater than 48 bytes
 
Matthew Burbridge
-----Original Message-----
From: Sanjay Goyal [mailto:sanjay_goyal@ivivity.com]
Sent: Wednesday, January 30, 2002 2:33 PM
To: 'roweber@acm.org'
Cc: ips@ece.cmu.edu
Subject: iSCSI: SCSI Cmd PDU larger than 48 bytes

what is the probability that the SCSI Cmd PDU will be more than 48 bytes? 

the cases are:

1. Bi-Di command

2. CDB larger than 16 bytes

Regards

Sanjay G

------_=_NextPart_001_01C2108E.AE11AE70-- From owner-ips@ece.cmu.edu Mon Jun 10 12:16:17 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11228 for ; Mon, 10 Jun 2002 12:16:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AFXoE22884 for ips-outgoing; Mon, 10 Jun 2002 11:33:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (io.iol.unh.edu [132.177.123.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5A7hMw21328 for ; Mon, 10 Jun 2002 03:43:22 -0400 (EDT) Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.3/8.12.3) with ESMTP id g5A7gt6U014680; Mon, 10 Jun 2002 03:42:55 -0400 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.3/8.12.3/Submit) with ESMTP id g5A7gsHt014677; Mon, 10 Jun 2002 03:42:55 -0400 Date: Mon, 10 Jun 2002 03:42:54 -0400 (EDT) From: "Robert D. Russell" To: Julian_Satran@il.ibm.com, Subject: Re: MaxRecvPDULength question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian: It has been stated several times that at this late stage we should not be requesting changes that are just preferences. Nevertheless, due to apparent misunderstandings of its meaning, the key named MaxRecvPDULength in draft 12 is apparently going to have its name changed in draft 13. Fine. No problem. However, to remove all possibility of future misunderstandings, why don't we give it a name that says precisely what it is: MaxRecvDataSegmentLength That way, the first sentence in the third paragraph of section 9.7.1 would begin: "DataSegmentLength MUST not exceed MaxRecvDataSegmentLength for the direction it is sent ..." which seems to me to be the classic definition of a maximum. The issue of changing the name from MaxRecvPDULength started with an e-mail sent by Luben Tuikov on 21 May (who, by the way, did NOT want to change the name, just its meaning), and was followed by a short flurry of e-mails under the thread "MaxRecvPDULength question". Some of the names suggested on that thread were: MaxRecvDataLength (21 May by Paul Konig) MaxRecvDataSegmentSize (21 May by Pat Thaler) MaxRecvDataSegSize (21 May by Pat Thaler) MaxRecvPDUDataSize (22 May by Pat Thaler) and what got into the draft was this last suggestion by Pat. I don't believe there was a consensus for this choice (probably, as was stated by Pat several times, because most people don't really see the need for a renaming and didn't bother to participate in the thread). Therefore, I would ask you to reconsider the new name and ask for consensus on the new choice. I believe the name MaxRecvDataSegmentLength is so closely linked to the name DataSegmentLength that its meaning should be clear to even a first-time reader, especially given the statement in section 9.7.1 quoted above. Furthermore, there clearly is the concept of DataSegmentLength elsewhere in the standard -- every PDU has a DataSegmentLength field. I could find no concept of PDUDataSize (or even "data size") elsewhere in the current draft. Whether or not this renaming happens (again), I believe there should be the following rewordings to be more precise in order to avoid any ambiguities and/or future misinterpretations. The first sentence in section 9.10.5 should be changed to read: "The DataSegmentLength in a Text Request MUST NOT exceed the iSCSI target's MaxRecvDataSegmentLength (a per connection and per direction negotiated parameter)." and the first sentence in section 9.11.6 should be changed to read: "The DataSegmentLength in a Text Request MUST NOT exceed the iSCSI initiator's MaxRecvDataSegmentLength (a per connection and per direction negotiated parameter)." Finally, two sentences in section 11.13 should be changed to read: "The initiator or target declares the maximum DataSegmentLength in bytes it can receive in an iSCSI PDU." and "The transmitter (initiator or target) is required to send PDUs with a DataSegmentLength not exceeding MaxRecvDataSegmentLength of the receiver." Thank you for your consideration, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Mon Jun 10 12:16:28 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11270 for ; Mon, 10 Jun 2002 12:16:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AFoqN23849 for ips-outgoing; Mon, 10 Jun 2002 11:50:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AFonw23843; Mon, 10 Jun 2002 11:50:50 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5AFog7n026246; Mon, 10 Jun 2002 17:50:42 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5AFogD66432; Mon, 10 Jun 2002 17:50:43 +0200 To: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: CHAP-Slight Re-Phrase! X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Mon, 10 Jun 2002 18:50:39 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 10/06/2002 18:50:43, Serialize complete at 10/06/2002 18:50:43 Content-Type: multipart/alternative; boundary="=_alternative 00567C77C2256BD4_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00567C77C2256BD4_= Content-Type: text/plain; charset="us-ascii" thanks - julo "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" Sent by: owner-ips@ece.cmu.edu 06/10/2002 04:47 PM Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: ips@ece.cmu.edu cc: Subject: iSCSI: CHAP-Slight Re-Phrase! Julian et al, I may have misinterpreted section "7.2.1 CHAP Considerations" (Third Paragraph) but may I suggest replacing the word "of" with "by" as it makes more sense. Matthew "Moreover, in this case IKE authentication with group pre-shared keys SHOULD NOT be used unless it is not essential to protect group members against off-line dictionary attacks of other members." "Moreover, in this case IKE authentication with group pre-shared keys SHOULD NOT be used unless it is not essential to protect group members against off-line dictionary attacks BY other members." --=_alternative 00567C77C2256BD4_= Content-Type: text/html; charset="us-ascii"
thanks - julo


"BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>
Sent by: owner-ips@ece.cmu.edu

06/10/2002 04:47 PM
Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)"

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI: CHAP-Slight Re-Phrase!

       


Julian et al,

I may have misinterpreted section "7.2.1 CHAP Considerations" (Third
Paragraph) but may I suggest replacing the word "of" with "by" as it makes
more sense.

Matthew

"Moreover, in this case IKE authentication with group pre-shared
keys SHOULD NOT be used unless it is not essential to protect group
members against off-line dictionary attacks of other members."

"Moreover, in this case IKE authentication with group pre-shared
keys SHOULD NOT be used unless it is not essential to protect group
members against off-line dictionary attacks BY other members."

--=_alternative 00567C77C2256BD4_=-- From owner-ips@ece.cmu.edu Mon Jun 10 12:21:44 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11489 for ; Mon, 10 Jun 2002 12:21:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AFolN23839 for ips-outgoing; Mon, 10 Jun 2002 11:50:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from best.eurologic.com ([213.190.135.5]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AFoiw23835 for ; Mon, 10 Jun 2002 11:50:45 -0400 (EDT) Received: from there (wombat [192.168.7.41]) by best.eurologic.com (8.9.3+Sun/8.9.3) with SMTP id QAA11665; Mon, 10 Jun 2002 16:50:28 +0100 (BST) Message-Id: <200206101550.QAA11665@best.eurologic.com> Content-Type: text/plain; charset="iso-8859-1" From: Ken Sandars Organization: Eurologic Systems To: "Julian Satran" , "Robert D. Russell" Subject: Re: MaxRecvPDULength question Date: Mon, 10 Jun 2002 16:49:43 +0000 X-Mailer: KMail [version 1.3.1] Cc: ips@ece.cmu.edu References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi Julo & Bob, I support Bob on this change to the completely unambiguous "MaxRecvDataSegmentLength" Cheers, Ken -- Ken Sandars Eurologic Systems Ltd ksandars@eurologic.com On Monday 10 June 2002 1:51 pm, Julian Satran wrote: > Bob, > > I can do that too - and if we wait for consensus for a name - well that > will be forever. > So if at least one more person wants the change and nobody is against we > will have it as you wish if not then not. > > Julo > > > > > "Robert D. Russell" > 06/10/2002 10:42 AM > Please respond to "Robert D. Russell" > > > To: Julian Satran/Haifa/IBM@IBMIL, > cc: > Subject: Re: MaxRecvPDULength question > > > > > Julian: > > It has been stated several times that at this late stage we > should not be requesting changes that are just preferences. > > Nevertheless, due to apparent misunderstandings of its meaning, > the key named MaxRecvPDULength in draft 12 is apparently going > to have its name changed in draft 13. > > Fine. No problem. > > However, to remove all possibility of future misunderstandings, > why don't we give it a name that says precisely what it is: > > MaxRecvDataSegmentLength > > That way, the first sentence in the third paragraph of section > 9.7.1 would begin: > > "DataSegmentLength MUST not exceed MaxRecvDataSegmentLength > for the direction it is sent ..." > > which seems to me to be the classic definition of a maximum. > > The issue of changing the name from MaxRecvPDULength started with an > e-mail sent by Luben Tuikov on 21 May (who, by the way, did NOT want > to change the name, just its meaning), and was followed by a short > flurry of e-mails under the thread "MaxRecvPDULength question". > > Some of the names suggested on that thread were: > MaxRecvDataLength (21 May by Paul Konig) > MaxRecvDataSegmentSize (21 May by Pat Thaler) > MaxRecvDataSegSize (21 May by Pat Thaler) > MaxRecvPDUDataSize (22 May by Pat Thaler) > > and what got into the draft was this last suggestion by Pat. > > I don't believe there was a consensus for this choice (probably, as > was stated by Pat several times, because most people don't really see > the need for a renaming and didn't bother to participate in the thread). > Therefore, I would ask you to reconsider the new name and ask for > consensus on the new choice. > > I believe the name MaxRecvDataSegmentLength is so closely linked to the > name DataSegmentLength that its meaning should be clear to even a > first-time reader, especially given the statement in section 9.7.1 > quoted above. > > Furthermore, there clearly is the concept of DataSegmentLength elsewhere > in the standard -- every PDU has a DataSegmentLength field. > I could find no concept of PDUDataSize (or even "data size") elsewhere in > the current draft. > > > Whether or not this renaming happens (again), I believe there should be > the following rewordings to be more precise in order to avoid any > ambiguities and/or future misinterpretations. > > The first sentence in section 9.10.5 should be changed to read: > > "The DataSegmentLength in a Text Request MUST NOT exceed the > iSCSI target's MaxRecvDataSegmentLength (a per connection and per > direction negotiated parameter)." > > and the first sentence in section 9.11.6 should be changed to read: > > "The DataSegmentLength in a Text Request MUST NOT exceed the > iSCSI initiator's MaxRecvDataSegmentLength (a per connection and per > direction negotiated parameter)." > > Finally, two sentences in section 11.13 should be changed to read: > > "The initiator or target declares the maximum DataSegmentLength in > bytes it can receive in an iSCSI PDU." > > and > > "The transmitter (initiator or target) is required to send PDUs with a > DataSegmentLength not exceeding MaxRecvDataSegmentLength of the > receiver." > > > Thank you for your consideration, > > > Bob Russell > InterOperability Lab > University of New Hampshire > rdr@iol.unh.edu > 603-862-3774 From owner-ips@ece.cmu.edu Mon Jun 10 12:34:14 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11987 for ; Mon, 10 Jun 2002 12:33:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AG1rk24556 for ips-outgoing; Mon, 10 Jun 2002 12:01:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AG1pw24551 for ; Mon, 10 Jun 2002 12:01:51 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5AG1i7n036766; Mon, 10 Jun 2002 18:01:44 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5AG1hK113902; Mon, 10 Jun 2002 18:01:43 +0200 To: Ken Sandars Cc: ips@ece.cmu.edu, "Robert D. Russell" MIME-Version: 1.0 Subject: Re: MaxRecvPDULength question X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Mon, 10 Jun 2002 19:01:37 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 10/06/2002 19:01:43, Serialize complete at 10/06/2002 19:01:43 Content-Type: multipart/alternative; boundary="=_alternative 0057A013C2256BD4_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0057A013C2256BD4_= Content-Type: text/plain; charset="us-ascii" Bob - you had your other voice! - Julo Ken Sandars 06/10/2002 07:49 PM Please respond to Ken Sandars To: Julian Satran/Haifa/IBM@IBMIL, "Robert D. Russell" cc: ips@ece.cmu.edu Subject: Re: MaxRecvPDULength question Hi Julo & Bob, I support Bob on this change to the completely unambiguous "MaxRecvDataSegmentLength" Cheers, Ken -- Ken Sandars Eurologic Systems Ltd ksandars@eurologic.com On Monday 10 June 2002 1:51 pm, Julian Satran wrote: > Bob, > > I can do that too - and if we wait for consensus for a name - well that > will be forever. > So if at least one more person wants the change and nobody is against we > will have it as you wish if not then not. > > Julo > > > > > "Robert D. Russell" > 06/10/2002 10:42 AM > Please respond to "Robert D. Russell" > > > To: Julian Satran/Haifa/IBM@IBMIL, > cc: > Subject: Re: MaxRecvPDULength question > > > > > Julian: > > It has been stated several times that at this late stage we > should not be requesting changes that are just preferences. > > Nevertheless, due to apparent misunderstandings of its meaning, > the key named MaxRecvPDULength in draft 12 is apparently going > to have its name changed in draft 13. > > Fine. No problem. > > However, to remove all possibility of future misunderstandings, > why don't we give it a name that says precisely what it is: > > MaxRecvDataSegmentLength > > That way, the first sentence in the third paragraph of section > 9.7.1 would begin: > > "DataSegmentLength MUST not exceed MaxRecvDataSegmentLength > for the direction it is sent ..." > > which seems to me to be the classic definition of a maximum. > > The issue of changing the name from MaxRecvPDULength started with an > e-mail sent by Luben Tuikov on 21 May (who, by the way, did NOT want > to change the name, just its meaning), and was followed by a short > flurry of e-mails under the thread "MaxRecvPDULength question". > > Some of the names suggested on that thread were: > MaxRecvDataLength (21 May by Paul Konig) > MaxRecvDataSegmentSize (21 May by Pat Thaler) > MaxRecvDataSegSize (21 May by Pat Thaler) > MaxRecvPDUDataSize (22 May by Pat Thaler) > > and what got into the draft was this last suggestion by Pat. > > I don't believe there was a consensus for this choice (probably, as > was stated by Pat several times, because most people don't really see > the need for a renaming and didn't bother to participate in the thread). > Therefore, I would ask you to reconsider the new name and ask for > consensus on the new choice. > > I believe the name MaxRecvDataSegmentLength is so closely linked to the > name DataSegmentLength that its meaning should be clear to even a > first-time reader, especially given the statement in section 9.7.1 > quoted above. > > Furthermore, there clearly is the concept of DataSegmentLength elsewhere > in the standard -- every PDU has a DataSegmentLength field. > I could find no concept of PDUDataSize (or even "data size") elsewhere in > the current draft. > > > Whether or not this renaming happens (again), I believe there should be > the following rewordings to be more precise in order to avoid any > ambiguities and/or future misinterpretations. > > The first sentence in section 9.10.5 should be changed to read: > > "The DataSegmentLength in a Text Request MUST NOT exceed the > iSCSI target's MaxRecvDataSegmentLength (a per connection and per > direction negotiated parameter)." > > and the first sentence in section 9.11.6 should be changed to read: > > "The DataSegmentLength in a Text Request MUST NOT exceed the > iSCSI initiator's MaxRecvDataSegmentLength (a per connection and per > direction negotiated parameter)." > > Finally, two sentences in section 11.13 should be changed to read: > > "The initiator or target declares the maximum DataSegmentLength in > bytes it can receive in an iSCSI PDU." > > and > > "The transmitter (initiator or target) is required to send PDUs with a > DataSegmentLength not exceeding MaxRecvDataSegmentLength of the > receiver." > > > Thank you for your consideration, > > > Bob Russell > InterOperability Lab > University of New Hampshire > rdr@iol.unh.edu > 603-862-3774 --=_alternative 0057A013C2256BD4_= Content-Type: text/html; charset="us-ascii"
Bob - you had your other voice! - Julo


Ken Sandars <ksandars@eurologic.com>

06/10/2002 07:49 PM
Please respond to Ken Sandars

       
        To:        Julian Satran/Haifa/IBM@IBMIL, "Robert D. Russell" <rdr@io.iol.unh.edu>
        cc:        ips@ece.cmu.edu
        Subject:        Re: MaxRecvPDULength question

       


Hi Julo & Bob,

I support Bob on this change to the completely unambiguous

     "MaxRecvDataSegmentLength"

Cheers,
Ken

--
Ken Sandars
Eurologic Systems Ltd
ksandars@eurologic.com



On Monday 10 June 2002 1:51 pm, Julian Satran wrote:
> Bob,
>
>  I can do that too - and if we wait for consensus for a name - well that
> will be forever.
> So  if at least one more person wants the change and nobody is against we
> will have it as you wish if not then not.
>
> Julo
>
>
>
>
> "Robert D. Russell" <rdr@io.iol.unh.edu>
> 06/10/2002 10:42 AM
> Please respond to "Robert D. Russell"
>
>
>         To:     Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>
>         cc:
>         Subject:        Re: MaxRecvPDULength question
>
>
>
>
> Julian:
>
> It has been stated several times that at this late stage we
> should not be requesting changes that are just preferences.
>
> Nevertheless, due to apparent misunderstandings of its meaning,
> the key named MaxRecvPDULength in draft 12 is apparently going
> to have its name changed in draft 13.
>
> Fine.  No problem.
>
> However, to remove all possibility of future misunderstandings,
> why don't we give it a name that says precisely what it is:
>
> MaxRecvDataSegmentLength
>
> That way, the first sentence in the third paragraph of section
> 9.7.1 would begin:
>
> "DataSegmentLength MUST not exceed MaxRecvDataSegmentLength
>  for the direction it is sent ..."
>
> which seems to me to be the classic definition of a maximum.
>
> The issue of changing the name from MaxRecvPDULength started with an
> e-mail sent by Luben Tuikov on 21 May (who, by the way, did NOT want
> to change the name, just its meaning), and was followed by a short
> flurry of e-mails under the thread "MaxRecvPDULength question".
>
> Some of the names suggested on that thread were:
>   MaxRecvDataLength        (21 May by Paul Konig)
>   MaxRecvDataSegmentSize   (21 May by Pat Thaler)
>   MaxRecvDataSegSize       (21 May by Pat Thaler)
>   MaxRecvPDUDataSize       (22 May by Pat Thaler)
>
> and what got into the draft was this last suggestion by Pat.
>
> I don't believe there was a consensus for this choice (probably, as
> was stated by Pat several times, because most people don't really see
> the need for a renaming and didn't bother to participate in the thread).
> Therefore, I would ask you to reconsider the new name and ask for
> consensus on the new choice.
>
> I believe the name MaxRecvDataSegmentLength is so closely linked to the
> name DataSegmentLength that its meaning should be clear to even a
> first-time reader, especially given the statement in section 9.7.1
> quoted above.
>
> Furthermore, there clearly is the concept of DataSegmentLength elsewhere
> in the standard -- every PDU has a DataSegmentLength field.
> I could find no concept of PDUDataSize (or even "data size") elsewhere in
> the current draft.
>
>
> Whether or not this renaming happens (again), I believe there should be
> the following rewordings to be more precise in order to avoid any
> ambiguities and/or future misinterpretations.
>
> The first sentence in section 9.10.5 should be changed to read:
>
>  "The DataSegmentLength in a Text Request MUST NOT exceed the
>  iSCSI target's MaxRecvDataSegmentLength (a per connection and per
>  direction negotiated parameter)."
>
> and the first sentence in section 9.11.6 should be changed to read:
>
>  "The DataSegmentLength in a Text Request MUST NOT exceed the
>  iSCSI initiator's MaxRecvDataSegmentLength (a per connection and per
>  direction negotiated parameter)."
>
> Finally, two sentences in section 11.13 should be changed to read:
>
>  "The initiator or target declares the maximum DataSegmentLength in
>  bytes it can receive in an iSCSI PDU."
>
> and
>
>  "The transmitter (initiator or target) is required to send PDUs with a
>  DataSegmentLength not exceeding MaxRecvDataSegmentLength of the
> receiver."
>
>
> Thank you for your consideration,
>
>
> Bob Russell
> InterOperability Lab
> University of New Hampshire
> rdr@iol.unh.edu
> 603-862-3774

--=_alternative 0057A013C2256BD4_=-- From owner-ips@ece.cmu.edu Mon Jun 10 13:14:11 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14007 for ; Mon, 10 Jun 2002 13:14:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AGSCt26348 for ips-outgoing; Mon, 10 Jun 2002 12:28:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from astutenetworks.com (2.astutenetworks.com [216.142.74.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AGS7w26336 for ; Mon, 10 Jun 2002 12:28:07 -0400 (EDT) Received: from amirdesktop (dhcp62 [172.21.2.62]) by astutenetworks.com (8.11.6/8.11.2) with SMTP id g5AGRq725613; Mon, 10 Jun 2002 09:27:52 -0700 From: "Amir Shalit" To: "Robert D. Russell" , , Subject: RE: MaxRecvPDULength question Date: Mon, 10 Jun 2002 09:27:50 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sounds good but at the same time it's hard to argue about a name. Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Robert D. Russell Sent: Monday, June 10, 2002 12:43 AM To: Julian_Satran@il.ibm.com; ips@ece.cmu.edu Subject: Re: MaxRecvPDULength question Julian: It has been stated several times that at this late stage we should not be requesting changes that are just preferences. Nevertheless, due to apparent misunderstandings of its meaning, the key named MaxRecvPDULength in draft 12 is apparently going to have its name changed in draft 13. Fine. No problem. However, to remove all possibility of future misunderstandings, why don't we give it a name that says precisely what it is: MaxRecvDataSegmentLength That way, the first sentence in the third paragraph of section 9.7.1 would begin: "DataSegmentLength MUST not exceed MaxRecvDataSegmentLength for the direction it is sent ..." which seems to me to be the classic definition of a maximum. The issue of changing the name from MaxRecvPDULength started with an e-mail sent by Luben Tuikov on 21 May (who, by the way, did NOT want to change the name, just its meaning), and was followed by a short flurry of e-mails under the thread "MaxRecvPDULength question". Some of the names suggested on that thread were: MaxRecvDataLength (21 May by Paul Konig) MaxRecvDataSegmentSize (21 May by Pat Thaler) MaxRecvDataSegSize (21 May by Pat Thaler) MaxRecvPDUDataSize (22 May by Pat Thaler) and what got into the draft was this last suggestion by Pat. I don't believe there was a consensus for this choice (probably, as was stated by Pat several times, because most people don't really see the need for a renaming and didn't bother to participate in the thread). Therefore, I would ask you to reconsider the new name and ask for consensus on the new choice. I believe the name MaxRecvDataSegmentLength is so closely linked to the name DataSegmentLength that its meaning should be clear to even a first-time reader, especially given the statement in section 9.7.1 quoted above. Furthermore, there clearly is the concept of DataSegmentLength elsewhere in the standard -- every PDU has a DataSegmentLength field. I could find no concept of PDUDataSize (or even "data size") elsewhere in the current draft. Whether or not this renaming happens (again), I believe there should be the following rewordings to be more precise in order to avoid any ambiguities and/or future misinterpretations. The first sentence in section 9.10.5 should be changed to read: "The DataSegmentLength in a Text Request MUST NOT exceed the iSCSI target's MaxRecvDataSegmentLength (a per connection and per direction negotiated parameter)." and the first sentence in section 9.11.6 should be changed to read: "The DataSegmentLength in a Text Request MUST NOT exceed the iSCSI initiator's MaxRecvDataSegmentLength (a per connection and per direction negotiated parameter)." Finally, two sentences in section 11.13 should be changed to read: "The initiator or target declares the maximum DataSegmentLength in bytes it can receive in an iSCSI PDU." and "The transmitter (initiator or target) is required to send PDUs with a DataSegmentLength not exceeding MaxRecvDataSegmentLength of the receiver." Thank you for your consideration, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Mon Jun 10 13:14:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14025 for ; Mon, 10 Jun 2002 13:14:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AGkcr27292 for ips-outgoing; Mon, 10 Jun 2002 12:46:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AGkaw27288 for ; Mon, 10 Jun 2002 12:46:36 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 1388F30706; Mon, 10 Jun 2002 12:46:36 -0400 (EDT) Date: Mon, 10 Jun 2002 09:44:28 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Luben Tuikov Cc: Robert Snively , "'Ken Sandars'" , "Ips Reflector (E-mail)" Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys In-Reply-To: <3D013F36.3CEB198F@splentec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Fri, 7 Jun 2002, Luben Tuikov wrote: > Bill Studenmund wrote: > > > > > > That comment reflects a very nice ideal. My concern is that I'm not sure > > we're there. What about Luben's comments that there are existing > > interoperability problems among compliant systems? AS I understand him, > > compliant *iSCSI* systems. ?? > > I haven't checked for those lately, (especially in the login procedure), > but any time you see ``MAY'' or ``may'' in the draft and a target > and initiator arrive at different outcomes _just_ by taking one > or the other route, you have ``compliant-non-interoperability'' > (as you coined the term). I must say that's not what I had in mind when I coined the phrase. I don't think the fact we let folks make different choices at MAY points is bad. That's the point. I thought most of them were of the form, you MAY close the connection, or you MAY do some error cleanup & try to recover. So both sides know something happened. What I'd be worried about are places where different sides both thing things are ok, but get on entirely different pages as to what exactly is going on. *Those* are what I was thinking of when I came up with compliant-non- interoperability. :-) Take care, Bill From owner-ips@ece.cmu.edu Mon Jun 10 13:33:58 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15297 for ; Mon, 10 Jun 2002 13:33:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AHFQ429224 for ips-outgoing; Mon, 10 Jun 2002 13:15:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from emailO.iomega.com (email.iomega.com [147.178.1.2]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g5AELYw18416 for ; Mon, 10 Jun 2002 10:21:34 -0400 (EDT) Received: from ROYNTEX01.iomega.com by emailO.iomega.com via smtpd (for ECE.CMU.EDU [128.2.136.200]) with SMTP; 10 Jun 2002 14:21:33 UT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: RE: iSCSI variable CDB length Date: Mon, 10 Jun 2002 08:21:33 -0600 Message-ID: <0FA2250F5A23D64FBD983956F9B286433D7DA5@royntex01.iomegacorp.com> Thread-Topic: iSCSI variable CDB length Thread-Index: AcIQH0lWMOySNpHGT82GQVWwjRz6UwAZ0omAAADPgNw= From: "Pat LaVarre" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ece.cmu.edu id g5AELYw18420 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit > restricting the maximum CDB length to 260 bytes. Max allowed is 260 = 8 + 252, yes. Max expressible is 263 = 8 + 255. We can only hope nobody visits the land between max allowed and max expressible. > That field must be a multiple of 4 The day's soon coming when people will prefer multiples of 8 ... Pat LaVarre -----Original Message----- From: Elliott, Robert (Server Storage) [mailto:Elliott@hp.com] Sent: Mon 6/10/2002 8:01 AM To: ips@ece.cmu.edu Cc: Subject: RE: iSCSI variable CDB length > -----Original Message----- > From: Michael J. S. Smith (PacBell) [mailto:smithmjs@pacbell.net] > Sent: Sunday, June 09, 2002 2:24 PM > Subject: variable CDB length > > I'm trying to bound some of the iSCSI structures. This email > is regarding the AHS for extended CDBs. > > The following (page 37 of the PDF, page 7 in the draft page > numbering) is from ftp://ftp.t10.org/t10/drafts/spc3/spc3r07.pdf. > [quote] > Command descriptor block (CDB): The structure used to communicate > commands from an application client to a device server. A CDB may > have a fixed length of up to 16 bytes or a variable length of > between 12 and 260 bytes. > [end quote] > > I can't find another reference within the 442 pages of the 07 > draft of SPC-3 to the 260-byte maximum length for a > variable-length CDB. > > 1. Is the 260-byte figure in the definitions section of the > 07 draft of SPC-3 correct? The variable length CDB structure (spc3r07 table 7) has an 8 byte header, with a one byte ADDITIONAL CDB LENGTH field indicating the additional size in bytes. That field must be a multiple of 4, so the maximum value is 252, restricting the maximum CDB length to 260 bytes. > 2. Is it intended that the maximum length of ExtendedCDB > field in the iSCSI Extended CDB AHS comes from SPC-3? The iSCSI AHS carries bytes 16-259 of a variable length CDB. The 2-byte AHSLength field needs to contain a value big enough to hold the CDB. It should be 8 less than the ADDITIONAL CDB LENGTH field in the CDB itself. > ... > Mike Smith > CTO, iReady -- Rob Elliott, elliott@hp.com Industry Standard Server Storage Advanced Technology Hewlett-Packard From owner-ips@ece.cmu.edu Mon Jun 10 13:37:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15529 for ; Mon, 10 Jun 2002 13:37:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AH6Zw28594 for ips-outgoing; Mon, 10 Jun 2002 13:06:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mercury.corp.iready.com ([65.115.68.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AH6Xw28590 for ; Mon, 10 Jun 2002 13:06:33 -0400 (EDT) Received: by mercury.corp.iready.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 10:06:22 -0700 Message-ID: <034670D62D19D31180990090277A37B702437BC0@mercury.corp.iready.com> From: Michael Smith To: Michael Smith , ips@ece.cmu.edu Subject: iSCSI: AHS use Date: Mon, 10 Jun 2002 10:06:16 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C210A1.220E3250" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C210A1.220E3250 Content-Type: text/plain; charset="iso-8859-1" I have some questions on the current AHS descriptions in 12-97. I just tripped over this, so I think maybe others might too. 1. In 12-97, p.130 we have the definition of AHS as Multiple Additional Header Segments (plural); switching between "AHS (singular), AHS (plural), AHS header segments made me look closer: [quote] The BHS is a fixed-length 48-byte header segment. It MAY be followed by Additional Header Segments (AHS), a Header-Digest, a Data Segment, and/or a Data-Digest. [end quote] 2. However, in the PDU format diagram on p. 131 of 12-97 it is not clear that we have the option of zero, one or more Additional Header Segments. After I re-read things a few times, and apologies if I have this wrong, I think that the use of multiple Additional Header Segments is along these lines: (a) Use one and only one Additional Header Segment for an extended CDB (SPC calls this a variable-length CDB). This extended CDB (or variable-length CDB) Additional Header Segment must immediately follow the BHS. (A suggested exact use definition of this type of Additional Header Segment coming up.) (b) Use one and only one Additional Header Segment for an Bidirectional Expected Read-Data Length. This Bidirectional Expected Read-Data Length Additional Header Segment must immediately follow the BHS. (c) Use of more than one Additional Header Segment is left up to the user. How many Additional Header Segments were we expecting to be able to be used? Would this maximum length of Additional Header Segments be limited only by the TotalAHSLength (8-bit field measuring length in four-byte words or ((2**8) - 1) * 4 bytes or roughly 1 kbyte)? Can we follow an extended CDB Additional Header Segment or a Bidirectional Expected Read-Data Length Additional Header Segment by one or more user-defined Additional Header Segment? Did I get this anywhere close to correct? 3. In one of Bob Russell's emails we have the following, which does seem to make the use of multiple Additional Header Segments a little clearer to me: [quote http://www.pdl.cmu.edu/mailinglists/ips/mail/msg03784.html] [view in fixed-width font on wide window] +------------------------+ | required BHS | > fixed length of 48 bytes +------------------------+ | optional AHS 1 |\ | - - - - - - - - - - - | \ | optional AHS 2 | \ | - - - - - - - - - - - | > total length in AHS_length field in BHS | . . . . | / | - - - - - - - - - - - | / | optional AHS n |/ +------------------------+ | optional header digest | -- covers preceding (48 + AHS_length) bytes +------------------------+ | |\ | optional data | > total length in DATA_length field in BHS | |/ +------------------------+ | optional data digest | -- covers preceding (DATA_length) bytes +------------------------+ [end view in fixed-width font on wide window] [end quote http://www.pdl.cmu.edu/mailinglists/ips/mail/msg03784.html] Is it possible to add something like this picture to the format diagram on p.131. I wouldn't ask if I hadn't tripped myself up on this already. 4. On p. 139 of 12-97 we have the following: [quote] 9.3.5 CDB - SCSI Command Descriptor Block There are 16 bytes in the CDB field to accommodate the commonly used CDBs. Whenever the CDB is larger than 16 bytes, an Extended CDB AHS MUST be used to contain the CDB spillover. [end quote] I tripped again on the term "spillover". Could we perhaps change 9.3.5 to the following (thanks to Rob Elliott, see http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10620.html): There are 16 bytes in the CDB field to accommodate bytes 0-15 of the commonly used CDBs. An Extended CDB AHS MUST be used to contain bytes 16-259 of a variable-length CDB [SPC]. 5. There is no description of ExtendedCDB...+ in 9.2.2.3 Extended CDB AHS I guess we would be repeating 9.3.5 if we defined ExtendedCDB as "bytes 16-259 of a variable-length CDB", but perhaps that is not a bad thing? Aloha Mike Smith CTO, iReady ------_=_NextPart_001_01C210A1.220E3250 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable iSCSI: AHS use

I have some questions on the current AHS descriptions = in 12-97. I just tripped over this, so I think maybe others might = too.

 
1. In 12-97, p.130 we have the definition of AHS as = Multiple Additional Header Segments (plural); switching between = "AHS (singular), AHS (plural), AHS header segments made me look = closer:

 
[quote]
The BHS is a fixed-length 48-byte header segment. It = MAY be followed by Additional Header Segments (AHS), a Header-Digest, a = Data Segment, and/or a Data-Digest.

[end quote]

2. However, in the PDU format diagram on p. 131 of = 12-97 it is not clear that we have the option of zero, one or more = Additional Header Segments. After I re-read things a few times, and = apologies if I have this wrong, I think that the use of multiple = Additional Header Segments is along these lines:

(a) Use one and only one Additional Header Segment = for an extended CDB (SPC calls this a variable-length CDB). This = extended CDB (or variable-length CDB) Additional Header Segment must = immediately follow the BHS. (A suggested exact use definition of this = type of Additional Header Segment coming up.)

(b) Use one and only one Additional Header Segment = for an Bidirectional Expected Read-Data Length. This Bidirectional = Expected Read-Data Length Additional Header Segment must immediately = follow the BHS.

(c) Use of more than one Additional Header Segment is = left up to the user.

How many Additional Header Segments were we expecting = to be able to be used? Would this maximum length of Additional Header = Segments be limited only by the TotalAHSLength (8-bit field measuring = length in four-byte words or ((2**8) - 1) * 4 bytes or roughly 1 = kbyte)? Can we follow an extended CDB Additional Header Segment or a = Bidirectional Expected Read-Data Length Additional Header Segment by = one or more user-defined Additional Header Segment?

Did I get this anywhere close to correct?

3. In one of Bob Russell's emails we have the = following, which does seem to make the use of multiple Additional = Header Segments a little clearer to me:

 
[quote http://www.pdl.cmu.edu/mailinglists/ips/mail/msg03784.= html]
 
[view in fixed-width font on wide window]
     = +------------------------+
     |     = required BHS       | > fixed length of = 48 bytes
     = +------------------------+
     |     = optional AHS 1     |\
     | - - - - - - - - - - = -  | \
     |     = optional AHS 2     |  \
     | - - - - - - - - - - = -  |   > total length in AHS_length field in = BHS
     = |        . . . = .         |  /
     | - - - - - - - - - - = -  | /
     |     = optional AHS n     |/
     = +------------------------+
     | optional header digest | = -- covers preceding (48 + AHS_length) bytes
     = +------------------------+
     = |            = ;            = |\
     |     = optional data      | > total length in = DATA_length field in BHS
     = |            = ;            = |/
     = +------------------------+
     |  optional data = digest  | -- covers preceding (DATA_length) bytes
     = +------------------------+

[end view in fixed-width font on wide window]
 
[end quote http://www.pdl.cmu.edu/mailinglists/ips/mail/msg03784.= html]

Is it possible to add something like this picture to = the format diagram on p.131. I wouldn't ask if I hadn't tripped myself = up on this already.

 
4. On p. 139 of 12-97 we have the following:
 
[quote]
 
9.3.5 CDB - SCSI Command Descriptor Block
There are 16 bytes in the CDB field to accommodate = the commonly used CDBs. Whenever the CDB is larger than 16 bytes, an = Extended CDB AHS MUST be used to contain the CDB spillover.

 
[end quote]

I tripped again on the term "spillover". = Could we perhaps change 9.3.5 to the following (thanks to Rob Elliott, = see = http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10620.html):

There are 16 bytes in the CDB field to accommodate = bytes 0-15 of the commonly used CDBs. An Extended CDB AHS MUST be used = to contain bytes 16-259 of a variable-length CDB [SPC].

5. There is no description of ExtendedCDB...+ in = 9.2.2.3 Extended CDB AHS

I guess we would be repeating 9.3.5 if we defined = ExtendedCDB as "bytes 16-259 of a variable-length CDB", but = perhaps that is not a bad thing?

Aloha
 
Mike Smith
CTO, iReady

------_=_NextPart_001_01C210A1.220E3250-- From owner-ips@ece.cmu.edu Mon Jun 10 14:12:11 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17119 for ; Mon, 10 Jun 2002 14:11:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AHTjM00150 for ips-outgoing; Mon, 10 Jun 2002 13:29:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AHThw00146 for ; Mon, 10 Jun 2002 13:29:44 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 0516FA30C; Mon, 10 Jun 2002 11:29:43 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id A70841BB; Mon, 10 Jun 2002 11:29:42 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 10 Jun 2002 11:29:42 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 11:29:42 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E3DC4@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: michael_schoberg@cnt.com, cbm@rose.hp.com, ips@ece.cmu.edu Subject: RE: iSCSI: MaxRecvPDULength simplification Date: Mon, 10 Jun 2002 11:29:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Michael, That is true where the limit on PDU length is due to TUF and network packet size limits. However, when the connection is migrating the limitation may be in the new receiver and that may not be flexible. Pat -----Original Message----- From: Michael Schoberg [mailto:michael_schoberg@cnt.com] Sent: Thursday, March 28, 2002 8:48 AM To: 'Mallikarjun C.'; IPS Reflector (E-mail) Subject: RE: iSCSI: MaxRecvPDULength simplification Thank you for the draft reference. It's good that the iSCSI group is looking at these other drafts. Unfortunately, I haven't been following the TUFs draft so my opinion may be way off. From my brief read, it seems iSCSI may be able to afford a little elasticity with MaxRecvPDULength than what's being proposed. The PMTU reduction scenario is referenced within TUFs as rare and recoverable. In your opinion, could an iSCSI client afford to ignore resegmentation on previously sent PDUs (SNACK) or for recovered PDUs (task reassignment) and simply apply the new MaxRecvPDULength negotiated value on future PDUs? This would turn the resegmentation feature into a MAY from a MUST. Thanks. :-----Original Message----- :From: Mallikarjun C. [mailto:cbm@rose.hp.com] :Sent: Wednesday, March 27, 2002 9:27 PM :To: IPS Reflector (E-mail) :Subject: Re: iSCSI: MaxRecvPDULength simplification : : :One of the design goals of task reassign is to be able to reassign the :connection allegiance of a task to a different connection :that's perhaps :using an entire different network for a true failover :capability - for ex., :the original allegiant connection could be traversing a :corprorate intranet, :and the reassigned connection could be using the public :internet. That's :the reason for not placing the equivalence requirement on the two :connections. : :MaxRecvPDULength was made negotiable during the FFP because :several of us felt that it's very useful for iSCSI to allow :implementations :with the `ULPDU containment' property :(http://search.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-ul :p-frame-01.txt). :This automatically means that MaxRecvPDULength should be changeable :with changes in PMTU changes, particularly with dynamic PMTU :degradation. : :Let's look at the possibility you suggest - there being two :valid MaxRecvPDULength :values at the same time. If a change in FFP is being :attempted for this key, it must :be due to PMTU changes, and the implicit expectation is that :initiator will sense :it and initiate the negotiation process (thus enabling the :target to declare its changed :MaxRecvPDULength, if any, as well in the text response). :There is no ambiguity for :the initiator since the text negotiation can not be assumed :successful (meaning new :MaxRecvPDULength can't be used) until the text response (with :F-bit) is received. :As far as the target is concerned, it can not assume the text :negotiation to be effective :(meaing new MaxRecvPDULength can't be used) until the StatSN :for the text response :is ack'ed - perhaps we should make this clear in the text (and :allow explicit soliciting :for StatSN acknowledgement using a NOP-ping). :-- :Mallikarjun : :Mallikarjun Chadalapaka :Networked Storage Architecture :Network Storage Solutions Organization :Hewlett-Packard MS 5668 :Roseville CA 95747 :cbm@rose.hp.com : :----- Original Message ----- :From: "Michael Schoberg" :To: "IPS Reflector (E-mail)" :Sent: Wednesday, March 27, 2002 8:36 AM :Subject: RE: iSCSI: MaxRecvPDULength simplification : : :> SNACK with RL=0 is only one requirement. Another is task allegiance :> reassignment (6.1.2) which does not use SNACK (correct?) :Here the initiator :> sends a Task-Management request with a Task-Reassign message :to the target. :> The target must reorganize it's T->I messages to match the :MaxRecvPDULength :> of the new connection. Plus, the Task Reassign message includes the :> ExpDataSN field which, if I'm reading right, on reassignment :the target must :> remember the sequencing of the old connection in order to track the :> ExpDataSN field then re-sequence for the new connection :(9.5.4). So now :> target implementations will have to keep track of sequence :indexes for :> Data-In PDUs for conversion over to the new allegiance. :> :> On-the-fly modification of MaxRecvPDULength also means that :some compliance :> standard must be set for in-flight messages. An outstanding :read request :> may have T->I PDUs that comply with multiple :MaxRecvPDULength values. In a :> sense, there will be times where multiple MaxRecvPDULength :values are valid. :> At what point MUST the target comply with the new value? :> :> So I guess I'm not convinced that the benefit of simplification is :> illusionary. Is there a discussion thread that expressly states :> MaxRecvPDULength must have the flexibility allowed for in :the draft? The :> discussions I've seen mainly centered around whether it :should be duplex :> valued (I->T, T->I). :> :> Thanks. :> :> -----Original Message----- :> From: Julian Satran [mailto:Julian_Satran@il.ibm.com] :> Sent: Wednesday, March 27, 2002 1:40 AM :> To: Michael Schoberg :> Cc: IPS Reflector (E-mail); owner-ips@ece.cmu.edu :> Subject: Re: iSCSI: MaxRecvPDULength simplification :> :> :> :> The simplification you are talking about is illusory. Currently this :> requires SNACK to require all data(RL = 0). :> The restriction you propose instead is far more severe (and :unwarranted). :> :> Julo :> :> :> :> Michael Schoberg :> Sent by: owner-ips@ece.cmu.edu :> :> :> 27-03-02 01:19 :> Please respond to Michael Schoberg :> :> :> :> To: "IPS Reflector (E-mail)" :> cc: :> Subject: iSCSI: MaxRecvPDULength simplification :> :> :> :> :> I've looked over some of the reflector messages regarding :MaxRecvPDULength :> negotiation (back to Oct 2001). I can't find the discussion :of why this :> value must be available for negotiation outside of login. It really :> complicates SNACK and Task Reassignment if the initiator can :change this :> value on-the-fly. Would it be too restrictive to propose :the following :> rules? :> :> 1) MaxRecvPDULength is negotiated only at login before FFP. :> :> 2) For message-level recovery, a connection must be prepared :to accept the :> MaxRecvPDULength of the connection it's providing fail over :capability for. :> It doesn't seem unreasonable to expect fault tolerant :configurations to :> comply with this. It would simply be stating that :RecoveryLevel 2 devices :> should be somewhat matched in this capability. :> :> :> :> -----Original Message----- :> From: Julian Satran [mailto:Julian_Satran@il.ibm.com] :> Sent: Tuesday, March 26, 2002 1:50 AM :> To: Michael Schoberg :> Cc: IPS Reflector (E-mail); owner-ips@ece.cmu.edu :> Subject: Re: iSCSI: SNACK RunLength :> :> :> Michael, :> :> The paragraph says that if you issue a SNACK after the :MaxPDURecvLength has :> decreased you should use RunLength 0 (meaning all) instead :of a specific :> runlength which might not be accurate anymore. :> :> Julo :> :> :> Michael Schoberg :> Sent by: owner-ips@ece.cmu.edu :> :> :> 25-03-02 19:43 :> Please respond to Michael Schoberg :> :> :> To: "IPS Reflector (E-mail)" :> cc: :> Subject: iSCSI: SNACK RunLength :> :> :> :> :> :> Am I just not reading this or can this paragraph use some :help? Can someone :> give an interpretation? :> :> 9.16.3 RunLength :> ... :> :> The first data SNACK, issued after initiator's :MaxRecvPDULength :> decreased, for a command issued on the same :connection before the :> :> change in MaxRecvPDULength, MUST use RunLength "0" :to request :> retransmission of any number of PDUs (including :one). The number :> of :> retransmitted PDUs in this case, may or may not be :the same as :> the :> original transmission, depending on whether loss :was before or :> after :> the MaxRecvPDULength was changed at the target. :> :> :> Does this refer to something like: :> :> For connections with unacknowledged PDUs that undergo :MaxRecvPDULength :> negotiation ... :> :> :> :> :> :> :> : From owner-ips@ece.cmu.edu Mon Jun 10 15:12:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20134 for ; Mon, 10 Jun 2002 15:12:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AIOTv03294 for ips-outgoing; Mon, 10 Jun 2002 14:24:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AIORw03289 for ; Mon, 10 Jun 2002 14:24:27 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g5AIQ1u09047; Mon, 10 Jun 2002 14:26:01 -0400 Message-ID: <3D04EED2.5043DCBF@splentec.com> Date: Mon, 10 Jun 2002 14:24:18 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Bill Studenmund CC: Robert Snively , "'Ken Sandars'" , "Ips Reflector (E-mail)" Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bill Studenmund wrote: > > On Fri, 7 Jun 2002, Luben Tuikov wrote: > > > Bill Studenmund wrote: > > > > > > > > > That comment reflects a very nice ideal. My concern is that I'm not sure > > > we're there. What about Luben's comments that there are existing > > > interoperability problems among compliant systems? AS I understand him, > > > compliant *iSCSI* systems. ?? > > > > I haven't checked for those lately, (especially in the login procedure), > > but any time you see ``MAY'' or ``may'' in the draft and a target > > and initiator arrive at different outcomes _just_ by taking one > > or the other route, you have ``compliant-non-interoperability'' > > (as you coined the term). > > I must say that's not what I had in mind when I coined the phrase. I don't > think the fact we let folks make different choices at MAY points is bad. > That's the point. You (as Paul) didn't read this sentence (quoted here from above): Any time you see ``MAY'' or ``may'' in the draft and a target and initiator arrive at different outcomes _just_ by taking one or the other route, you have ``compliant-non-interoperability''. Which is what you are describing in more ``baby-terms'' below. Read my reply to Paul, where I give 2 links to emails where this is described well -- this has since been fixed in the draft. BTW, I don't like ``MAY'' and ``may'' -- I don't use those two words personally and I sure don't like them in the spec as well. > I thought most of them were of the form, you MAY close the connection, or > you MAY do some error cleanup & try to recover. So both sides know > something happened. > > What I'd be worried about are places where different sides both thing > things are ok, but get on entirely different pages as to what exactly is > going on. > > *Those* are what I was thinking of when I came up with compliant-non- > interoperability. :-) But you are merely repeating what I'm saying above... (and in my previous email). -- Luben From owner-ips@ece.cmu.edu Mon Jun 10 15:14:17 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20259 for ; Mon, 10 Jun 2002 15:14:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AIrG805023 for ips-outgoing; Mon, 10 Jun 2002 14:53:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AIrEw05019 for ; Mon, 10 Jun 2002 14:53:14 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 24FFE30706; Mon, 10 Jun 2002 14:53:14 -0400 (EDT) Date: Mon, 10 Jun 2002 11:51:05 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Luben Tuikov Cc: Robert Snively , "'Ken Sandars'" , "Ips Reflector (E-mail)" Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys In-Reply-To: <3D04EED2.5043DCBF@splentec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Mon, 10 Jun 2002, Luben Tuikov wrote: > Bill Studenmund wrote: > > > > I must say that's not what I had in mind when I coined the phrase. I don't > > think the fact we let folks make different choices at MAY points is bad. > > That's the point. > > You (as Paul) didn't read this sentence (quoted here from above): Yes, I did. > Any time you see ``MAY'' or ``may'' in the draft and a target > and initiator arrive at different outcomes _just_ by taking one > or the other route, you have ``compliant-non-interoperability''. > > Which is what you are describing in more ``baby-terms'' below. No, that's not the same thing. You are saying EVERY may/MAY is a problem. I disagree with that. I'll agree that SOME may be a problem, and that we want to find them. The difference is that the ones I recall describe one side as being able to make a choice. If that choice is clearly communicated to the other side, then we are fine. I think we communicate that all of the time, but would appreciate finding out if we don't. > Read my reply to Paul, where I give 2 links to emails > where this is described well -- this has since been fixed > in the draft. Cool! > > *Those* are what I was thinking of when I came up with compliant-non- > > interoperability. :-) > > But you are merely repeating what I'm saying above... (and in my previous > email). No, the difference is I don't think that a MAY automatically lands us in trouble. I agree that most trouble cases start with a MAY, but I don't think the presence of a MAY automatically leads us to trouble. Take care, Bill From owner-ips@ece.cmu.edu Mon Jun 10 15:44:17 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21923 for ; Mon, 10 Jun 2002 15:44:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AJ7wd05951 for ips-outgoing; Mon, 10 Jun 2002 15:07:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AJ7uw05946 for ; Mon, 10 Jun 2002 15:07:56 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 1B06A30706; Mon, 10 Jun 2002 15:07:56 -0400 (EDT) Date: Mon, 10 Jun 2002 12:05:48 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Ken Sandars Cc: Julian Satran , "Robert D. Russell" , Subject: Re: MaxRecvPDULength question In-Reply-To: <200206101550.QAA11665@best.eurologic.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Mon, 10 Jun 2002, Ken Sandars wrote: > Hi Julo & Bob, > > I support Bob on this change to the completely unambiguous > > "MaxRecvDataSegmentLength" I'll add another vote for it. :-) Take care, Bill From owner-ips@ece.cmu.edu Mon Jun 10 15:52:14 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22218 for ; Mon, 10 Jun 2002 15:52:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AJP9406907 for ips-outgoing; Mon, 10 Jun 2002 15:25:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from esply02.cnt.com (mailhost.cnt.com [139.93.128.21]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AI9Ew02310 for ; Mon, 10 Jun 2002 14:09:15 -0400 (EDT) Received: by esply02.cnt.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 13:09:09 -0500 Message-ID: <3C7122FAF06DD5118ED600500473364826325F@esply01.cnt.com> From: Michael Schoberg To: "'pat_thaler@agilent.com'" , "IPS Reflector (E-mail)" Subject: RE: iSCSI: MaxRecvPDULength simplification Date: Mon, 10 Jun 2002 13:09:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk By "connection is migrating", are you talking about iSCSI connection recovery or is this something else? If it's an iSCSI connection in recovery, I think your scenario is unlikely (or I hope it's unlikely). I guess I'd argue that in those circumstances, the new receiver could choose a different method for recovery. TUFs appears to have more to do with the TCP layer and segment loss than iSCSI. Adjusting the MaxRecvPDULength dynamically seems like just another costly draft feature. My guess on the original intent of this feature was to ensure the RDMA blocks were posted in-sync with the (ever changing) TCP MSS. If so, this should be handled between the IP and TCP layer where iSCSI would be oblivious to it. If MaxRecvPDULength is for dynamically changing the receive characteristics of the iSCSI initiator/target, it seems like existing mechanisms could be used without requiring this feature. So far, I haven't seen a posted scenario where this feature really makes sense and in my (humble) opinion, these unlikely events could be handled simply by doing a logout & relogin. However, it does appear there's a strong consensus for this as a spec necessity, so I haven't kept the thread active. :-----Original Message----- :From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] :Sent: Monday, June 10, 2002 12:30 PM :To: Michael Schoberg; cbm@rose.hp.com; ips@ece.cmu.edu :Subject: RE: iSCSI: MaxRecvPDULength simplification : : :Michael, : :That is true where the limit on PDU length is due to TUF and :network packet size limits. However, when the connection is :migrating the limitation may be in the new receiver and that :may not be flexible. : :Pat : :-----Original Message----- :From: Michael Schoberg [mailto:michael_schoberg@cnt.com] :Sent: Thursday, March 28, 2002 8:48 AM :To: 'Mallikarjun C.'; IPS Reflector (E-mail) :Subject: RE: iSCSI: MaxRecvPDULength simplification : : :Thank you for the draft reference. It's good that the iSCSI group is :looking at these other drafts. Unfortunately, I haven't been :following the :TUFs draft so my opinion may be way off. From my brief read, :it seems iSCSI :may be able to afford a little elasticity with :MaxRecvPDULength than what's :being proposed. The PMTU reduction scenario is referenced :within TUFs as :rare and recoverable. In your opinion, could an iSCSI client afford to :ignore resegmentation on previously sent PDUs (SNACK) or for :recovered PDUs :(task reassignment) and simply apply the new MaxRecvPDULength :negotiated :value on future PDUs? This would turn the resegmentation :feature into a MAY :from a MUST. : :Thanks. : ::-----Original Message----- ::From: Mallikarjun C. [mailto:cbm@rose.hp.com] ::Sent: Wednesday, March 27, 2002 9:27 PM ::To: IPS Reflector (E-mail) ::Subject: Re: iSCSI: MaxRecvPDULength simplification :: :: ::One of the design goals of task reassign is to be able to reassign the ::connection allegiance of a task to a different connection ::that's perhaps ::using an entire different network for a true failover ::capability - for ex., ::the original allegiant connection could be traversing a ::corprorate intranet, ::and the reassigned connection could be using the public ::internet. That's ::the reason for not placing the equivalence requirement on the two ::connections. :: ::MaxRecvPDULength was made negotiable during the FFP because ::several of us felt that it's very useful for iSCSI to allow ::implementations ::with the `ULPDU containment' property ::(http://search.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-ul ::p-frame-01.txt). ::This automatically means that MaxRecvPDULength should be changeable ::with changes in PMTU changes, particularly with dynamic PMTU ::degradation. :: ::Let's look at the possibility you suggest - there being two ::valid MaxRecvPDULength ::values at the same time. If a change in FFP is being ::attempted for this key, it must ::be due to PMTU changes, and the implicit expectation is that ::initiator will sense ::it and initiate the negotiation process (thus enabling the ::target to declare its changed ::MaxRecvPDULength, if any, as well in the text response). ::There is no ambiguity for ::the initiator since the text negotiation can not be assumed ::successful (meaning new ::MaxRecvPDULength can't be used) until the text response (with ::F-bit) is received. ::As far as the target is concerned, it can not assume the text ::negotiation to be effective ::(meaing new MaxRecvPDULength can't be used) until the StatSN ::for the text response ::is ack'ed - perhaps we should make this clear in the text (and ::allow explicit soliciting ::for StatSN acknowledgement using a NOP-ping). ::-- ::Mallikarjun :: ::Mallikarjun Chadalapaka ::Networked Storage Architecture ::Network Storage Solutions Organization ::Hewlett-Packard MS 5668 ::Roseville CA 95747 ::cbm@rose.hp.com :: ::----- Original Message ----- ::From: "Michael Schoberg" ::To: "IPS Reflector (E-mail)" ::Sent: Wednesday, March 27, 2002 8:36 AM ::Subject: RE: iSCSI: MaxRecvPDULength simplification :: :: ::> SNACK with RL=0 is only one requirement. Another is task allegiance ::> reassignment (6.1.2) which does not use SNACK (correct?) ::Here the initiator ::> sends a Task-Management request with a Task-Reassign message ::to the target. ::> The target must reorganize it's T->I messages to match the ::MaxRecvPDULength ::> of the new connection. Plus, the Task Reassign message includes the ::> ExpDataSN field which, if I'm reading right, on reassignment ::the target must ::> remember the sequencing of the old connection in order to track the ::> ExpDataSN field then re-sequence for the new connection ::(9.5.4). So now ::> target implementations will have to keep track of sequence ::indexes for ::> Data-In PDUs for conversion over to the new allegiance. ::> ::> On-the-fly modification of MaxRecvPDULength also means that ::some compliance ::> standard must be set for in-flight messages. An outstanding ::read request ::> may have T->I PDUs that comply with multiple ::MaxRecvPDULength values. In a ::> sense, there will be times where multiple MaxRecvPDULength ::values are valid. ::> At what point MUST the target comply with the new value? ::> ::> So I guess I'm not convinced that the benefit of simplification is ::> illusionary. Is there a discussion thread that expressly states ::> MaxRecvPDULength must have the flexibility allowed for in ::the draft? The ::> discussions I've seen mainly centered around whether it ::should be duplex ::> valued (I->T, T->I). ::> ::> Thanks. ::> ::> -----Original Message----- ::> From: Julian Satran [mailto:Julian_Satran@il.ibm.com] ::> Sent: Wednesday, March 27, 2002 1:40 AM ::> To: Michael Schoberg ::> Cc: IPS Reflector (E-mail); owner-ips@ece.cmu.edu ::> Subject: Re: iSCSI: MaxRecvPDULength simplification ::> ::> ::> ::> The simplification you are talking about is illusory. Currently this ::> requires SNACK to require all data(RL = 0). ::> The restriction you propose instead is far more severe (and ::unwarranted). ::> ::> Julo ::> ::> ::> ::> Michael Schoberg ::> Sent by: owner-ips@ece.cmu.edu ::> ::> ::> 27-03-02 01:19 ::> Please respond to Michael Schoberg ::> ::> ::> ::> To: "IPS Reflector (E-mail)" ::> cc: ::> Subject: iSCSI: MaxRecvPDULength simplification ::> ::> ::> ::> ::> I've looked over some of the reflector messages regarding ::MaxRecvPDULength ::> negotiation (back to Oct 2001). I can't find the discussion ::of why this ::> value must be available for negotiation outside of login. It really ::> complicates SNACK and Task Reassignment if the initiator can ::change this ::> value on-the-fly. Would it be too restrictive to propose ::the following ::> rules? ::> ::> 1) MaxRecvPDULength is negotiated only at login before FFP. ::> ::> 2) For message-level recovery, a connection must be prepared ::to accept the ::> MaxRecvPDULength of the connection it's providing fail over ::capability for. ::> It doesn't seem unreasonable to expect fault tolerant ::configurations to ::> comply with this. It would simply be stating that ::RecoveryLevel 2 devices ::> should be somewhat matched in this capability. ::> ::> ::> ::> -----Original Message----- ::> From: Julian Satran [mailto:Julian_Satran@il.ibm.com] ::> Sent: Tuesday, March 26, 2002 1:50 AM ::> To: Michael Schoberg ::> Cc: IPS Reflector (E-mail); owner-ips@ece.cmu.edu ::> Subject: Re: iSCSI: SNACK RunLength ::> ::> ::> Michael, ::> ::> The paragraph says that if you issue a SNACK after the ::MaxPDURecvLength has ::> decreased you should use RunLength 0 (meaning all) instead ::of a specific ::> runlength which might not be accurate anymore. ::> ::> Julo ::> ::> ::> Michael Schoberg ::> Sent by: owner-ips@ece.cmu.edu ::> ::> ::> 25-03-02 19:43 ::> Please respond to Michael Schoberg ::> ::> ::> To: "IPS Reflector (E-mail)" ::> cc: ::> Subject: iSCSI: SNACK RunLength ::> ::> ::> ::> ::> ::> Am I just not reading this or can this paragraph use some ::help? Can someone ::> give an interpretation? ::> ::> 9.16.3 RunLength ::> ... ::> ::> The first data SNACK, issued after initiator's ::MaxRecvPDULength ::> decreased, for a command issued on the same ::connection before the ::> ::> change in MaxRecvPDULength, MUST use RunLength "0" ::to request ::> retransmission of any number of PDUs (including ::one). The number ::> of ::> retransmitted PDUs in this case, may or may not be ::the same as ::> the ::> original transmission, depending on whether loss ::was before or ::> after ::> the MaxRecvPDULength was changed at the target. ::> ::> ::> Does this refer to something like: ::> ::> For connections with unacknowledged PDUs that undergo ::MaxRecvPDULength ::> negotiation ... ::> ::> ::> ::> ::> ::> ::> :: : From owner-ips@ece.cmu.edu Mon Jun 10 16:32:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24027 for ; Mon, 10 Jun 2002 16:32:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AK0qd09116 for ips-outgoing; Mon, 10 Jun 2002 16:00:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AK0ow09112 for ; Mon, 10 Jun 2002 16:00:51 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id B47AEBC58; Mon, 10 Jun 2002 14:00:46 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 09FD8120; Mon, 10 Jun 2002 14:00:46 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 10 Jun 2002 14:00:42 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 14:00:42 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E3E60@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: wrstuden@wasabisystems.com, rsnively@Brocade.COM Cc: ksandars@eurologic.com, ips@ece.cmu.edu Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys Date: Mon, 10 Jun 2002 14:00:37 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Bill, It is the place of MIBs and CIM objects to cover items like this. For diagnostic problems, these are more useful because they are available to management systems as well as at the two ends of the link. Generally, building a duplicate capability to exchange management objects in protocols adds cost without benefit. Regards, Pat -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Friday, June 07, 2002 10:27 AM To: Robert Snively Cc: 'Ken Sandars'; Ips Reflector (E-mail) Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys On Fri, 7 Jun 2002, Robert Snively wrote: > The management component already has standard mechanisms > for determining such information, including MIBs and CIM > objects. The operational components already have standard > mechanisms for determining such information, including > SCSI INQUIRY commands. I cannot see how this additional > (non-standard) mechanism for capturing this information is > going to help iSCSI achieve its goals. Question about the operational components being able to determine this info. iSCSI is, in terms from SAM-2, a Service Delivery Subsystem (SDS). While many implementations act as scsi servers (disks & tapes, etc.), that's not part of the spec. So I'm confused how an SDS answers a SCSI INQUIRY. I thought that was the domain of the device(s) at the other end of the connection, not the domain of the connection itself. Take care, Bill From owner-ips@ece.cmu.edu Mon Jun 10 16:35:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24175 for ; Mon, 10 Jun 2002 16:35:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AKA9U09683 for ips-outgoing; Mon, 10 Jun 2002 16:10:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AKA8w09679 for ; Mon, 10 Jun 2002 16:10:08 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 27F429A34; Mon, 10 Jun 2002 14:10:07 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 6B98914E; Mon, 10 Jun 2002 14:10:06 -0600 (MDT) Received: from 130.29.152.143 by axcsbh1.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 10 Jun 2002 14:10:06 -0600 Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 14:10:05 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E3E67@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Ken Sandars , "THALER,PAT (A-Roseville,ex1)" , ni1d@arrl.net, bmastors@allocity.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys Date: Mon, 10 Jun 2002 14:10:00 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Ken, The incentive is that, in my experience, when products interoperate out of the chute (because the spec is clear) the market grows quickly. When interoperability is a nightmare built in by testing and tweaks, then markets grow slowly. Ambiguities need to be fixed. A number that have been raised recently have been fixed. If there are ones you feel haven't been addressed, I would like to see them fixed. That is what we should do rather than planning on building in work arounds. Regards, Pat -----Original Message----- From: Ken Sandars [mailto:ksandars@eurologic.com] Sent: Friday, June 07, 2002 10:54 AM To: pat_thaler@agilent.com; ni1d@arrl.net; bmastors@allocity.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys Hi Pat, Paul, Bob, There is no disputing the fact that identifying brokeness and fixing it is the right way to go. Now while it's nice to lend our mental muscles to the task of identifying these problems, it's pretty difficult to compel other vendors to fix something which is broken wrt to the spec, when it works with some other products in the marketplace. The unfortunate reality is that certain problems have been long identified (over half a year in some cases), and remain unfixed. Our approach is to implement the spec. As we encounter problems we fix our broken bits and notify the partner of the issue - in most cases this has worked well and they have fixed their problems too. However, we are compelled to put work-arounds in our system in order to interoperate with those who have have fielded systems which remain broken. At this stage, unless the intiator is known, we turn all the work-arounds on. This has an impact on performance. We'd like to avoid this. We want to see iSCSI run at the speed of a thousand startled gazelles. We want to see all iSCSI offerings interoperate. We don't want to see the management of these things as a nightmare. I think the use of the proposed keys will only assist implementers by providing additonal information - which can be used or ignored. Oh, and we won't send them from our target if the initiator doesn't send them, as there may be some initiator which doesn't handle the X- keys! (I have further comments inline): On Thursday 06 June 2002 11:31 pm, pat_thaler@agilent.com wrote: > Paul, > > I agree. This would also create a testing nightmare for initiator > developers. If the initiator has adapts itself for n targets then > it has n different personalities that all need to be tested. > As Bob Mastors said, it's already in there, so it's being done. And testers are meant to have nightmares! It's their job ;-) > We have interoperability testing to help us find and fix > spec ambiguities that cause interoperability problems. > Yep - we find them, and they ignore them, so this doesn't get us over the finish line. > The way to build market for iSCSI is to have interoperability - > not to have cases wher Brand_x Target doesn't work with Brand_y > Initiator because Brand_y doesn't have the tweak profile for > Brand_x. > As I noted above, we interoperate, but at the cost of performance. > Regards, > Pat > > -----Original Message----- > From: Paul Koning [mailto:ni1d@arrl.net] > Sent: Thursday, June 06, 2002 1:06 PM > To: bmastors@allocity.com > Cc: ksandars@eurologic.com; ips@ece.cmu.edu > Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys > > >>>>> "Bob" == Bob Mastors writes: > > Bob> I like it. Otherwise the user has to configure the initiator > Bob> with the target type and the target with the initiator type. It > Bob> is unlikely that this problem will disappear for a long time if > Bob> ever. As the threads on the C bit has shown there will be lots > Bob> of ways to implement the spec and probably no device will > Bob> correctly support all possibilities. I am already putting "if > Bob> (vendor)" code in my implementation. Maybe in a few years I will > Bob> not need it. But until then it would be nice if I could > Bob> dynamically determine vendor information for iscsi so the user > Bob> does not have to configure it. > > Oh boy, now I'm well and truly frightened. Welcome to my nightmare! > > I read your message as saying that there isn't going to be > interoperability for several years. I'm a lot more optimistic than that - these problems should be gone within a year of the draft becoming a standard. In the meantime, we DO interoperate, just in a hobbled mode for unknown initiators. > Sorather than create a serious > incentive for implementers to fix their defects, Can you suggest what this incentive might be? > we should implement a > way to have them report which collection of defects they implement so > we can invoke workaround collection #42. Of course, the larger the > collection of crocks we work around, the larger the number of bugs in > implementations that everyone else will have to work around. > Sounds messy to me. It comes down to this: we work by default in a mode to achieve maximum interoperability, albeit at the expense of some performance/reliability features. If an initiator lets our target know what it is, and we recognise its lack of the known quirks, we remove the work-arounds. Our tester's nightmares, our developer's pain to identify and create work-arounds, and at no cost to the standards track. And it's all optional. > In the words of a well known American, "Just Say NO". OK - but think carefully before following the advice of famous Americans - didn't some other well known American spell tomato with an 'e'? ;-) > > paul Cheers, Ken -- Ken Sandars Eurologic Systems Ltd ksandars@eurologic.com From owner-ips@ece.cmu.edu Mon Jun 10 16:39:58 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24258 for ; Mon, 10 Jun 2002 16:39:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AJvBE08892 for ips-outgoing; Mon, 10 Jun 2002 15:57:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AJv8w08884 for ; Mon, 10 Jun 2002 15:57:08 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 5FEF830706; Mon, 10 Jun 2002 15:57:07 -0400 (EDT) Date: Mon, 10 Jun 2002 12:54:59 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Michael Smith Cc: Subject: Re: iSCSI: AHS use In-Reply-To: <034670D62D19D31180990090277A37B702437BC0@mercury.corp.iready.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Mon, 10 Jun 2002, Michael Smith wrote: > I have some questions on the current AHS descriptions in 12-97. I just > tripped over this, so I think maybe others might too. [snip] > 2. However, in the PDU format diagram on p. 131 of 12-97 it is not clear > that we have the option of zero, one or more Additional Header Segments. > After I re-read things a few times, and apologies if I have this wrong, I > think that the use of multiple Additional Header Segments is along these > lines: > > (a) Use one and only one Additional Header Segment for an extended CDB (SPC > calls this a variable-length CDB). This extended CDB (or variable-length > CDB) Additional Header Segment must immediately follow the BHS. (A suggested > exact use definition of this type of Additional Header Segment coming up.) > > (b) Use one and only one Additional Header Segment for an Bidirectional > Expected Read-Data Length. This Bidirectional Expected Read-Data Length > Additional Header Segment must immediately follow the BHS. > > (c) Use of more than one Additional Header Segment is left up to the user. > > How many Additional Header Segments were we expecting to be able to be used? > Would this maximum length of Additional Header Segments be limited only by > the TotalAHSLength (8-bit field measuring length in four-byte words or > ((2**8) - 1) * 4 bytes or roughly 1 kbyte)? Can we follow an extended CDB > Additional Header Segment or a Bidirectional Expected Read-Data Length > Additional Header Segment by one or more user-defined Additional Header > Segment? > > Did I get this anywhere close to correct? Not sure about correct, but you got it as I understand it. :-) The one thing I'm not sure about is the use of, "must immediately follow the BHS." I agree it must be in the AHS associated with the BHS, but if you have a variable-length command (with CDB spill) which is also a bidi command, you will have both an (a) and a (b), and only one can immediately follow the BHS. :-) > 3. In one of Bob Russell's emails we have the following, which does seem to > make the use of multiple Additional Header Segments a little clearer to me: > > > [quote http://www.pdl.cmu.edu/mailinglists/ips/mail/msg03784.html] > > [view in fixed-width font on wide window] > +------------------------+ > | required BHS | > fixed length of 48 bytes > +------------------------+ > | optional AHS 1 |\ > | - - - - - - - - - - - | \ > | optional AHS 2 | \ > | - - - - - - - - - - - | > total length in AHS_length field in BHS > | . . . . | / > | - - - - - - - - - - - | / > | optional AHS n |/ > +------------------------+ > | optional header digest | -- covers preceding (48 + AHS_length) bytes > +------------------------+ > | |\ > | optional data | > total length in DATA_length field in BHS > | |/ > +------------------------+ > | optional data digest | -- covers preceding (DATA_length) bytes > +------------------------+ > > [end view in fixed-width font on wide window] > > [end quote http://www.pdl.cmu.edu/mailinglists/ips/mail/msg03784.html] > > Is it possible to add something like this picture to the format diagram on > p.131. I wouldn't ask if I hadn't tripped myself up on this already. I think such a diagram would help too. > 4. On p. 139 of 12-97 we have the following: [snip text suggestion] > There are 16 bytes in the CDB field to accommodate bytes 0-15 of the > commonly used CDBs. An Extended CDB AHS MUST be used to contain bytes 16-259 > of a variable-length CDB [SPC]. Sounds like a good change too. Take care, Bill From owner-ips@ece.cmu.edu Mon Jun 10 16:40:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24281 for ; Mon, 10 Jun 2002 16:40:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AKUKe10935 for ips-outgoing; Mon, 10 Jun 2002 16:30:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AKUIw10931 for ; Mon, 10 Jun 2002 16:30:18 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g5AKVqu09901; Mon, 10 Jun 2002 16:31:52 -0400 Message-ID: <3D050C52.5379887@splentec.com> Date: Mon, 10 Jun 2002 16:30:10 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Bill Studenmund CC: Robert Snively , "'Ken Sandars'" , "Ips Reflector (E-mail)" Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bill Studenmund wrote: > > On Mon, 10 Jun 2002, Luben Tuikov wrote: > > > Any time you see ``MAY'' or ``may'' in the draft and a target > > and initiator arrive at different outcomes _just_ by taking one > > or the other route, you have ``compliant-non-interoperability''. > > > > Which is what you are describing in more ``baby-terms'' below. > > No, that's not the same thing. You are saying EVERY may/MAY is a problem. > I disagree with that. I'll agree that SOME may be a problem, and that we > want to find them. > ``Any time'' doesn't imply ``EVERY may/MAY''! Look, I used the conjunctive ``and''. Here: (Every time ... MAY or may) AND (target/initiator arrive at different outcomes) THEN problem. -- Luben From owner-ips@ece.cmu.edu Mon Jun 10 16:48:44 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24712 for ; Mon, 10 Jun 2002 16:48:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AKRfM10776 for ips-outgoing; Mon, 10 Jun 2002 16:27:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AKRdw10772 for ; Mon, 10 Jun 2002 16:27:39 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id BF913A4A; Mon, 10 Jun 2002 14:27:34 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 978B228F; Mon, 10 Jun 2002 14:27:34 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 10 Jun 2002 14:27:33 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 14:27:32 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E3E7B@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: luben@splentec.com, wrstuden@wasabisystems.com Cc: rsnively@Brocade.COM, ksandars@eurologic.com, ips@ece.cmu.edu Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys Date: Mon, 10 Jun 2002 14:27:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Luben, An IETF standard is suppose to produce interoperability. Therefore, when there is a MAY in the standard, it should be because each side can choose either option and they will interoperate independent of which they choose. For example: "iSCSI targets and initiators MUST support at least one TCP connection and MAY support several connections in a session." A device that supports only one connection per session will interoperate (over one connection) to a device that supports multiple connections. Pat -----Original Message----- From: Luben Tuikov [mailto:luben@splentec.com] Sent: Friday, June 07, 2002 4:18 PM To: Bill Studenmund Cc: Robert Snively; 'Ken Sandars'; Ips Reflector (E-mail) Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys Bill Studenmund wrote: > > > That comment reflects a very nice ideal. My concern is that I'm not sure > we're there. What about Luben's comments that there are existing > interoperability problems among compliant systems? AS I understand him, > compliant *iSCSI* systems. ?? I haven't checked for those lately, (especially in the login procedure), but any time you see ``MAY'' or ``may'' in the draft and a target and initiator arrive at different outcomes _just_ by taking one or the other route, you have ``compliant-non-interoperability'' (as you coined the term). > My technical writing skills aren't up > to the task to do anything different, and I expect someone will make some > $$ off of an intro book. There are books that talk about iSCSI now. I bet that just one month after iSCSI becomes a standard, you'll see 10 books on iSCSI, 5 for Unix/Linux (2 of them with CDs + implementations) and 5 for Windoze. I can think of at least one Linux Guru who's known to write books like that (for a month's time) and who might be considering this. > But the problem (as a number of recent threads have shown :-) is that > people who are looking at the spec for the first time don't necessarily > come to understand the spec the same way that the longer-term WG members > do. The longer-term members see the written spec as a clear reflection of > their idea of the spec, so they don't see the problems. They've been to > plug-fests, and so they have a lot of commonality in their mental ideas of > what the spec is. When a choice comes up, they naturally choose the same > way as the other longer-term members, and they don't always see that > they've made a choice. This basically is the old conundrum: How does one express one's ideas in the most unambiguous way? We don't know of a better way than formalism (i.e. mathematics). This is the reason I've been asking to be more formal in the draft. And I'm not just whining, as I've made it clear that I can volunteer time. This is why 4.1 and 1. exist in their current form. This is also why I've been trying to get the CRC algorithm in 11.1 become more formal, which would make it more clear and straightforward to implement. And this is why I'd like to see someone draw the decision graphs for the login/text stage/negotiations for the T and I -- then any problems will be evident. And this is why Robert of UNH started the variables' dependency charts. > So what do we do? The rest of us (certainly me) cannot do anything. I can just wait. (I can only correct spelling mistakes and missed periods, and such, like this one ) It would be interesing to see the development of iSCSI and the reaction of the rest of the industry and (closer to my heart) the Linux community once iSCSI becomes a standard. -- Luben From owner-ips@ece.cmu.edu Mon Jun 10 17:23:54 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26164 for ; Mon, 10 Jun 2002 17:23:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AKeHt11551 for ips-outgoing; Mon, 10 Jun 2002 16:40:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AKeFw11544 for ; Mon, 10 Jun 2002 16:40:15 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g5AKfZu10001; Mon, 10 Jun 2002 16:41:35 -0400 Message-ID: <3D050E99.1A33B188@splentec.com> Date: Mon, 10 Jun 2002 16:39:53 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: pat_thaler@agilent.com CC: wrstuden@wasabisystems.com, rsnively@Brocade.COM, ksandars@eurologic.com, ips@ece.cmu.edu Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys References: <1BEBA5E8600DD4119A50009027AF54A00C5E3E7B@axcs04.cos.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit pat_thaler@agilent.com wrote: > > Luben, > > An IETF standard is suppose to produce interoperability. Therefore, when > there is a MAY in the standard, it should be because each side can choose > either option and they will interoperate independent of which they choose. > For example: > > "iSCSI targets and initiators MUST support at least one TCP connection > and MAY support several connections in a session." > A device that supports only one connection per session will interoperate > (over one connection) to a device that supports multiple connections. Pat, please read carefully my reply to Paul. "a target MAY close the connection or may offer its own acceptable values" and "receiving non-offered value is a protocol error" doesn't interoperate. -- Luben From owner-ips@ece.cmu.edu Mon Jun 10 17:26:06 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26263 for ; Mon, 10 Jun 2002 17:26:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AKwPC12581 for ips-outgoing; Mon, 10 Jun 2002 16:58:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AKwNw12577 for ; Mon, 10 Jun 2002 16:58:23 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 16:58:07 -0400 Message-ID: From: Eddy Quicksall To: "Robert D. Russell" , Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: MaxRecvPDULength question Date: Mon, 10 Jun 2002 16:58:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Below it says: "The DataSegmentLength in a Text *Request* MUST NOT exceed the iSCSI initiator's MaxRecvDataSegmentLength (a per connection and per direction negotiated parameter)." But it seems it should say "Response". Eddy -----Original Message----- From: Robert D. Russell [mailto:rdr@io.iol.unh.edu] Sent: Monday, June 10, 2002 3:43 AM To: Julian_Satran@il.ibm.com; ips@ece.cmu.edu Subject: Re: MaxRecvPDULength question Julian: It has been stated several times that at this late stage we should not be requesting changes that are just preferences. Nevertheless, due to apparent misunderstandings of its meaning, the key named MaxRecvPDULength in draft 12 is apparently going to have its name changed in draft 13. Fine. No problem. However, to remove all possibility of future misunderstandings, why don't we give it a name that says precisely what it is: MaxRecvDataSegmentLength That way, the first sentence in the third paragraph of section 9.7.1 would begin: "DataSegmentLength MUST not exceed MaxRecvDataSegmentLength for the direction it is sent ..." which seems to me to be the classic definition of a maximum. The issue of changing the name from MaxRecvPDULength started with an e-mail sent by Luben Tuikov on 21 May (who, by the way, did NOT want to change the name, just its meaning), and was followed by a short flurry of e-mails under the thread "MaxRecvPDULength question". Some of the names suggested on that thread were: MaxRecvDataLength (21 May by Paul Konig) MaxRecvDataSegmentSize (21 May by Pat Thaler) MaxRecvDataSegSize (21 May by Pat Thaler) MaxRecvPDUDataSize (22 May by Pat Thaler) and what got into the draft was this last suggestion by Pat. I don't believe there was a consensus for this choice (probably, as was stated by Pat several times, because most people don't really see the need for a renaming and didn't bother to participate in the thread). Therefore, I would ask you to reconsider the new name and ask for consensus on the new choice. I believe the name MaxRecvDataSegmentLength is so closely linked to the name DataSegmentLength that its meaning should be clear to even a first-time reader, especially given the statement in section 9.7.1 quoted above. Furthermore, there clearly is the concept of DataSegmentLength elsewhere in the standard -- every PDU has a DataSegmentLength field. I could find no concept of PDUDataSize (or even "data size") elsewhere in the current draft. Whether or not this renaming happens (again), I believe there should be the following rewordings to be more precise in order to avoid any ambiguities and/or future misinterpretations. The first sentence in section 9.10.5 should be changed to read: "The DataSegmentLength in a Text Request MUST NOT exceed the iSCSI target's MaxRecvDataSegmentLength (a per connection and per direction negotiated parameter)." and the first sentence in section 9.11.6 should be changed to read: "The DataSegmentLength in a Text Request MUST NOT exceed the iSCSI initiator's MaxRecvDataSegmentLength (a per connection and per direction negotiated parameter)." Finally, two sentences in section 11.13 should be changed to read: "The initiator or target declares the maximum DataSegmentLength in bytes it can receive in an iSCSI PDU." and "The transmitter (initiator or target) is required to send PDUs with a DataSegmentLength not exceeding MaxRecvDataSegmentLength of the receiver." Thank you for your consideration, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Mon Jun 10 17:27:35 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26395 for ; Mon, 10 Jun 2002 17:27:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AKxUN12657 for ips-outgoing; Mon, 10 Jun 2002 16:59:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AKxSw12653 for ; Mon, 10 Jun 2002 16:59:28 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 0ED1930706; Mon, 10 Jun 2002 16:59:28 -0400 (EDT) Date: Mon, 10 Jun 2002 13:57:21 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Cc: , , Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00C5E3E60@axcs04.cos.agilent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Mon, 10 Jun 2002 pat_thaler@agilent.com wrote: > Bill, > > It is the place of MIBs and CIM objects to cover items like this. For > diagnostic problems, these are more useful because they are available to > management systems as well as at the two ends of the link. Then why do we have a SendTargets command? Can't that information be obtained from the MIBs? Isn't it the place of MIBs and CIM objects to cover items like that too? I mean, come on, SendTargets has had much more impact on iSCSI than the three keys we're talking about. It is, as I understand it, the main reason the text negotiation code supports responses over multiple PDUs. Yes, we found a lot more uses for this, but SendTargets was (AFAICT) the instigator. To answer my own question, I think we have a SendTargets command because the WG thought the information was useful and didn't want to have to go to SNMP to get it. Which is a fine reason (and one I agree with). But to say we shouldn't echo things in the MIB in a way we find useful when we have opened the door with SendTargets is hypocritical. > Generally, building a duplicate capability to exchange management objects in > protocols adds cost without benefit. For the general case, I agree. But last I understood of this thread, we were not talking about exchanging arbitrary management objects, we were talking about a key for the vendor, a key for the product name, and a key for the revision. These are static text strings exchanged once at login. What is so onerous about them? They strike me as as useful as aliases, which we permit. Also, why do you assume that the iSCSI MIBs will be available? While I expect product vendors will support them, 1) I don't think we can depend on it being available for iSCSI entities on general-purpose computers (like things running Windows, Linux, or any of the *BSDs), 2) what about sites where admins don't like SNMP, and so they either turn it off or firewall it? Finally, what about multi-vendor situations? Say I want to run target code from two vendors on the same box at once? Great for a head-to-head comparison. I fire one up on a different port (not 3260), and away I go. While I find it reasonable that each vendor will supply SNMP bits, I find it unlikely that they will work together. So you get one or the other showing up in SNMP. While I agree this isn't the common case, I mention it because it illustrates a case where, "It's available in the MIB," isn't true. Take care, Bill From owner-ips@ece.cmu.edu Mon Jun 10 18:25:15 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28031 for ; Mon, 10 Jun 2002 18:25:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5ALWWP14568 for ips-outgoing; Mon, 10 Jun 2002 17:32:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5ALWTw14561 for ; Mon, 10 Jun 2002 17:32:30 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 17:32:29 -0400 Message-ID: From: Eddy Quicksall To: Julian Satran Cc: ips@ece.cmu.edu, pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength Date: Mon, 10 Jun 2002 17:32:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C210C6.52695900" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C210C6.52695900 Content-Type: text/plain; charset="iso-8859-1" Julian, Another problem here is that the target has to calculate the offset from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 means starting DataSN=4, send all the data for that sequence. I think it would be a performance hit and waist of memory to keep a tally of all PDU sizes just for an occasional SNACK. It's not that it can't be done ... it is more that it is messy and I think there is a solution that will satisfy the design requirements but keep the software simpler. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, June 08, 2002 10:16 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength That is not completely accurate. The only problem is when PDU size decreases and then SNACK must be for all data. Target can also keep a mapping of numbers/to offsets (the list should be small and if it gets long ask for ack (A-bit). Julo Eddy Quicksall Sent by: owner-ips@ece.cmu.edu 06/08/2002 10:54 PM Please respond to Eddy Quicksall To: pat_thaler@agilent.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Thanks, As a target, I won't be able to let it change until all of the outstanding commands are finished (running with ErrorRecoveryLevel>=1). This is because I must use the PDU size to compute the offset from a SNACK's BegRun/RunLength. So, I plan to not give the text response for a MaxPDURecvDataLength in FFP until I get back an ExpStatSN == next StatSN. This will cause a delay of unknown time before the PDU size can actually change ... do you see any problem with this? Eddy -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Friday, June 07, 2002 1:13 PM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Eddy, If one uses a message sync and steering that relys on the transport segments carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path MTU changes one would want to change the PDU data length to fit the new path MTU. Pat -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Wednesday, June 05, 2002 12:24 PM To: ips@ece.cmu.edu Subject: iSCSI: changing MaxPDUDataLength Does anybody know a case where it is necessary to support a new PDU data length during full feature phase? Eddy mailto: Eddy_Quicksall@iVivity.com ------_=_NextPart_001_01C210C6.52695900 Content-Type: text/html; charset="iso-8859-1"
Julian,
 
Another problem here is that the target has to calculate the offset from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 means starting DataSN=4, send all the data for that sequence.
 
I think it would be a performance hit and waist of memory to keep a tally of all PDU sizes just for an occasional SNACK.
 
It's not that it can't be done ... it is more that it is messy and I think there is a solution that will satisfy the design requirements but keep the software simpler.
 
Eddy
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, June 08, 2002 10:16 PM
To: Eddy Quicksall
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com
Subject: RE: iSCSI: changing MaxPDUDataLength


That is not completely accurate.
The only problem is when PDU size decreases and then SNACK must be for all data.
Target can also keep a mapping of numbers/to offsets (the list should be small and if it gets long ask for ack (A-bit).

Julo


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

06/08/2002 10:54 PM
Please respond to Eddy Quicksall

       
        To:        pat_thaler@agilent.com
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: changing MaxPDUDataLength

       


Thanks,

As a target, I won't be able to let it change until all of the outstanding
commands are finished (running with ErrorRecoveryLevel>=1). This is because
I must use the PDU size to compute the offset from a SNACK's
BegRun/RunLength.

So, I plan to not give the text response for a MaxPDURecvDataLength in FFP
until I get back an ExpStatSN == next StatSN.

This will cause a delay of unknown time before the PDU size can actually
change ... do you see any problem with this?

Eddy

-----Original Message-----
From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]
Sent: Friday, June 07, 2002 1:13 PM
To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu
Subject: RE: iSCSI: changing MaxPDUDataLength


Eddy,

If one uses a message sync and steering that relys on the transport segments
carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path
MTU changes one would want to change the PDU data length to fit the new path
MTU.

Pat

-----Original Message-----
From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com]
Sent: Wednesday, June 05, 2002 12:24 PM
To: ips@ece.cmu.edu
Subject: iSCSI: changing MaxPDUDataLength


Does anybody know a case where it is necessary to support a new PDU data
length during full feature phase?

Eddy
mailto: Eddy_Quicksall@iVivity.com



------_=_NextPart_001_01C210C6.52695900-- From owner-ips@ece.cmu.edu Mon Jun 10 19:09:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28932 for ; Mon, 10 Jun 2002 19:09:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AMLYX17077 for ips-outgoing; Mon, 10 Jun 2002 18:21:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AMLWw17073 for ; Mon, 10 Jun 2002 18:21:33 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 4B76030706; Mon, 10 Jun 2002 18:21:32 -0400 (EDT) Date: Mon, 10 Jun 2002 15:19:25 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: "THALER,PAT (A-Roseville,ex1)" Cc: Ken Sandars , , , Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00C5E3E67@axcs04.cos.agilent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Mon, 10 Jun 2002, THALER,PAT (A-Roseville,ex1) wrote: > Ken, > > The incentive is that, in my experience, when products interoperate > out of the chute (because the spec is clear) the market grows quickly. > When interoperability is a nightmare built in by testing and tweaks, > then markets grow slowly. > > Ambiguities need to be fixed. A number that have been raised recently > have been fixed. If there are ones you feel haven't been addressed, I > would like to see them fixed. That is what we should do rather than > planning on building in work arounds. I agree that if folks know of ambiguities, we should fix them. PLEASE bring them up. NOW. :-) I also agree that we shouldn't ship a spec with what we know to be holes in it. In fact, that's why my EMails have been quite, shall we say, vigorous. _I_ want iSCSI to be the best spec it can. The question to me, though, is two-fold. 1) as my other note indicates, I think these keys have value on their own (I don't plan on using them for bug adaptability, just info). 2) (and this is the bigger question) What do we do about bugs we find *after* we get to RFC stage? Yes, we fix them in the next version. But how quickly are we going to get that version out? Are we going to crank RFCs out as fast as Julian can make I-D drafts now? I doubt it. If we were, then I think saying, "Update to the next version," is a reasonable approach. I expect iSCSI 2 (or 1.1) will be on the order of a year or more out from iSCSI. What does everyone else think? What do we do in the mean time? And shouldn't we think about that now? Take care, Bill From owner-ips@ece.cmu.edu Mon Jun 10 20:30:08 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29897 for ; Mon, 10 Jun 2002 20:30:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5B05tG21664 for ips-outgoing; Mon, 10 Jun 2002 20:05:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5B05mw21657 for ; Mon, 10 Jun 2002 20:05:52 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5B05c7n015650; Tue, 11 Jun 2002 02:05:39 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5B05cD61504; Tue, 11 Jun 2002 02:05:38 +0200 To: Eddy Quicksall Cc: ips@ece.cmu.edu, pat_thaler@agilent.com MIME-Version: 1.0 Subject: RE: iSCSI: changing MaxPDUDataLength X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 11 Jun 2002 03:05:36 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 11/06/2002 03:05:38, Serialize complete at 11/06/2002 03:05:38 Content-Type: multipart/alternative; boundary="=_alternative 0000306FC2256BD5_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0000306FC2256BD5_= Content-Type: text/plain; charset="us-ascii" I said only that when you change length you can ask for all PDUs after the ack! (no need to keep a tall - the old offsets are good up to the hole). Julo Eddy Quicksall 06/11/2002 12:32 AM Please respond to Eddy Quicksall To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength Julian, Another problem here is that the target has to calculate the offset from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 means starting DataSN=4, send all the data for that sequence. I think it would be a performance hit and waist of memory to keep a tally of all PDU sizes just for an occasional SNACK. It's not that it can't be done ... it is more that it is messy and I think there is a solution that will satisfy the design requirements but keep the software simpler. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, June 08, 2002 10:16 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength That is not completely accurate. The only problem is when PDU size decreases and then SNACK must be for all data. Target can also keep a mapping of numbers/to offsets (the list should be small and if it gets long ask for ack (A-bit). Julo Eddy Quicksall Sent by: owner-ips@ece.cmu.edu 06/08/2002 10:54 PM Please respond to Eddy Quicksall To: pat_thaler@agilent.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Thanks, As a target, I won't be able to let it change until all of the outstanding commands are finished (running with ErrorRecoveryLevel>=1). This is because I must use the PDU size to compute the offset from a SNACK's BegRun/RunLength. So, I plan to not give the text response for a MaxPDURecvDataLength in FFP until I get back an ExpStatSN == next StatSN. This will cause a delay of unknown time before the PDU size can actually change ... do you see any problem with this? Eddy -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Friday, June 07, 2002 1:13 PM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Eddy, If one uses a message sync and steering that relys on the transport segments carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path MTU changes one would want to change the PDU data length to fit the new path MTU. Pat -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Wednesday, June 05, 2002 12:24 PM To: ips@ece.cmu.edu Subject: iSCSI: changing MaxPDUDataLength Does anybody know a case where it is necessary to support a new PDU data length during full feature phase? Eddy mailto: Eddy_Quicksall@iVivity.com --=_alternative 0000306FC2256BD5_= Content-Type: text/html; charset="us-ascii"
I said only that when you change length you can ask for all PDUs after the ack! (no need to keep a tall - the old offsets are good up to the hole).

Julo


Eddy Quicksall <eddy_quicksall@ivivity.com>

06/11/2002 12:32 AM
Please respond to Eddy Quicksall

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu, pat_thaler@agilent.com
        Subject:        RE: iSCSI: changing MaxPDUDataLength

       


Julian,
 
Another problem here is that the target has to calculate the offset from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 means starting DataSN=4, send all the data for that sequence.
 
I think it would be a performance hit and waist of memory to keep a tally of all PDU sizes just for an occasional SNACK.
 
It's not that it can't be done ... it is more that it is messy and I think there is a solution that will satisfy the design requirements but keep the software simpler.
 
Eddy
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, June 08, 2002 10:16 PM
To: Eddy Quicksall
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com
Subject: RE: iSCSI: changing MaxPDUDataLength

That is not completely accurate.
The only problem is when PDU size decreases and then SNACK must be for all data.
Target can also keep a mapping of numbers/to offsets (the list should be small and if it gets long ask for ack (A-bit).

Julo

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

06/08/2002 10:54 PM
Please respond to Eddy Quicksall

       
       To:        pat_thaler@agilent.com
       cc:        ips@ece.cmu.edu
       Subject:        RE: iSCSI: changing MaxPDUDataLength

     



Thanks,

As a target, I won't be able to let it change until all of the outstanding
commands are finished (running with ErrorRecoveryLevel>=1). This is because
I must use the PDU size to compute the offset from a SNACK's
BegRun/RunLength.

So, I plan to not give the text response for a MaxPDURecvDataLength in FFP
until I get back an ExpStatSN == next StatSN.

This will cause a delay of unknown time before the PDU size can actually
change ... do you see any problem with this?

Eddy

-----Original Message-----
From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]
Sent: Friday, June 07, 2002 1:13 PM
To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu
Subject: RE: iSCSI: changing MaxPDUDataLength


Eddy,

If one uses a message sync and steering that relys on the transport segments
carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path
MTU changes one would want to change the PDU data length to fit the new path
MTU.

Pat

-----Original Message-----
From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com]
Sent: Wednesday, June 05, 2002 12:24 PM
To: ips@ece.cmu.edu
Subject: iSCSI: changing MaxPDUDataLength


Does anybody know a case where it is necessary to support a new PDU data
length during full feature phase?

Eddy
mailto: Eddy_Quicksall@iVivity.com

--=_alternative 0000306FC2256BD5_=-- From owner-ips@ece.cmu.edu Mon Jun 10 20:34:51 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00006 for ; Mon, 10 Jun 2002 20:34:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5ANjFe20771 for ips-outgoing; Mon, 10 Jun 2002 19:45:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5ANjCw20764; Mon, 10 Jun 2002 19:45:12 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5ANiv7n035574; Tue, 11 Jun 2002 01:44:57 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5ANiuK48318; Tue, 11 Jun 2002 01:44:56 +0200 To: Michael Smith Cc: ips@ece.cmu.edu, Michael Smith , owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: AHS use X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 11 Jun 2002 02:44:54 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 11/06/2002 02:44:56, Serialize complete at 11/06/2002 02:44:56 Content-Type: multipart/alternative; boundary="=_alternative 0081E504C2256BD4_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0081E504C2256BD4_= Content-Type: text/plain; charset="us-ascii" Michael, I am not sure to change the wording to fit the 259 limit of the CDB as set by current SPC - as SPC changes too. We dot envision many new AHSs - but the format design allows for them. You are correct that the design allows for several AHSs up to the total predefined length (and having one predefined max length was not my first choice but is the result of some debate). Julo Michael Smith Sent by: owner-ips@ece.cmu.edu 06/10/2002 08:06 PM Please respond to Michael Smith To: Michael Smith , ips@ece.cmu.edu cc: Subject: iSCSI: AHS use I have some questions on the current AHS descriptions in 12-97. I just tripped over this, so I think maybe others might too. 1. In 12-97, p.130 we have the definition of AHS as Multiple Additional Header Segments (plural); switching between "AHS (singular), AHS (plural), AHS header segments made me look closer: [quote] The BHS is a fixed-length 48-byte header segment. It MAY be followed by Additional Header Segments (AHS), a Header-Digest, a Data Segment, and/or a Data-Digest. [end quote] 2. However, in the PDU format diagram on p. 131 of 12-97 it is not clear that we have the option of zero, one or more Additional Header Segments. After I re-read things a few times, and apologies if I have this wrong, I think that the use of multiple Additional Header Segments is along these lines: (a) Use one and only one Additional Header Segment for an extended CDB (SPC calls this a variable-length CDB). This extended CDB (or variable-length CDB) Additional Header Segment must immediately follow the BHS. (A suggested exact use definition of this type of Additional Header Segment coming up.) (b) Use one and only one Additional Header Segment for an Bidirectional Expected Read-Data Length. This Bidirectional Expected Read-Data Length Additional Header Segment must immediately follow the BHS. (c) Use of more than one Additional Header Segment is left up to the user. How many Additional Header Segments were we expecting to be able to be used? Would this maximum length of Additional Header Segments be limited only by the TotalAHSLength (8-bit field measuring length in four-byte words or ((2**8) - 1) * 4 bytes or roughly 1 kbyte)? Can we follow an extended CDB Additional Header Segment or a Bidirectional Expected Read-Data Length Additional Header Segment by one or more user-defined Additional Header Segment? Did I get this anywhere close to correct? 3. In one of Bob Russell's emails we have the following, which does seem to make the use of multiple Additional Header Segments a little clearer to me: [quote http://www.pdl.cmu.edu/mailinglists/ips/mail/msg03784.html] [view in fixed-width font on wide window] +------------------------+ | required BHS | > fixed length of 48 bytes +------------------------+ | optional AHS 1 |\ | - - - - - - - - - - - | \ | optional AHS 2 | \ | - - - - - - - - - - - | > total length in AHS_length field in BHS | . . . . | / | - - - - - - - - - - - | / | optional AHS n |/ +------------------------+ | optional header digest | -- covers preceding (48 + AHS_length) bytes +------------------------+ | |\ | optional data | > total length in DATA_length field in BHS | |/ +------------------------+ | optional data digest | -- covers preceding (DATA_length) bytes +------------------------+ [end view in fixed-width font on wide window] [end quote http://www.pdl.cmu.edu/mailinglists/ips/mail/msg03784.html] Is it possible to add something like this picture to the format diagram on p.131. I wouldn't ask if I hadn't tripped myself up on this already. 4. On p. 139 of 12-97 we have the following: [quote] 9.3.5 CDB - SCSI Command Descriptor Block There are 16 bytes in the CDB field to accommodate the commonly used CDBs. Whenever the CDB is larger than 16 bytes, an Extended CDB AHS MUST be used to contain the CDB spillover. [end quote] I tripped again on the term "spillover". Could we perhaps change 9.3.5 to the following (thanks to Rob Elliott, see http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10620.html): There are 16 bytes in the CDB field to accommodate bytes 0-15 of the commonly used CDBs. An Extended CDB AHS MUST be used to contain bytes 16-259 of a variable-length CDB [SPC]. 5. There is no description of ExtendedCDB...+ in 9.2.2.3 Extended CDB AHS I guess we would be repeating 9.3.5 if we defined ExtendedCDB as "bytes 16-259 of a variable-length CDB", but perhaps that is not a bad thing? Aloha Mike Smith CTO, iReady --=_alternative 0081E504C2256BD4_= Content-Type: text/html; charset="us-ascii"
Michael,

I am not sure to change the wording to fit the 259 limit of the CDB as set by current SPC - as SPC changes too.
We dot envision many new AHSs - but the format design allows for them.
You are correct that the design allows for several AHSs up to the total predefined length (and having one predefined max length was not my first choice but is the result of some debate).

Julo


Michael Smith <msmith@corp.iready.com>
Sent by: owner-ips@ece.cmu.edu

06/10/2002 08:06 PM
Please respond to Michael Smith

       
        To:        Michael Smith <msmith@corp.iready.com>, ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI: AHS use

       


I have some questions on the current AHS descriptions in 12-97. I just tripped over this, so I think maybe others might too.

 
1. In 12-97, p.130 we have the definition of AHS as Multiple Additional Header Segments (plural); switching between "AHS (singular), AHS (plural), AHS header segments made me look closer:

 
[quote]
The BHS is a fixed-length 48-byte header segment. It MAY be followed by Additional Header Segments (AHS), a Header-Digest, a Data Segment, and/or a Data-Digest.

[end quote]

2. However, in the PDU format diagram on p. 131 of 12-97 it is not clear that we have the option of zero, one or more Additional Header Segments. After I re-read things a few times, and apologies if I have this wrong, I think that the use of multiple Additional Header Segments is along these lines:

(a) Use one and only one Additional Header Segment for an extended CDB (SPC calls this a variable-length CDB). This extended CDB (or variable-length CDB) Additional Header Segment must immediately follow the BHS. (A suggested exact use definition of this type of Additional Header Segment coming up.)

(b) Use one and only one Additional Header Segment for an Bidirectional Expected Read-Data Length. This Bidirectional Expected Read-Data Length Additional Header Segment must immediately follow the BHS.

(c) Use of more than one Additional Header Segment is left up to the user.

How many Additional Header Segments were we expecting to be able to be used? Would this maximum length of Additional Header Segments be limited only by the TotalAHSLength (8-bit field measuring length in four-byte words or ((2**8) - 1) * 4 bytes or roughly 1 kbyte)? Can we follow an extended CDB Additional Header Segment or a Bidirectional Expected Read-Data Length Additional Header Segment by one or more user-defined Additional Header Segment?

Did I get this anywhere close to correct?

3. In one of Bob Russell's emails we have the following, which does seem to make the use of multiple Additional Header Segments a little clearer to me:

 
[quote http://www.pdl.cmu.edu/mailinglists/ips/mail/msg03784.html]
 
[view in fixed-width font on wide window]
    +------------------------+
    |     required BHS       | > fixed length of 48 bytes
    +------------------------+
    |     optional AHS 1     |\
    | - - - - - - - - - - -  | \
    |     optional AHS 2     |  \
    | - - - - - - - - - - -  |   > total length in AHS_length field in BHS
    |        . . . .         |  /
     | - - - - - - - - - - -  | /
    |     optional AHS n     |/
    +------------------------+
    | optional header digest | -- covers preceding (48 + AHS_length) bytes
    +------------------------+
    |                        |\
    |     optional data      | > total length in DATA_length field in BHS
    |                        |/
    +------------------------+
    |  optional data digest  | -- covers preceding (DATA_length) bytes
    +------------------------+

[end view in fixed-width font on wide window]
 
[end quote http://www.pdl.cmu.edu/mailinglists/ips/mail/msg03784.html]

Is it possible to add something like this picture to the format diagram on p.131. I wouldn't ask if I hadn't tripped myself up on this already.

 
4. On p. 139 of 12-97 we have the following:
 
[quote]
 
9.3.5 CDB - SCSI Command Descriptor Block
There are 16 bytes in the CDB field to accommodate the commonly used CDBs. Whenever the CDB is larger than 16 bytes, an Extended CDB AHS MUST be used to contain the CDB spillover.

 
[end quote]

I tripped again on the term "spillover". Could we perhaps change 9.3.5 to the following (thanks to Rob Elliott, see http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10620.html):

There are 16 bytes in the CDB field to accommodate bytes 0-15 of the commonly used CDBs. An Extended CDB AHS MUST be used to contain bytes 16-259 of a variable-length CDB [SPC].

5. There is no description of ExtendedCDB...+ in 9.2.2.3 Extended CDB AHS

I guess we would be repeating 9.3.5 if we defined ExtendedCDB as "bytes 16-259 of a variable-length CDB", but perhaps that is not a bad thing?

Aloha
 
Mike Smith
CTO, iReady

--=_alternative 0081E504C2256BD4_=-- From owner-ips@ece.cmu.edu Mon Jun 10 21:11:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00585 for ; Mon, 10 Jun 2002 21:11:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5B0SV622546 for ips-outgoing; Mon, 10 Jun 2002 20:28:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g5B0STw22542 for ; Mon, 10 Jun 2002 20:28:29 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g5B0SNp26963 for ; Mon, 10 Jun 2002 20:28:23 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g5B0SMc26945; Mon, 10 Jun 2002 20:28:22 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g5B0SKb15785; Mon, 10 Jun 2002 20:28:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15621.17446.323000.879391@gargle.gargle.HOWL> Date: Mon, 10 Jun 2002 20:28:22 -0400 From: Paul Koning To: wrstuden@wasabisystems.com Cc: pat_thaler@agilent.com, ksandars@eurologic.com, bmastors@allocity.com, ips@ece.cmu.edu Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys References: <1BEBA5E8600DD4119A50009027AF54A00C5E3E67@axcs04.cos.agilent.com> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 10 June 2002) by Bill Studenmund: >... 2) (and this is the bigger question) What do we do about bugs we find > *after* we get to RFC stage? > > Yes, we fix them in the next version. But how quickly are we going to get > that version out? > > Are we going to crank RFCs out as fast as Julian can make I-D drafts now? > I doubt it. If we were, then I think saying, "Update to the next version," > is a reasonable approach. > > I expect iSCSI 2 (or 1.1) will be on the order of a year or more out from > iSCSI. What does everyone else think? If the spec is as good as it should be, that's a fine time frame. But if significant interop issues are found soon after RFC, then 1.1 will have to happen a whole lot sooner. paul From owner-ips@ece.cmu.edu Mon Jun 10 21:13:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00601 for ; Mon, 10 Jun 2002 21:12:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5B0s6r23557 for ips-outgoing; Mon, 10 Jun 2002 20:54:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5B0s5w23552 for ; Mon, 10 Jun 2002 20:54:05 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 64F5C30706; Mon, 10 Jun 2002 20:54:04 -0400 (EDT) Date: Mon, 10 Jun 2002 17:51:57 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Paul Koning Cc: , , , Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys In-Reply-To: <15621.17446.323000.879391@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Mon, 10 Jun 2002, Paul Koning wrote: > Excerpt of message (sent 10 June 2002) by Bill Studenmund: > > I expect iSCSI 2 (or 1.1) will be on the order of a year or more out from > > iSCSI. What does everyone else think? > > If the spec is as good as it should be, that's a fine time frame. But > if significant interop issues are found soon after RFC, then 1.1 will > have to happen a whole lot sooner. What happens if we're somewhere inbetween? Or what if we find an issue where 80% of the implementations all chose the same way? I'm trying to scope out the shades of gray we might run into. Take care, Bill From owner-ips@ece.cmu.edu Mon Jun 10 22:18:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01944 for ; Mon, 10 Jun 2002 22:18:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5B1Sjn25173 for ips-outgoing; Mon, 10 Jun 2002 21:28:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5B1Shw25168 for ; Mon, 10 Jun 2002 21:28:43 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 21:28:42 -0400 Message-ID: From: Eddy Quicksall To: Julian Satran Cc: ips@ece.cmu.edu, pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength Date: Mon, 10 Jun 2002 21:28:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C210E7.522D5E70" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C210E7.522D5E70 Content-Type: text/plain; charset="iso-8859-1" How about if we say that an initiator must not change the MaxPDUDataSize unless it first idles the commands (at least the ones with the R bit) or if ErrorRecoveryLevel==0? That would simplify target code greatly and would meet the design goals; and since it should be rare to change it, it would be of little impact to idle the commands for a split second. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, June 10, 2002 8:06 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu; pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength I said only that when you change length you can ask for all PDUs after the ack! (no need to keep a tall - the old offsets are good up to the hole). Julo Eddy Quicksall 06/11/2002 12:32 AM Please respond to Eddy Quicksall To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength Julian, Another problem here is that the target has to calculate the offset from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 means starting DataSN=4, send all the data for that sequence. I think it would be a performance hit and waist of memory to keep a tally of all PDU sizes just for an occasional SNACK. It's not that it can't be done ... it is more that it is messy and I think there is a solution that will satisfy the design requirements but keep the software simpler. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, June 08, 2002 10:16 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength That is not completely accurate. The only problem is when PDU size decreases and then SNACK must be for all data. Target can also keep a mapping of numbers/to offsets (the list should be small and if it gets long ask for ack (A-bit). Julo Eddy Quicksall Sent by: owner-ips@ece.cmu.edu 06/08/2002 10:54 PM Please respond to Eddy Quicksall To: pat_thaler@agilent.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Thanks, As a target, I won't be able to let it change until all of the outstanding commands are finished (running with ErrorRecoveryLevel>=1). This is because I must use the PDU size to compute the offset from a SNACK's BegRun/RunLength. So, I plan to not give the text response for a MaxPDURecvDataLength in FFP until I get back an ExpStatSN == next StatSN. This will cause a delay of unknown time before the PDU size can actually change ... do you see any problem with this? Eddy -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Friday, June 07, 2002 1:13 PM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Eddy, If one uses a message sync and steering that relys on the transport segments carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path MTU changes one would want to change the PDU data length to fit the new path MTU. Pat -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Wednesday, June 05, 2002 12:24 PM To: ips@ece.cmu.edu Subject: iSCSI: changing MaxPDUDataLength Does anybody know a case where it is necessary to support a new PDU data length during full feature phase? Eddy mailto: Eddy_Quicksall@iVivity.com ------_=_NextPart_001_01C210E7.522D5E70 Content-Type: text/html; charset="iso-8859-1"

How about if we say that an initiator must not change the MaxPDUDataSize unless it first idles the commands (at least the ones with the R bit) or if ErrorRecoveryLevel==0?
 
That would simplify target code greatly and would meet the design goals; and since it should be rare to change it, it would be of little impact to idle the commands for a split second.
 
 
Eddy
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Monday, June 10, 2002 8:06 PM
To: Eddy Quicksall
Cc: ips@ece.cmu.edu; pat_thaler@agilent.com
Subject: RE: iSCSI: changing MaxPDUDataLength


I said only that when you change length you can ask for all PDUs after the ack! (no need to keep a tall - the old offsets are good up to the hole).

Julo


Eddy Quicksall <eddy_quicksall@ivivity.com>

06/11/2002 12:32 AM
Please respond to Eddy Quicksall

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu, pat_thaler@agilent.com
        Subject:        RE: iSCSI: changing MaxPDUDataLength

       


Julian,
 
Another problem here is that the target has to calculate the offset from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 means starting DataSN=4, send all the data for that sequence.
 
I think it would be a performance hit and waist of memory to keep a tally of all PDU sizes just for an occasional SNACK.
 
It's not that it can't be done ... it is more that it is messy and I think there is a solution that will satisfy the design requirements but keep the software simpler.
 
Eddy
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, June 08, 2002 10:16 PM
To: Eddy Quicksall
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com
Subject: RE: iSCSI: changing MaxPDUDataLength


That is not completely accurate.
The only problem is when PDU size decreases and then SNACK must be for all data.
Target can also keep a mapping of numbers/to offsets (the list should be small and if it gets long ask for ack (A-bit).

Julo

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

06/08/2002 10:54 PM
Please respond to Eddy Quicksall

       
       To:        pat_thaler@agilent.com
       cc:        ips@ece.cmu.edu
       Subject:        RE: iSCSI: changing MaxPDUDataLength

     



Thanks,

As a target, I won't be able to let it change until all of the outstanding
commands are finished (running with ErrorRecoveryLevel>=1). This is because
I must use the PDU size to compute the offset from a SNACK's
BegRun/RunLength.

So, I plan to not give the text response for a MaxPDURecvDataLength in FFP
until I get back an ExpStatSN == next StatSN.

This will cause a delay of unknown time before the PDU size can actually
change ... do you see any problem with this?

Eddy

-----Original Message-----
From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]
Sent: Friday, June 07, 2002 1:13 PM
To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu
Subject: RE: iSCSI: changing MaxPDUDataLength


Eddy,

If one uses a message sync and steering that relys on the transport segments
carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path
MTU changes one would want to change the PDU data length to fit the new path
MTU.

Pat

-----Original Message-----
From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com]
Sent: Wednesday, June 05, 2002 12:24 PM
To: ips@ece.cmu.edu
Subject: iSCSI: changing MaxPDUDataLength


Does anybody know a case where it is necessary to support a new PDU data
length during full feature phase?

Eddy
mailto: Eddy_Quicksall@iVivity.com




------_=_NextPart_001_01C210E7.522D5E70-- From owner-ips@ece.cmu.edu Mon Jun 10 23:18:32 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03048 for ; Mon, 10 Jun 2002 23:18:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5B2Wnw27874 for ips-outgoing; Mon, 10 Jun 2002 22:32:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar2aa.compuserve.com (siaar2aa.compuserve.com [149.174.40.137]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5B2Wkw27869 for ; Mon, 10 Jun 2002 22:32:46 -0400 (EDT) Received: (from mailgate@localhost) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id WAA22173 for ips@ece.cmu.edu; Mon, 10 Jun 2002 22:32:40 -0400 (EDT) Received: from compuserve.com (chi-tgn-gvp-vty9.as.wcom.net [216.192.150.9]) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id WAA22145 for ; Mon, 10 Jun 2002 22:32:30 -0400 (EDT) Message-ID: <3D0560C0.1120B499@compuserve.com> Date: Mon, 10 Jun 2002 21:30:24 -0500 From: Ralph Weber Reply-To: roweber@acm.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IPS Reflector Subject: FCIP does not reference draft-ietf-ips-security-??.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit It has come to my attention that FCIP does not reference draft-ietf-ips-security-??.txt as was agreed in Huntington Beach. As part of the WG Last Call resolution for FCIP, the following actions are proposed to remedy this oversight. 1) Add a normative reference to draft-ietf-ips-security-??.txt 2) Give the normative reference some wording in the body text by adding a new paragraph near the beginning of Section 10 (the Security section in FCIP). The proposed wording for the new paragraph is as follows: "The ips Security document [xx] contains an expanded discussion and additional rational for the security require- ments in this section. The ips Security document also may contain requirements beyond those present in this document. However, in the event that requirements in the ips Security document conflict with requirements stated in this document, the requirements in this document SHALL prevail." Comments on these changes are welcomed within the context of the FCIP WG Last Call process (i.e., when the WG Last Call closes the FCIP draft will be revised based on the results of the discussion initiated here). Thanks. .Ralph From owner-ips@ece.cmu.edu Mon Jun 10 23:21:06 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03101 for ; Mon, 10 Jun 2002 23:21:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5B2oZl28608 for ips-outgoing; Mon, 10 Jun 2002 22:50:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5B2o5w28577 for ; Mon, 10 Jun 2002 22:50:05 -0400 (EDT) Received: from phys-hanwk16-2.ebay.sun.com ([129.149.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA18895; Mon, 10 Jun 2002 19:49:59 -0700 (PDT) Received: from Sun.COM (vpn-129-147-152-110.Central.Sun.COM [129.147.152.110]) by phys-hanwk16-2.ebay.sun.com (8.10.2+Sun/8.10.2/ENSMAIL,v2.1p1) with ESMTP id g5B2nuB14917; Mon, 10 Jun 2002 19:49:56 -0700 (PDT) Message-ID: <3D05658A.6040707@Sun.COM> Date: Mon, 10 Jun 2002 21:50:50 -0500 From: David Robinson User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Bill Studenmund CC: Paul Koning , pat_thaler@agilent.com, ksandars@eurologic.com, bmastors@allocity.com, ips@ece.cmu.edu Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bill Studenmund wrote: > On Mon, 10 Jun 2002, Paul Koning wrote: >>Excerpt of message (sent 10 June 2002) by Bill Studenmund: >> >>>I expect iSCSI 2 (or 1.1) will be on the order of a year or more out from >>>iSCSI. What does everyone else think? >>> >>If the spec is as good as it should be, that's a fine time frame. But >>if significant interop issues are found soon after RFC, then 1.1 will >>have to happen a whole lot sooner. >> > > What happens if we're somewhere inbetween? Or what if we find an issue > where 80% of the implementations all chose the same way? > > I'm trying to scope out the shades of gray we might run into. As a reminder about the IETF standards process, RFC2026. The IPS working group is driving towards "Proposed Standard" which by definition: "Implementors should treat Proposed Standards as immature specifications." The next step is "Draft Standard" where there is expectation that changes will be made between Proposed and Draft. "A Draft Standard is normally considered to be a final specification..." To move from Proposed to Draft is where two independant implementations are required and where the "80%" implementation problems are caught and fixed. The RFC we are driving towards is just the first step in a long path, there will be plenty of opportunities to fix "bugs" that are found we real implementations are built. Thus vendor specific keys are not needed, what we have today is not going to be the "Internet Standard." -David From owner-ips@ece.cmu.edu Tue Jun 11 08:12:14 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19651 for ; Tue, 11 Jun 2002 08:12:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BBPep00249 for ips-outgoing; Tue, 11 Jun 2002 07:25:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BB6Pw29507 for ; Tue, 11 Jun 2002 07:06:25 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17762; Tue, 11 Jun 2002 07:05:45 -0400 (EDT) Message-Id: <200206111105.HAA17762@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-security-13.txt Date: Tue, 11 Jun 2002 07:05:45 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Securing Block Storage Protocols over IP Author(s) : B. Aboba et al. Filename : draft-ietf-ips-security-13.txt Pages : 67 Date : 10-Jun-02 This document discusses how to secure block storage and storage discovery protocols running over IP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-security-13.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-security-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-security-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020610143005.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-security-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-security-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020610143005.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Tue Jun 11 10:16:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25442 for ; Tue, 11 Jun 2002 10:16:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BDBLx05156 for ips-outgoing; Tue, 11 Jun 2002 09:11:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BDBJw05151 for ; Tue, 11 Jun 2002 09:11:19 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5BDB67n015636; Tue, 11 Jun 2002 15:11:07 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5BDB6634648; Tue, 11 Jun 2002 15:11:06 +0200 To: Eddy Quicksall Cc: ips@ece.cmu.edu, pat_thaler@agilent.com MIME-Version: 1.0 Subject: RE: iSCSI: changing MaxPDUDataLength X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 11 Jun 2002 16:11:00 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 11/06/2002 16:11:06, Serialize complete at 11/06/2002 16:11:06 Content-Type: multipart/alternative; boundary="=_alternative 0047D7D3C2256BD5_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0047D7D3C2256BD5_= Content-Type: text/plain; charset="us-ascii" That is a fair request - we may slip in a recommendation to that effect (in chapter 11?) Julo Eddy Quicksall 06/11/2002 04:28 AM Please respond to Eddy Quicksall To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength How about if we say that an initiator must not change the MaxPDUDataSize unless it first idles the commands (at least the ones with the R bit) or if ErrorRecoveryLevel==0? That would simplify target code greatly and would meet the design goals; and since it should be rare to change it, it would be of little impact to idle the commands for a split second. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, June 10, 2002 8:06 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu; pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength I said only that when you change length you can ask for all PDUs after the ack! (no need to keep a tall - the old offsets are good up to the hole). Julo Eddy Quicksall 06/11/2002 12:32 AM Please respond to Eddy Quicksall To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength Julian, Another problem here is that the target has to calculate the offset from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 means starting DataSN=4, send all the data for that sequence. I think it would be a performance hit and waist of memory to keep a tally of all PDU sizes just for an occasional SNACK. It's not that it can't be done ... it is more that it is messy and I think there is a solution that will satisfy the design requirements but keep the software simpler. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, June 08, 2002 10:16 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength That is not completely accurate. The only problem is when PDU size decreases and then SNACK must be for all data. Target can also keep a mapping of numbers/to offsets (the list should be small and if it gets long ask for ack (A-bit). Julo Eddy Quicksall Sent by: owner-ips@ece.cmu.edu 06/08/2002 10:54 PM Please respond to Eddy Quicksall To: pat_thaler@agilent.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Thanks, As a target, I won't be able to let it change until all of the outstanding commands are finished (running with ErrorRecoveryLevel>=1). This is because I must use the PDU size to compute the offset from a SNACK's BegRun/RunLength. So, I plan to not give the text response for a MaxPDURecvDataLength in FFP until I get back an ExpStatSN == next StatSN. This will cause a delay of unknown time before the PDU size can actually change ... do you see any problem with this? Eddy -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Friday, June 07, 2002 1:13 PM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Eddy, If one uses a message sync and steering that relys on the transport segments carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path MTU changes one would want to change the PDU data length to fit the new path MTU. Pat -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Wednesday, June 05, 2002 12:24 PM To: ips@ece.cmu.edu Subject: iSCSI: changing MaxPDUDataLength Does anybody know a case where it is necessary to support a new PDU data length during full feature phase? Eddy mailto: Eddy_Quicksall@iVivity.com --=_alternative 0047D7D3C2256BD5_= Content-Type: text/html; charset="us-ascii"
That is a fair request - we may slip in a recommendation to that effect (in chapter 11?)

Julo


Eddy Quicksall <eddy_quicksall@ivivity.com>

06/11/2002 04:28 AM
Please respond to Eddy Quicksall

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu, pat_thaler@agilent.com
        Subject:        RE: iSCSI: changing MaxPDUDataLength

       


How about if we say that an initiator must not change the MaxPDUDataSize unless it first idles the commands (at least the ones with the R bit) or if ErrorRecoveryLevel==0?
 
That would simplify target code greatly and would meet the design goals; and since it should be rare to change it, it would be of little impact to idle the commands for a split second.
 
 
Eddy
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Monday, June 10, 2002 8:06 PM
To: Eddy Quicksall
Cc: ips@ece.cmu.edu; pat_thaler@agilent.com
Subject: RE: iSCSI: changing MaxPDUDataLength

I said only that when you change length you can ask for all PDUs after the ack! (no need to keep a tall - the old offsets are good up to the hole).

Julo

Eddy Quicksall <eddy_quicksall@ivivity.com>

06/11/2002 12:32 AM
Please respond to Eddy Quicksall

       
       To:        Julian Satran/Haifa/IBM@IBMIL
       cc:        ips@ece.cmu.edu, pat_thaler@agilent.com
       Subject:        RE: iSCSI: changing MaxPDUDataLength

     



Julian,
 
Another problem here is that the target has to calculate the offset from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 means starting DataSN=4, send all the data for that sequence.
 
I think it would be a performance hit and waist of memory to keep a tally of all PDU sizes just for an occasional SNACK.
 
It's not that it can't be done ... it is more that it is messy and I think there is a solution that will satisfy the design requirements but keep the software simpler.
 
Eddy
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, June 08, 2002 10:16 PM
To: Eddy Quicksall
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com
Subject: RE: iSCSI: changing MaxPDUDataLength


That is not completely accurate.
The only problem is when PDU size decreases and then SNACK must be for all data.
Target can also keep a mapping of numbers/to offsets (the list should be small and if it gets long ask for ack (A-bit).

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

06/08/2002 10:54 PM
Please respond to Eddy Quicksall

       
      To:        pat_thaler@agilent.com
      cc:        ips@ece.cmu.edu
      Subject:        RE: iSCSI: changing MaxPDUDataLength

     




Thanks,

As a target, I won't be able to let it change until all of the outstanding
commands are finished (running with ErrorRecoveryLevel>=1). This is because
I must use the PDU size to compute the offset from a SNACK's
BegRun/RunLength.

So, I plan to not give the text response for a MaxPDURecvDataLength in FFP
until I get back an ExpStatSN == next StatSN.

This will cause a delay of unknown time before the PDU size can actually
change ... do you see any problem with this?

Eddy

-----Original Message-----
From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]
Sent: Friday, June 07, 2002 1:13 PM
To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu
Subject: RE: iSCSI: changing MaxPDUDataLength


Eddy,

If one uses a message sync and steering that relys on the transport segments
carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path
MTU changes one would want to change the PDU data length to fit the new path
MTU.

Pat

-----Original Message-----
From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com]
Sent: Wednesday, June 05, 2002 12:24 PM
To: ips@ece.cmu.edu
Subject: iSCSI: changing MaxPDUDataLength


Does anybody know a case where it is necessary to support a new PDU data
length during full feature phase?

Eddy
mailto: Eddy_Quicksall@iVivity.com

--=_alternative 0047D7D3C2256BD5_=-- From owner-ips@ece.cmu.edu Tue Jun 11 11:41:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29567 for ; Tue, 11 Jun 2002 11:41:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BEuSo11409 for ips-outgoing; Tue, 11 Jun 2002 10:56:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BEuPw11403 for ; Tue, 11 Jun 2002 10:56:26 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 10:56:25 -0400 Message-ID: From: Eddy Quicksall To: Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Date: Tue, 11 Jun 2002 10:56:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I think it should be a requirement because if it is not, all target code will have to have the messy code. Or, we could say that if it is not idle commands, then the target may reject it. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, June 11, 2002 9:11 AM To: Eddy Quicksall Cc: ips@ece.cmu.edu; pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength That is a fair request - we may slip in a recommendation to that effect (in chapter 11?) Julo Eddy Quicksall 06/11/2002 04:28 AM Please respond to Eddy Quicksall To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength How about if we say that an initiator must not change the MaxPDUDataSize unless it first idles the commands (at least the ones with the R bit) or if ErrorRecoveryLevel==0? That would simplify target code greatly and would meet the design goals; and since it should be rare to change it, it would be of little impact to idle the commands for a split second. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, June 10, 2002 8:06 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu; pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength I said only that when you change length you can ask for all PDUs after the ack! (no need to keep a tall - the old offsets are good up to the hole). Julo Eddy Quicksall 06/11/2002 12:32 AM Please respond to Eddy Quicksall To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength Julian, Another problem here is that the target has to calculate the offset from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 means starting DataSN=4, send all the data for that sequence. I think it would be a performance hit and waist of memory to keep a tally of all PDU sizes just for an occasional SNACK. It's not that it can't be done ... it is more that it is messy and I think there is a solution that will satisfy the design requirements but keep the software simpler. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, June 08, 2002 10:16 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength That is not completely accurate. The only problem is when PDU size decreases and then SNACK must be for all data. Target can also keep a mapping of numbers/to offsets (the list should be small and if it gets long ask for ack (A-bit). Julo Eddy Quicksall Sent by: owner-ips@ece.cmu.edu 06/08/2002 10:54 PM Please respond to Eddy Quicksall To: pat_thaler@agilent.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Thanks, As a target, I won't be able to let it change until all of the outstanding commands are finished (running with ErrorRecoveryLevel>=1). This is because I must use the PDU size to compute the offset from a SNACK's BegRun/RunLength. So, I plan to not give the text response for a MaxPDURecvDataLength in FFP until I get back an ExpStatSN == next StatSN. This will cause a delay of unknown time before the PDU size can actually change ... do you see any problem with this? Eddy -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Friday, June 07, 2002 1:13 PM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Eddy, If one uses a message sync and steering that relys on the transport segments carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path MTU changes one would want to change the PDU data length to fit the new path MTU. Pat -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Wednesday, June 05, 2002 12:24 PM To: ips@ece.cmu.edu Subject: iSCSI: changing MaxPDUDataLength Does anybody know a case where it is necessary to support a new PDU data length during full feature phase? Eddy mailto: Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Tue Jun 11 11:50:49 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00060 for ; Tue, 11 Jun 2002 11:50:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BEk7u10702 for ips-outgoing; Tue, 11 Jun 2002 10:46:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BEk5w10695 for ; Tue, 11 Jun 2002 10:46:05 -0400 (EDT) Received: from london ([192.168.1.47]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id HAA20198; Tue, 11 Jun 2002 07:44:28 -0700 (PDT) From: "Rod Harrison" To: "Julian Satran" , "Eddy Quicksall" Cc: , Subject: RE: iSCSI: changing MaxPDUDataLength Date: Tue, 11 Jun 2002 09:46:44 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I don't see an issue with this, although I would prefer to see it mandated rather than recommended. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Tuesday, June 11, 2002 8:11 AM To: Eddy Quicksall Cc: ips@ece.cmu.edu; pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength That is a fair request - we may slip in a recommendation to that effect (in chapter 11?) Julo Eddy Quicksall 06/11/2002 04:28 AM Please respond to Eddy Quicksall To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength How about if we say that an initiator must not change the MaxPDUDataSize unless it first idles the commands (at least the ones with the R bit) or if ErrorRecoveryLevel==0? That would simplify target code greatly and would meet the design goals; and since it should be rare to change it, it would be of little impact to idle the commands for a split second. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, June 10, 2002 8:06 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu; pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength I said only that when you change length you can ask for all PDUs after the ack! (no need to keep a tall - the old offsets are good up to the hole). Julo Eddy Quicksall 06/11/2002 12:32 AM Please respond to Eddy Quicksall To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength Julian, Another problem here is that the target has to calculate the offset from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 means starting DataSN=4, send all the data for that sequence. I think it would be a performance hit and waist of memory to keep a tally of all PDU sizes just for an occasional SNACK. It's not that it can't be done ... it is more that it is messy and I think there is a solution that will satisfy the design requirements but keep the software simpler. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, June 08, 2002 10:16 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength That is not completely accurate. The only problem is when PDU size decreases and then SNACK must be for all data. Target can also keep a mapping of numbers/to offsets (the list should be small and if it gets long ask for ack (A-bit). Julo Eddy Quicksall Sent by: owner-ips@ece.cmu.edu 06/08/2002 10:54 PM Please respond to Eddy Quicksall To: pat_thaler@agilent.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Thanks, As a target, I won't be able to let it change until all of the outstanding commands are finished (running with ErrorRecoveryLevel>=1). This is because I must use the PDU size to compute the offset from a SNACK's BegRun/RunLength. So, I plan to not give the text response for a MaxPDURecvDataLength in FFP until I get back an ExpStatSN == next StatSN. This will cause a delay of unknown time before the PDU size can actually change ... do you see any problem with this? Eddy -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Friday, June 07, 2002 1:13 PM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Eddy, If one uses a message sync and steering that relys on the transport segments carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path MTU changes one would want to change the PDU data length to fit the new path MTU. Pat -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Wednesday, June 05, 2002 12:24 PM To: ips@ece.cmu.edu Subject: iSCSI: changing MaxPDUDataLength Does anybody know a case where it is necessary to support a new PDU data length during full feature phase? Eddy mailto: Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Tue Jun 11 12:42:27 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02394 for ; Tue, 11 Jun 2002 12:42:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BFbPR13965 for ips-outgoing; Tue, 11 Jun 2002 11:37:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BFbNw13959 for ; Tue, 11 Jun 2002 11:37:23 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5BFbFYj034840 for ; Tue, 11 Jun 2002 17:37:15 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5BFbFp41464 for ; Tue, 11 Jun 2002 17:37:15 +0200 Importance: High Subject: RE: iSCSI: changing MaxPDUDataLength To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Tue, 11 Jun 2002 18:34:08 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 11/06/2002 18:37:15 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I suggest the following text in 11.13 A change of MaxRecvDataSegmentLength by an initiator or target becomes effective after all commands preceding the negotiation end-ing request have been processed by the target and their status is acknowledged. I also realized that we don't have "negotiation prompt" from the target. I am not sure that we need one. If some of you think we need we may want one additional code in the Asynch Message. Please comment TODAY. Julo ----- Forwarded by Julian Satran/Haifa/IBM on 06/11/2002 06:29 PM ----- Julian Satran To: Eddy Quicksall 06/11/2002 04:04 cc: ips@ece.cmu.edu, pat_thaler@agilent.com PM From: Julian Satran/Haifa/IBM@IBMIL Subject: RE: iSCSI: changing MaxPDUDataLength(Document link: Julian Satran - Mail) That is a fair request - we may slip in a recommendation to that effect (in chapter 11?) Julo Eddy Quicksall cc: ips@ece.cmu.edu, pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength 06/11/2002 04:28 AM Please respond to Eddy Quicksall How about if we say that an initiator must not change the MaxPDUDataSize unless it first idles the commands (at least the ones with the R bit) or if ErrorRecoveryLevel==0? That would simplify target code greatly and would meet the design goals; and since it should be rare to change it, it would be of little impact to idle the commands for a split second. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, June 10, 2002 8:06 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu; pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength I said only that when you change length you can ask for all PDUs after the ack! (no need to keep a tall - the old offsets are good up to the hole). Julo Eddy Quicksall To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, 06/11/2002 12:32 AM pat_thaler@agilent.com Please respond to Eddy Quicksall Subject: RE: iSCSI: changing MaxPDUDataLength Julian, Another problem here is that the target has to calculate the offset from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 means starting DataSN=4, send all the data for that sequence. I think it would be a performance hit and waist of memory to keep a tally of all PDU sizes just for an occasional SNACK. It's not that it can't be done ... it is more that it is messy and I think there is a solution that will satisfy the design requirements but keep the software simpler. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, June 08, 2002 10:16 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength That is not completely accurate. The only problem is when PDU size decreases and then SNACK must be for all data. Target can also keep a mapping of numbers/to offsets (the list should be small and if it gets long ask for ack (A-bit). Julo Eddy Quicksall To: Sent by: owner-ips@ece.cmu.edu pat_thaler@agilent.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: 06/08/2002 10:54 PM changing MaxPDUDataLength Please respond to Eddy Quicksall Thanks, As a target, I won't be able to let it change until all of the outstanding commands are finished (running with ErrorRecoveryLevel>=1). This is because I must use the PDU size to compute the offset from a SNACK's BegRun/RunLength. So, I plan to not give the text response for a MaxPDURecvDataLength in FFP until I get back an ExpStatSN == next StatSN. This will cause a delay of unknown time before the PDU size can actually change ... do you see any problem with this? Eddy -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Friday, June 07, 2002 1:13 PM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Eddy, If one uses a message sync and steering that relys on the transport segments carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path MTU changes one would want to change the PDU data length to fit the new path MTU. Pat -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Wednesday, June 05, 2002 12:24 PM To: ips@ece.cmu.edu Subject: iSCSI: changing MaxPDUDataLength Does anybody know a case where it is necessary to support a new PDU data length during full feature phase? Eddy mailto: Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Tue Jun 11 14:39:55 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07608 for ; Tue, 11 Jun 2002 14:39:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BIMMw24422 for ips-outgoing; Tue, 11 Jun 2002 14:22:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BIMJw24416 for ; Tue, 11 Jun 2002 14:22:19 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 83FAD3070B; Tue, 11 Jun 2002 14:22:17 -0400 (EDT) Date: Tue, 11 Jun 2002 11:20:09 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: David Robinson Cc: Paul Koning , , , , Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys In-Reply-To: <3D05658A.6040707@Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Mon, 10 Jun 2002, David Robinson wrote: > > What happens if we're somewhere inbetween? Or what if we find an issue > > where 80% of the implementations all chose the same way? > > > > I'm trying to scope out the shades of gray we might run into. > > > As a reminder about the IETF standards process, RFC2026. The IPS > working group is driving towards "Proposed Standard" which > by definition: "Implementors should treat Proposed Standards as > immature specifications." The next step is "Draft Standard" > where there is expectation that changes will be made between > Proposed and Draft. "A Draft Standard is normally considered > to be a final specification..." > > To move from Proposed to Draft is where two independant implementations > are required and where the "80%" implementation problems are caught > and fixed. > > The RFC we are driving towards is just the first step in a long > path, there will be plenty of opportunities to fix "bugs" that > are found we real implementations are built. Thus vendor specific > keys are not needed, what we have today is not going to be > the "Internet Standard." So what do we tell our customers? Our paying, cranky customers? That they are part of the great iSCSI experiment? Or worse yet, what are you going to tell your sales folks when a big sale doesn't go because of some interop quirk? Try again in 6 months when the equipment has already been bought? :-) I'm not saying we shouldn't work (hard) to fix all the problems we can. I'm saying that a policy of, "You loose," to the customers who run into an interop problem is impolite. :-| Take care, Bill From owner-ips@ece.cmu.edu Tue Jun 11 14:43:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07862 for ; Tue, 11 Jun 2002 14:43:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BHuCL22613 for ips-outgoing; Tue, 11 Jun 2002 13:56:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BHuBw22609 for ; Tue, 11 Jun 2002 13:56:11 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 13:56:10 -0400 Message-ID: From: Eddy Quicksall To: Julian Satran , ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Date: Tue, 11 Jun 2002 13:56:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I see a case where the target could still end up sending PDU's of different lengths for a given command. It would be much safer if the initiator was required to idle the commands before sending the new MaxRecvDataSegmentLength. That way there is nothing for the target to do other than change the size. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, June 11, 2002 11:34 AM To: ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Importance: High I suggest the following text in 11.13 A change of MaxRecvDataSegmentLength by an initiator or target becomes effective after all commands preceding the negotiation end-ing request have been processed by the target and their status is acknowledged. I also realized that we don't have "negotiation prompt" from the target. I am not sure that we need one. If some of you think we need we may want one additional code in the Asynch Message. Please comment TODAY. Julo ----- Forwarded by Julian Satran/Haifa/IBM on 06/11/2002 06:29 PM ----- Julian Satran To: Eddy Quicksall 06/11/2002 04:04 cc: ips@ece.cmu.edu, pat_thaler@agilent.com PM From: Julian Satran/Haifa/IBM@IBMIL Subject: RE: iSCSI: changing MaxPDUDataLength(Document link: Julian Satran - Mail) That is a fair request - we may slip in a recommendation to that effect (in chapter 11?) Julo Eddy Quicksall cc: ips@ece.cmu.edu, pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength 06/11/2002 04:28 AM Please respond to Eddy Quicksall How about if we say that an initiator must not change the MaxPDUDataSize unless it first idles the commands (at least the ones with the R bit) or if ErrorRecoveryLevel==0? That would simplify target code greatly and would meet the design goals; and since it should be rare to change it, it would be of little impact to idle the commands for a split second. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, June 10, 2002 8:06 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu; pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength I said only that when you change length you can ask for all PDUs after the ack! (no need to keep a tall - the old offsets are good up to the hole). Julo Eddy Quicksall To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, 06/11/2002 12:32 AM pat_thaler@agilent.com Please respond to Eddy Quicksall Subject: RE: iSCSI: changing MaxPDUDataLength Julian, Another problem here is that the target has to calculate the offset from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 means starting DataSN=4, send all the data for that sequence. I think it would be a performance hit and waist of memory to keep a tally of all PDU sizes just for an occasional SNACK. It's not that it can't be done ... it is more that it is messy and I think there is a solution that will satisfy the design requirements but keep the software simpler. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, June 08, 2002 10:16 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength That is not completely accurate. The only problem is when PDU size decreases and then SNACK must be for all data. Target can also keep a mapping of numbers/to offsets (the list should be small and if it gets long ask for ack (A-bit). Julo Eddy Quicksall To: Sent by: owner-ips@ece.cmu.edu pat_thaler@agilent.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: 06/08/2002 10:54 PM changing MaxPDUDataLength Please respond to Eddy Quicksall Thanks, As a target, I won't be able to let it change until all of the outstanding commands are finished (running with ErrorRecoveryLevel>=1). This is because I must use the PDU size to compute the offset from a SNACK's BegRun/RunLength. So, I plan to not give the text response for a MaxPDURecvDataLength in FFP until I get back an ExpStatSN == next StatSN. This will cause a delay of unknown time before the PDU size can actually change ... do you see any problem with this? Eddy -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Friday, June 07, 2002 1:13 PM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Eddy, If one uses a message sync and steering that relys on the transport segments carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path MTU changes one would want to change the PDU data length to fit the new path MTU. Pat -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Wednesday, June 05, 2002 12:24 PM To: ips@ece.cmu.edu Subject: iSCSI: changing MaxPDUDataLength Does anybody know a case where it is necessary to support a new PDU data length during full feature phase? Eddy mailto: Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Tue Jun 11 15:39:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09432 for ; Tue, 11 Jun 2002 15:39:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BIshK26554 for ips-outgoing; Tue, 11 Jun 2002 14:54:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BIsfw26550 for ; Tue, 11 Jun 2002 14:54:41 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel10.hp.com (Postfix) with ESMTP id BE02BC00311; Tue, 11 Jun 2002 11:54:35 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id LAA08672; Tue, 11 Jun 2002 11:54:30 -0700 (PDT) Message-ID: <3D064959.660D58EC@cup.hp.com> Date: Tue, 11 Jun 2002 12:02:49 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: Bill Studenmund Cc: ips@ece.cmu.edu Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I don't see why this thread is going forever. There are other scsi transports that deal with these types of issues without having to define scsi transport protocol keys to indicate vendor_id, product_id and product_rev. You can do one of the following : a) Parse out the DNS name of the target device from the exchanged TargetName key, if you're an initiator. Similarly, parse out the DNS name of the initiator from the exchanged InitiatorName key, if you're a target. Use the DNS name as an indication of which device you're speaking to and add your device specific tweaks based on this. If the InitiatorName or TargetName is in EUI-64 format, you can obtain the vendor_id information from the upper 3 bytes of the EUI-64 name. b) Send INQUIRY to LUN 0 to determine the vendor_id, product_id and product_revisison_level of the device. Use this data to perform any device specific tweaks in your software/firmware. c) Provide out-of-band static configuration mechanisms in your initiator or target to assign a vendor specific identity to 1 or more initiators or targets. This allows the target configuration personnel to configure the device appropriately for the initiators it is speaking to. I don't see any need to be defining iscsi login keys to duplicate the vendor_id, product_id information. - Santosh Bill Studenmund wrote: > > On Mon, 10 Jun 2002, David Robinson wrote: > > > > What happens if we're somewhere inbetween? Or what if we find an issue > > > where 80% of the implementations all chose the same way? > > > > > > I'm trying to scope out the shades of gray we might run into. > > > > > > As a reminder about the IETF standards process, RFC2026. The IPS > > working group is driving towards "Proposed Standard" which > > by definition: "Implementors should treat Proposed Standards as > > immature specifications." The next step is "Draft Standard" > > where there is expectation that changes will be made between > > Proposed and Draft. "A Draft Standard is normally considered > > to be a final specification..." > > > > To move from Proposed to Draft is where two independant implementations > > are required and where the "80%" implementation problems are caught > > and fixed. > > > > The RFC we are driving towards is just the first step in a long > > path, there will be plenty of opportunities to fix "bugs" that > > are found we real implementations are built. Thus vendor specific > > keys are not needed, what we have today is not going to be > > the "Internet Standard." > > So what do we tell our customers? Our paying, cranky customers? That they > are part of the great iSCSI experiment? Or worse yet, what are you going > to tell your sales folks when a big sale doesn't go because of some > interop quirk? Try again in 6 months when the equipment has already been > bought? :-) > > I'm not saying we shouldn't work (hard) to fix all the problems we can. > > I'm saying that a policy of, "You loose," to the customers who run into an > interop problem is impolite. :-| > > Take care, > > Bill -- The world is so fast that there are days when the person who says it can't be done is interrupted by the person who is doing it. ~ Anon From owner-ips@ece.cmu.edu Tue Jun 11 16:28:23 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11450 for ; Tue, 11 Jun 2002 16:28:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BJpwg00077 for ips-outgoing; Tue, 11 Jun 2002 15:51:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BJpvw00073 for ; Tue, 11 Jun 2002 15:51:57 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 83F6630706; Tue, 11 Jun 2002 15:51:56 -0400 (EDT) Date: Tue, 11 Jun 2002 12:49:49 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Santosh Rao Cc: Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys In-Reply-To: <3D064959.660D58EC@cup.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 11 Jun 2002, Santosh Rao wrote: > I don't see why this thread is going forever. There are other scsi > transports that deal with these types of issues without having to define > scsi transport protocol keys to indicate vendor_id, product_id and > product_rev. You can do one of the following : > > a) Parse out the DNS name of the target device from the exchanged > TargetName key, if you're an initiator. Similarly, parse out the DNS > name of the initiator from the exchanged InitiatorName key, if you're a > target. Use the DNS name as an indication of which device you're > speaking to and add your device specific tweaks based on this. That we can do. But that means that the system adminsitrator or a "smart agent" has to correlate the info. And, if a device moves, it has to get involved again to reconfigure. It could be that this won't be a problem, but it could also be a hassle. > If the InitiatorName or TargetName is in EUI-64 format, you can obtain > the vendor_id information from the upper 3 bytes of the EUI-64 name. That only gets you one of the three keys. :-) The product and revisions are the ones that are more important if we are bug-compensating. :-) > b) Send INQUIRY to LUN 0 to determine the vendor_id, product_id and > product_revisison_level of the device. Use this data to perform any > device specific tweaks in your software/firmware. That assumes that the iscsi device is the same as the scsi device. In the case of an iscsi->FC or iscsi->Parallel SCSI gateway, that's not going to be the case. > c) Provide out-of-band static configuration mechanisms in your initiator > or target to assign a vendor specific identity to 1 or more initiators > or targets. This allows the target configuration personnel to configure > the device appropriately for the initiators it is speaking to. That, like the first option above, involves correlating a lot of info, and keeping it up to date. Sounds like turning a protocol mess into a management mess. > I don't see any need to be defining iscsi login keys to duplicate the > vendor_id, product_id information. Well, that's your opinion. Some of us feel that what you describe above is a hassle we'd rather spare our customers. Especially since happy customers spend more. :-) Take care, Bill From owner-ips@ece.cmu.edu Tue Jun 11 16:28:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11468 for ; Tue, 11 Jun 2002 16:28:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BJoKv29926 for ips-outgoing; Tue, 11 Jun 2002 15:50:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BJoHw29921 for ; Tue, 11 Jun 2002 15:50:17 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel6.hp.com (Postfix) with ESMTP id 4586B8BD; Tue, 11 Jun 2002 15:50:11 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id MAA07098; Tue, 11 Jun 2002 12:51:59 -0700 (PDT) Message-ID: <002601c21181$31bc69c0$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: , "Julian Satran" References: Subject: Re: iSCSI: changing MaxPDUDataLength Date: Tue, 11 Jun 2002 12:50:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I also realized that we don't have "negotiation prompt" from the target. > I am not sure that we need one. I am not sure about it either. My preference is not to add this. It appears to me that a target does have the option of dropping the connection today if it can't work with non-ULPDU-contained segments for too long. I suspect that the target would do the same if (we introduced the "negotiation prompt" and) the initiator doesn't/couldn't honor the "negotiation prompt". Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Julian Satran" To: Sent: Tuesday, June 11, 2002 8:34 AM Subject: RE: iSCSI: changing MaxPDUDataLength > I suggest the following text in 11.13 > > A change of MaxRecvDataSegmentLength by an initiator or target > becomes effective after all commands preceding the negotiation > end-ing request have been processed by the target and their status > is acknowledged. > > I also realized that we don't have "negotiation prompt" from the target. > I am not sure that we need one. > If some of you think we need we may want one additional code in the Asynch > Message. > Please comment TODAY. > > Julo > ----- Forwarded by Julian Satran/Haifa/IBM on 06/11/2002 06:29 PM ----- > > Julian Satran > To: Eddy Quicksall > 06/11/2002 04:04 cc: ips@ece.cmu.edu, pat_thaler@agilent.com > PM From: Julian Satran/Haifa/IBM@IBMIL > Subject: RE: iSCSI: changing MaxPDUDataLength(Document link: Julian Satran - Mail) > > > > > > > > > > That is a fair request - we may slip in a recommendation to that effect (in > chapter 11?) > > Julo > > > > Eddy Quicksall > vivity.com> cc: ips@ece.cmu.edu, pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > 06/11/2002 04:28 > AM > Please respond to > Eddy Quicksall > > > > > > How about if we say that an initiator must not change the MaxPDUDataSize > unless it first idles the commands (at least the ones with the R bit) or if > ErrorRecoveryLevel==0? > > That would simplify target code greatly and would meet the design goals; > and since it should be rare to change it, it would be of little impact to > idle the commands for a split second. > > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Monday, June 10, 2002 8:06 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > I said only that when you change length you can ask for all PDUs > after the ack! (no need to keep a tall - the old offsets are good up > to the hole). > > Julo > > > Eddy Quicksall > To: Julian > Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu, > 06/11/2002 12:32 AM pat_thaler@agilent.com > Please respond to Eddy Quicksall Subject: RE: iSCSI: > changing MaxPDUDataLength > > > > > > > > Julian, > > Another problem here is that the target has to calculate the offset > from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and > RunLngth=0 means starting DataSN=4, send all the data for that > sequence. > > I think it would be a performance hit and waist of memory to keep a > tally of all PDU sizes just for an occasional SNACK. > > It's not that it can't be done ... it is more that it is messy and I > think there is a solution that will satisfy the design requirements > but keep the software simpler. > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Saturday, June 08, 2002 10:16 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > That is not completely accurate. > The only problem is when PDU size decreases and then SNACK must be > for all data. > Target can also keep a mapping of numbers/to offsets (the list should > be small and if it gets long ask for ack (A-bit). > > Julo > > Eddy Quicksall > To: > Sent by: owner-ips@ece.cmu.edu pat_thaler@agilent.com > cc: ips@ece.cmu.edu > Subject: RE: iSCSI: > 06/08/2002 10:54 PM changing MaxPDUDataLength > Please respond to Eddy Quicksall > > > > > > > > Thanks, > > As a target, I won't be able to let it change until all of the > outstanding > commands are finished (running with ErrorRecoveryLevel>=1). This is > because > I must use the PDU size to compute the offset from a SNACK's > BegRun/RunLength. > > So, I plan to not give the text response for a MaxPDURecvDataLength > in FFP > until I get back an ExpStatSN == next StatSN. > > This will cause a delay of unknown time before the PDU size can > actually > change ... do you see any problem with this? > > Eddy > > -----Original Message----- > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > Sent: Friday, June 07, 2002 1:13 PM > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > Subject: RE: iSCSI: changing MaxPDUDataLength > > > Eddy, > > If one uses a message sync and steering that relys on the transport > segments > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the > path > MTU changes one would want to change the PDU data length to fit the > new path > MTU. > > Pat > > -----Original Message----- > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > Sent: Wednesday, June 05, 2002 12:24 PM > To: ips@ece.cmu.edu > Subject: iSCSI: changing MaxPDUDataLength > > > Does anybody know a case where it is necessary to support a new PDU > data > length during full feature phase? > > Eddy > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > > > From owner-ips@ece.cmu.edu Tue Jun 11 16:31:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11702 for ; Tue, 11 Jun 2002 16:31:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BJZdf29042 for ips-outgoing; Tue, 11 Jun 2002 15:35:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BJZbw29038 for ; Tue, 11 Jun 2002 15:35:37 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel11.hp.com (Postfix) with ESMTP id 8F2A46007A9; Tue, 11 Jun 2002 12:35:29 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id MAA04831; Tue, 11 Jun 2002 12:37:17 -0700 (PDT) Message-ID: <002001c2117f$24527e20$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Eddy Quicksall" , "Julian Satran" Cc: References: Subject: Re: iSCSI: changing MaxPDUDataLength Date: Tue, 11 Jun 2002 12:35:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Eddy, I am not clear on why you think the target code becomes messy on a PDU size change. The last para in section 4.4 states the following - "Parameters negotiated by a text exchange negotiation sequence become effective only after the negotiation sequence is completed." Since the target gets to complete a text negotiation with a Text Response PDU, it can time the applicability of a changed MaxRecvDataSegmentLength. Requiring that an initiator must idle the connection before changing this parameter, IMHO, is counter-productive when there's a dynamic PMTU degradation in the presence of long-running commands (writes in particular). Once the initiator starts the renegotiation, target would ideally want to quickly renegotiate its receive size as well to receive ULPDU-contained segments. In short, seems to me that the draft is saying what you would like. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Eddy Quicksall" To: "Julian Satran" Cc: Sent: Tuesday, June 11, 2002 7:56 AM Subject: RE: iSCSI: changing MaxPDUDataLength > I think it should be a requirement because if it is not, all target code > will have to have the messy code. Or, we could say that if it is not idle > commands, then the target may reject it. > > Eddy > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Tuesday, June 11, 2002 9:11 AM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > That is a fair request - we may slip in a recommendation to that effect (in > chapter 11?) > > Julo > > > > Eddy Quicksall > > > 06/11/2002 04:28 AM > Please respond to Eddy Quicksall > > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > How about if we say that an initiator must not change the MaxPDUDataSize > unless it first idles the commands (at least the ones with the R bit) or if > ErrorRecoveryLevel==0? > > That would simplify target code greatly and would meet the design goals; and > since it should be rare to change it, it would be of little impact to idle > the commands for a split second. > > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Monday, June 10, 2002 8:06 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > I said only that when you change length you can ask for all PDUs after the > ack! (no need to keep a tall - the old offsets are good up to the hole). > > Julo > > > Eddy Quicksall > > > 06/11/2002 12:32 AM > Please respond to Eddy Quicksall > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > Julian, > > Another problem here is that the target has to calculate the offset from the > DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 > means starting DataSN=4, send all the data for that sequence. > > I think it would be a performance hit and waist of memory to keep a tally of > all PDU sizes just for an occasional SNACK. > > It's not that it can't be done ... it is more that it is messy and I think > there is a solution that will satisfy the design requirements but keep the > software simpler. > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Saturday, June 08, 2002 10:16 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > That is not completely accurate. > The only problem is when PDU size decreases and then SNACK must be for all > data. > Target can also keep a mapping of numbers/to offsets (the list should be > small and if it gets long ask for ack (A-bit). > > Julo > > Eddy Quicksall > Sent by: owner-ips@ece.cmu.edu > > > 06/08/2002 10:54 PM > Please respond to Eddy Quicksall > > > To: pat_thaler@agilent.com > cc: ips@ece.cmu.edu > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > Thanks, > > As a target, I won't be able to let it change until all of the outstanding > commands are finished (running with ErrorRecoveryLevel>=1). This is because > I must use the PDU size to compute the offset from a SNACK's > BegRun/RunLength. > > So, I plan to not give the text response for a MaxPDURecvDataLength in FFP > until I get back an ExpStatSN == next StatSN. > > This will cause a delay of unknown time before the PDU size can actually > change ... do you see any problem with this? > > Eddy > > -----Original Message----- > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > Sent: Friday, June 07, 2002 1:13 PM > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > Subject: RE: iSCSI: changing MaxPDUDataLength > > > Eddy, > > If one uses a message sync and steering that relys on the transport segments > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path > MTU changes one would want to change the PDU data length to fit the new path > MTU. > > Pat > > -----Original Message----- > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > Sent: Wednesday, June 05, 2002 12:24 PM > To: ips@ece.cmu.edu > Subject: iSCSI: changing MaxPDUDataLength > > > Does anybody know a case where it is necessary to support a new PDU data > length during full feature phase? > > Eddy > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > From owner-ips@ece.cmu.edu Tue Jun 11 17:40:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13895 for ; Tue, 11 Jun 2002 17:40:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BKqQ603958 for ips-outgoing; Tue, 11 Jun 2002 16:52:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from astutenetworks.com (2.astutenetworks.com [216.142.74.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BKqNw03951 for ; Tue, 11 Jun 2002 16:52:23 -0400 (EDT) Received: from amirdesktop (dhcp62 [172.21.2.62]) by astutenetworks.com (8.11.6/8.11.2) with SMTP id g5BKpA909685; Tue, 11 Jun 2002 13:51:10 -0700 From: "Amir Shalit" To: "Mallikarjun C." , "Eddy Quicksall" , "Julian Satran" Cc: Subject: RE: iSCSI: changing MaxPDUDataLength Date: Tue, 11 Jun 2002 13:51:08 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <002001c2117f$24527e20$edd52b0f@rose.hp.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mallikarjun, The initiator can wait for all outstanding sequences to get acknowledged prior to negotiating MaxPDUDataLength change. That will work well for long-running commands and simplify target management. Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Mallikarjun C. Sent: Tuesday, June 11, 2002 12:35 PM To: Eddy Quicksall; Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iSCSI: changing MaxPDUDataLength Eddy, I am not clear on why you think the target code becomes messy on a PDU size change. The last para in section 4.4 states the following - "Parameters negotiated by a text exchange negotiation sequence become effective only after the negotiation sequence is completed." Since the target gets to complete a text negotiation with a Text Response PDU, it can time the applicability of a changed MaxRecvDataSegmentLength. Requiring that an initiator must idle the connection before changing this parameter, IMHO, is counter-productive when there's a dynamic PMTU degradation in the presence of long-running commands (writes in particular). Once the initiator starts the renegotiation, target would ideally want to quickly renegotiate its receive size as well to receive ULPDU-contained segments. In short, seems to me that the draft is saying what you would like. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Eddy Quicksall" To: "Julian Satran" Cc: Sent: Tuesday, June 11, 2002 7:56 AM Subject: RE: iSCSI: changing MaxPDUDataLength > I think it should be a requirement because if it is not, all target code > will have to have the messy code. Or, we could say that if it is not idle > commands, then the target may reject it. > > Eddy > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Tuesday, June 11, 2002 9:11 AM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > That is a fair request - we may slip in a recommendation to that effect (in > chapter 11?) > > Julo > > > > Eddy Quicksall > > > 06/11/2002 04:28 AM > Please respond to Eddy Quicksall > > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > How about if we say that an initiator must not change the MaxPDUDataSize > unless it first idles the commands (at least the ones with the R bit) or if > ErrorRecoveryLevel==0? > > That would simplify target code greatly and would meet the design goals; and > since it should be rare to change it, it would be of little impact to idle > the commands for a split second. > > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Monday, June 10, 2002 8:06 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > I said only that when you change length you can ask for all PDUs after the > ack! (no need to keep a tall - the old offsets are good up to the hole). > > Julo > > > Eddy Quicksall > > > 06/11/2002 12:32 AM > Please respond to Eddy Quicksall > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > Julian, > > Another problem here is that the target has to calculate the offset from the > DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 > means starting DataSN=4, send all the data for that sequence. > > I think it would be a performance hit and waist of memory to keep a tally of > all PDU sizes just for an occasional SNACK. > > It's not that it can't be done ... it is more that it is messy and I think > there is a solution that will satisfy the design requirements but keep the > software simpler. > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Saturday, June 08, 2002 10:16 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > That is not completely accurate. > The only problem is when PDU size decreases and then SNACK must be for all > data. > Target can also keep a mapping of numbers/to offsets (the list should be > small and if it gets long ask for ack (A-bit). > > Julo > > Eddy Quicksall > Sent by: owner-ips@ece.cmu.edu > > > 06/08/2002 10:54 PM > Please respond to Eddy Quicksall > > > To: pat_thaler@agilent.com > cc: ips@ece.cmu.edu > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > Thanks, > > As a target, I won't be able to let it change until all of the outstanding > commands are finished (running with ErrorRecoveryLevel>=1). This is because > I must use the PDU size to compute the offset from a SNACK's > BegRun/RunLength. > > So, I plan to not give the text response for a MaxPDURecvDataLength in FFP > until I get back an ExpStatSN == next StatSN. > > This will cause a delay of unknown time before the PDU size can actually > change ... do you see any problem with this? > > Eddy > > -----Original Message----- > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > Sent: Friday, June 07, 2002 1:13 PM > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > Subject: RE: iSCSI: changing MaxPDUDataLength > > > Eddy, > > If one uses a message sync and steering that relys on the transport segments > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path > MTU changes one would want to change the PDU data length to fit the new path > MTU. > > Pat > > -----Original Message----- > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > Sent: Wednesday, June 05, 2002 12:24 PM > To: ips@ece.cmu.edu > Subject: iSCSI: changing MaxPDUDataLength > > > Does anybody know a case where it is necessary to support a new PDU data > length during full feature phase? > > Eddy > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > From owner-ips@ece.cmu.edu Tue Jun 11 19:15:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15991 for ; Tue, 11 Jun 2002 19:15:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BMocw10196 for ips-outgoing; Tue, 11 Jun 2002 18:50:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BMoYw10181; Tue, 11 Jun 2002 18:50:34 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5BMoRYj060852; Wed, 12 Jun 2002 00:50:27 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5BMoQp125010; Wed, 12 Jun 2002 00:50:27 +0200 Importance: High Subject: Re: iSCSI: changing MaxPDUDataLength To: "Mallikarjun C." Cc: ips@ece.cmu.edu, "Julian Satran" , owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Wed, 12 Jun 2002 00:28:28 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 12/06/2002 01:50:27 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mallikarjun, The question was general and not specific to MaxRecv.... Although we say that negotiation is symmetric we don't have any mechanism through which a target can say it wants to start negotiation something (sort of similar but not as strong as a the "request logout" - "request to negotiate" that will require the initiator to issue a text request and kick-off a negotiation. Julo "Mallikarjun C." To: , Julian Satran/Haifa/IBM@IBMIL Sent by: cc: owner-ips@ece.cmu Subject: Re: iSCSI: changing MaxPDUDataLength .edu 06/11/2002 10:50 PM Please respond to "Mallikarjun C." > I also realized that we don't have "negotiation prompt" from the target. > I am not sure that we need one. I am not sure about it either. My preference is not to add this. It appears to me that a target does have the option of dropping the connection today if it can't work with non-ULPDU-contained segments for too long. I suspect that the target would do the same if (we introduced the "negotiation prompt" and) the initiator doesn't/couldn't honor the "negotiation prompt". Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Julian Satran" To: Sent: Tuesday, June 11, 2002 8:34 AM Subject: RE: iSCSI: changing MaxPDUDataLength > I suggest the following text in 11.13 > > A change of MaxRecvDataSegmentLength by an initiator or target > becomes effective after all commands preceding the negotiation > end-ing request have been processed by the target and their status > is acknowledged. > > I also realized that we don't have "negotiation prompt" from the target. > I am not sure that we need one. > If some of you think we need we may want one additional code in the Asynch > Message. > Please comment TODAY. > > Julo > ----- Forwarded by Julian Satran/Haifa/IBM on 06/11/2002 06:29 PM ----- > > Julian Satran > To: Eddy Quicksall > 06/11/2002 04:04 cc: ips@ece.cmu.edu, pat_thaler@agilent.com > PM From: Julian Satran/Haifa/IBM@IBMIL > Subject: RE: iSCSI: changing MaxPDUDataLength(Document link: Julian Satran - Mail) > > > > > > > > > > That is a fair request - we may slip in a recommendation to that effect (in > chapter 11?) > > Julo > > > > Eddy Quicksall > vivity.com> cc: ips@ece.cmu.edu, pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > 06/11/2002 04:28 > AM > Please respond to > Eddy Quicksall > > > > > > How about if we say that an initiator must not change the MaxPDUDataSize > unless it first idles the commands (at least the ones with the R bit) or if > ErrorRecoveryLevel==0? > > That would simplify target code greatly and would meet the design goals; > and since it should be rare to change it, it would be of little impact to > idle the commands for a split second. > > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Monday, June 10, 2002 8:06 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > I said only that when you change length you can ask for all PDUs > after the ack! (no need to keep a tall - the old offsets are good up > to the hole). > > Julo > > > Eddy Quicksall > To: Julian > Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu, > 06/11/2002 12:32 AM pat_thaler@agilent.com > Please respond to Eddy Quicksall Subject: RE: iSCSI: > changing MaxPDUDataLength > > > > > > > > Julian, > > Another problem here is that the target has to calculate the offset > from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and > RunLngth=0 means starting DataSN=4, send all the data for that > sequence. > > I think it would be a performance hit and waist of memory to keep a > tally of all PDU sizes just for an occasional SNACK. > > It's not that it can't be done ... it is more that it is messy and I > think there is a solution that will satisfy the design requirements > but keep the software simpler. > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Saturday, June 08, 2002 10:16 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > That is not completely accurate. > The only problem is when PDU size decreases and then SNACK must be > for all data. > Target can also keep a mapping of numbers/to offsets (the list should > be small and if it gets long ask for ack (A-bit). > > Julo > > Eddy Quicksall > To: > Sent by: owner-ips@ece.cmu.edu pat_thaler@agilent.com > cc: ips@ece.cmu.edu > Subject: RE: iSCSI: > 06/08/2002 10:54 PM changing MaxPDUDataLength > Please respond to Eddy Quicksall > > > > > > > > Thanks, > > As a target, I won't be able to let it change until all of the > outstanding > commands are finished (running with ErrorRecoveryLevel>=1). This is > because > I must use the PDU size to compute the offset from a SNACK's > BegRun/RunLength. > > So, I plan to not give the text response for a MaxPDURecvDataLength > in FFP > until I get back an ExpStatSN == next StatSN. > > This will cause a delay of unknown time before the PDU size can > actually > change ... do you see any problem with this? > > Eddy > > -----Original Message----- > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > Sent: Friday, June 07, 2002 1:13 PM > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > Subject: RE: iSCSI: changing MaxPDUDataLength > > > Eddy, > > If one uses a message sync and steering that relys on the transport > segments > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the > path > MTU changes one would want to change the PDU data length to fit the > new path > MTU. > > Pat > > -----Original Message----- > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > Sent: Wednesday, June 05, 2002 12:24 PM > To: ips@ece.cmu.edu > Subject: iSCSI: changing MaxPDUDataLength > > > Does anybody know a case where it is necessary to support a new PDU > data > length during full feature phase? > > Eddy > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > > > From owner-ips@ece.cmu.edu Tue Jun 11 19:18:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16072 for ; Tue, 11 Jun 2002 19:18:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BMobx10193 for ips-outgoing; Tue, 11 Jun 2002 18:50:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BMoYw10182 for ; Tue, 11 Jun 2002 18:50:34 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5BMoRYj015576; Wed, 12 Jun 2002 00:50:27 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5BMoQp61766; Wed, 12 Jun 2002 00:50:26 +0200 Importance: High Subject: RE: iSCSI: changing MaxPDUDataLength To: Eddy Quicksall Cc: ips@ece.cmu.edu, Julian Satran X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Wed, 12 Jun 2002 00:17:16 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 12/06/2002 01:50:26 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I think that even the text I suggested is more than it is needed. Quiescing the connection is not practical - many large box builder will find this unacceptable and obviously an implementation can go away without it. As I pointed out for retries you need only the offset at the change point and anything that happens later require retransmission of everything from the known point. Julo Eddy Quicksall cc: Subject: RE: iSCSI: changing MaxPDUDataLength 06/11/2002 08:56 PM Please respond to Eddy Quicksall I see a case where the target could still end up sending PDU's of different lengths for a given command. It would be much safer if the initiator was required to idle the commands before sending the new MaxRecvDataSegmentLength. That way there is nothing for the target to do other than change the size. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, June 11, 2002 11:34 AM To: ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Importance: High I suggest the following text in 11.13 A change of MaxRecvDataSegmentLength by an initiator or target becomes effective after all commands preceding the negotiation end-ing request have been processed by the target and their status is acknowledged. I also realized that we don't have "negotiation prompt" from the target. I am not sure that we need one. If some of you think we need we may want one additional code in the Asynch Message. Please comment TODAY. Julo ----- Forwarded by Julian Satran/Haifa/IBM on 06/11/2002 06:29 PM ----- Julian Satran To: Eddy Quicksall 06/11/2002 04:04 cc: ips@ece.cmu.edu, pat_thaler@agilent.com PM From: Julian Satran/Haifa/IBM@IBMIL Subject: RE: iSCSI: changing MaxPDUDataLength(Document link: Julian Satran - Mail) That is a fair request - we may slip in a recommendation to that effect (in chapter 11?) Julo Eddy Quicksall cc: ips@ece.cmu.edu, pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength 06/11/2002 04:28 AM Please respond to Eddy Quicksall How about if we say that an initiator must not change the MaxPDUDataSize unless it first idles the commands (at least the ones with the R bit) or if ErrorRecoveryLevel==0? That would simplify target code greatly and would meet the design goals; and since it should be rare to change it, it would be of little impact to idle the commands for a split second. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, June 10, 2002 8:06 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu; pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength I said only that when you change length you can ask for all PDUs after the ack! (no need to keep a tall - the old offsets are good up to the hole). Julo Eddy Quicksall To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, 06/11/2002 12:32 AM pat_thaler@agilent.com Please respond to Eddy Quicksall Subject: RE: iSCSI: changing MaxPDUDataLength Julian, Another problem here is that the target has to calculate the offset from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 means starting DataSN=4, send all the data for that sequence. I think it would be a performance hit and waist of memory to keep a tally of all PDU sizes just for an occasional SNACK. It's not that it can't be done ... it is more that it is messy and I think there is a solution that will satisfy the design requirements but keep the software simpler. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, June 08, 2002 10:16 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength That is not completely accurate. The only problem is when PDU size decreases and then SNACK must be for all data. Target can also keep a mapping of numbers/to offsets (the list should be small and if it gets long ask for ack (A-bit). Julo Eddy Quicksall To: Sent by: owner-ips@ece.cmu.edu pat_thaler@agilent.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: 06/08/2002 10:54 PM changing MaxPDUDataLength Please respond to Eddy Quicksall Thanks, As a target, I won't be able to let it change until all of the outstanding commands are finished (running with ErrorRecoveryLevel>=1). This is because I must use the PDU size to compute the offset from a SNACK's BegRun/RunLength. So, I plan to not give the text response for a MaxPDURecvDataLength in FFP until I get back an ExpStatSN == next StatSN. This will cause a delay of unknown time before the PDU size can actually change ... do you see any problem with this? Eddy -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Friday, June 07, 2002 1:13 PM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Eddy, If one uses a message sync and steering that relys on the transport segments carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path MTU changes one would want to change the PDU data length to fit the new path MTU. Pat -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Wednesday, June 05, 2002 12:24 PM To: ips@ece.cmu.edu Subject: iSCSI: changing MaxPDUDataLength Does anybody know a case where it is necessary to support a new PDU data length during full feature phase? Eddy mailto: Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Tue Jun 11 19:18:39 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16086 for ; Tue, 11 Jun 2002 19:18:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BMI5s08723 for ips-outgoing; Tue, 11 Jun 2002 18:18:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BMI3w08718 for ; Tue, 11 Jun 2002 18:18:03 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 18:18:01 -0400 Message-ID: From: Eddy Quicksall To: "Mallikarjun C." , Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Date: Tue, 11 Jun 2002 18:18:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk You are correct and that is exactly how I have had to code it. With fast path and slow path code split between processors, it becomes even worse. When I read your comments on why the PDU size could change (from way back in March I think), I got did not get the impression that it would happen very often and that in fact it may only happen when you are maintaining allegiance to another connection. If it is something that is not going to happen very often, then it would be so much easier to have the initiator idle the commands first (all it really needs to do is idle the READ commands). If it is going to change so often that idling would be degrading, I suspect that just doing the negotiation that often would itself be degrading. And, be aware that the target will probably idle the R commands. Otherwise, it will have to track PDU sizes and that would be really "counter-productive" (especially when there should be no SNACKs on a good connection anyway). I don't see any problem with the target negotiating its size at any time. And the initiator would not have to idle the WRITE or no-data commands. Eddy -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com] Sent: Tuesday, June 11, 2002 3:35 PM To: Eddy Quicksall; Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iSCSI: changing MaxPDUDataLength Eddy, I am not clear on why you think the target code becomes messy on a PDU size change. The last para in section 4.4 states the following - "Parameters negotiated by a text exchange negotiation sequence become effective only after the negotiation sequence is completed." Since the target gets to complete a text negotiation with a Text Response PDU, it can time the applicability of a changed MaxRecvDataSegmentLength. Requiring that an initiator must idle the connection before changing this parameter, IMHO, is counter-productive when there's a dynamic PMTU degradation in the presence of long-running commands (writes in particular). Once the initiator starts the renegotiation, target would ideally want to quickly renegotiate its receive size as well to receive ULPDU-contained segments. In short, seems to me that the draft is saying what you would like. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Eddy Quicksall" To: "Julian Satran" Cc: Sent: Tuesday, June 11, 2002 7:56 AM Subject: RE: iSCSI: changing MaxPDUDataLength > I think it should be a requirement because if it is not, all target code > will have to have the messy code. Or, we could say that if it is not idle > commands, then the target may reject it. > > Eddy > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Tuesday, June 11, 2002 9:11 AM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > That is a fair request - we may slip in a recommendation to that effect (in > chapter 11?) > > Julo > > > > Eddy Quicksall > > > 06/11/2002 04:28 AM > Please respond to Eddy Quicksall > > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > How about if we say that an initiator must not change the MaxPDUDataSize > unless it first idles the commands (at least the ones with the R bit) or if > ErrorRecoveryLevel==0? > > That would simplify target code greatly and would meet the design goals; and > since it should be rare to change it, it would be of little impact to idle > the commands for a split second. > > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Monday, June 10, 2002 8:06 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > I said only that when you change length you can ask for all PDUs after the > ack! (no need to keep a tall - the old offsets are good up to the hole). > > Julo > > > Eddy Quicksall > > > 06/11/2002 12:32 AM > Please respond to Eddy Quicksall > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > Julian, > > Another problem here is that the target has to calculate the offset from the > DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 > means starting DataSN=4, send all the data for that sequence. > > I think it would be a performance hit and waist of memory to keep a tally of > all PDU sizes just for an occasional SNACK. > > It's not that it can't be done ... it is more that it is messy and I think > there is a solution that will satisfy the design requirements but keep the > software simpler. > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Saturday, June 08, 2002 10:16 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > That is not completely accurate. > The only problem is when PDU size decreases and then SNACK must be for all > data. > Target can also keep a mapping of numbers/to offsets (the list should be > small and if it gets long ask for ack (A-bit). > > Julo > > Eddy Quicksall > Sent by: owner-ips@ece.cmu.edu > > > 06/08/2002 10:54 PM > Please respond to Eddy Quicksall > > > To: pat_thaler@agilent.com > cc: ips@ece.cmu.edu > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > Thanks, > > As a target, I won't be able to let it change until all of the outstanding > commands are finished (running with ErrorRecoveryLevel>=1). This is because > I must use the PDU size to compute the offset from a SNACK's > BegRun/RunLength. > > So, I plan to not give the text response for a MaxPDURecvDataLength in FFP > until I get back an ExpStatSN == next StatSN. > > This will cause a delay of unknown time before the PDU size can actually > change ... do you see any problem with this? > > Eddy > > -----Original Message----- > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > Sent: Friday, June 07, 2002 1:13 PM > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > Subject: RE: iSCSI: changing MaxPDUDataLength > > > Eddy, > > If one uses a message sync and steering that relys on the transport segments > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path > MTU changes one would want to change the PDU data length to fit the new path > MTU. > > Pat > > -----Original Message----- > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > Sent: Wednesday, June 05, 2002 12:24 PM > To: ips@ece.cmu.edu > Subject: iSCSI: changing MaxPDUDataLength > > > Does anybody know a case where it is necessary to support a new PDU data > length during full feature phase? > > Eddy > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > From owner-ips@ece.cmu.edu Tue Jun 11 19:24:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16220 for ; Tue, 11 Jun 2002 19:23:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BMm0Y10073 for ips-outgoing; Tue, 11 Jun 2002 18:48:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail1irv.inside.istor.com (host28.istor.com [66.134.214.28]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BMlww10068 for ; Tue, 11 Jun 2002 18:47:58 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: Task management processing MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 11 Jun 2002 15:47:09 -0700 Message-ID: <7D036BD3216A084DB1BD9D62BCEAF29008A0D9@mail1irv.inside.istor.com> Thread-Topic: Task management processing Thread-Index: AcIRmerxwv4w46Q4RRKMORO+MtxduA== From: "Ken Craig" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g5BMlww10069 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit I have a question about section 9.6.2, Task Management actions on task sets. SAM-2 specifies that a LUN RESET shall abort all tasks per SAM-2 aborting tasks rules. From my perspective a target's handling of a LUN RESET is the equivalent of the LUN having received a CLEAR TASK SET, in addition to the other requirements of a LUN RESET. My question is should section 9.6.2 also include LUN RESET, TARGET WARM RESET, and TARGET COLD RESET as task management requests that force a specific order of execution by the initiator and the target? Thanks, Kenneth Ray Craig, Jr. From owner-ips@ece.cmu.edu Tue Jun 11 19:46:53 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16731 for ; Tue, 11 Jun 2002 19:46:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BNEnC11296 for ips-outgoing; Tue, 11 Jun 2002 19:14:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BNEmw11292 for ; Tue, 11 Jun 2002 19:14:48 -0400 (EDT) Received: from london ([192.168.1.19]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id QAA15678; Tue, 11 Jun 2002 16:13:05 -0700 (PDT) From: "Rod Harrison" To: "Mallikarjun C." , "Eddy Quicksall" , "Julian Satran" Cc: Subject: RE: iSCSI: changing MaxPDUDataLength Date: Tue, 11 Jun 2002 18:15:13 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <002001c2117f$24527e20$edd52b0f@rose.hp.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mallikarjun , The current wording doesn't appear to prevent the initiator from staging new commands whilst the negotiation is in process and therefore the target may never find a "good time" to end the negotiation sequence. I don't think idling the connection would be a big issue in the event of PMTU change since the worst case is that existing commands have to run to completion using the inefficient PMTU. The initiator also has the options of aborting and restarting the commands if they can't complete with the old PMTU, or better, open another connection with the appropriate MaxPDUDataLength and change the command allegiance. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Mallikarjun C. Sent: Tuesday, June 11, 2002 2:35 PM To: Eddy Quicksall; Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iSCSI: changing MaxPDUDataLength Eddy, I am not clear on why you think the target code becomes messy on a PDU size change. The last para in section 4.4 states the following - "Parameters negotiated by a text exchange negotiation sequence become effective only after the negotiation sequence is completed." Since the target gets to complete a text negotiation with a Text Response PDU, it can time the applicability of a changed MaxRecvDataSegmentLength. Requiring that an initiator must idle the connection before changing this parameter, IMHO, is counter-productive when there's a dynamic PMTU degradation in the presence of long-running commands (writes in particular). Once the initiator starts the renegotiation, target would ideally want to quickly renegotiate its receive size as well to receive ULPDU-contained segments. In short, seems to me that the draft is saying what you would like. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Eddy Quicksall" To: "Julian Satran" Cc: Sent: Tuesday, June 11, 2002 7:56 AM Subject: RE: iSCSI: changing MaxPDUDataLength > I think it should be a requirement because if it is not, all target code > will have to have the messy code. Or, we could say that if it is not idle > commands, then the target may reject it. > > Eddy > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Tuesday, June 11, 2002 9:11 AM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > That is a fair request - we may slip in a recommendation to that effect (in > chapter 11?) > > Julo > > > > Eddy Quicksall > > > 06/11/2002 04:28 AM > Please respond to Eddy Quicksall > > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > How about if we say that an initiator must not change the MaxPDUDataSize > unless it first idles the commands (at least the ones with the R bit) or if > ErrorRecoveryLevel==0? > > That would simplify target code greatly and would meet the design goals; and > since it should be rare to change it, it would be of little impact to idle > the commands for a split second. > > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Monday, June 10, 2002 8:06 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > I said only that when you change length you can ask for all PDUs after the > ack! (no need to keep a tall - the old offsets are good up to the hole). > > Julo > > > Eddy Quicksall > > > 06/11/2002 12:32 AM > Please respond to Eddy Quicksall > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > Julian, > > Another problem here is that the target has to calculate the offset from the > DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 > means starting DataSN=4, send all the data for that sequence. > > I think it would be a performance hit and waist of memory to keep a tally of > all PDU sizes just for an occasional SNACK. > > It's not that it can't be done ... it is more that it is messy and I think > there is a solution that will satisfy the design requirements but keep the > software simpler. > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Saturday, June 08, 2002 10:16 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > That is not completely accurate. > The only problem is when PDU size decreases and then SNACK must be for all > data. > Target can also keep a mapping of numbers/to offsets (the list should be > small and if it gets long ask for ack (A-bit). > > Julo > > Eddy Quicksall > Sent by: owner-ips@ece.cmu.edu > > > 06/08/2002 10:54 PM > Please respond to Eddy Quicksall > > > To: pat_thaler@agilent.com > cc: ips@ece.cmu.edu > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > Thanks, > > As a target, I won't be able to let it change until all of the outstanding > commands are finished (running with ErrorRecoveryLevel>=1). This is because > I must use the PDU size to compute the offset from a SNACK's > BegRun/RunLength. > > So, I plan to not give the text response for a MaxPDURecvDataLength in FFP > until I get back an ExpStatSN == next StatSN. > > This will cause a delay of unknown time before the PDU size can actually > change ... do you see any problem with this? > > Eddy > > -----Original Message----- > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > Sent: Friday, June 07, 2002 1:13 PM > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > Subject: RE: iSCSI: changing MaxPDUDataLength > > > Eddy, > > If one uses a message sync and steering that relys on the transport segments > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path > MTU changes one would want to change the PDU data length to fit the new path > MTU. > > Pat > > -----Original Message----- > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > Sent: Wednesday, June 05, 2002 12:24 PM > To: ips@ece.cmu.edu > Subject: iSCSI: changing MaxPDUDataLength > > > Does anybody know a case where it is necessary to support a new PDU data > length during full feature phase? > > Eddy > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > From owner-ips@ece.cmu.edu Tue Jun 11 19:48:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16817 for ; Tue, 11 Jun 2002 19:48:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BMvBj10516 for ips-outgoing; Tue, 11 Jun 2002 18:57:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BMvAw10511 for ; Tue, 11 Jun 2002 18:57:10 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel7.hp.com (Postfix) with ESMTP id F0EF58050A8; Tue, 11 Jun 2002 18:57:03 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id PAA12983; Tue, 11 Jun 2002 15:58:52 -0700 (PDT) Message-ID: <00ae01c2119b$4cbaaa60$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Eddy Quicksall" , "Julian Satran" Cc: References: Subject: Re: iSCSI: changing MaxPDUDataLength Date: Tue, 11 Jun 2002 15:57:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Eddy, I am not sure if you're agreeing with me or not... but let me add some comments. I don't expect the change in PDU size to happen frequently - no change in what I earlier said. You are making an assumption that a target must record the PDU size for every PDU if SNACKs are to be satisfied across changed MaxRecvDataSegmentLength. As Julian earlier said, you don't have to. I will not go into implementation details, but I believe just the value of the DataSN from which the new size is effective should be all that's needed. Besides, the spec guarantees that only RunLength=0 is used on any SNACK after the change. You are also implying that targets can declare their changed MaxRecvDataSegmentLength anytime just for writes. There are two problems with this - a) reads and writes may both be active in the typical case on an iSCSI connection, and b) a target can declare its changed value only if an initiator is allowed to start the Text Request (and I thought you were suggesting that we explicitly disallow that). Hope that clears it up. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Eddy Quicksall" To: "Mallikarjun C." ; "Julian Satran" Cc: Sent: Tuesday, June 11, 2002 3:18 PM Subject: RE: iSCSI: changing MaxPDUDataLength > You are correct and that is exactly how I have had to code it. With fast > path and slow path code split between processors, it becomes even worse. > > When I read your comments on why the PDU size could change (from way back in > March I think), I got did not get the impression that it would happen very > often and that in fact it may only happen when you are maintaining > allegiance to another connection. > > If it is something that is not going to happen very often, then it would be > so much easier to have the initiator idle the commands first (all it really > needs to do is idle the READ commands). If it is going to change so often > that idling would be degrading, I suspect that just doing the negotiation > that often would itself be degrading. > > And, be aware that the target will probably idle the R commands. Otherwise, > it will have to track PDU sizes and that would be really > "counter-productive" (especially when there should be no SNACKs on a good > connection anyway). > > I don't see any problem with the target negotiating its size at any time. > And the initiator would not have to idle the WRITE or no-data commands. > > Eddy > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Tuesday, June 11, 2002 3:35 PM > To: Eddy Quicksall; Julian Satran > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: changing MaxPDUDataLength > > > Eddy, > > I am not clear on why you think the target code becomes messy on > a PDU size change. The last para in section 4.4 states the following - > > "Parameters negotiated by a text exchange negotiation sequence become > effective only after the negotiation sequence is completed." > > Since the target gets to complete a text negotiation with a Text Response > PDU, it can time the applicability of a changed MaxRecvDataSegmentLength. > > Requiring that an initiator must idle the connection before changing this > parameter, IMHO, is counter-productive when there's a dynamic PMTU > degradation in the presence of long-running commands (writes in particular). > Once the initiator starts the renegotiation, target would ideally want to > quickly > renegotiate its receive size as well to receive ULPDU-contained segments. > > In short, seems to me that the draft is saying what you would like. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > > ----- Original Message ----- > From: "Eddy Quicksall" > To: "Julian Satran" > Cc: > Sent: Tuesday, June 11, 2002 7:56 AM > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > I think it should be a requirement because if it is not, all target code > > will have to have the messy code. Or, we could say that if it is not idle > > commands, then the target may reject it. > > > > Eddy > > > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Tuesday, June 11, 2002 9:11 AM > > To: Eddy Quicksall > > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > That is a fair request - we may slip in a recommendation to that effect > (in > > chapter 11?) > > > > Julo > > > > > > > > Eddy Quicksall > > > > > > 06/11/2002 04:28 AM > > Please respond to Eddy Quicksall > > > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > How about if we say that an initiator must not change the MaxPDUDataSize > > unless it first idles the commands (at least the ones with the R bit) or > if > > ErrorRecoveryLevel==0? > > > > That would simplify target code greatly and would meet the design goals; > and > > since it should be rare to change it, it would be of little impact to idle > > the commands for a split second. > > > > > > Eddy > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Monday, June 10, 2002 8:06 PM > > To: Eddy Quicksall > > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > I said only that when you change length you can ask for all PDUs after the > > ack! (no need to keep a tall - the old offsets are good up to the hole). > > > > Julo > > > > > > Eddy Quicksall > > > > > > 06/11/2002 12:32 AM > > Please respond to Eddy Quicksall > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > Julian, > > > > Another problem here is that the target has to calculate the offset from > the > > DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 > > means starting DataSN=4, send all the data for that sequence. > > > > I think it would be a performance hit and waist of memory to keep a tally > of > > all PDU sizes just for an occasional SNACK. > > > > It's not that it can't be done ... it is more that it is messy and I think > > there is a solution that will satisfy the design requirements but keep the > > software simpler. > > > > Eddy > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Saturday, June 08, 2002 10:16 PM > > To: Eddy Quicksall > > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > That is not completely accurate. > > The only problem is when PDU size decreases and then SNACK must be for all > > data. > > Target can also keep a mapping of numbers/to offsets (the list should be > > small and if it gets long ask for ack (A-bit). > > > > Julo > > > > Eddy Quicksall > > Sent by: owner-ips@ece.cmu.edu > > > > > > 06/08/2002 10:54 PM > > Please respond to Eddy Quicksall > > > > > > To: pat_thaler@agilent.com > > cc: ips@ece.cmu.edu > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > > > Thanks, > > > > As a target, I won't be able to let it change until all of the outstanding > > commands are finished (running with ErrorRecoveryLevel>=1). This is > because > > I must use the PDU size to compute the offset from a SNACK's > > BegRun/RunLength. > > > > So, I plan to not give the text response for a MaxPDURecvDataLength in FFP > > until I get back an ExpStatSN == next StatSN. > > > > This will cause a delay of unknown time before the PDU size can actually > > change ... do you see any problem with this? > > > > Eddy > > > > -----Original Message----- > > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > > Sent: Friday, June 07, 2002 1:13 PM > > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > Eddy, > > > > If one uses a message sync and steering that relys on the transport > segments > > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path > > MTU changes one would want to change the PDU data length to fit the new > path > > MTU. > > > > Pat > > > > -----Original Message----- > > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > > Sent: Wednesday, June 05, 2002 12:24 PM > > To: ips@ece.cmu.edu > > Subject: iSCSI: changing MaxPDUDataLength > > > > > > Does anybody know a case where it is necessary to support a new PDU data > > length during full feature phase? > > > > Eddy > > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Tue Jun 11 20:25:25 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17562 for ; Tue, 11 Jun 2002 20:25:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BNwjn13303 for ips-outgoing; Tue, 11 Jun 2002 19:58:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BNwhw13299 for ; Tue, 11 Jun 2002 19:58:43 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 19:58:43 -0400 Message-ID: From: Eddy Quicksall To: Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Date: Tue, 11 Jun 2002 19:58:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk The target would have to quiesc all data-outs anyway before sending the response (or keep track of PDU sizes which is even worse). I believe this is easier done at the initiator. Also, why would one want to do so many PDU size changes that it would really make a difference? How are you going to get the offset if the PDU's changed size on you without keeping track of PDU size changes? Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, June 11, 2002 5:17 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu; Julian Satran Subject: RE: iSCSI: changing MaxPDUDataLength Importance: High I think that even the text I suggested is more than it is needed. Quiescing the connection is not practical - many large box builder will find this unacceptable and obviously an implementation can go away without it. As I pointed out for retries you need only the offset at the change point and anything that happens later require retransmission of everything from the known point. Julo Eddy Quicksall cc: Subject: RE: iSCSI: changing MaxPDUDataLength 06/11/2002 08:56 PM Please respond to Eddy Quicksall I see a case where the target could still end up sending PDU's of different lengths for a given command. It would be much safer if the initiator was required to idle the commands before sending the new MaxRecvDataSegmentLength. That way there is nothing for the target to do other than change the size. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, June 11, 2002 11:34 AM To: ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Importance: High I suggest the following text in 11.13 A change of MaxRecvDataSegmentLength by an initiator or target becomes effective after all commands preceding the negotiation end-ing request have been processed by the target and their status is acknowledged. I also realized that we don't have "negotiation prompt" from the target. I am not sure that we need one. If some of you think we need we may want one additional code in the Asynch Message. Please comment TODAY. Julo ----- Forwarded by Julian Satran/Haifa/IBM on 06/11/2002 06:29 PM ----- Julian Satran To: Eddy Quicksall 06/11/2002 04:04 cc: ips@ece.cmu.edu, pat_thaler@agilent.com PM From: Julian Satran/Haifa/IBM@IBMIL Subject: RE: iSCSI: changing MaxPDUDataLength(Document link: Julian Satran - Mail) That is a fair request - we may slip in a recommendation to that effect (in chapter 11?) Julo Eddy Quicksall cc: ips@ece.cmu.edu, pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength 06/11/2002 04:28 AM Please respond to Eddy Quicksall How about if we say that an initiator must not change the MaxPDUDataSize unless it first idles the commands (at least the ones with the R bit) or if ErrorRecoveryLevel==0? That would simplify target code greatly and would meet the design goals; and since it should be rare to change it, it would be of little impact to idle the commands for a split second. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, June 10, 2002 8:06 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu; pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength I said only that when you change length you can ask for all PDUs after the ack! (no need to keep a tall - the old offsets are good up to the hole). Julo Eddy Quicksall To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, 06/11/2002 12:32 AM pat_thaler@agilent.com Please respond to Eddy Quicksall Subject: RE: iSCSI: changing MaxPDUDataLength Julian, Another problem here is that the target has to calculate the offset from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 means starting DataSN=4, send all the data for that sequence. I think it would be a performance hit and waist of memory to keep a tally of all PDU sizes just for an occasional SNACK. It's not that it can't be done ... it is more that it is messy and I think there is a solution that will satisfy the design requirements but keep the software simpler. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, June 08, 2002 10:16 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength That is not completely accurate. The only problem is when PDU size decreases and then SNACK must be for all data. Target can also keep a mapping of numbers/to offsets (the list should be small and if it gets long ask for ack (A-bit). Julo Eddy Quicksall To: Sent by: owner-ips@ece.cmu.edu pat_thaler@agilent.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: 06/08/2002 10:54 PM changing MaxPDUDataLength Please respond to Eddy Quicksall Thanks, As a target, I won't be able to let it change until all of the outstanding commands are finished (running with ErrorRecoveryLevel>=1). This is because I must use the PDU size to compute the offset from a SNACK's BegRun/RunLength. So, I plan to not give the text response for a MaxPDURecvDataLength in FFP until I get back an ExpStatSN == next StatSN. This will cause a delay of unknown time before the PDU size can actually change ... do you see any problem with this? Eddy -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Friday, June 07, 2002 1:13 PM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Eddy, If one uses a message sync and steering that relys on the transport segments carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path MTU changes one would want to change the PDU data length to fit the new path MTU. Pat -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Wednesday, June 05, 2002 12:24 PM To: ips@ece.cmu.edu Subject: iSCSI: changing MaxPDUDataLength Does anybody know a case where it is necessary to support a new PDU data length during full feature phase? Eddy mailto: Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Tue Jun 11 20:25:30 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17563 for ; Tue, 11 Jun 2002 20:25:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BNvHf13225 for ips-outgoing; Tue, 11 Jun 2002 19:57:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BNvFw13216 for ; Tue, 11 Jun 2002 19:57:15 -0400 (EDT) Received: from london ([192.168.1.19]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id QAA16002; Tue, 11 Jun 2002 16:55:32 -0700 (PDT) From: "Rod Harrison" To: "Julian Satran" , "Mallikarjun C." Cc: Subject: RE: iSCSI: changing MaxPDUDataLength Date: Tue, 11 Jun 2002 18:57:36 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I'm torn, I don't want to make this sort of change late on but I think it would be a good thing in the long term. How about adding the additional async message code and saying upon receipt the initiator MAY start a negotiation sequence or logout and re-login the connection immediately without having to wait for the negotiated timeouts? - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Tuesday, June 11, 2002 4:28 PM To: Mallikarjun C. Cc: ips@ece.cmu.edu; Julian Satran; owner-ips@ece.cmu.edu Subject: Re: iSCSI: changing MaxPDUDataLength Importance: High Mallikarjun, The question was general and not specific to MaxRecv.... Although we say that negotiation is symmetric we don't have any mechanism through which a target can say it wants to start negotiation something (sort of similar but not as strong as a the "request logout" - "request to negotiate" that will require the initiator to issue a text request and kick-off a negotiation. Julo "Mallikarjun C." To: , Julian Satran/Haifa/IBM@IBMIL Sent by: cc: owner-ips@ece.cmu Subject: Re: iSCSI: changing MaxPDUDataLength .edu 06/11/2002 10:50 PM Please respond to "Mallikarjun C." > I also realized that we don't have "negotiation prompt" from the target. > I am not sure that we need one. I am not sure about it either. My preference is not to add this. It appears to me that a target does have the option of dropping the connection today if it can't work with non-ULPDU-contained segments for too long. I suspect that the target would do the same if (we introduced the "negotiation prompt" and) the initiator doesn't/couldn't honor the "negotiation prompt". Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Julian Satran" To: Sent: Tuesday, June 11, 2002 8:34 AM Subject: RE: iSCSI: changing MaxPDUDataLength > I suggest the following text in 11.13 > > A change of MaxRecvDataSegmentLength by an initiator or target > becomes effective after all commands preceding the negotiation > end-ing request have been processed by the target and their status > is acknowledged. > > I also realized that we don't have "negotiation prompt" from the target. > I am not sure that we need one. > If some of you think we need we may want one additional code in the Asynch > Message. > Please comment TODAY. > > Julo > ----- Forwarded by Julian Satran/Haifa/IBM on 06/11/2002 06:29 PM ----- > > Julian Satran > To: Eddy Quicksall > 06/11/2002 04:04 cc: ips@ece.cmu.edu, pat_thaler@agilent.com > PM From: Julian Satran/Haifa/IBM@IBMIL > Subject: RE: iSCSI: changing MaxPDUDataLength(Document link: Julian Satran - Mail) > > > > > > > > > > That is a fair request - we may slip in a recommendation to that effect (in > chapter 11?) > > Julo > > > > Eddy Quicksall > vivity.com> cc: ips@ece.cmu.edu, pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > 06/11/2002 04:28 > AM > Please respond to > Eddy Quicksall > > > > > > How about if we say that an initiator must not change the MaxPDUDataSize > unless it first idles the commands (at least the ones with the R bit) or if > ErrorRecoveryLevel==0? > > That would simplify target code greatly and would meet the design goals; > and since it should be rare to change it, it would be of little impact to > idle the commands for a split second. > > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Monday, June 10, 2002 8:06 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > I said only that when you change length you can ask for all PDUs > after the ack! (no need to keep a tall - the old offsets are good up > to the hole). > > Julo > > > Eddy Quicksall > To: Julian > Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu, > 06/11/2002 12:32 AM pat_thaler@agilent.com > Please respond to Eddy Quicksall Subject: RE: iSCSI: > changing MaxPDUDataLength > > > > > > > > Julian, > > Another problem here is that the target has to calculate the offset > from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and > RunLngth=0 means starting DataSN=4, send all the data for that > sequence. > > I think it would be a performance hit and waist of memory to keep a > tally of all PDU sizes just for an occasional SNACK. > > It's not that it can't be done ... it is more that it is messy and I > think there is a solution that will satisfy the design requirements > but keep the software simpler. > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Saturday, June 08, 2002 10:16 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > That is not completely accurate. > The only problem is when PDU size decreases and then SNACK must be > for all data. > Target can also keep a mapping of numbers/to offsets (the list should > be small and if it gets long ask for ack (A-bit). > > Julo > > Eddy Quicksall > To: > Sent by: owner-ips@ece.cmu.edu pat_thaler@agilent.com > cc: ips@ece.cmu.edu > Subject: RE: iSCSI: > 06/08/2002 10:54 PM changing MaxPDUDataLength > Please respond to Eddy Quicksall > > > > > > > > Thanks, > > As a target, I won't be able to let it change until all of the > outstanding > commands are finished (running with ErrorRecoveryLevel>=1). This is > because > I must use the PDU size to compute the offset from a SNACK's > BegRun/RunLength. > > So, I plan to not give the text response for a MaxPDURecvDataLength > in FFP > until I get back an ExpStatSN == next StatSN. > > This will cause a delay of unknown time before the PDU size can > actually > change ... do you see any problem with this? > > Eddy > > -----Original Message----- > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > Sent: Friday, June 07, 2002 1:13 PM > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > Subject: RE: iSCSI: changing MaxPDUDataLength > > > Eddy, > > If one uses a message sync and steering that relys on the transport > segments > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the > path > MTU changes one would want to change the PDU data length to fit the > new path > MTU. > > Pat > > -----Original Message----- > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > Sent: Wednesday, June 05, 2002 12:24 PM > To: ips@ece.cmu.edu > Subject: iSCSI: changing MaxPDUDataLength > > > Does anybody know a case where it is necessary to support a new PDU > data > length during full feature phase? > > Eddy > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > > > From owner-ips@ece.cmu.edu Tue Jun 11 20:26:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17603 for ; Tue, 11 Jun 2002 20:26:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BNjY512669 for ips-outgoing; Tue, 11 Jun 2002 19:45:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BNjWw12664 for ; Tue, 11 Jun 2002 19:45:32 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 19:45:32 -0400 Message-ID: From: Eddy Quicksall To: "Mallikarjun C." , Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Date: Tue, 11 Jun 2002 19:45:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Consider the following (using Julian's suggestion): -> cmd 1 -> req to change to length 2 -> cmd 2 <- stat 1 <- data 2, PDU 0, Length 1 -> cmd 3, ack 1 so change the length <- data 2, PDU 1, Length 2 -> SNACK data 2, PDU 1 So we have to calculate the offset for Data 2, PDU 1 using old length and send data after that offset using new length. That means keeping track of PDU lengths which I would like to avoid. Or, the target would have to force idling of commands before it gives the response to the change. Can you suggest how this would be handled otherwise? Eddy -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com] Sent: Tuesday, June 11, 2002 6:57 PM To: Eddy Quicksall; Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iSCSI: changing MaxPDUDataLength Eddy, I am not sure if you're agreeing with me or not... but let me add some comments. I don't expect the change in PDU size to happen frequently - no change in what I earlier said. You are making an assumption that a target must record the PDU size for every PDU if SNACKs are to be satisfied across changed MaxRecvDataSegmentLength. As Julian earlier said, you don't have to. I will not go into implementation details, but I believe just the value of the DataSN from which the new size is effective should be all that's needed. Besides, the spec guarantees that only RunLength=0 is used on any SNACK after the change. You are also implying that targets can declare their changed MaxRecvDataSegmentLength anytime just for writes. There are two problems with this - a) reads and writes may both be active in the typical case on an iSCSI connection, and b) a target can declare its changed value only if an initiator is allowed to start the Text Request (and I thought you were suggesting that we explicitly disallow that). Hope that clears it up. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Eddy Quicksall" To: "Mallikarjun C." ; "Julian Satran" Cc: Sent: Tuesday, June 11, 2002 3:18 PM Subject: RE: iSCSI: changing MaxPDUDataLength > You are correct and that is exactly how I have had to code it. With fast > path and slow path code split between processors, it becomes even worse. > > When I read your comments on why the PDU size could change (from way back in > March I think), I got did not get the impression that it would happen very > often and that in fact it may only happen when you are maintaining > allegiance to another connection. > > If it is something that is not going to happen very often, then it would be > so much easier to have the initiator idle the commands first (all it really > needs to do is idle the READ commands). If it is going to change so often > that idling would be degrading, I suspect that just doing the negotiation > that often would itself be degrading. > > And, be aware that the target will probably idle the R commands. Otherwise, > it will have to track PDU sizes and that would be really > "counter-productive" (especially when there should be no SNACKs on a good > connection anyway). > > I don't see any problem with the target negotiating its size at any time. > And the initiator would not have to idle the WRITE or no-data commands. > > Eddy > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Tuesday, June 11, 2002 3:35 PM > To: Eddy Quicksall; Julian Satran > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: changing MaxPDUDataLength > > > Eddy, > > I am not clear on why you think the target code becomes messy on > a PDU size change. The last para in section 4.4 states the following - > > "Parameters negotiated by a text exchange negotiation sequence become > effective only after the negotiation sequence is completed." > > Since the target gets to complete a text negotiation with a Text Response > PDU, it can time the applicability of a changed MaxRecvDataSegmentLength. > > Requiring that an initiator must idle the connection before changing this > parameter, IMHO, is counter-productive when there's a dynamic PMTU > degradation in the presence of long-running commands (writes in particular). > Once the initiator starts the renegotiation, target would ideally want to > quickly > renegotiate its receive size as well to receive ULPDU-contained segments. > > In short, seems to me that the draft is saying what you would like. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > > ----- Original Message ----- > From: "Eddy Quicksall" > To: "Julian Satran" > Cc: > Sent: Tuesday, June 11, 2002 7:56 AM > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > I think it should be a requirement because if it is not, all target code > > will have to have the messy code. Or, we could say that if it is not idle > > commands, then the target may reject it. > > > > Eddy > > > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Tuesday, June 11, 2002 9:11 AM > > To: Eddy Quicksall > > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > That is a fair request - we may slip in a recommendation to that effect > (in > > chapter 11?) > > > > Julo > > > > > > > > Eddy Quicksall > > > > > > 06/11/2002 04:28 AM > > Please respond to Eddy Quicksall > > > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > How about if we say that an initiator must not change the MaxPDUDataSize > > unless it first idles the commands (at least the ones with the R bit) or > if > > ErrorRecoveryLevel==0? > > > > That would simplify target code greatly and would meet the design goals; > and > > since it should be rare to change it, it would be of little impact to idle > > the commands for a split second. > > > > > > Eddy > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Monday, June 10, 2002 8:06 PM > > To: Eddy Quicksall > > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > I said only that when you change length you can ask for all PDUs after the > > ack! (no need to keep a tall - the old offsets are good up to the hole). > > > > Julo > > > > > > Eddy Quicksall > > > > > > 06/11/2002 12:32 AM > > Please respond to Eddy Quicksall > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > Julian, > > > > Another problem here is that the target has to calculate the offset from > the > > DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 > > means starting DataSN=4, send all the data for that sequence. > > > > I think it would be a performance hit and waist of memory to keep a tally > of > > all PDU sizes just for an occasional SNACK. > > > > It's not that it can't be done ... it is more that it is messy and I think > > there is a solution that will satisfy the design requirements but keep the > > software simpler. > > > > Eddy > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Saturday, June 08, 2002 10:16 PM > > To: Eddy Quicksall > > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > That is not completely accurate. > > The only problem is when PDU size decreases and then SNACK must be for all > > data. > > Target can also keep a mapping of numbers/to offsets (the list should be > > small and if it gets long ask for ack (A-bit). > > > > Julo > > > > Eddy Quicksall > > Sent by: owner-ips@ece.cmu.edu > > > > > > 06/08/2002 10:54 PM > > Please respond to Eddy Quicksall > > > > > > To: pat_thaler@agilent.com > > cc: ips@ece.cmu.edu > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > > > Thanks, > > > > As a target, I won't be able to let it change until all of the outstanding > > commands are finished (running with ErrorRecoveryLevel>=1). This is > because > > I must use the PDU size to compute the offset from a SNACK's > > BegRun/RunLength. > > > > So, I plan to not give the text response for a MaxPDURecvDataLength in FFP > > until I get back an ExpStatSN == next StatSN. > > > > This will cause a delay of unknown time before the PDU size can actually > > change ... do you see any problem with this? > > > > Eddy > > > > -----Original Message----- > > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > > Sent: Friday, June 07, 2002 1:13 PM > > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > Eddy, > > > > If one uses a message sync and steering that relys on the transport > segments > > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path > > MTU changes one would want to change the PDU data length to fit the new > path > > MTU. > > > > Pat > > > > -----Original Message----- > > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > > Sent: Wednesday, June 05, 2002 12:24 PM > > To: ips@ece.cmu.edu > > Subject: iSCSI: changing MaxPDUDataLength > > > > > > Does anybody know a case where it is necessary to support a new PDU data > > length during full feature phase? > > > > Eddy > > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Tue Jun 11 21:52:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19792 for ; Tue, 11 Jun 2002 21:52:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5C0uN515899 for ips-outgoing; Tue, 11 Jun 2002 20:56:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5C0uLw15895 for ; Tue, 11 Jun 2002 20:56:21 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel10.hp.com (Postfix) with ESMTP id 9167DC0040E; Tue, 11 Jun 2002 17:56:15 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id RAA06663; Tue, 11 Jun 2002 17:55:39 -0700 (PDT) Message-ID: <011101c211ab$9d3dfb80$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Eddy Quicksall" , "Julian Satran" Cc: References: Subject: Re: iSCSI: changing MaxPDUDataLength Date: Tue, 11 Jun 2002 17:53:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Can you suggest how this would be handled otherwise? I earlier said I will not get into implementation details, I will however provide a generic answer. Given that the changed PDU size is not specific to one command, I see the history of "past max PDU size(s)" as a connection attribute. All you need on a per-task basis is really the value of one DataSN *where* it had changed. We could further debate how to deal with multiple number of PDU size changes during the life of an I/O - but I'm reluctant to be involved in that debate because a) it's most unlikely, and b) there's no hard requirement that the target must always satisfy SNACKs under extreme conditions, and finally c) it's too implementation-specific to be discussed on the ips reflector. Finally, I'd like to remind you that mandating "no text negotiation till quiesced" has harmful effects on targets dealing with long writes and wanting ULPDU- containment - whose case you may be arguing. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Eddy Quicksall" To: "Mallikarjun C." ; "Julian Satran" Cc: Sent: Tuesday, June 11, 2002 4:45 PM Subject: RE: iSCSI: changing MaxPDUDataLength > Consider the following (using Julian's suggestion): > > -> cmd 1 > -> req to change to length 2 > -> cmd 2 > > <- stat 1 > <- data 2, PDU 0, Length 1 > > -> cmd 3, ack 1 so change the length > > <- data 2, PDU 1, Length 2 > > -> SNACK data 2, PDU 1 > > So we have to calculate the offset for Data 2, PDU 1 using old length and > send data after that offset using new length. That means keeping track of > PDU lengths which I would like to avoid. > > Or, the target would have to force idling of commands before it gives the > response to the change. > > Can you suggest how this would be handled otherwise? > > Eddy > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Tuesday, June 11, 2002 6:57 PM > To: Eddy Quicksall; Julian Satran > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: changing MaxPDUDataLength > > > Eddy, > > I am not sure if you're agreeing with me or not... but let me add some > comments. > > I don't expect the change in PDU size to happen frequently - no change > in what I earlier said. > > You are making an assumption that a target must record the PDU size for > every > PDU if SNACKs are to be satisfied across changed MaxRecvDataSegmentLength. > > As Julian earlier said, you don't have to. I will not go into > implementation details, but > I believe just the value of the DataSN from which the new size is effective > should > be all that's needed. Besides, the spec guarantees that only RunLength=0 is > used > on any SNACK after the change. > > You are also implying that targets can declare their changed > MaxRecvDataSegmentLength > anytime just for writes. There are two problems with this - a) reads and > writes may both > be active in the typical case on an iSCSI connection, and b) a target can > declare its changed > value only if an initiator is allowed to start the Text Request (and I > thought you were suggesting > that we explicitly disallow that). > > Hope that clears it up. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > > ----- Original Message ----- > From: "Eddy Quicksall" > To: "Mallikarjun C." ; "Julian Satran" > > Cc: > Sent: Tuesday, June 11, 2002 3:18 PM > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > You are correct and that is exactly how I have had to code it. With fast > > path and slow path code split between processors, it becomes even worse. > > > > When I read your comments on why the PDU size could change (from way back > in > > March I think), I got did not get the impression that it would happen very > > often and that in fact it may only happen when you are maintaining > > allegiance to another connection. > > > > If it is something that is not going to happen very often, then it would > be > > so much easier to have the initiator idle the commands first (all it > really > > needs to do is idle the READ commands). If it is going to change so often > > that idling would be degrading, I suspect that just doing the negotiation > > that often would itself be degrading. > > > > And, be aware that the target will probably idle the R commands. > Otherwise, > > it will have to track PDU sizes and that would be really > > "counter-productive" (especially when there should be no SNACKs on a good > > connection anyway). > > > > I don't see any problem with the target negotiating its size at any time. > > And the initiator would not have to idle the WRITE or no-data commands. > > > > Eddy > > > > -----Original Message----- > > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > > Sent: Tuesday, June 11, 2002 3:35 PM > > To: Eddy Quicksall; Julian Satran > > Cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: changing MaxPDUDataLength > > > > > > Eddy, > > > > I am not clear on why you think the target code becomes messy on > > a PDU size change. The last para in section 4.4 states the following - > > > > "Parameters negotiated by a text exchange negotiation sequence become > > effective only after the negotiation sequence is completed." > > > > Since the target gets to complete a text negotiation with a Text Response > > PDU, it can time the applicability of a changed MaxRecvDataSegmentLength. > > > > Requiring that an initiator must idle the connection before changing this > > parameter, IMHO, is counter-productive when there's a dynamic PMTU > > degradation in the presence of long-running commands (writes in > particular). > > Once the initiator starts the renegotiation, target would ideally want to > > quickly > > renegotiate its receive size as well to receive ULPDU-contained segments. > > > > In short, seems to me that the draft is saying what you would like. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > > cbm@rose.hp.com > > > > > > ----- Original Message ----- > > From: "Eddy Quicksall" > > To: "Julian Satran" > > Cc: > > Sent: Tuesday, June 11, 2002 7:56 AM > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > I think it should be a requirement because if it is not, all target code > > > will have to have the messy code. Or, we could say that if it is not > idle > > > commands, then the target may reject it. > > > > > > Eddy > > > > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Tuesday, June 11, 2002 9:11 AM > > > To: Eddy Quicksall > > > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > That is a fair request - we may slip in a recommendation to that effect > > (in > > > chapter 11?) > > > > > > Julo > > > > > > > > > > > > Eddy Quicksall > > > > > > > > > 06/11/2002 04:28 AM > > > Please respond to Eddy Quicksall > > > > > > > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > > > > How about if we say that an initiator must not change the MaxPDUDataSize > > > unless it first idles the commands (at least the ones with the R bit) or > > if > > > ErrorRecoveryLevel==0? > > > > > > That would simplify target code greatly and would meet the design goals; > > and > > > since it should be rare to change it, it would be of little impact to > idle > > > the commands for a split second. > > > > > > > > > Eddy > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Monday, June 10, 2002 8:06 PM > > > To: Eddy Quicksall > > > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > I said only that when you change length you can ask for all PDUs after > the > > > ack! (no need to keep a tall - the old offsets are good up to the hole). > > > > > > > Julo > > > > > > > > > Eddy Quicksall > > > > > > > > > 06/11/2002 12:32 AM > > > Please respond to Eddy Quicksall > > > > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > > > > > > > Julian, > > > > > > Another problem here is that the target has to calculate the offset from > > the > > > DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 > > > means starting DataSN=4, send all the data for that sequence. > > > > > > I think it would be a performance hit and waist of memory to keep a > tally > > of > > > all PDU sizes just for an occasional SNACK. > > > > > > It's not that it can't be done ... it is more that it is messy and I > think > > > there is a solution that will satisfy the design requirements but keep > the > > > software simpler. > > > > > > Eddy > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Saturday, June 08, 2002 10:16 PM > > > To: Eddy Quicksall > > > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > That is not completely accurate. > > > The only problem is when PDU size decreases and then SNACK must be for > all > > > data. > > > Target can also keep a mapping of numbers/to offsets (the list should be > > > small and if it gets long ask for ack (A-bit). > > > > > > Julo > > > > > > Eddy Quicksall > > > Sent by: owner-ips@ece.cmu.edu > > > > > > > > > 06/08/2002 10:54 PM > > > Please respond to Eddy Quicksall > > > > > > > > > To: pat_thaler@agilent.com > > > cc: ips@ece.cmu.edu > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > As a target, I won't be able to let it change until all of the > outstanding > > > commands are finished (running with ErrorRecoveryLevel>=1). This is > > because > > > I must use the PDU size to compute the offset from a SNACK's > > > BegRun/RunLength. > > > > > > So, I plan to not give the text response for a MaxPDURecvDataLength in > FFP > > > until I get back an ExpStatSN == next StatSN. > > > > > > This will cause a delay of unknown time before the PDU size can actually > > > change ... do you see any problem with this? > > > > > > Eddy > > > > > > -----Original Message----- > > > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > > > Sent: Friday, June 07, 2002 1:13 PM > > > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > Eddy, > > > > > > If one uses a message sync and steering that relys on the transport > > segments > > > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the > path > > > MTU changes one would want to change the PDU data length to fit the new > > path > > > MTU. > > > > > > Pat > > > > > > -----Original Message----- > > > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > > > Sent: Wednesday, June 05, 2002 12:24 PM > > > To: ips@ece.cmu.edu > > > Subject: iSCSI: changing MaxPDUDataLength > > > > > > > > > Does anybody know a case where it is necessary to support a new PDU data > > > length during full feature phase? > > > > > > Eddy > > > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Tue Jun 11 21:56:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19842 for ; Tue, 11 Jun 2002 21:56:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5C1B4916541 for ips-outgoing; Tue, 11 Jun 2002 21:11:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5C1B2w16536 for ; Tue, 11 Jun 2002 21:11:02 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel11.hp.com (Postfix) with ESMTP id C342B60044C; Tue, 11 Jun 2002 18:10:56 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id SAA10416; Tue, 11 Jun 2002 18:12:45 -0700 (PDT) Message-ID: <012001c211ae$00baa990$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Julian Satran" Cc: References: Subject: Re: iSCSI: changing MaxPDUDataLength Date: Tue, 11 Jun 2002 18:10:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, I knew that the question was general, but I couldn't find any other key whose redeclaration/renegotiation is important during the life of a connection - and the proposed didn't look very useful for this key. Consequently, I don't see a strong reason for the addition except for completeness. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Julian Satran" To: "Mallikarjun C." Cc: ; "Julian Satran" ; Sent: Tuesday, June 11, 2002 2:28 PM Subject: Re: iSCSI: changing MaxPDUDataLength > > Mallikarjun, > > The question was general and not specific to MaxRecv.... > Although we say that negotiation is symmetric we don't have any mechanism > through which a target can say it wants to start negotiation something > (sort of similar but not as strong as a the "request logout" - "request to > negotiate" that will require the initiator to issue a text request and > kick-off a negotiation. > > Julo > > > > "Mallikarjun C." > To: , Julian Satran/Haifa/IBM@IBMIL > Sent by: cc: > owner-ips@ece.cmu Subject: Re: iSCSI: changing MaxPDUDataLength > .edu > > > 06/11/2002 10:50 > PM > Please respond to > "Mallikarjun C." > > > > > > > I also realized that we don't have "negotiation prompt" from the target. > > I am not sure that we need one. > > I am not sure about it either. > > My preference is not to add this. It appears to me that a target does have > the option of dropping the connection today if it can't work with > non-ULPDU-contained > segments for too long. I suspect that the target would do the same if (we > introduced the "negotiation prompt" and) the initiator doesn't/couldn't > honor the > "negotiation prompt". > > Thanks. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > > ----- Original Message ----- > From: "Julian Satran" > To: > Sent: Tuesday, June 11, 2002 8:34 AM > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > I suggest the following text in 11.13 > > > > A change of MaxRecvDataSegmentLength by an initiator or target > > becomes effective after all commands preceding the negotiation > > end-ing request have been processed by the target and their status > > is acknowledged. > > > > I also realized that we don't have "negotiation prompt" from the target. > > I am not sure that we need one. > > If some of you think we need we may want one additional code in the > Asynch > > Message. > > Please comment TODAY. > > > > Julo > > ----- Forwarded by Julian Satran/Haifa/IBM on 06/11/2002 06:29 PM ----- > > > > Julian Satran > > To: Eddy Quicksall > > > 06/11/2002 04:04 cc: ips@ece.cmu.edu, > pat_thaler@agilent.com > > > PM From: Julian > Satran/Haifa/IBM@IBMIL > > Subject: RE: iSCSI: > changing MaxPDUDataLength(Document link: > Julian Satran - Mail) > > > > > > > > > > > > > > > > > > > > That is a fair request - we may slip in a recommendation to that effect > (in > > chapter 11?) > > > > Julo > > > > > > > > Eddy Quicksall > > Satran/Haifa/IBM@IBMIL > > vivity.com> cc: ips@ece.cmu.edu, > pat_thaler@agilent.com > > Subject: RE: iSCSI: > changing MaxPDUDataLength > > 06/11/2002 04:28 > > AM > > Please respond to > > Eddy Quicksall > > > > > > > > > > > > How about if we say that an initiator must not change the MaxPDUDataSize > > unless it first idles the commands (at least the ones with the R bit) or > if > > ErrorRecoveryLevel==0? > > > > That would simplify target code greatly and would meet the design goals; > > and since it should be rare to change it, it would be of little impact to > > idle the commands for a split second. > > > > > > Eddy > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Monday, June 10, 2002 8:06 PM > > To: Eddy Quicksall > > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > I said only that when you change length you can ask for all PDUs > > after the ack! (no need to keep a tall - the old offsets are good > up > > to the hole). > > > > Julo > > > > > > Eddy Quicksall > > To: Julian > > Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu, > > 06/11/2002 12:32 AM pat_thaler@agilent.com > > Please respond to Eddy Quicksall Subject: RE: iSCSI: > > changing MaxPDUDataLength > > > > > > > > > > > > > > > > Julian, > > > > Another problem here is that the target has to calculate the offset > > from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 > and > > RunLngth=0 means starting DataSN=4, send all the data for that > > sequence. > > > > I think it would be a performance hit and waist of memory to keep a > > tally of all PDU sizes just for an occasional SNACK. > > > > It's not that it can't be done ... it is more that it is messy and > I > > think there is a solution that will satisfy the design requirements > > but keep the software simpler. > > > > Eddy > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Saturday, June 08, 2002 10:16 PM > > To: Eddy Quicksall > > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > That is not completely accurate. > > The only problem is when PDU size decreases and then SNACK must be > > for all data. > > Target can also keep a mapping of numbers/to offsets (the list > should > > be small and if it gets long ask for ack (A-bit). > > > > Julo > > > > Eddy Quicksall > > To: > > Sent by: owner-ips@ece.cmu.edu pat_thaler@agilent.com > > cc: ips@ece.cmu.edu > > Subject: RE: iSCSI: > > 06/08/2002 10:54 PM changing MaxPDUDataLength > > Please respond to Eddy Quicksall > > > > > > > > > > > > > > > > Thanks, > > > > As a target, I won't be able to let it change until all of the > > outstanding > > commands are finished (running with ErrorRecoveryLevel>=1). This is > > because > > I must use the PDU size to compute the offset from a SNACK's > > BegRun/RunLength. > > > > So, I plan to not give the text response for a MaxPDURecvDataLength > > in FFP > > until I get back an ExpStatSN == next StatSN. > > > > This will cause a delay of unknown time before the PDU size can > > actually > > change ... do you see any problem with this? > > > > Eddy > > > > -----Original Message----- > > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > > Sent: Friday, June 07, 2002 1:13 PM > > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > Eddy, > > > > If one uses a message sync and steering that relys on the transport > > segments > > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if > the > > path > > MTU changes one would want to change the PDU data length to fit the > > new path > > MTU. > > > > Pat > > > > -----Original Message----- > > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > > Sent: Wednesday, June 05, 2002 12:24 PM > > To: ips@ece.cmu.edu > > Subject: iSCSI: changing MaxPDUDataLength > > > > > > Does anybody know a case where it is necessary to support a new PDU > > data > > length during full feature phase? > > > > Eddy > > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Tue Jun 11 22:49:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21143 for ; Tue, 11 Jun 2002 22:49:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5C24s218821 for ips-outgoing; Tue, 11 Jun 2002 22:04:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail1irv.inside.istor.com (host28.istor.com [66.134.214.28]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5C24qw18816 for ; Tue, 11 Jun 2002 22:04:52 -0400 (EDT) Subject: target reset From: Michael Morrison To: iSCSI Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-MvKxF2JWqAi0eNtltSza" X-Mailer: Ximian Evolution 1.0.5 Date: 11 Jun 2002 19:04:22 -0400 Message-Id: <1023836662.3588.125.camel@jackal.engasic.istor.com> Mime-Version: 1.0 Sender: owner-ips@ece.cmu.edu Precedence: bulk --=-MvKxF2JWqAi0eNtltSza Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On page 148 of draft 12-97, in the paragraph ... "For the TARGET WARM RESET and TARGET COLD RESET functions, the target cancels all pending operations. Both functions are equivalent to the=20 Target Reset function specified by [SAM2]. They can affect many other initiators" In these cases, SAM2 refers to Logical Unit Reset, which refers to Aborting Tasks.=20 This implies to me that TARGET RESET (WARM or COLD) is equivalent to CLEAR TASK SET. The behavior in the iSCSI draft for CLEAR TASK SET is fairly well described. Is the=20 description presented in the discussion on CLEAR TASK SET supposed to define "cancels all pending operations?" Or does this statement have another meaning? =20 --=20 Michael Morrison mmorrison@istor.com ISTOR Networks 7585 Irvine Center Dr. Ste 250 Irvine Ca. 92618 PGP Key ID: http://pgp.mit.edu:11371/pks/lookup?search=3D0x74C30155&op=3Dindex --=-MvKxF2JWqAi0eNtltSza Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9BoH2j+YUdnTDAVURApBPAJ9Dc7AmAWMHcyB2v26UuHbbqgVIqgCgkTGD nq9aUr9GhBvfEa6CL0mWAuc= =bV6Q -----END PGP SIGNATURE----- --=-MvKxF2JWqAi0eNtltSza-- From owner-ips@ece.cmu.edu Tue Jun 11 23:54:55 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22440 for ; Tue, 11 Jun 2002 23:54:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5C3Km821952 for ips-outgoing; Tue, 11 Jun 2002 23:20:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from med.corp.rhapsodynetworks.com (64-160-62-201.rhapsodynetworks.com [64.160.62.201] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5C3Klw21947 for ; Tue, 11 Jun 2002 23:20:47 -0400 (EDT) Received: by med.corp.rhapsodynetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 20:20:41 -0700 Message-ID: <45BEF1D68145D51186C100B0D0AABE659E0169@med.corp.rhapsodynetworks.com> From: Dennis Young To: ips@ece.cmu.edu Subject: iscsi: unsolicited data question Date: Tue, 11 Jun 2002 20:20:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I have a question which has been asked before, but I couldn't find a direct answer in the archive. The table on page 200 of draft 12 doesn't directly answer this question either. The first paragraph on page 36 of draft 12 says "Targets operate in either solicitied (R2T) data mode or unsolicited (non R2T) data mode." tells me that a target, at all times during a data sequence transfer, can be one or the other, but not both (non R2T for the initial data out, R2T for the remaining data). Is this correct? Thanks, Dennis ---snip from an old email dated 3/30/2001--- " Hi Julian Sorry if I'm covering old ground... Is it possible to use unsolicited data for the first burst and then request any remaining data using R2T? For example, if the target has a previously allocated buffer available (length defined by FirstBurstSize) for unsolicited data, then once the initiator has sent unsolicited data up to and including this amount then the remaining data (if any) can be requested using R2T once the target has the buffer space available. ...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail: matthewb@bri.hp.com " From owner-ips@ece.cmu.edu Wed Jun 12 01:23:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24783 for ; Wed, 12 Jun 2002 01:23:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5C4c8025252 for ips-outgoing; Wed, 12 Jun 2002 00:38:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hclnpd.hclt.co.in ([202.54.64.7]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5C4c6w25248 for ; Wed, 12 Jun 2002 00:38:06 -0400 (EDT) Received: from mailnpd.hclt-ntl.co.in ([192.168.19.36]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MR12SYJZ; Wed, 12 Jun 2002 10:07:13 +0530 Received: from priya-pc.hclt-ntl.co.in (priya-pc.hclt-ntl.co.in [192.168.19.88]) by mailnpd.hclt-ntl.co.in (8.11.0/8.11.0) with SMTP id g5C4UdL08926; Wed, 12 Jun 2002 10:00:40 +0530 Content-Type: text/plain; charset="iso-8859-1" From: Priya Viswambharan To: Dennis Young , ips@ece.cmu.edu Subject: Re: iscsi: unsolicited data question Date: Wed, 12 Jun 2002 10:04:58 +0530 X-Mailer: KMail [version 1.2] References: <45BEF1D68145D51186C100B0D0AABE659E0169@med.corp.rhapsodynetworks.com> In-Reply-To: <45BEF1D68145D51186C100B0D0AABE659E0169@med.corp.rhapsodynetworks.com> MIME-Version: 1.0 Message-Id: <0206121004580K.01202@priya-pc.hclt-ntl.co.in> Content-Transfer-Encoding: 8bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi Dennis, These parameters ImmediateData and InitialR2T are session specific parameters that are negotiated during the Leading Only negotiations. Once negotiated they hold true for the life of the session because parameters once negotiated cannot be renegotiated. If a target is operating in unsolicited mode, then the unsolicited mode is only for the initial data that the initiator wants to send to the target. In other words, for a target in unsolicited mode, the initiator does not have to wait for an R2T from the target to start sending data. Such unsolicited data may be sent either in the form of immediate data or through DATA Out PDUs. The maximum amount of unsolicited data that can be sent is up to the FirstBurstSize negotiated. If the initiator has more data to send then it must necessarily be solicited by the target through R2Ts. Hope this clarifies. Thanks Priya On Wednesday 12 June 2002 08:50 am, Dennis Young wrote: > I have a question which has been asked before, but I > couldn't find a direct answer in the archive. The table > on page 200 of draft 12 doesn't directly answer this > question either. > > The first paragraph on page 36 of draft 12 says "Targets > operate in either solicitied (R2T) data mode or > unsolicited (non R2T) data mode." tells me that a target, > at all times during a data sequence transfer, can be > > one or the other, but not both (non R2T for the initial > data out, R2T for the > remaining data). Is this correct? > > Thanks, > Dennis > > ---snip from an old email dated 3/30/2001--- > > " Hi Julian > Sorry if I'm covering old ground... Is it possible to use > unsolicited data for the first burst and then request any > remaining data using R2T? For example, if the target has > a previously allocated buffer available (length defined > by FirstBurstSize) for unsolicited data, then once the > initiator has sent unsolicited data up to and including > this amount then the remaining data (if any) can be > requested using R2T once the target has the buffer space > available. > ...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 > 7010 E-mail: matthewb@bri.hp.com " _________________________________________________ HCL Technologies, Chennai, India http://san.hcltech.com From owner-ips@ece.cmu.edu Wed Jun 12 01:23:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24787 for ; Wed, 12 Jun 2002 01:23:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5C53Nr26237 for ips-outgoing; Wed, 12 Jun 2002 01:03:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hclnpd.hclt.co.in ([202.54.64.7]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5C53Kw26229 for ; Wed, 12 Jun 2002 01:03:20 -0400 (EDT) Received: from mailnpd.hclt-ntl.co.in ([192.168.19.36]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MR12SYWK; Wed, 12 Jun 2002 10:32:26 +0530 Received: from npd.hcltech.com (IDENT:tskariah@tskariah-pc.hclt-ntl.co.in [192.168.19.72]) by mailnpd.hclt-ntl.co.in (8.11.0/8.11.0) with ESMTP id g5C4tqL09752; Wed, 12 Jun 2002 10:25:52 +0530 Message-ID: <3D06D575.E9FB8A28@npd.hcltech.com> Date: Wed, 12 Jun 2002 10:30:37 +0530 From: Thanu Skariah X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Dennis Young CC: ips@ece.cmu.edu Subject: Re: iscsi: unsolicited data question References: <45BEF1D68145D51186C100B0D0AABE659E0169@med.corp.rhapsodynetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit A target can operate in nonR2T (unsolicited) mode for initial data out and in solicited mode for the remaining data. Also if the ImmediateData=Yes is the agreed value during negotiation, then it will operate in unsolicited mode upto a data size of negotiated maximum PDU size. If during login negotiation, InitialR2T=No is the agreed value, then the initiator and the target will operate in unsolicited mode upto a data size of negotiated FirstBurstSize. If InitialR2T is Yes, and immediate data also yes, then target can operate in nonR2T mode for a size of data upto the maxmimum PDU size only. If initialR2T is yes and immediate data is no, then the target cannot operated in nonR2T mode at all. All the data must be solicited in this case. (draft - 12.97,Sec 2.2.3, page 35, last paragraph) Thanks, Thanu Dennis Young wrote: > > I have a question which has been asked before, but I couldn't find a direct > answer in the archive. The table on page 200 of draft 12 doesn't directly > answer this question either. > > The first paragraph on page 36 of draft 12 says "Targets operate in either > solicitied (R2T) data mode or unsolicited (non R2T) data mode." > tells me that a target, at all times during a data sequence transfer, can be > > one or the other, but not both (non R2T for the initial data out, R2T for > the > remaining data). Is this correct? > > Thanks, > Dennis > > ---snip from an old email dated 3/30/2001--- > > " Hi Julian > Sorry if I'm covering old ground... Is it possible to use unsolicited data > for the first burst and then request any remaining data using R2T? For > example, if the target has a previously allocated buffer available (length > defined by FirstBurstSize) for unsolicited data, then once the initiator has > sent unsolicited data up to and including this amount then the remaining > data (if any) can be requested using R2T once the target has the buffer > space available. > ...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail: > matthewb@bri.hp.com " -- Thanu Skariah Member Technical Staff HCL Technologies http://san.hcltech.com From owner-ips@ece.cmu.edu Wed Jun 12 02:15:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05389 for ; Wed, 12 Jun 2002 02:15:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5C5Usw27362 for ips-outgoing; Wed, 12 Jun 2002 01:30:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5C5Urw27358 for ; Wed, 12 Jun 2002 01:30:53 -0400 (EDT) Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.192.94]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5C5SEg5068754; Wed, 12 Jun 2002 01:28:14 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014h.boulder.ibm.com [9.17.194.13]) by westrelay04.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5C5RDO49142; Tue, 11 Jun 2002 23:27:13 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys To: Bill Studenmund Cc: Santosh Rao , X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Tue, 11 Jun 2002 22:26:16 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 06/11/2002 11:28:13 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Let me state again, this will not fly, please take it off this reflector and take it to SNIA or any where else. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Bill Studenmund @ece.cmu.edu on 06/11/2002 12:49:49 PM Sent by: owner-ips@ece.cmu.edu To: Santosh Rao cc: Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys On Tue, 11 Jun 2002, Santosh Rao wrote: > I don't see why this thread is going forever. There are other scsi > transports that deal with these types of issues without having to define > scsi transport protocol keys to indicate vendor_id, product_id and > product_rev. You can do one of the following : > > a) Parse out the DNS name of the target device from the exchanged > TargetName key, if you're an initiator. Similarly, parse out the DNS > name of the initiator from the exchanged InitiatorName key, if you're a > target. Use the DNS name as an indication of which device you're > speaking to and add your device specific tweaks based on this. That we can do. But that means that the system adminsitrator or a "smart agent" has to correlate the info. And, if a device moves, it has to get involved again to reconfigure. It could be that this won't be a problem, but it could also be a hassle. > If the InitiatorName or TargetName is in EUI-64 format, you can obtain > the vendor_id information from the upper 3 bytes of the EUI-64 name. That only gets you one of the three keys. :-) The product and revisions are the ones that are more important if we are bug-compensating. :-) > b) Send INQUIRY to LUN 0 to determine the vendor_id, product_id and > product_revisison_level of the device. Use this data to perform any > device specific tweaks in your software/firmware. That assumes that the iscsi device is the same as the scsi device. In the case of an iscsi->FC or iscsi->Parallel SCSI gateway, that's not going to be the case. > c) Provide out-of-band static configuration mechanisms in your initiator > or target to assign a vendor specific identity to 1 or more initiators > or targets. This allows the target configuration personnel to configure > the device appropriately for the initiators it is speaking to. That, like the first option above, involves correlating a lot of info, and keeping it up to date. Sounds like turning a protocol mess into a management mess. > I don't see any need to be defining iscsi login keys to duplicate the > vendor_id, product_id information. Well, that's your opinion. Some of us feel that what you describe above is a hassle we'd rather spare our customers. Especially since happy customers spend more. :-) Take care, Bill From owner-ips@ece.cmu.edu Wed Jun 12 03:45:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19862 for ; Wed, 12 Jun 2002 03:45:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5C6rbD00516 for ips-outgoing; Wed, 12 Jun 2002 02:53:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5C6rZw00511 for ; Wed, 12 Jun 2002 02:53:35 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 02:53:34 -0400 Message-ID: From: Eddy Quicksall To: "Mallikarjun C." Cc: ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Date: Wed, 12 Jun 2002 02:53:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I think you have misunderstood something... I'm not suggesting that you mandate "no text negotiation till quiesced". I'm suggesting that only when Max length changes and then only for the READS. This suggestion is to simplify the logic you point out below. What are the harmful effects you mention below? Eddy -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com] Sent: Tuesday, June 11, 2002 8:54 PM To: Eddy Quicksall; Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iSCSI: changing MaxPDUDataLength > Can you suggest how this would be handled otherwise? I earlier said I will not get into implementation details, I will however provide a generic answer. Given that the changed PDU size is not specific to one command, I see the history of "past max PDU size(s)" as a connection attribute. All you need on a per-task basis is really the value of one DataSN *where* it had changed. We could further debate how to deal with multiple number of PDU size changes during the life of an I/O - but I'm reluctant to be involved in that debate because a) it's most unlikely, and b) there's no hard requirement that the target must always satisfy SNACKs under extreme conditions, and finally c) it's too implementation-specific to be discussed on the ips reflector. Finally, I'd like to remind you that mandating "no text negotiation till quiesced" has harmful effects on targets dealing with long writes and wanting ULPDU- containment - whose case you may be arguing. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Eddy Quicksall" To: "Mallikarjun C." ; "Julian Satran" Cc: Sent: Tuesday, June 11, 2002 4:45 PM Subject: RE: iSCSI: changing MaxPDUDataLength > Consider the following (using Julian's suggestion): > > -> cmd 1 > -> req to change to length 2 > -> cmd 2 > > <- stat 1 > <- data 2, PDU 0, Length 1 > > -> cmd 3, ack 1 so change the length > > <- data 2, PDU 1, Length 2 > > -> SNACK data 2, PDU 1 > > So we have to calculate the offset for Data 2, PDU 1 using old length and > send data after that offset using new length. That means keeping track of > PDU lengths which I would like to avoid. > > Or, the target would have to force idling of commands before it gives the > response to the change. > > Can you suggest how this would be handled otherwise? > > Eddy > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Tuesday, June 11, 2002 6:57 PM > To: Eddy Quicksall; Julian Satran > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: changing MaxPDUDataLength > > > Eddy, > > I am not sure if you're agreeing with me or not... but let me add some > comments. > > I don't expect the change in PDU size to happen frequently - no change > in what I earlier said. > > You are making an assumption that a target must record the PDU size for > every > PDU if SNACKs are to be satisfied across changed MaxRecvDataSegmentLength. > > As Julian earlier said, you don't have to. I will not go into > implementation details, but > I believe just the value of the DataSN from which the new size is effective > should > be all that's needed. Besides, the spec guarantees that only RunLength=0 is > used > on any SNACK after the change. > > You are also implying that targets can declare their changed > MaxRecvDataSegmentLength > anytime just for writes. There are two problems with this - a) reads and > writes may both > be active in the typical case on an iSCSI connection, and b) a target can > declare its changed > value only if an initiator is allowed to start the Text Request (and I > thought you were suggesting > that we explicitly disallow that). > > Hope that clears it up. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > > ----- Original Message ----- > From: "Eddy Quicksall" > To: "Mallikarjun C." ; "Julian Satran" > > Cc: > Sent: Tuesday, June 11, 2002 3:18 PM > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > You are correct and that is exactly how I have had to code it. With fast > > path and slow path code split between processors, it becomes even worse. > > > > When I read your comments on why the PDU size could change (from way back > in > > March I think), I got did not get the impression that it would happen very > > often and that in fact it may only happen when you are maintaining > > allegiance to another connection. > > > > If it is something that is not going to happen very often, then it would > be > > so much easier to have the initiator idle the commands first (all it > really > > needs to do is idle the READ commands). If it is going to change so often > > that idling would be degrading, I suspect that just doing the negotiation > > that often would itself be degrading. > > > > And, be aware that the target will probably idle the R commands. > Otherwise, > > it will have to track PDU sizes and that would be really > > "counter-productive" (especially when there should be no SNACKs on a good > > connection anyway). > > > > I don't see any problem with the target negotiating its size at any time. > > And the initiator would not have to idle the WRITE or no-data commands. > > > > Eddy > > > > -----Original Message----- > > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > > Sent: Tuesday, June 11, 2002 3:35 PM > > To: Eddy Quicksall; Julian Satran > > Cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: changing MaxPDUDataLength > > > > > > Eddy, > > > > I am not clear on why you think the target code becomes messy on > > a PDU size change. The last para in section 4.4 states the following - > > > > "Parameters negotiated by a text exchange negotiation sequence become > > effective only after the negotiation sequence is completed." > > > > Since the target gets to complete a text negotiation with a Text Response > > PDU, it can time the applicability of a changed MaxRecvDataSegmentLength. > > > > Requiring that an initiator must idle the connection before changing this > > parameter, IMHO, is counter-productive when there's a dynamic PMTU > > degradation in the presence of long-running commands (writes in > particular). > > Once the initiator starts the renegotiation, target would ideally want to > > quickly > > renegotiate its receive size as well to receive ULPDU-contained segments. > > > > In short, seems to me that the draft is saying what you would like. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > > cbm@rose.hp.com > > > > > > ----- Original Message ----- > > From: "Eddy Quicksall" > > To: "Julian Satran" > > Cc: > > Sent: Tuesday, June 11, 2002 7:56 AM > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > I think it should be a requirement because if it is not, all target code > > > will have to have the messy code. Or, we could say that if it is not > idle > > > commands, then the target may reject it. > > > > > > Eddy > > > > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Tuesday, June 11, 2002 9:11 AM > > > To: Eddy Quicksall > > > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > That is a fair request - we may slip in a recommendation to that effect > > (in > > > chapter 11?) > > > > > > Julo > > > > > > > > > > > > Eddy Quicksall > > > > > > > > > 06/11/2002 04:28 AM > > > Please respond to Eddy Quicksall > > > > > > > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > > > > How about if we say that an initiator must not change the MaxPDUDataSize > > > unless it first idles the commands (at least the ones with the R bit) or > > if > > > ErrorRecoveryLevel==0? > > > > > > That would simplify target code greatly and would meet the design goals; > > and > > > since it should be rare to change it, it would be of little impact to > idle > > > the commands for a split second. > > > > > > > > > Eddy > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Monday, June 10, 2002 8:06 PM > > > To: Eddy Quicksall > > > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > I said only that when you change length you can ask for all PDUs after > the > > > ack! (no need to keep a tall - the old offsets are good up to the hole). > > > > > > > Julo > > > > > > > > > Eddy Quicksall > > > > > > > > > 06/11/2002 12:32 AM > > > Please respond to Eddy Quicksall > > > > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > > > > > > > Julian, > > > > > > Another problem here is that the target has to calculate the offset from > > the > > > DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 > > > means starting DataSN=4, send all the data for that sequence. > > > > > > I think it would be a performance hit and waist of memory to keep a > tally > > of > > > all PDU sizes just for an occasional SNACK. > > > > > > It's not that it can't be done ... it is more that it is messy and I > think > > > there is a solution that will satisfy the design requirements but keep > the > > > software simpler. > > > > > > Eddy > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Saturday, June 08, 2002 10:16 PM > > > To: Eddy Quicksall > > > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > That is not completely accurate. > > > The only problem is when PDU size decreases and then SNACK must be for > all > > > data. > > > Target can also keep a mapping of numbers/to offsets (the list should be > > > small and if it gets long ask for ack (A-bit). > > > > > > Julo > > > > > > Eddy Quicksall > > > Sent by: owner-ips@ece.cmu.edu > > > > > > > > > 06/08/2002 10:54 PM > > > Please respond to Eddy Quicksall > > > > > > > > > To: pat_thaler@agilent.com > > > cc: ips@ece.cmu.edu > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > As a target, I won't be able to let it change until all of the > outstanding > > > commands are finished (running with ErrorRecoveryLevel>=1). This is > > because > > > I must use the PDU size to compute the offset from a SNACK's > > > BegRun/RunLength. > > > > > > So, I plan to not give the text response for a MaxPDURecvDataLength in > FFP > > > until I get back an ExpStatSN == next StatSN. > > > > > > This will cause a delay of unknown time before the PDU size can actually > > > change ... do you see any problem with this? > > > > > > Eddy > > > > > > -----Original Message----- > > > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > > > Sent: Friday, June 07, 2002 1:13 PM > > > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > Eddy, > > > > > > If one uses a message sync and steering that relys on the transport > > segments > > > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the > path > > > MTU changes one would want to change the PDU data length to fit the new > > path > > > MTU. > > > > > > Pat > > > > > > -----Original Message----- > > > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > > > Sent: Wednesday, June 05, 2002 12:24 PM > > > To: ips@ece.cmu.edu > > > Subject: iSCSI: changing MaxPDUDataLength > > > > > > > > > Does anybody know a case where it is necessary to support a new PDU data > > > length during full feature phase? > > > > > > Eddy > > > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Wed Jun 12 03:45:10 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19875 for ; Wed, 12 Jun 2002 03:45:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5C75WL00984 for ips-outgoing; Wed, 12 Jun 2002 03:05:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5C75Uw00979 for ; Wed, 12 Jun 2002 03:05:30 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 03:05:30 -0400 Message-ID: From: Eddy Quicksall To: "Mallikarjun C." Cc: ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Date: Wed, 12 Jun 2002 03:05:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I just noticed something you said way below: >>You are also implying that targets can declare their changed >>MaxRecvDataSegmentLength anytime just for writes. I didn't mean it that way. What I was saying was that when the target changes his value, there are no messy logic issues involved; and therefore there are no timing issues about when it changes. Did you ever think about using an offset and a data length in the SNACK instead of using PDU counters? That would also simplify things at the target. Eddy -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Tuesday, June 11, 2002 7:46 PM To: Mallikarjun C.; Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Consider the following (using Julian's suggestion): -> cmd 1 -> req to change to length 2 -> cmd 2 <- stat 1 <- data 2, PDU 0, Length 1 -> cmd 3, ack 1 so change the length <- data 2, PDU 1, Length 2 -> SNACK data 2, PDU 1 So we have to calculate the offset for Data 2, PDU 1 using old length and send data after that offset using new length. That means keeping track of PDU lengths which I would like to avoid. Or, the target would have to force idling of commands before it gives the response to the change. Can you suggest how this would be handled otherwise? Eddy -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com] Sent: Tuesday, June 11, 2002 6:57 PM To: Eddy Quicksall; Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iSCSI: changing MaxPDUDataLength Eddy, I am not sure if you're agreeing with me or not... but let me add some comments. I don't expect the change in PDU size to happen frequently - no change in what I earlier said. You are making an assumption that a target must record the PDU size for every PDU if SNACKs are to be satisfied across changed MaxRecvDataSegmentLength. As Julian earlier said, you don't have to. I will not go into implementation details, but I believe just the value of the DataSN from which the new size is effective should be all that's needed. Besides, the spec guarantees that only RunLength=0 is used on any SNACK after the change. You are also implying that targets can declare their changed MaxRecvDataSegmentLength anytime just for writes. There are two problems with this - a) reads and writes may both be active in the typical case on an iSCSI connection, and b) a target can declare its changed value only if an initiator is allowed to start the Text Request (and I thought you were suggesting that we explicitly disallow that). Hope that clears it up. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Eddy Quicksall" To: "Mallikarjun C." ; "Julian Satran" Cc: Sent: Tuesday, June 11, 2002 3:18 PM Subject: RE: iSCSI: changing MaxPDUDataLength > You are correct and that is exactly how I have had to code it. With fast > path and slow path code split between processors, it becomes even worse. > > When I read your comments on why the PDU size could change (from way back in > March I think), I got did not get the impression that it would happen very > often and that in fact it may only happen when you are maintaining > allegiance to another connection. > > If it is something that is not going to happen very often, then it would be > so much easier to have the initiator idle the commands first (all it really > needs to do is idle the READ commands). If it is going to change so often > that idling would be degrading, I suspect that just doing the negotiation > that often would itself be degrading. > > And, be aware that the target will probably idle the R commands. Otherwise, > it will have to track PDU sizes and that would be really > "counter-productive" (especially when there should be no SNACKs on a good > connection anyway). > > I don't see any problem with the target negotiating its size at any time. > And the initiator would not have to idle the WRITE or no-data commands. > > Eddy > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Tuesday, June 11, 2002 3:35 PM > To: Eddy Quicksall; Julian Satran > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: changing MaxPDUDataLength > > > Eddy, > > I am not clear on why you think the target code becomes messy on > a PDU size change. The last para in section 4.4 states the following - > > "Parameters negotiated by a text exchange negotiation sequence become > effective only after the negotiation sequence is completed." > > Since the target gets to complete a text negotiation with a Text Response > PDU, it can time the applicability of a changed MaxRecvDataSegmentLength. > > Requiring that an initiator must idle the connection before changing this > parameter, IMHO, is counter-productive when there's a dynamic PMTU > degradation in the presence of long-running commands (writes in particular). > Once the initiator starts the renegotiation, target would ideally want to > quickly > renegotiate its receive size as well to receive ULPDU-contained segments. > > In short, seems to me that the draft is saying what you would like. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > > ----- Original Message ----- > From: "Eddy Quicksall" > To: "Julian Satran" > Cc: > Sent: Tuesday, June 11, 2002 7:56 AM > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > I think it should be a requirement because if it is not, all target code > > will have to have the messy code. Or, we could say that if it is not idle > > commands, then the target may reject it. > > > > Eddy > > > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Tuesday, June 11, 2002 9:11 AM > > To: Eddy Quicksall > > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > That is a fair request - we may slip in a recommendation to that effect > (in > > chapter 11?) > > > > Julo > > > > > > > > Eddy Quicksall > > > > > > 06/11/2002 04:28 AM > > Please respond to Eddy Quicksall > > > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > How about if we say that an initiator must not change the MaxPDUDataSize > > unless it first idles the commands (at least the ones with the R bit) or > if > > ErrorRecoveryLevel==0? > > > > That would simplify target code greatly and would meet the design goals; > and > > since it should be rare to change it, it would be of little impact to idle > > the commands for a split second. > > > > > > Eddy > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Monday, June 10, 2002 8:06 PM > > To: Eddy Quicksall > > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > I said only that when you change length you can ask for all PDUs after the > > ack! (no need to keep a tall - the old offsets are good up to the hole). > > > > Julo > > > > > > Eddy Quicksall > > > > > > 06/11/2002 12:32 AM > > Please respond to Eddy Quicksall > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > Julian, > > > > Another problem here is that the target has to calculate the offset from > the > > DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 > > means starting DataSN=4, send all the data for that sequence. > > > > I think it would be a performance hit and waist of memory to keep a tally > of > > all PDU sizes just for an occasional SNACK. > > > > It's not that it can't be done ... it is more that it is messy and I think > > there is a solution that will satisfy the design requirements but keep the > > software simpler. > > > > Eddy > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Saturday, June 08, 2002 10:16 PM > > To: Eddy Quicksall > > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > That is not completely accurate. > > The only problem is when PDU size decreases and then SNACK must be for all > > data. > > Target can also keep a mapping of numbers/to offsets (the list should be > > small and if it gets long ask for ack (A-bit). > > > > Julo > > > > Eddy Quicksall > > Sent by: owner-ips@ece.cmu.edu > > > > > > 06/08/2002 10:54 PM > > Please respond to Eddy Quicksall > > > > > > To: pat_thaler@agilent.com > > cc: ips@ece.cmu.edu > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > > > Thanks, > > > > As a target, I won't be able to let it change until all of the outstanding > > commands are finished (running with ErrorRecoveryLevel>=1). This is > because > > I must use the PDU size to compute the offset from a SNACK's > > BegRun/RunLength. > > > > So, I plan to not give the text response for a MaxPDURecvDataLength in FFP > > until I get back an ExpStatSN == next StatSN. > > > > This will cause a delay of unknown time before the PDU size can actually > > change ... do you see any problem with this? > > > > Eddy > > > > -----Original Message----- > > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > > Sent: Friday, June 07, 2002 1:13 PM > > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > Eddy, > > > > If one uses a message sync and steering that relys on the transport > segments > > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path > > MTU changes one would want to change the PDU data length to fit the new > path > > MTU. > > > > Pat > > > > -----Original Message----- > > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > > Sent: Wednesday, June 05, 2002 12:24 PM > > To: ips@ece.cmu.edu > > Subject: iSCSI: changing MaxPDUDataLength > > > > > > Does anybody know a case where it is necessary to support a new PDU data > > length during full feature phase? > > > > Eddy > > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Wed Jun 12 09:26:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27249 for ; Wed, 12 Jun 2002 09:26:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CD4qa26730 for ips-outgoing; Wed, 12 Jun 2002 09:04:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CD4ow26724; Wed, 12 Jun 2002 09:04:50 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5CD4d4L005198; Wed, 12 Jun 2002 15:04:39 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5CD4ax46910; Wed, 12 Jun 2002 15:04:36 +0200 To: Dennis Young Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iscsi: unsolicited data question X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 12 Jun 2002 16:04:34 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 12/06/2002 16:04:38, Serialize complete at 12/06/2002 16:04:38 Content-Type: multipart/alternative; boundary="=_alternative 0047A947C2256BD6_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0047A947C2256BD6_= Content-Type: text/plain; charset="us-ascii" yes - julo Dennis Young Sent by: owner-ips@ece.cmu.edu 06/12/2002 06:20 AM Please respond to Dennis Young To: ips@ece.cmu.edu cc: Subject: iscsi: unsolicited data question I have a question which has been asked before, but I couldn't find a direct answer in the archive. The table on page 200 of draft 12 doesn't directly answer this question either. The first paragraph on page 36 of draft 12 says "Targets operate in either solicitied (R2T) data mode or unsolicited (non R2T) data mode." tells me that a target, at all times during a data sequence transfer, can be one or the other, but not both (non R2T for the initial data out, R2T for the remaining data). Is this correct? Thanks, Dennis ---snip from an old email dated 3/30/2001--- " Hi Julian Sorry if I'm covering old ground... Is it possible to use unsolicited data for the first burst and then request any remaining data using R2T? For example, if the target has a previously allocated buffer available (length defined by FirstBurstSize) for unsolicited data, then once the initiator has sent unsolicited data up to and including this amount then the remaining data (if any) can be requested using R2T once the target has the buffer space available. ...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail: matthewb@bri.hp.com " --=_alternative 0047A947C2256BD6_= Content-Type: text/html; charset="us-ascii"
yes - julo


Dennis Young <dyoung@rhapsodynetworks.com>
Sent by: owner-ips@ece.cmu.edu

06/12/2002 06:20 AM
Please respond to Dennis Young

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iscsi: unsolicited data question

       


I have a question which has been asked before, but I couldn't find a direct
answer in the archive.  The table on page 200 of draft 12 doesn't directly
answer this question either.

The first paragraph on page 36 of draft 12 says "Targets operate in either
solicitied (R2T) data mode or unsolicited (non R2T) data mode."
tells me that a target, at all times during a data sequence transfer, can be

one or the other, but not both (non R2T for the initial data out, R2T for
the
remaining data).  Is this correct?

Thanks,
Dennis

---snip from an old email dated 3/30/2001---

" Hi Julian
Sorry if I'm covering old ground... Is it possible to use unsolicited data
for the first burst and then request any remaining data using R2T? For
example, if the target has a previously allocated buffer available (length
defined by FirstBurstSize) for unsolicited data, then once the initiator has
sent unsolicited data up to and including this amount then the remaining
data (if any) can be requested using R2T once the target has the buffer
space available.
...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail:
matthewb@bri.hp.com "

--=_alternative 0047A947C2256BD6_=-- From owner-ips@ece.cmu.edu Wed Jun 12 09:31:51 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27549 for ; Wed, 12 Jun 2002 09:31:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CCf2Q25383 for ips-outgoing; Wed, 12 Jun 2002 08:41:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CCf0w25378 for ; Wed, 12 Jun 2002 08:41:00 -0400 (EDT) Received: from mail pickup service by mail5.nc.rr.com with Microsoft SMTPSVC; Tue, 11 Jun 2002 15:23:03 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 16:16:29 -0400 Received: from ruebert.ieee.org (ruebert.ieee.org [140.98.193.10]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AKGUtH012644 for ; Mon, 10 Jun 2002 16:16:30 -0400 (EDT) Received: from ece.cmu.edu (gemini3.ieee.org [140.98.193.25]) by ruebert.ieee.org (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5AKGBq02801; Mon, 10 Jun 2002 16:16:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AK0qd09116 for ips-outgoing; Mon, 10 Jun 2002 16:00:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AK0ow09112 for ; Mon, 10 Jun 2002 16:00:51 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id B47AEBC58; Mon, 10 Jun 2002 14:00:46 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 09FD8120; Mon, 10 Jun 2002 14:00:46 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 10 Jun 2002 14:00:42 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 14:00:42 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E3E60@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: wrstuden@wasabisystems.com, rsnively@Brocade.COM Cc: ksandars@eurologic.com, ips@ece.cmu.edu Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys Date: Mon, 10 Jun 2002 14:00:37 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Bill, It is the place of MIBs and CIM objects to cover items like this. For diagnostic problems, these are more useful because they are available to management systems as well as at the two ends of the link. Generally, building a duplicate capability to exchange management objects in protocols adds cost without benefit. Regards, Pat -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Friday, June 07, 2002 10:27 AM To: Robert Snively Cc: 'Ken Sandars'; Ips Reflector (E-mail) Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys On Fri, 7 Jun 2002, Robert Snively wrote: > The management component already has standard mechanisms > for determining such information, including MIBs and CIM > objects. The operational components already have standard > mechanisms for determining such information, including > SCSI INQUIRY commands. I cannot see how this additional > (non-standard) mechanism for capturing this information is > going to help iSCSI achieve its goals. Question about the operational components being able to determine this info. iSCSI is, in terms from SAM-2, a Service Delivery Subsystem (SDS). While many implementations act as scsi servers (disks & tapes, etc.), that's not part of the spec. So I'm confused how an SDS answers a SCSI INQUIRY. I thought that was the domain of the device(s) at the other end of the connection, not the domain of the connection itself. Take care, Bill From owner-ips@ece.cmu.edu Wed Jun 12 09:34:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27641 for ; Wed, 12 Jun 2002 09:33:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CD4fb26711 for ips-outgoing; Wed, 12 Jun 2002 09:04:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CD4dw26706 for ; Wed, 12 Jun 2002 09:04:39 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5CD4RZm022696; Wed, 12 Jun 2002 15:04:27 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5CD4NM24942; Wed, 12 Jun 2002 15:04:23 +0200 To: "Rod Harrison" Cc: "Mallikarjun C." , ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: changing MaxPDUDataLength X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 12 Jun 2002 16:04:14 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 12/06/2002 16:04:26, Serialize complete at 12/06/2002 16:04:26 Content-Type: multipart/alternative; boundary="=_alternative 004731E7C2256BD6_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004731E7C2256BD6_= Content-Type: text/plain; charset="us-ascii" Rod, It is clearly missing. I was thinking at something benign like using it an indication that target wants to negotiate. Logout - inititaor is always free to use but it may want to issue a text. Julo "Rod Harrison" 06/12/2002 02:57 AM Please respond to "Rod Harrison" To: Julian Satran/Haifa/IBM@IBMIL, "Mallikarjun C." cc: Subject: RE: iSCSI: changing MaxPDUDataLength I'm torn, I don't want to make this sort of change late on but I think it would be a good thing in the long term. How about adding the additional async message code and saying upon receipt the initiator MAY start a negotiation sequence or logout and re-login the connection immediately without having to wait for the negotiated timeouts? - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Tuesday, June 11, 2002 4:28 PM To: Mallikarjun C. Cc: ips@ece.cmu.edu; Julian Satran; owner-ips@ece.cmu.edu Subject: Re: iSCSI: changing MaxPDUDataLength Importance: High Mallikarjun, The question was general and not specific to MaxRecv.... Although we say that negotiation is symmetric we don't have any mechanism through which a target can say it wants to start negotiation something (sort of similar but not as strong as a the "request logout" - "request to negotiate" that will require the initiator to issue a text request and kick-off a negotiation. Julo "Mallikarjun C." To: , Julian Satran/Haifa/IBM@IBMIL Sent by: cc: owner-ips@ece.cmu Subject: Re: iSCSI: changing MaxPDUDataLength .edu 06/11/2002 10:50 PM Please respond to "Mallikarjun C." > I also realized that we don't have "negotiation prompt" from the target. > I am not sure that we need one. I am not sure about it either. My preference is not to add this. It appears to me that a target does have the option of dropping the connection today if it can't work with non-ULPDU-contained segments for too long. I suspect that the target would do the same if (we introduced the "negotiation prompt" and) the initiator doesn't/couldn't honor the "negotiation prompt". Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Julian Satran" To: Sent: Tuesday, June 11, 2002 8:34 AM Subject: RE: iSCSI: changing MaxPDUDataLength > I suggest the following text in 11.13 > > A change of MaxRecvDataSegmentLength by an initiator or target > becomes effective after all commands preceding the negotiation > end-ing request have been processed by the target and their status > is acknowledged. > > I also realized that we don't have "negotiation prompt" from the target. > I am not sure that we need one. > If some of you think we need we may want one additional code in the Asynch > Message. > Please comment TODAY. > > Julo > ----- Forwarded by Julian Satran/Haifa/IBM on 06/11/2002 06:29 PM ----- > > Julian Satran > To: Eddy Quicksall > 06/11/2002 04:04 cc: ips@ece.cmu.edu, pat_thaler@agilent.com > PM From: Julian Satran/Haifa/IBM@IBMIL > Subject: RE: iSCSI: changing MaxPDUDataLength(Document link: Julian Satran - Mail) > > > > > > > > > > That is a fair request - we may slip in a recommendation to that effect (in > chapter 11?) > > Julo > > > > Eddy Quicksall > vivity.com> cc: ips@ece.cmu.edu, pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > 06/11/2002 04:28 > AM > Please respond to > Eddy Quicksall > > > > > > How about if we say that an initiator must not change the MaxPDUDataSize > unless it first idles the commands (at least the ones with the R bit) or if > ErrorRecoveryLevel==0? > > That would simplify target code greatly and would meet the design goals; > and since it should be rare to change it, it would be of little impact to > idle the commands for a split second. > > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Monday, June 10, 2002 8:06 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > I said only that when you change length you can ask for all PDUs > after the ack! (no need to keep a tall - the old offsets are good up > to the hole). > > Julo > > > Eddy Quicksall > To: Julian > Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu, > 06/11/2002 12:32 AM pat_thaler@agilent.com > Please respond to Eddy Quicksall Subject: RE: iSCSI: > changing MaxPDUDataLength > > > > > > > > Julian, > > Another problem here is that the target has to calculate the offset > from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and > RunLngth=0 means starting DataSN=4, send all the data for that > sequence. > > I think it would be a performance hit and waist of memory to keep a > tally of all PDU sizes just for an occasional SNACK. > > It's not that it can't be done ... it is more that it is messy and I > think there is a solution that will satisfy the design requirements > but keep the software simpler. > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Saturday, June 08, 2002 10:16 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > That is not completely accurate. > The only problem is when PDU size decreases and then SNACK must be > for all data. > Target can also keep a mapping of numbers/to offsets (the list should > be small and if it gets long ask for ack (A-bit). > > Julo > > Eddy Quicksall > To: > Sent by: owner-ips@ece.cmu.edu pat_thaler@agilent.com > cc: ips@ece.cmu.edu > Subject: RE: iSCSI: > 06/08/2002 10:54 PM changing MaxPDUDataLength > Please respond to Eddy Quicksall > > > > > > > > Thanks, > > As a target, I won't be able to let it change until all of the > outstanding > commands are finished (running with ErrorRecoveryLevel>=1). This is > because > I must use the PDU size to compute the offset from a SNACK's > BegRun/RunLength. > > So, I plan to not give the text response for a MaxPDURecvDataLength > in FFP > until I get back an ExpStatSN == next StatSN. > > This will cause a delay of unknown time before the PDU size can > actually > change ... do you see any problem with this? > > Eddy > > -----Original Message----- > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > Sent: Friday, June 07, 2002 1:13 PM > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > Subject: RE: iSCSI: changing MaxPDUDataLength > > > Eddy, > > If one uses a message sync and steering that relys on the transport > segments > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the > path > MTU changes one would want to change the PDU data length to fit the > new path > MTU. > > Pat > > -----Original Message----- > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > Sent: Wednesday, June 05, 2002 12:24 PM > To: ips@ece.cmu.edu > Subject: iSCSI: changing MaxPDUDataLength > > > Does anybody know a case where it is necessary to support a new PDU > data > length during full feature phase? > > Eddy > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > > > --=_alternative 004731E7C2256BD6_= Content-Type: text/html; charset="us-ascii"
Rod,

It is clearly missing. I was thinking at something benign like using it an indication that target wants to negotiate.
Logout - inititaor is always free to use but it may want to issue a text.

Julo


"Rod Harrison" <rod.harrison@windriver.com>

06/12/2002 02:57 AM
Please respond to "Rod Harrison"

       
        To:        Julian Satran/Haifa/IBM@IBMIL, "Mallikarjun C." <cbm@rose.hp.com>
        cc:        <ips@ece.cmu.edu>
        Subject:        RE: iSCSI: changing MaxPDUDataLength

       



                I'm torn, I don't want to make this sort of change late on but I
think it would be a good thing in the long term.

                How about adding the additional async message code and saying upon
receipt the initiator MAY start a negotiation sequence or logout and
re-login the connection immediately without having to wait for the
negotiated timeouts?

                - Rod

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Julian Satran
Sent: Tuesday, June 11, 2002 4:28 PM
To: Mallikarjun C.
Cc: ips@ece.cmu.edu; Julian Satran; owner-ips@ece.cmu.edu
Subject: Re: iSCSI: changing MaxPDUDataLength
Importance: High



Mallikarjun,

The question was general and not specific to MaxRecv....
Although we say that negotiation is symmetric we don't have any
mechanism
through which a target can say it wants to start negotiation something
(sort of similar but not as strong as a the "request logout" -
"request to
negotiate" that will require the initiator to issue a text request and
kick-off a negotiation.

Julo



                     "Mallikarjun C."
                     <cbm@rose.hp.com>        To:
<ips@ece.cmu.edu>, Julian Satran/Haifa/IBM@IBMIL
                     Sent by:                 cc:
                     owner-ips@ece.cmu        Subject:  Re: iSCSI:
changing MaxPDUDataLength
                     .edu


                     06/11/2002 10:50
                     PM
                     Please respond to
                     "Mallikarjun C."





>  I also realized that we don't have "negotiation prompt" from the
target.
>  I am not sure that we need one.

I am not sure about it either.

My preference is not to add this.  It appears to me that a target does
have
the option of dropping the connection today if it can't work with
non-ULPDU-contained
segments for too long.  I suspect that the target would do the same if
(we
introduced the "negotiation prompt" and) the initiator
doesn't/couldn't
honor the
"negotiation prompt".

Thanks.
--
Mallikarjun

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


----- Original Message -----
From: "Julian Satran" <Julian_Satran@il.ibm.com>
To: <ips@ece.cmu.edu>
Sent: Tuesday, June 11, 2002 8:34 AM
Subject: RE: iSCSI: changing MaxPDUDataLength


> I suggest the following text in 11.13
>
>        A change of MaxRecvDataSegmentLength by an initiator or
target
>        becomes effective after all commands preceding the
negotiation
>        end-ing request have been processed by the target and their
status
>        is acknowledged.
>
>  I also realized that we don't have "negotiation prompt" from the
target.
>  I am not sure that we need one.
>  If some of you think we need we may want one additional code in the
Asynch
>  Message.
>  Please comment TODAY.
>
>  Julo
> ----- Forwarded by Julian Satran/Haifa/IBM on 06/11/2002 06:29
PM -----
>
>                       Julian Satran
>                                                To:      Eddy
Quicksall
<eddy_quicksall@ivivity.com>
>                       06/11/2002 04:04         cc:
ips@ece.cmu.edu,
pat_thaler@agilent.com

>                       PM                       From:    Julian
Satran/Haifa/IBM@IBMIL
>                                                Subject: RE: iSCSI:
changing MaxPDUDataLength(Document link:
Julian Satran - Mail)
>
>
>
>
>
>
>
>
>
> That is a fair request - we may slip in a recommendation to that
effect
(in
> chapter 11?)
>
> Julo
>
>
>
>                       Eddy Quicksall
>                       <eddy_quicksall@i        To:       Julian
Satran/Haifa/IBM@IBMIL
>                       vivity.com>              cc:
ips@ece.cmu.edu,
pat_thaler@agilent.com
>                                                Subject:  RE: iSCSI:
changing MaxPDUDataLength
>                       06/11/2002 04:28
>                       AM
>                       Please respond to
>                       Eddy Quicksall
>
>
>
>
>
> How about if we say that an initiator must not change the
MaxPDUDataSize
> unless it first idles the commands (at least the ones with the R
bit) or
if
> ErrorRecoveryLevel==0?
>
> That would simplify target code greatly and would meet the design
goals;
> and since it should be rare to change it, it would be of little
impact to
> idle the commands for a split second.
>
>
> Eddy
>       -----Original Message-----
>       From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
>       Sent: Monday, June 10, 2002 8:06 PM
>       To: Eddy Quicksall
>       Cc: ips@ece.cmu.edu; pat_thaler@agilent.com
>       Subject: RE: iSCSI: changing MaxPDUDataLength
>
>
>       I said only that when you change length you can ask for all
PDUs
>       after the ack! (no need to keep a tall - the old offsets are
good
up
>       to the hole).
>
>       Julo
>
>
>    Eddy Quicksall
>    <eddy_quicksall@ivivity.com>              To:        Julian
>                                      Satran/Haifa/IBM@IBMIL
>                                              cc:
ips@ece.cmu.edu,
>    06/11/2002 12:32 AM               pat_thaler@agilent.com
>    Please respond to Eddy Quicksall          Subject:        RE:
iSCSI:
>                                      changing MaxPDUDataLength
>
>
>
>
>
>
>
>       Julian,
>
>       Another problem here is that the target has to calculate the
offset
>       from the DataSN #. And as BegRun can be any value. E.g.,
BegRun=4
and
>       RunLngth=0 means starting DataSN=4, send all the data for that
>       sequence.
>
>       I think it would be a performance hit and waist of memory to
keep a
>       tally of all PDU sizes just for an occasional SNACK.
>
>       It's not that it can't be done ... it is more that it is messy
and
I
>       think there is a solution that will satisfy the design
requirements
>       but keep the software simpler.
>
>       Eddy
>       -----Original Message-----
>       From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
>       Sent: Saturday, June 08, 2002 10:16 PM
>       To: Eddy Quicksall
>       Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu;
pat_thaler@agilent.com
>       Subject: RE: iSCSI: changing MaxPDUDataLength
>
>
>       That is not completely accurate.
>       The only problem is when PDU size decreases and then SNACK
must be
>       for all data.
>       Target can also keep a mapping of numbers/to offsets (the list
should
>       be small and if it gets long ask for ack (A-bit).
>
>       Julo
>
>    Eddy Quicksall
>    <eddy_quicksall@ivivity.com>             To:
>    Sent by: owner-ips@ece.cmu.edu    pat_thaler@agilent.com
>                                             cc:
ips@ece.cmu.edu
>                                             Subject:        RE:
iSCSI:
>    06/08/2002 10:54 PM               changing MaxPDUDataLength
>    Please respond to Eddy Quicksall
>
>
>
>
>
>
>
>       Thanks,
>
>       As a target, I won't be able to let it change until all of the
>       outstanding
>       commands are finished (running with ErrorRecoveryLevel>=1).
This is
>       because
>       I must use the PDU size to compute the offset from a SNACK's
>       BegRun/RunLength.
>
>       So, I plan to not give the text response for a
MaxPDURecvDataLength
>       in FFP
>       until I get back an ExpStatSN == next StatSN.
>
>       This will cause a delay of unknown time before the PDU size
can
>       actually
>       change ... do you see any problem with this?
>
>       Eddy
>
>       -----Original Message-----
>       From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]
>       Sent: Friday, June 07, 2002 1:13 PM
>       To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu
>       Subject: RE: iSCSI: changing MaxPDUDataLength
>
>
>       Eddy,
>
>       If one uses a message sync and steering that relys on the
transport
>       segments
>       carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then
if
the
>       path
>       MTU changes one would want to change the PDU data length to
fit the
>       new path
>       MTU.
>
>       Pat
>
>       -----Original Message-----
>       From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com]
>       Sent: Wednesday, June 05, 2002 12:24 PM
>       To: ips@ece.cmu.edu
>       Subject: iSCSI: changing MaxPDUDataLength
>
>
>       Does anybody know a case where it is necessary to support a
new PDU
>       data
>       length during full feature phase?
>
>       Eddy
>       mailto: Eddy_Quicksall@iVivity.com
>
>
>
>
>
>
>
>
>
>

--=_alternative 004731E7C2256BD6_=-- From owner-ips@ece.cmu.edu Wed Jun 12 13:01:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04873 for ; Wed, 12 Jun 2002 13:01:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CGAYZ08535 for ips-outgoing; Wed, 12 Jun 2002 12:10:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CGAWw08529 for ; Wed, 12 Jun 2002 12:10:32 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 8895A30706; Wed, 12 Jun 2002 12:10:31 -0400 (EDT) Date: Wed, 12 Jun 2002 09:08:22 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: John Hufferd Cc: Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 11 Jun 2002, John Hufferd wrote: > Let me state again, this will not fly, please take it off this reflector > and take it to SNIA or any where else. John, would you please stop with these EMails telling people to be quiet? Do you really think telling folks to hush is 1) polite, 2) something you are in a position of authority to do, or 3) good for the spec? I seem to recall at least one recent thread to which you sent out a, "can we hush now," email that latter turned into a change to the spec. i.e. because folks didn't hush, we now have a better spec. So now which would you rather have, a silent list that leads to a flawed spec, or a list that discusses things (even if the don't fly) and leads to a better spec? Take care, Bill From owner-ips@ece.cmu.edu Wed Jun 12 13:38:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06323 for ; Wed, 12 Jun 2002 13:38:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CGwCS11419 for ips-outgoing; Wed, 12 Jun 2002 12:58:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CGwAw11413 for ; Wed, 12 Jun 2002 12:58:10 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5CGw4ML041584 for ; Wed, 12 Jun 2002 18:58:04 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5CGw3M99914 for ; Wed, 12 Jun 2002 18:58:03 +0200 To: ips@ece.cmu.edu Importance: High MIME-Version: 1.0 Subject: iSCSI-Asynch event code X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 12 Jun 2002 19:58:03 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 12/06/2002 19:58:02, Serialize complete at 12/06/2002 19:58:02 Content-Type: multipart/alternative; boundary="=_alternative 005C6BBCC2256BD6_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005C6BBCC2256BD6_= Content-Type: text/plain; charset="us-ascii" Dear colleagues, I plan to add to the text in 9.9.1 an additional event code as follows. It is needed for completeness. 4 - target requests parameter negotiation on this connection. The initiator MUST honor this request by issuing a Text Request (that can be empty) on the same connection as early as possible unless a Text Request is already pending on the connection or by issuing a Logout Request. Julo --=_alternative 005C6BBCC2256BD6_= Content-Type: text/html; charset="us-ascii"
Dear colleagues,

I plan to add to the text in 9.9.1 an additional event code as follows. It is needed for completeness.

4 - target requests parameter negotiation on this connection. The initiator MUST honor this request by issuing a Text Request (that can be empty) on the same connection as early as possible unless a Text Request is already pending on the connection or by issuing a Logout Request.    
Julo

--=_alternative 005C6BBCC2256BD6_=-- From owner-ips@ece.cmu.edu Wed Jun 12 13:39:23 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06348 for ; Wed, 12 Jun 2002 13:39:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CGwJF11430 for ips-outgoing; Wed, 12 Jun 2002 12:58:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CGwHw11423; Wed, 12 Jun 2002 12:58:17 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5CGw54L055704; Wed, 12 Jun 2002 18:58:05 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5CGw4M74088; Wed, 12 Jun 2002 18:58:04 +0200 To: Michael Morrison Cc: iSCSI , owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: target reset X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 12 Jun 2002 19:58:03 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 12/06/2002 19:58:04, Serialize complete at 12/06/2002 19:58:04 Content-Type: multipart/alternative; boundary="=_alternative 005CA938C2256BD6_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005CA938C2256BD6_= Content-Type: text/plain; charset="us-ascii" the meaning is the one of the SAM reset LUN. Clear Task set is different. Julo Michael Morrison 06/12/2002 04:34 PM Please respond to Michael Morrison To: Julian Satran/Haifa/IBM@IBMIL cc: iSCSI , owner-ips@ece.cmu.edu Subject: Re: target reset Sorry for being obtuse, but I don't understand your response. Are you saying 'yes, cancel all operations == clear task set description' - or - 'yes, the statement has another meaning' On Wed, 2002-06-12 at 09:15, Julian Satran wrote: yes it means cancel all operations - look for the fine differences on cancelling other initiators tasks. That is a SAM issue that we don't want to touch! Julo Michael Morrison Sent by: owner-ips@ece.cmu.edu 06/12/2002 02:04 AM Please respond to Michael Morrison To: iSCSI cc: Subject: target reset On page 148 of draft 12-97, in the paragraph ... "For the TARGET WARM RESET and TARGET COLD RESET functions, the target cancels all pending operations. Both functions are equivalent to the Target Reset function specified by [SAM2]. They can affect many other initiators" In these cases, SAM2 refers to Logical Unit Reset, which refers to Aborting Tasks. This implies to me that TARGET RESET (WARM or COLD) is equivalent to CLEAR TASK SET. The behavior in the iSCSI draft for CLEAR TASK SET is fairly well described. Is the description presented in the discussion on CLEAR TASK SET supposed to define "cancels all pending operations?" Or does this statement have another meaning? --=_alternative 005CA938C2256BD6_= Content-Type: text/html; charset="us-ascii"
the meaning is the one of the SAM reset LUN. Clear Task set is different. Julo


Michael Morrison <mmorrison@istor.com>

06/12/2002 04:34 PM
Please respond to Michael Morrison

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        iSCSI <ips@ece.cmu.edu>, owner-ips@ece.cmu.edu
        Subject:        Re: target reset

       


Sorry for being obtuse, but I don't understand your response.

Are you saying 'yes, cancel all operations == clear task set
description'
- or -
'yes, the statement has another meaning'




On Wed, 2002-06-12 at 09:15, Julian Satran wrote:
   yes it means cancel all operations - look for the fine differences
   on cancelling other initiators tasks.
   That is a SAM issue that we don't want to touch!
   
   Julo
   
   
   
   
   Michael Morrison
   <mmorrison@istor.com>
   Sent by:
   owner-ips@ece.cmu.edu
   
   06/12/2002 02:04 AM
   Please respond to
   Michael Morrison
   
           
           To:      
   iSCSI
   <ips@ece.cmu.edu>
           cc:        
           Subject:      
   target reset
   
         
   
   
   On page 148 of draft 12-97, in the paragraph ...
   
   "For the TARGET WARM RESET and TARGET COLD RESET functions, the
   target
   cancels all pending operations.  Both functions are equivalent to
   the
   Target Reset function specified by [SAM2].  They can affect many
   other
   initiators"
   
   In these cases, SAM2 refers to Logical Unit Reset, which refers to
   Aborting Tasks.
   
   This implies to me that TARGET RESET (WARM or COLD) is equivalent to
   CLEAR TASK SET.  The behavior in the iSCSI draft for CLEAR TASK SET
   is
   fairly well described.  Is the
   description presented in the discussion on CLEAR TASK SET supposed
   to
   define "cancels all pending operations?"  Or does this statement
   have
   another meaning?
   
   
   
   

--=_alternative 005CA938C2256BD6_=-- From owner-ips@ece.cmu.edu Wed Jun 12 13:40:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06369 for ; Wed, 12 Jun 2002 13:40:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CHJ1x12783 for ips-outgoing; Wed, 12 Jun 2002 13:19:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail1irv.inside.istor.com (host28.istor.com [66.134.214.28]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CGZCw10060; Wed, 12 Jun 2002 12:35:12 -0400 (EDT) Subject: Re: target reset From: Michael Morrison To: Julian Satran Cc: iSCSI , owner-ips@ece.cmu.edu In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 12 Jun 2002 09:34:39 -0400 Message-Id: <1023888879.7322.5.camel@jackal.engasic.istor.com> Mime-Version: 1.0 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sorry for being obtuse, but I don't understand your response. Are you saying 'yes, cancel all operations == clear task set description' - or - 'yes, the statement has another meaning' On Wed, 2002-06-12 at 09:15, Julian Satran wrote: yes it means cancel all operations - look for the fine differences on cancelling other initiators tasks. That is a SAM issue that we don't want to touch! Julo Michael Morrison Sent by: owner-ips@ece.cmu.edu 06/12/2002 02:04 AM Please respond to Michael Morrison To: iSCSI cc: Subject: target reset On page 148 of draft 12-97, in the paragraph ... "For the TARGET WARM RESET and TARGET COLD RESET functions, the target cancels all pending operations. Both functions are equivalent to the Target Reset function specified by [SAM2]. They can affect many other initiators" In these cases, SAM2 refers to Logical Unit Reset, which refers to Aborting Tasks. This implies to me that TARGET RESET (WARM or COLD) is equivalent to CLEAR TASK SET. The behavior in the iSCSI draft for CLEAR TASK SET is fairly well described. Is the description presented in the discussion on CLEAR TASK SET supposed to define "cancels all pending operations?" Or does this statement have another meaning? From owner-ips@ece.cmu.edu Wed Jun 12 13:42:10 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06447 for ; Wed, 12 Jun 2002 13:42:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CHHmi12678 for ips-outgoing; Wed, 12 Jun 2002 13:17:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CDFdw27314; Wed, 12 Jun 2002 09:15:39 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5CDFRZm094782; Wed, 12 Jun 2002 15:15:27 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5CDFOx22102; Wed, 12 Jun 2002 15:15:26 +0200 To: Michael Morrison Cc: iSCSI , owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: target reset X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 12 Jun 2002 16:15:23 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 12/06/2002 16:15:26, Serialize complete at 12/06/2002 16:15:26 Content-Type: multipart/alternative; boundary="=_alternative 0047E3CFC2256BD6_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0047E3CFC2256BD6_= Content-Type: text/plain; charset="us-ascii" yes it means cancel all operations - look for the fine differences on cancelling other initiators tasks. That is a SAM issue that we don't want to touch! Julo Michael Morrison Sent by: owner-ips@ece.cmu.edu 06/12/2002 02:04 AM Please respond to Michael Morrison To: iSCSI cc: Subject: target reset On page 148 of draft 12-97, in the paragraph ... "For the TARGET WARM RESET and TARGET COLD RESET functions, the target cancels all pending operations. Both functions are equivalent to the Target Reset function specified by [SAM2]. They can affect many other initiators" In these cases, SAM2 refers to Logical Unit Reset, which refers to Aborting Tasks. This implies to me that TARGET RESET (WARM or COLD) is equivalent to CLEAR TASK SET. The behavior in the iSCSI draft for CLEAR TASK SET is fairly well described. Is the description presented in the discussion on CLEAR TASK SET supposed to define "cancels all pending operations?" Or does this statement have another meaning? -- Michael Morrison mmorrison@istor.com ISTOR Networks 7585 Irvine Center Dr. Ste 250 Irvine Ca. 92618 PGP Key ID: http://pgp.mit.edu:11371/pks/lookup?search=0x74C30155&op=index #### signature.asc has been removed from this note on June 12 2002 by Julian Satran --=_alternative 0047E3CFC2256BD6_= Content-Type: text/html; charset="us-ascii"
yes it means cancel all operations - look for the fine differences on cancelling other initiators tasks.
That is a SAM issue that we don't want to touch!

Julo


Michael Morrison <mmorrison@istor.com>
Sent by: owner-ips@ece.cmu.edu

06/12/2002 02:04 AM
Please respond to Michael Morrison

       
        To:        iSCSI <ips@ece.cmu.edu>
        cc:        
        Subject:        target reset

       



On page 148 of draft 12-97, in the paragraph ...
"For the TARGET WARM RESET and TARGET COLD RESET functions, the target
cancels all pending operations.  Both functions are equivalent to the
Target Reset function specified by [SAM2].  They can affect many other
initiators"
In these cases, SAM2 refers to Logical Unit Reset, which refers to
Aborting Tasks.
This implies to me that TARGET RESET (WARM or COLD) is equivalent to
CLEAR TASK SET.  The behavior in the iSCSI draft for CLEAR TASK SET is
fairly well described.  Is the
description presented in the discussion on CLEAR TASK SET supposed to
define "cancels all pending operations?"  Or does this statement have
another meaning?



--
Michael Morrison
mmorrison@istor.com
ISTOR Networks
7585 Irvine Center Dr. Ste 250
Irvine Ca. 92618
PGP Key ID:
http://pgp.mit.edu:11371/pks/lookup?search=0x74C30155&op=index



#### signature.asc has been removed from this note on June 12 2002 by Julian Satran

--=_alternative 0047E3CFC2256BD6_=-- From owner-ips@ece.cmu.edu Wed Jun 12 13:42:30 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06501 for ; Wed, 12 Jun 2002 13:42:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CHIx812775 for ips-outgoing; Wed, 12 Jun 2002 13:18:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CHIvw12769; Wed, 12 Jun 2002 13:18:57 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5CHIoUi074874; Wed, 12 Jun 2002 19:18:50 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5CHInr120808; Wed, 12 Jun 2002 19:18:50 +0200 To: Dennis Young Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iscsi: unsolicited data question X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 12 Jun 2002 20:18:49 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 12/06/2002 20:18:49, Serialize complete at 12/06/2002 20:18:49 Content-Type: multipart/alternative; boundary="=_alternative 005EEF7FC2256BD6_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005EEF7FC2256BD6_= Content-Type: text/plain; charset="us-ascii" This is the reason why the initiator is required to send ALL unsolicited data (target can count on it and start sending R2Ts as soon as it sees the first header> Neither bandwidth nor latency are wasted. Julo Dennis Young 06/12/2002 08:05 PM Please respond to Dennis Young To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Julian, This leads me to a more interesting question. A session with InitialR2T=No in effect, i.e. unsolicited Data-out allowed, could cause unintended waste of bandwidth, depending on how fast the target sends our R2T in response to the SCSI Write. If the target sees the unsolicited Data-out PDU before building the R2T, then everything is fine. If the target doesn't see the unsolicited Data-out PDU before building the R2T, the R2T would request the same portion of data in the unsolicited Data-out, thus bandwidth is wasted. The question is, how can a target be smart about this? Should the target wait a moment for the possible unsolicited Data-out after receiving each SCSI Write, this sounds kludgy. Also, why do we need the unsolicited Data-out PDU feature when there is ImmediateData? Regards, Dennis -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 6:05 AM To: Dennis Young Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iscsi: unsolicited data question yes - julo Dennis Young Sent by: owner-ips@ece.cmu.edu 06/12/2002 06:20 AM Please respond to Dennis Young To: ips@ece.cmu.edu cc: Subject: iscsi: unsolicited data question I have a question which has been asked before, but I couldn't find a direct answer in the archive. The table on page 200 of draft 12 doesn't directly answer this question either. The first paragraph on page 36 of draft 12 says "Targets operate in either solicitied (R2T) data mode or unsolicited (non R2T) data mode." tells me that a target, at all times during a data sequence transfer, can be one or the other, but not both (non R2T for the initial data out, R2T for the remaining data). Is this correct? Thanks, Dennis ---snip from an old email dated 3/30/2001--- " Hi Julian Sorry if I'm covering old ground... Is it possible to use unsolicited data for the first burst and then request any remaining data using R2T? For example, if the target has a previously allocated buffer available (length defined by FirstBurstSize) for unsolicited data, then once the initiator has sent unsolicited data up to and including this amount then the remaining data (if any) can be requested using R2T once the target has the buffer space available. ...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail: matthewb@bri.hp.com " --=_alternative 005EEF7FC2256BD6_= Content-Type: text/html; charset="us-ascii"
This is the reason why the initiator is required to send ALL unsolicited data (target can count on it and start sending R2Ts as soon as it sees the first header>
Neither bandwidth nor latency are wasted.

Julo


Dennis Young <dyoung@rhapsodynetworks.com>

06/12/2002 08:05 PM
Please respond to Dennis Young

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
        Subject:        RE: iscsi: unsolicited data question

       


Julian,
 
This leads me to a more interesting question.
A session with InitialR2T=No in effect, i.e. unsolicited Data-out
allowed, could cause unintended waste of bandwidth, depending on
how fast the target sends our R2T in response to the SCSI Write.
 
If the target sees the unsolicited Data-out PDU before building the
R2T, then everything is fine.
If the target doesn't see the unsolicited Data-out PDU before building
the R2T, the R2T would request the same portion of data in the
unsolicited Data-out, thus bandwidth is wasted.
 
The question is, how can a target be smart about this?
Should the target wait a moment for the possible unsolicited Data-out
after receiving each SCSI Write, this sounds kludgy.
 
Also, why do we need the unsolicited Data-out PDU feature when
there is ImmediateData?
 
Regards,
Dennis
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 12, 2002 6:05 AM
To: Dennis Young
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iscsi: unsolicited data question

yes - julo

Dennis Young <dyoung@rhapsodynetworks.com>
Sent by: owner-ips@ece.cmu.edu

06/12/2002 06:20 AM
Please respond to Dennis Young

       
       To:        ips@ece.cmu.edu
       cc:        
       Subject:        iscsi: unsolicited data question

     



I have a question which has been asked before, but I couldn't find a direct
answer in the archive.  The table on page 200 of draft 12 doesn't directly
answer this question either.

The first paragraph on page 36 of draft 12 says "Targets operate in either
solicitied (R2T) data mode or unsolicited (non R2T) data mode."
tells me that a target, at all times during a data sequence transfer, can be

one or the other, but not both (non R2T for the initial data out, R2T for
the
remaining data).  Is this correct?

Thanks,
Dennis

---snip from an old email dated 3/30/2001---

" Hi Julian
Sorry if I'm covering old ground... Is it possible to use unsolicited data
for the first burst and then request any remaining data using R2T? For
example, if the target has a previously allocated buffer available (length
defined by FirstBurstSize) for unsolicited data, then once the initiator has
sent unsolicited data up to and including this amount then the remaining
data (if any) can be requested using R2T once the target has the buffer
space available.
...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail:
matthewb@bri.hp.com "

--=_alternative 005EEF7FC2256BD6_=-- From owner-ips@ece.cmu.edu Wed Jun 12 13:42:39 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06499 for ; Wed, 12 Jun 2002 13:42:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CH5d311864 for ips-outgoing; Wed, 12 Jun 2002 13:05:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from med.corp.rhapsodynetworks.com (64-160-62-201.rhapsodynetworks.com [64.160.62.201] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CH5aw11852; Wed, 12 Jun 2002 13:05:36 -0400 (EDT) Received: by med.corp.rhapsodynetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 10:05:30 -0700 Message-ID: <45BEF1D68145D51186C100B0D0AABE659E016A@med.corp.rhapsodynetworks.com> From: Dennis Young To: "'Julian Satran'" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Date: Wed, 12 Jun 2002 10:05:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21233.5AB52C10" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21233.5AB52C10 Content-Type: text/plain; charset="iso-8859-1" Julian, This leads me to a more interesting question. A session with InitialR2T=No in effect, i.e. unsolicited Data-out allowed, could cause unintended waste of bandwidth, depending on how fast the target sends our R2T in response to the SCSI Write. If the target sees the unsolicited Data-out PDU before building the R2T, then everything is fine. If the target doesn't see the unsolicited Data-out PDU before building the R2T, the R2T would request the same portion of data in the unsolicited Data-out, thus bandwidth is wasted. The question is, how can a target be smart about this? Should the target wait a moment for the possible unsolicited Data-out after receiving each SCSI Write, this sounds kludgy. Also, why do we need the unsolicited Data-out PDU feature when there is ImmediateData? Regards, Dennis -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 6:05 AM To: Dennis Young Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iscsi: unsolicited data question yes - julo Dennis Young Sent by: owner-ips@ece.cmu.edu 06/12/2002 06:20 AM Please respond to Dennis Young To: ips@ece.cmu.edu cc: Subject: iscsi: unsolicited data question I have a question which has been asked before, but I couldn't find a direct answer in the archive. The table on page 200 of draft 12 doesn't directly answer this question either. The first paragraph on page 36 of draft 12 says "Targets operate in either solicitied (R2T) data mode or unsolicited (non R2T) data mode." tells me that a target, at all times during a data sequence transfer, can be one or the other, but not both (non R2T for the initial data out, R2T for the remaining data). Is this correct? Thanks, Dennis ---snip from an old email dated 3/30/2001--- " Hi Julian Sorry if I'm covering old ground... Is it possible to use unsolicited data for the first burst and then request any remaining data using R2T? For example, if the target has a previously allocated buffer available (length defined by FirstBurstSize) for unsolicited data, then once the initiator has sent unsolicited data up to and including this amount then the remaining data (if any) can be requested using R2T once the target has the buffer space available. ...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail: matthewb@bri.hp.com " ------_=_NextPart_001_01C21233.5AB52C10 Content-Type: text/html; charset="iso-8859-1"
Julian,
 
This leads me to a more interesting question.
A session with InitialR2T=No in effect, i.e. unsolicited Data-out
allowed, could cause unintended waste of bandwidth, depending on
how fast the target sends our R2T in response to the SCSI Write.
 
If the target sees the unsolicited Data-out PDU before building the
R2T, then everything is fine. 
If the target doesn't see the unsolicited Data-out PDU before building
the R2T, the R2T would request the same portion of data in the
unsolicited Data-out, thus bandwidth is wasted.
 
The question is, how can a target be smart about this?
Should the target wait a moment for the possible unsolicited Data-out
after receiving each SCSI Write, this sounds kludgy.
 
Also, why do we need the unsolicited Data-out PDU feature when
there is ImmediateData?
 
Regards,
Dennis
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 12, 2002 6:05 AM
To: Dennis Young
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iscsi: unsolicited data question


yes - julo


Dennis Young <dyoung@rhapsodynetworks.com>
Sent by: owner-ips@ece.cmu.edu

06/12/2002 06:20 AM
Please respond to Dennis Young

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iscsi: unsolicited data question

       


I have a question which has been asked before, but I couldn't find a direct
answer in the archive.  The table on page 200 of draft 12 doesn't directly
answer this question either.

The first paragraph on page 36 of draft 12 says "Targets operate in either
solicitied (R2T) data mode or unsolicited (non R2T) data mode."
tells me that a target, at all times during a data sequence transfer, can be

one or the other, but not both (non R2T for the initial data out, R2T for
the
remaining data).  Is this correct?

Thanks,
Dennis

---snip from an old email dated 3/30/2001---

" Hi Julian
Sorry if I'm covering old ground... Is it possible to use unsolicited data
for the first burst and then request any remaining data using R2T? For
example, if the target has a previously allocated buffer available (length
defined by FirstBurstSize) for unsolicited data, then once the initiator has
sent unsolicited data up to and including this amount then the remaining
data (if any) can be requested using R2T once the target has the buffer
space available.
...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail:
matthewb@bri.hp.com "




------_=_NextPart_001_01C21233.5AB52C10-- From owner-ips@ece.cmu.edu Wed Jun 12 14:32:53 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08391 for ; Wed, 12 Jun 2002 14:32:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CIKkc16963 for ips-outgoing; Wed, 12 Jun 2002 14:20:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CIKiw16958 for ; Wed, 12 Jun 2002 14:20:44 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5CIKcML017342 for ; Wed, 12 Jun 2002 20:20:38 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5CIKcr35274 for ; Wed, 12 Jun 2002 20:20:38 +0200 To: ips@ece.cmu.edu Importance: High MIME-Version: 1.0 Subject: iscsi - 12-98 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 12 Jun 2002 21:20:37 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 12/06/2002 21:20:37, Serialize complete at 12/06/2002 21:20:37 Content-Type: multipart/alternative; boundary="=_alternative 006437C7C2256BD6_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 006437C7C2256BD6_= Content-Type: text/plain; charset="us-ascii" 12-98 is out. I hope it is the last before submission. Julo --=_alternative 006437C7C2256BD6_= Content-Type: text/html; charset="us-ascii"
12-98 is out.
I hope it is the last before submission.

Julo --=_alternative 006437C7C2256BD6_=-- From owner-ips@ece.cmu.edu Wed Jun 12 14:33:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08409 for ; Wed, 12 Jun 2002 14:33:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CHvji15388 for ips-outgoing; Wed, 12 Jun 2002 13:57:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CHvgw15379 for ; Wed, 12 Jun 2002 13:57:42 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel6.hp.com (Postfix) with ESMTP id AC004F64; Wed, 12 Jun 2002 13:57:36 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id KAA09936; Wed, 12 Jun 2002 10:59:24 -0700 (PDT) Message-ID: <004701c2123a$a1f64670$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Rod Harrison" Cc: References: Subject: Re: iSCSI: changing MaxPDUDataLength Date: Wed, 12 Jun 2002 10:57:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Rod, If you had tracked my earlier comments, you'd notice that I'm arguing that there's no specific reason for a "good time". Certain hardware implementations may choose to effect the change only on Data-In sequence boundaries, but the basic nature of text negotiation allows for that flexibility. Yes, as you suggest, we have a variety of other options including dropping the I/Os, or the connection etc. But the point in allowing dynamic redeclaration of this key is to make iSCSI adapt to but not be impacted by, lower-level dynamics - similar to TCP. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Rod Harrison" To: "Mallikarjun C." ; "Eddy Quicksall" ; "Julian Satran" Cc: Sent: Tuesday, June 11, 2002 4:15 PM Subject: RE: iSCSI: changing MaxPDUDataLength > Mallikarjun , > > The current wording doesn't appear to prevent the initiator from > staging new commands whilst the negotiation is in process and > therefore the target may never find a "good time" to end the > negotiation sequence. > > I don't think idling the connection would be a big issue in the event > of PMTU change since the worst case is that existing commands have to > run to completion using the inefficient PMTU. The initiator also has > the options of aborting and restarting the commands if they can't > complete with the old PMTU, or better, open another connection with > the appropriate MaxPDUDataLength and change the command allegiance. > > - Rod > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Mallikarjun C. > Sent: Tuesday, June 11, 2002 2:35 PM > To: Eddy Quicksall; Julian Satran > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: changing MaxPDUDataLength > > > Eddy, > > I am not clear on why you think the target code becomes messy on > a PDU size change. The last para in section 4.4 states the > following - > > "Parameters negotiated by a text exchange negotiation sequence become > effective only after the negotiation sequence is completed." > > Since the target gets to complete a text negotiation with a Text > Response > PDU, it can time the applicability of a changed > MaxRecvDataSegmentLength. > > Requiring that an initiator must idle the connection before changing > this > parameter, IMHO, is counter-productive when there's a dynamic PMTU > degradation in the presence of long-running commands (writes in > particular). > Once the initiator starts the renegotiation, target would ideally want > to quickly > renegotiate its receive size as well to receive ULPDU-contained > segments. > > In short, seems to me that the draft is saying what you would like. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > > ----- Original Message ----- > From: "Eddy Quicksall" > To: "Julian Satran" > Cc: > Sent: Tuesday, June 11, 2002 7:56 AM > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > I think it should be a requirement because if it is not, all target > code > > will have to have the messy code. Or, we could say that if it is not > idle > > commands, then the target may reject it. > > > > Eddy > > > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Tuesday, June 11, 2002 9:11 AM > > To: Eddy Quicksall > > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > That is a fair request - we may slip in a recommendation to that > effect (in > > chapter 11?) > > > > Julo > > > > > > > > Eddy Quicksall > > > > > > 06/11/2002 04:28 AM > > Please respond to Eddy Quicksall > > > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > How about if we say that an initiator must not change the > MaxPDUDataSize > > unless it first idles the commands (at least the ones with the R > bit) or if > > ErrorRecoveryLevel==0? > > > > That would simplify target code greatly and would meet the design > goals; and > > since it should be rare to change it, it would be of little impact > to idle > > the commands for a split second. > > > > > > Eddy > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Monday, June 10, 2002 8:06 PM > > To: Eddy Quicksall > > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > I said only that when you change length you can ask for all PDUs > after the > > ack! (no need to keep a tall - the old offsets are good up to the > hole). > > > > Julo > > > > > > Eddy Quicksall > > > > > > 06/11/2002 12:32 AM > > Please respond to Eddy Quicksall > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > Julian, > > > > Another problem here is that the target has to calculate the offset > from the > > DataSN #. And as BegRun can be any value. E.g., BegRun=4 and > RunLngth=0 > > means starting DataSN=4, send all the data for that sequence. > > > > I think it would be a performance hit and waist of memory to keep a > tally of > > all PDU sizes just for an occasional SNACK. > > > > It's not that it can't be done ... it is more that it is messy and I > think > > there is a solution that will satisfy the design requirements but > keep the > > software simpler. > > > > Eddy > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Saturday, June 08, 2002 10:16 PM > > To: Eddy Quicksall > > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > That is not completely accurate. > > The only problem is when PDU size decreases and then SNACK must be > for all > > data. > > Target can also keep a mapping of numbers/to offsets (the list > should be > > small and if it gets long ask for ack (A-bit). > > > > Julo > > > > Eddy Quicksall > > Sent by: owner-ips@ece.cmu.edu > > > > > > 06/08/2002 10:54 PM > > Please respond to Eddy Quicksall > > > > > > To: pat_thaler@agilent.com > > cc: ips@ece.cmu.edu > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > > > Thanks, > > > > As a target, I won't be able to let it change until all of the > outstanding > > commands are finished (running with ErrorRecoveryLevel>=1). This is > because > > I must use the PDU size to compute the offset from a SNACK's > > BegRun/RunLength. > > > > So, I plan to not give the text response for a MaxPDURecvDataLength > in FFP > > until I get back an ExpStatSN == next StatSN. > > > > This will cause a delay of unknown time before the PDU size can > actually > > change ... do you see any problem with this? > > > > Eddy > > > > -----Original Message----- > > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > > Sent: Friday, June 07, 2002 1:13 PM > > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > Eddy, > > > > If one uses a message sync and steering that relys on the transport > segments > > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if > the path > > MTU changes one would want to change the PDU data length to fit the > new path > > MTU. > > > > Pat > > > > -----Original Message----- > > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > > Sent: Wednesday, June 05, 2002 12:24 PM > > To: ips@ece.cmu.edu > > Subject: iSCSI: changing MaxPDUDataLength > > > > > > Does anybody know a case where it is necessary to support a new PDU > data > > length during full feature phase? > > > > Eddy > > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Wed Jun 12 14:36:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08594 for ; Wed, 12 Jun 2002 14:36:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CHfEk14296 for ips-outgoing; Wed, 12 Jun 2002 13:41:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CHfBw14288; Wed, 12 Jun 2002 13:41:11 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 0DE8B10DF; Wed, 12 Jun 2002 11:41:10 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 8E1FE246; Wed, 12 Jun 2002 11:41:09 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 12 Jun 2002 11:41:08 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 11:41:06 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E4361@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: iSCSI: 12-97 Bit Rule Date: Wed, 12 Jun 2002 11:41:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-11cd19fb-aad0-4b4d-8765-57b0e58900bc" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-11cd19fb-aad0-4b4d-8765-57b0e58900bc Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21238.5443E740" ------_=_NextPart_001_01C21238.5443E740 Content-Type: text/plain; charset="iso-8859-1" Julian, The bit rule added to 12-97 (1.3.4 page 31) is inconsistant with the clauses above it: Word Rule, Half-Word Rule and Byte Rule. It says "when the sequence of bits has a positional significance (e.g., a modulo 2 polynomial) then bit 7 of the lowest numbered byte is considered the most significant bit (2**n), followed by ...." When bits represent a number, they have positional significance so that sentence applies. However, the other rules apply the opposite significance to the bits within each byte. Also, note that bits represent polynomials at other times than the CRC such as for the purpose of authentication or encryption algorithms and those algorithms do not necessarily use the bit significance of the Bit Rule. The bit rule only applies to bit significance for CRC calculation. Bit Rule should be CRC Bit Rule and the associated text should make it clear that it only applies to the CRC calculation. Since it only applies there, it would be kinder to the reader to put the text in 11.1 rather than making the reader of 11.1 look nearly 200 pages back in the spec. Regards, Pat ------_=_NextPart_001_01C21238.5443E740 Content-Type: text/html; charset="iso-8859-1"
Julian,
 
The bit rule added to 12-97 (1.3.4 page 31) is inconsistant with the clauses above it: Word Rule,  Half-Word Rule and Byte Rule.
 
It says "when the sequence of bits has a positional significance (e.g., a modulo 2 polynomial) then bit 7 of the lowest numbered byte is considered the most significant bit (2**n), followed by ...."
 
When bits represent a number, they have positional significance so that sentence applies. However, the other rules apply the opposite significance to the bits within each byte.
 
Also, note that bits represent polynomials at other times than the CRC such as for the purpose of authentication or encryption algorithms and those algorithms do not necessarily use the bit significance of the Bit Rule. The bit rule only applies to bit significance for CRC calculation.
 
Bit Rule should be CRC Bit Rule and the associated text should make it clear that it only applies to the CRC calculation. Since it only applies there, it would be kinder to the reader to put the text in 11.1 rather than making the reader of 11.1 look nearly 200 pages back in the spec.
 
Regards,
Pat
------_=_NextPart_001_01C21238.5443E740-- ------=_NextPartTM-000-11cd19fb-aad0-4b4d-8765-57b0e58900bc-- From owner-ips@ece.cmu.edu Wed Jun 12 14:36:44 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08578 for ; Wed, 12 Jun 2002 14:36:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CHo4I14865 for ips-outgoing; Wed, 12 Jun 2002 13:50:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from med.corp.rhapsodynetworks.com (64-160-62-201.rhapsodynetworks.com [64.160.62.201] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CHo0w14858; Wed, 12 Jun 2002 13:50:00 -0400 (EDT) Received: by med.corp.rhapsodynetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 10:49:54 -0700 Message-ID: <45BEF1D68145D51186C100B0D0AABE659E016D@med.corp.rhapsodynetworks.com> From: Dennis Young To: "'Julian Satran'" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Date: Wed, 12 Jun 2002 10:49:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21239.8EAD40B0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21239.8EAD40B0 Content-Type: text/plain; charset="iso-8859-1" Are you saying that, for a session that has InitialR2T=No in effect, the initiator must send all its data as unsolicited first, up to the amount negotiated in FirstBurstSize, before it waits for a R2T from the target? Can you shed some light on why we need unsolicited Data-out PDU when there is ImmediateData, seems like they both serve the same purpose, having both of them only make the spec more complex. Thanks, -Dennis -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 10:19 AM To: Dennis Young Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question This is the reason why the initiator is required to send ALL unsolicited data (target can count on it and start sending R2Ts as soon as it sees the first header> Neither bandwidth nor latency are wasted. Julo Dennis Young 06/12/2002 08:05 PM Please respond to Dennis Young To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Julian, This leads me to a more interesting question. A session with InitialR2T=No in effect, i.e. unsolicited Data-out allowed, could cause unintended waste of bandwidth, depending on how fast the target sends our R2T in response to the SCSI Write. If the target sees the unsolicited Data-out PDU before building the R2T, then everything is fine. If the target doesn't see the unsolicited Data-out PDU before building the R2T, the R2T would request the same portion of data in the unsolicited Data-out, thus bandwidth is wasted. The question is, how can a target be smart about this? Should the target wait a moment for the possible unsolicited Data-out after receiving each SCSI Write, this sounds kludgy. Also, why do we need the unsolicited Data-out PDU feature when there is ImmediateData? Regards, Dennis -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 6:05 AM To: Dennis Young Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iscsi: unsolicited data question yes - julo Dennis Young Sent by: owner-ips@ece.cmu.edu 06/12/2002 06:20 AM Please respond to Dennis Young To: ips@ece.cmu.edu cc: Subject: iscsi: unsolicited data question I have a question which has been asked before, but I couldn't find a direct answer in the archive. The table on page 200 of draft 12 doesn't directly answer this question either. The first paragraph on page 36 of draft 12 says "Targets operate in either solicitied (R2T) data mode or unsolicited (non R2T) data mode." tells me that a target, at all times during a data sequence transfer, can be one or the other, but not both (non R2T for the initial data out, R2T for the remaining data). Is this correct? Thanks, Dennis ---snip from an old email dated 3/30/2001--- " Hi Julian Sorry if I'm covering old ground... Is it possible to use unsolicited data for the first burst and then request any remaining data using R2T? For example, if the target has a previously allocated buffer available (length defined by FirstBurstSize) for unsolicited data, then once the initiator has sent unsolicited data up to and including this amount then the remaining data (if any) can be requested using R2T once the target has the buffer space available. ...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail: matthewb@bri.hp.com " ------_=_NextPart_001_01C21239.8EAD40B0 Content-Type: text/html; charset="iso-8859-1"
Are you saying that, for a session that has InitialR2T=No in effect, the initiator
must send all its data as unsolicited first, up to the amount negotiated in
FirstBurstSize, before it waits for a R2T from the target? 
 
Can you shed some light on why we need unsolicited Data-out PDU when there 
is ImmediateData, seems like they both serve the same purpose, having both of
them only make the spec more complex.
 
Thanks,
-Dennis
 
 -----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 12, 2002 10:19 AM
To: Dennis Young
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iscsi: unsolicited data question


This is the reason why the initiator is required to send ALL unsolicited data (target can count on it and start sending R2Ts as soon as it sees the first header>
Neither bandwidth nor latency are wasted.

Julo


Dennis Young <dyoung@rhapsodynetworks.com>

06/12/2002 08:05 PM
Please respond to Dennis Young

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
        Subject:        RE: iscsi: unsolicited data question

       


Julian,
 
This leads me to a more interesting question.
A session with InitialR2T=No in effect, i.e. unsolicited Data-out
allowed, could cause unintended waste of bandwidth, depending on
how fast the target sends our R2T in response to the SCSI Write.
 
If the target sees the unsolicited Data-out PDU before building the
R2T, then everything is fine.
If the target doesn't see the unsolicited Data-out PDU before building
the R2T, the R2T would request the same portion of data in the
unsolicited Data-out, thus bandwidth is wasted.
 
The question is, how can a target be smart about this?
Should the target wait a moment for the possible unsolicited Data-out
after receiving each SCSI Write, this sounds kludgy.
 
Also, why do we need the unsolicited Data-out PDU feature when
there is ImmediateData?
 
Regards,
Dennis
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 12, 2002 6:05 AM
To: Dennis Young
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iscsi: unsolicited data question


yes - julo

Dennis Young <dyoung@rhapsodynetworks.com>
Sent by: owner-ips@ece.cmu.edu

06/12/2002 06:20 AM
Please respond to Dennis Young

       
       To:        ips@ece.cmu.edu
       cc:        
       Subject:        iscsi: unsolicited data question

     



I have a question which has been asked before, but I couldn't find a direct
answer in the archive.  The table on page 200 of draft 12 doesn't directly
answer this question either.

The first paragraph on page 36 of draft 12 says "Targets operate in either
solicitied (R2T) data mode or unsolicited (non R2T) data mode."
tells me that a target, at all times during a data sequence transfer, can be

one or the other, but not both (non R2T for the initial data out, R2T for
the
remaining data).  Is this correct?

Thanks,
Dennis

---snip from an old email dated 3/30/2001---

" Hi Julian
Sorry if I'm covering old ground... Is it possible to use unsolicited data
for the first burst and then request any remaining data using R2T? For
example, if the target has a previously allocated buffer available (length
defined by FirstBurstSize) for unsolicited data, then once the initiator has
sent unsolicited data up to and including this amount then the remaining
data (if any) can be requested using R2T once the target has the buffer
space available.
...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail:
matthewb@bri.hp.com "





------_=_NextPart_001_01C21239.8EAD40B0-- From owner-ips@ece.cmu.edu Wed Jun 12 14:38:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08687 for ; Wed, 12 Jun 2002 14:37:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CI5vi15971 for ips-outgoing; Wed, 12 Jun 2002 14:05:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CI5rw15963 for ; Wed, 12 Jun 2002 14:05:53 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel13.hp.com (Postfix) with ESMTP id EED2E400992; Wed, 12 Jun 2002 11:05:47 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id LAA11997; Wed, 12 Jun 2002 11:07:36 -0700 (PDT) Message-ID: <005101c2123b$c7094880$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Eddy Quicksall" , "Rod Harrison" , "Julian Satran" Cc: References: Subject: Re: iSCSI: changing MaxPDUDataLength Date: Wed, 12 Jun 2002 11:05:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I am afraid this thread is going in circles, let me respond to this message before I rest my case on this topic. > I think you have misunderstood something... I'm not suggesting that you > mandate "no text negotiation till quiesced". I'm suggesting that only when > Max length changes and then only for the READS. This suggestion is to > simplify the logic you point out below. > > What are the harmful effects you mention below? As I earlier hinted twice, the Data-Out PDUs will not be ULPDU-contained anymore - and that could mean target would need to spend more memory/bus bandwidth/computation to deal with those till the long write is done. I do not understand your specific proposal yet. If you're arguing that a special case be made for reads, a cogent, clear rationale for the special case, coupled with the specifics of your proposal, would help the WG consider this further. Based on my current understanding of your position, I currently don't see the need for the special case. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com > > Eddy > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Tuesday, June 11, 2002 8:54 PM > To: Eddy Quicksall; Julian Satran > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: changing MaxPDUDataLength > > > > Can you suggest how this would be handled otherwise? > > I earlier said I will not get into implementation details, I will > however provide a generic answer. > > Given that the changed PDU size is not specific to one command, > I see the history of "past max PDU size(s)" as a connection attribute. > All you need on a per-task basis is really the value of one DataSN > *where* it had changed. > > We could further debate how to deal with multiple number of PDU size > changes during the life of an I/O - but I'm reluctant to be involved in that > debate because a) it's most unlikely, and b) there's no hard requirement > that > the target must always satisfy SNACKs under extreme conditions, and finally > c) it's too implementation-specific to be discussed on the ips reflector. > > Finally, I'd like to remind you that mandating "no text negotiation till > quiesced" > has harmful effects on targets dealing with long writes and wanting ULPDU- > containment - whose case you may be arguing. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > > ----- Original Message ----- > From: "Eddy Quicksall" > To: "Mallikarjun C." ; "Julian Satran" > > Cc: > Sent: Tuesday, June 11, 2002 4:45 PM > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > Consider the following (using Julian's suggestion): > > > > -> cmd 1 > > -> req to change to length 2 > > -> cmd 2 > > > > <- stat 1 > > <- data 2, PDU 0, Length 1 > > > > -> cmd 3, ack 1 so change the length > > > > <- data 2, PDU 1, Length 2 > > > > -> SNACK data 2, PDU 1 > > > > So we have to calculate the offset for Data 2, PDU 1 using old length and > > send data after that offset using new length. That means keeping track of > > PDU lengths which I would like to avoid. > > > > Or, the target would have to force idling of commands before it gives the > > response to the change. > > > > Can you suggest how this would be handled otherwise? > > > > Eddy > > > > -----Original Message----- > > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > > Sent: Tuesday, June 11, 2002 6:57 PM > > To: Eddy Quicksall; Julian Satran > > Cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: changing MaxPDUDataLength > > > > > > Eddy, > > > > I am not sure if you're agreeing with me or not... but let me add some > > comments. > > > > I don't expect the change in PDU size to happen frequently - no change > > in what I earlier said. > > > > You are making an assumption that a target must record the PDU size for > > every > > PDU if SNACKs are to be satisfied across changed > MaxRecvDataSegmentLength. > > > > As Julian earlier said, you don't have to. I will not go into > > implementation details, but > > I believe just the value of the DataSN from which the new size is > effective > > should > > be all that's needed. Besides, the spec guarantees that only RunLength=0 > is > > used > > on any SNACK after the change. > > > > You are also implying that targets can declare their changed > > MaxRecvDataSegmentLength > > anytime just for writes. There are two problems with this - a) reads and > > writes may both > > be active in the typical case on an iSCSI connection, and b) a target can > > declare its changed > > value only if an initiator is allowed to start the Text Request (and I > > thought you were suggesting > > that we explicitly disallow that). > > > > Hope that clears it up. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > > cbm@rose.hp.com > > > > > > ----- Original Message ----- > > From: "Eddy Quicksall" > > To: "Mallikarjun C." ; "Julian Satran" > > > > Cc: > > Sent: Tuesday, June 11, 2002 3:18 PM > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > You are correct and that is exactly how I have had to code it. With fast > > > path and slow path code split between processors, it becomes even worse. > > > > > > When I read your comments on why the PDU size could change (from way > back > > in > > > March I think), I got did not get the impression that it would happen > very > > > often and that in fact it may only happen when you are maintaining > > > allegiance to another connection. > > > > > > If it is something that is not going to happen very often, then it would > > be > > > so much easier to have the initiator idle the commands first (all it > > really > > > needs to do is idle the READ commands). If it is going to change so > often > > > that idling would be degrading, I suspect that just doing the > negotiation > > > that often would itself be degrading. > > > > > > And, be aware that the target will probably idle the R commands. > > Otherwise, > > > it will have to track PDU sizes and that would be really > > > "counter-productive" (especially when there should be no SNACKs on a > good > > > connection anyway). > > > > > > I don't see any problem with the target negotiating its size at any > time. > > > And the initiator would not have to idle the WRITE or no-data commands. > > > > > > Eddy > > > > > > -----Original Message----- > > > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > > > Sent: Tuesday, June 11, 2002 3:35 PM > > > To: Eddy Quicksall; Julian Satran > > > Cc: ips@ece.cmu.edu > > > Subject: Re: iSCSI: changing MaxPDUDataLength > > > > > > > > > Eddy, > > > > > > I am not clear on why you think the target code becomes messy on > > > a PDU size change. The last para in section 4.4 states the following - > > > > > > "Parameters negotiated by a text exchange negotiation sequence become > > > effective only after the negotiation sequence is completed." > > > > > > Since the target gets to complete a text negotiation with a Text > Response > > > PDU, it can time the applicability of a changed > MaxRecvDataSegmentLength. > > > > > > Requiring that an initiator must idle the connection before changing > this > > > parameter, IMHO, is counter-productive when there's a dynamic PMTU > > > degradation in the presence of long-running commands (writes in > > particular). > > > Once the initiator starts the renegotiation, target would ideally want > to > > > quickly > > > renegotiate its receive size as well to receive ULPDU-contained > segments. > > > > > > In short, seems to me that the draft is saying what you would like. > > > -- > > > Mallikarjun > > > > > > Mallikarjun Chadalapaka > > > Networked Storage Architecture > > > Network Storage Solutions > > > Hewlett-Packard MS 5668 > > > Roseville CA 95747 > > > cbm@rose.hp.com > > > > > > > > > ----- Original Message ----- > > > From: "Eddy Quicksall" > > > To: "Julian Satran" > > > Cc: > > > Sent: Tuesday, June 11, 2002 7:56 AM > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > I think it should be a requirement because if it is not, all target > code > > > > will have to have the messy code. Or, we could say that if it is not > > idle > > > > commands, then the target may reject it. > > > > > > > > Eddy > > > > > > > > -----Original Message----- > > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > > Sent: Tuesday, June 11, 2002 9:11 AM > > > > To: Eddy Quicksall > > > > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > > > > > That is a fair request - we may slip in a recommendation to that > effect > > > (in > > > > chapter 11?) > > > > > > > > Julo > > > > > > > > > > > > > > > > Eddy Quicksall > > > > > > > > > > > > 06/11/2002 04:28 AM > > > > Please respond to Eddy Quicksall > > > > > > > > > > > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > > > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > > > > > > > > > How about if we say that an initiator must not change the > MaxPDUDataSize > > > > unless it first idles the commands (at least the ones with the R bit) > or > > > if > > > > ErrorRecoveryLevel==0? > > > > > > > > That would simplify target code greatly and would meet the design > goals; > > > and > > > > since it should be rare to change it, it would be of little impact to > > idle > > > > the commands for a split second. > > > > > > > > > > > > Eddy > > > > -----Original Message----- > > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > > Sent: Monday, June 10, 2002 8:06 PM > > > > To: Eddy Quicksall > > > > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > I said only that when you change length you can ask for all PDUs after > > the > > > > ack! (no need to keep a tall - the old offsets are good up to the > hole). > > > > > > > > > > Julo > > > > > > > > > > > > Eddy Quicksall > > > > > > > > > > > > 06/11/2002 12:32 AM > > > > Please respond to Eddy Quicksall > > > > > > > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > > > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > > > > > > > > > > > > > Julian, > > > > > > > > Another problem here is that the target has to calculate the offset > from > > > the > > > > DataSN #. And as BegRun can be any value. E.g., BegRun=4 and > RunLngth=0 > > > > means starting DataSN=4, send all the data for that sequence. > > > > > > > > I think it would be a performance hit and waist of memory to keep a > > tally > > > of > > > > all PDU sizes just for an occasional SNACK. > > > > > > > > It's not that it can't be done ... it is more that it is messy and I > > think > > > > there is a solution that will satisfy the design requirements but keep > > the > > > > software simpler. > > > > > > > > Eddy > > > > -----Original Message----- > > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > > Sent: Saturday, June 08, 2002 10:16 PM > > > > To: Eddy Quicksall > > > > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > That is not completely accurate. > > > > The only problem is when PDU size decreases and then SNACK must be for > > all > > > > data. > > > > Target can also keep a mapping of numbers/to offsets (the list should > be > > > > small and if it gets long ask for ack (A-bit). > > > > > > > > Julo > > > > > > > > Eddy Quicksall > > > > Sent by: owner-ips@ece.cmu.edu > > > > > > > > > > > > 06/08/2002 10:54 PM > > > > Please respond to Eddy Quicksall > > > > > > > > > > > > To: pat_thaler@agilent.com > > > > cc: ips@ece.cmu.edu > > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > As a target, I won't be able to let it change until all of the > > outstanding > > > > commands are finished (running with ErrorRecoveryLevel>=1). This is > > > because > > > > I must use the PDU size to compute the offset from a SNACK's > > > > BegRun/RunLength. > > > > > > > > So, I plan to not give the text response for a MaxPDURecvDataLength in > > FFP > > > > until I get back an ExpStatSN == next StatSN. > > > > > > > > This will cause a delay of unknown time before the PDU size can > actually > > > > change ... do you see any problem with this? > > > > > > > > Eddy > > > > > > > > -----Original Message----- > > > > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > > > > Sent: Friday, June 07, 2002 1:13 PM > > > > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > Eddy, > > > > > > > > If one uses a message sync and steering that relys on the transport > > > segments > > > > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the > > path > > > > MTU changes one would want to change the PDU data length to fit the > new > > > path > > > > MTU. > > > > > > > > Pat > > > > > > > > -----Original Message----- > > > > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > > > > Sent: Wednesday, June 05, 2002 12:24 PM > > > > To: ips@ece.cmu.edu > > > > Subject: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > Does anybody know a case where it is necessary to support a new PDU > data > > > > length during full feature phase? > > > > > > > > Eddy > > > > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Wed Jun 12 14:44:11 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08894 for ; Wed, 12 Jun 2002 14:44:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CIOq017276 for ips-outgoing; Wed, 12 Jun 2002 14:24:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CIOow17270; Wed, 12 Jun 2002 14:24:50 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 701551234; Wed, 12 Jun 2002 12:24:49 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 27CB214E; Wed, 12 Jun 2002 12:24:49 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 12 Jun 2002 12:24:49 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 12:24:49 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E438B@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI: CRC description Date: Wed, 12 Jun 2002 12:24:47 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-d4a7c429-de82-4d75-8564-727f32caabc3" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-d4a7c429-de82-4d75-8564-727f32caabc3 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2123E.6E7C08D0" ------_=_NextPart_001_01C2123E.6E7C08D0 Content-Type: text/plain; charset="iso-8859-1" Julian, The changes to the text on CRC are a step down rather than up in clarity. In particular: " - In the bit stream mentioned above the CRC bits are appended to the message bits with x^31 first followed by x^30 etc. In the examples provided in Appendix B.4 - CRC Examples, the value is outlined as a word sent or received and therefore the CRC bits are mapped into the CRC word according to Section 1.3.4 Bit Rule - i.e., the x^31 coefficient in bit 7 of the first byte of the digest continuing to through the byte the x^24 coefficient in bit 0 of the first byte, continuing with the x^23 coefficient in bit 7 of second byte through x^0 in bit 7 of the last byte. This statement will be very confusing to readers. The there is no abstract bit stream in which the CRC bits follow each other. Trying to specify the CRC with respect a bit stream will just lead to confusion. The old text with the changes I had suggested would provide more clarity. Also, there is no MUST on the CRC computation method. Using a compatible computation method is necessary to produce interoperability so there should be a MUST. I suggest the following which should allow for compatible variations in implementation: Replace, "The CRC should be calculated as follows:" with "The CRC MUST be calculated using a method that produces the same result as the following process:" Regards, Pat ------_=_NextPart_001_01C2123E.6E7C08D0 Content-Type: text/html; charset="iso-8859-1"
Julian,
 
The changes to the text on CRC are a step down rather than up in clarity.
 
In particular:

 " - In the bit stream mentioned above the CRC bits are appended   to the message bits with x^31 first followed by x^30 etc. In   the examples provided in Appendix B.4 - CRC Examples, the   value is outlined as a word sent or received and therefore   the CRC bits are mapped into the CRC word according to Section   1.3.4 Bit Rule - i.e., the x^31 coefficient in bit 7 of   the first byte of the digest continuing to through the byte the x^24 coefficient in bit 0 of the first byte, continuing with the x^23 coefficient in bit 7 of second byte through x^0 in bit 7 of the last byte.  

This statement will be very confusing to readers. The there is no abstract bit stream in which the CRC bits follow each other. Trying to specify the CRC with respect a bit stream will just lead to confusion. The old text with the changes I had suggested would provide more clarity.

Also, there is no MUST on the CRC computation method. Using a compatible computation method is necessary to produce interoperability so there should be a MUST. I suggest the following  which should allow for compatible variations in implementation:

Replace, "The CRC should be calculated as follows:" with "The CRC MUST be calculated using a method that produces the same result as the following process:"

Regards,
Pat

------_=_NextPart_001_01C2123E.6E7C08D0-- ------=_NextPartTM-000-d4a7c429-de82-4d75-8564-727f32caabc3-- From owner-ips@ece.cmu.edu Wed Jun 12 14:51:52 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09129 for ; Wed, 12 Jun 2002 14:51:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CIKxi16990 for ips-outgoing; Wed, 12 Jun 2002 14:20:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CIKvw16985; Wed, 12 Jun 2002 14:20:57 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5CIKoML012826; Wed, 12 Jun 2002 20:20:50 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5CIKnr145526; Wed, 12 Jun 2002 20:20:49 +0200 To: Dennis Young Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iscsi: unsolicited data question X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 12 Jun 2002 21:20:38 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 12/06/2002 21:20:49, Serialize complete at 12/06/2002 21:20:49 Content-Type: multipart/alternative; boundary="=_alternative 0064B1B2C2256BD6_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0064B1B2C2256BD6_= Content-Type: text/plain; charset="us-ascii" You are wrong about waiting - read my previous text. You need unsolicited as the amount in one PDU may not be all you want. Julo Dennis Young Sent by: owner-ips@ece.cmu.edu 06/12/2002 08:49 PM Please respond to Dennis Young To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Are you saying that, for a session that has InitialR2T=No in effect, the initiator must send all its data as unsolicited first, up to the amount negotiated in FirstBurstSize, before it waits for a R2T from the target? Can you shed some light on why we need unsolicited Data-out PDU when there is ImmediateData, seems like they both serve the same purpose, having both of them only make the spec more complex. Thanks, -Dennis -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 10:19 AM To: Dennis Young Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question This is the reason why the initiator is required to send ALL unsolicited data (target can count on it and start sending R2Ts as soon as it sees the first header> Neither bandwidth nor latency are wasted. Julo Dennis Young 06/12/2002 08:05 PM Please respond to Dennis Young To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Julian, This leads me to a more interesting question. A session with InitialR2T=No in effect, i.e. unsolicited Data-out allowed, could cause unintended waste of bandwidth, depending on how fast the target sends our R2T in response to the SCSI Write. If the target sees the unsolicited Data-out PDU before building the R2T, then everything is fine. If the target doesn't see the unsolicited Data-out PDU before building the R2T, the R2T would request the same portion of data in the unsolicited Data-out, thus bandwidth is wasted. The question is, how can a target be smart about this? Should the target wait a moment for the possible unsolicited Data-out after receiving each SCSI Write, this sounds kludgy. Also, why do we need the unsolicited Data-out PDU feature when there is ImmediateData? Regards, Dennis -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 6:05 AM To: Dennis Young Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iscsi: unsolicited data question yes - julo Dennis Young Sent by: owner-ips@ece.cmu.edu 06/12/2002 06:20 AM Please respond to Dennis Young To: ips@ece.cmu.edu cc: Subject: iscsi: unsolicited data question I have a question which has been asked before, but I couldn't find a direct answer in the archive. The table on page 200 of draft 12 doesn't directly answer this question either. The first paragraph on page 36 of draft 12 says "Targets operate in either solicitied (R2T) data mode or unsolicited (non R2T) data mode." tells me that a target, at all times during a data sequence transfer, can be one or the other, but not both (non R2T for the initial data out, R2T for the remaining data). Is this correct? Thanks, Dennis ---snip from an old email dated 3/30/2001--- " Hi Julian Sorry if I'm covering old ground... Is it possible to use unsolicited data for the first burst and then request any remaining data using R2T? For example, if the target has a previously allocated buffer available (length defined by FirstBurstSize) for unsolicited data, then once the initiator has sent unsolicited data up to and including this amount then the remaining data (if any) can be requested using R2T once the target has the buffer space available. ...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail: matthewb@bri.hp.com " --=_alternative 0064B1B2C2256BD6_= Content-Type: text/html; charset="us-ascii"
You are wrong about waiting - read my previous text.
You need unsolicited as the amount in one PDU may not be all you want.

Julo


Dennis Young <dyoung@rhapsodynetworks.com>
Sent by: owner-ips@ece.cmu.edu

06/12/2002 08:49 PM
Please respond to Dennis Young

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
        Subject:        RE: iscsi: unsolicited data question

       


Are you saying that, for a session that has InitialR2T=No in effect, the initiator
must send all its data as unsolicited first, up to the amount negotiated in
FirstBurstSize, before it waits for a R2T from the target?
 
Can you shed some light on why we need unsolicited Data-out PDU when there
is ImmediateData, seems like they both serve the same purpose, having both of
them only make the spec more complex.
 
Thanks,
-Dennis
 
 -----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 12, 2002 10:19 AM
To: Dennis Young
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iscsi: unsolicited data question

This is the reason why the initiator is required to send ALL unsolicited data (target can count on it and start sending R2Ts as soon as it sees the first header>
Neither bandwidth nor latency are wasted.

Julo

Dennis Young <dyoung@rhapsodynetworks.com>

06/12/2002 08:05 PM
Please respond to Dennis Young

       
       To:        Julian Satran/Haifa/IBM@IBMIL
       cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
       Subject:        RE: iscsi: unsolicited data question

     



Julian,
 
This leads me to a more interesting question.
A session with InitialR2T=No in effect, i.e. unsolicited Data-out
allowed, could cause unintended waste of bandwidth, depending on
how fast the target sends our R2T in response to the SCSI Write.
 
If the target sees the unsolicited Data-out PDU before building the
R2T, then everything is fine.
If the target doesn't see the unsolicited Data-out PDU before building
the R2T, the R2T would request the same portion of data in the
unsolicited Data-out, thus bandwidth is wasted.
 
The question is, how can a target be smart about this?
Should the target wait a moment for the possible unsolicited Data-out
after receiving each SCSI Write, this sounds kludgy.
 
Also, why do we need the unsolicited Data-out PDU feature when
there is ImmediateData?
 
Regards,
Dennis
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 12, 2002 6:05 AM
To: Dennis Young
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iscsi: unsolicited data question


yes - julo
Dennis Young <dyoung@rhapsodynetworks.com>
Sent by: owner-ips@ece.cmu.edu

06/12/2002 06:20 AM
Please respond to Dennis Young

       
      To:        ips@ece.cmu.edu
      cc:        
      Subject:        iscsi: unsolicited data question

     




I have a question which has been asked before, but I couldn't find a direct
answer in the archive.  The table on page 200 of draft 12 doesn't directly
answer this question either.

The first paragraph on page 36 of draft 12 says "Targets operate in either
solicitied (R2T) data mode or unsolicited (non R2T) data mode."
tells me that a target, at all times during a data sequence transfer, can be

one or the other, but not both (non R2T for the initial data out, R2T for
the
remaining data).  Is this correct?

Thanks,
Dennis

---snip from an old email dated 3/30/2001---

" Hi Julian
Sorry if I'm covering old ground... Is it possible to use unsolicited data
for the first burst and then request any remaining data using R2T? For
example, if the target has a previously allocated buffer available (length
defined by FirstBurstSize) for unsolicited data, then once the initiator has
sent unsolicited data up to and including this amount then the remaining
data (if any) can be requested using R2T once the target has the buffer
space available.
...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail:
matthewb@bri.hp.com "

--=_alternative 0064B1B2C2256BD6_=-- From owner-ips@ece.cmu.edu Wed Jun 12 14:53:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09253 for ; Wed, 12 Jun 2002 14:53:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CIX6X17832 for ips-outgoing; Wed, 12 Jun 2002 14:33:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CIX4w17825 for ; Wed, 12 Jun 2002 14:33:04 -0400 (EDT) Received: from cisco.com (dhcp-161-44-68-217.cisco.com [161.44.68.217]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA18585 for ; Wed, 12 Jun 2002 14:32:58 -0400 (EDT) Message-ID: <3D0793D9.5EBAA0DB@cisco.com> Date: Wed, 12 Jun 2002 13:32:58 -0500 From: Steve Senum X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ips Subject: iSCSI: 7.2.1 CHAP Considerations (12-98) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I have a concern over the wording of the following text from section 7.2.1 (12-98 version): When CHAP is used with secret shorter than 96 bits, a compliant implementation MUST NOT continue with the login unless it can verify that IPsec encryption is being used to protect the connection. I know the above is attempt to "put some teeth" into the requirements to make the use of CHAP secure, but I believe there are common cases where the length of the CHAP secret cannot be verified, such as when a RADIUS server is being used. Regards, Steve Senum From owner-ips@ece.cmu.edu Wed Jun 12 14:55:54 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09360 for ; Wed, 12 Jun 2002 14:55:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CIXHH17853 for ips-outgoing; Wed, 12 Jun 2002 14:33:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CIXEw17844 for ; Wed, 12 Jun 2002 14:33:15 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel10.hp.com (Postfix) with ESMTP id 443B3C00BDC; Wed, 12 Jun 2002 11:33:09 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id LAA18840; Wed, 12 Jun 2002 11:33:02 -0700 (PDT) Message-ID: <3D0795D3.92AA67CC@cup.hp.com> Date: Wed, 12 Jun 2002 11:41:23 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iSCSI-Asynch event code References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Why is this needed ? The target can just send an async event to drop the connection or request a connection logout, and the connection can be re-established allowing for new negotiation. I don't see the point of making this change so late in the game. There exist mechanisms such as target driven connection logout/drop which can be used to achieve the same effect. In any case, what do you do if the initiator does not respond with a text message ? The target would end up dropping the cxn with an async message in this case, causing a re-login and thus, re-negotiation. To summarize, I don't see a need for this change, since there are simpler mechanisms to achieve the same effect. In particular, given that we are so close to the finish line, I suggest that we not make this change, but instead, use the async cxn/ssn logout/drop mechanisms. Rgds, Santosh Julian Satran wrote: > > Dear colleagues, > > I plan to add to the text in 9.9.1 an additional event code as > follows. It is needed for completeness. > > 4 - target requests parameter negotiation on this connection. The > initiator MUST honor this request by issuing a Text Request (that can > be empty) on the same connection as early as possible unless a Text > Request is already pending on the connection or by issuing a Logout > Request. > Julo -- The world is so fast that there are days when the person who says it can't be done is interrupted by the person who is doing it. ~ Anon From owner-ips@ece.cmu.edu Wed Jun 12 15:13:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10130 for ; Wed, 12 Jun 2002 15:13:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CIfQg18404 for ips-outgoing; Wed, 12 Jun 2002 14:41:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CIfOw18399 for ; Wed, 12 Jun 2002 14:41:24 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5CIfIUi059310 for ; Wed, 12 Jun 2002 20:41:18 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5CIfIr115784 for ; Wed, 12 Jun 2002 20:41:18 +0200 To: ips@ece.cmu.edu Importance: High MIME-Version: 1.0 Subject: RE: iSCSI: CRC description X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 12 Jun 2002 21:41:17 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 12/06/2002 21:41:17, Serialize complete at 12/06/2002 21:41:17 Content-Type: multipart/alternative; boundary="=_alternative 00661FBCC2256BD6_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00661FBCC2256BD6_= Content-Type: text/plain; charset="us-ascii" The thing about this text that is going on and on is very frustrating. First Vince insisted on emphasis. Now you find it confusing. I gave it as a quiz to a undergraduate class and no one made a mistake. How much effort do you think I will spend on it? And who are the people that are confused? Julo pat_thaler@agilent.com 06/12/2002 09:24 PM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI: CRC description Julian, The changes to the text on CRC are a step down rather than up in clarity. In particular: " - In the bit stream mentioned above the CRC bits are appended to the message bits with x^31 first followed by x^30 etc. In the examples provided in Appendix B.4 - CRC Examples, the value is outlined as a word sent or received and therefore the CRC bits are mapped into the CRC word according to Section 1.3.4 Bit Rule - i.e., the x^31 coefficient in bit 7 of the first byte of the digest continuing to through the byte the x^24 coefficient in bit 0 of the first byte, continuing with the x^23 coefficient in bit 7 of second byte through x^0 in bit 7 of the last byte. This statement will be very confusing to readers. The there is no abstract bit stream in which the CRC bits follow each other. Trying to specify the CRC with respect a bit stream will just lead to confusion. The old text with the changes I had suggested would provide more clarity. Also, there is no MUST on the CRC computation method. Using a compatible computation method is necessary to produce interoperability so there should be a MUST. I suggest the following which should allow for compatible variations in implementation: Replace, "The CRC should be calculated as follows:" with "The CRC MUST be calculated using a method that produces the same result as the following process:" Regards, Pat --=_alternative 00661FBCC2256BD6_= Content-Type: text/html; charset="us-ascii"
The thing about this text that is going on and on is very frustrating.
First Vince insisted on emphasis.
Now you find it confusing.

I gave it as a quiz to a undergraduate class and no one made a mistake.

How much effort do you think I will spend on it? And who are the people that are confused?

Julo


pat_thaler@agilent.com

06/12/2002 09:24 PM
Please respond to pat_thaler

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
        Subject:        RE: iSCSI: CRC description

       


Julian,
 
The changes to the text on CRC are a step down rather than up in clarity.
 
In particular:

 " - In the bit stream mentioned above the CRC bits are appended   to the message bits with x^31 first followed by x^30 etc. In   the examples provided in Appendix B.4 - CRC Examples, the   value is outlined as a word sent or received and therefore   the CRC bits are mapped into the CRC word according to Section   1.3.4 Bit Rule - i.e., the x^31 coefficient in bit 7 of   the first byte of the digest continuing to through the byte the x^24 coefficient in bit 0 of the first ! byte, continuing with the x^23 coefficient in bit 7 of second byte through x^0 in bit 7 of the last byte.  

This statement will be very confusing to readers. The there is no abstract bit stream in which the CRC bits follow each other. Trying to specify the CRC with respect a bit stream will just lead to confusion. The old text with the changes I had suggested would provide more clarity.

Also, there is no MUST on the CRC computation method. Using a compatible computation method is necessary to produce interoperability so there should be a MUST. I suggest the following  which should allow for compatible variations in implementation:

Replace, "The CRC should be calculated as follows:" with "The CRC MUST be calculated using a method that produces the same result as the following process:"

Regards,
Pat

--=_alternative 00661FBCC2256BD6_=-- From owner-ips@ece.cmu.edu Wed Jun 12 15:57:10 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11164 for ; Wed, 12 Jun 2002 15:57:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CJex222348 for ips-outgoing; Wed, 12 Jun 2002 15:40:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CJeuw22342; Wed, 12 Jun 2002 15:40:56 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id E5D7430706; Wed, 12 Jun 2002 15:40:55 -0400 (EDT) Date: Wed, 12 Jun 2002 12:38:47 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Dennis Young Cc: Julian Satran , , Subject: RE: iscsi: unsolicited data question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Wed, 12 Jun 2002, Julian Satran wrote: > This is the reason why the initiator is required to send ALL unsolicited > data (target can count on it and start sending R2Ts as soon as it sees the > first header> > Neither bandwidth nor latency are wasted. I'm agreeing with Julian, and commenting to Dennis. I don't find Dennis's note in my ips mailbox; I either deleted it too fast, or Julian's arrived before it. :-) > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu > Subject: RE: iscsi: unsolicited data question > > > > Julian, > > This leads me to a more interesting question. > A session with InitialR2T=No in effect, i.e. unsolicited Data-out > allowed, could cause unintended waste of bandwidth, depending on > how fast the target sends our R2T in response to the SCSI Write. > > If the target sees the unsolicited Data-out PDU before building the > R2T, then everything is fine. > If the target doesn't see the unsolicited Data-out PDU before building > the R2T, the R2T would request the same portion of data in the > unsolicited Data-out, thus bandwidth is wasted. > > The question is, how can a target be smart about this? > Should the target wait a moment for the possible unsolicited Data-out > after receiving each SCSI Write, this sounds kludgy. > > Also, why do we need the unsolicited Data-out PDU feature when > there is ImmediateData? To answer the last bit first, because you can burst out more PDU and convey more data than just one PDUs worth. Here's how I think about it. The initiator can, in principle, do one of four things (negotiations after this): 1) Send no unsolicited data and no immediate data with the command PDU. In this case, the F bit will be set, and the pdu's data length will be 0. Also, the initiator is now waiting for an initial R2T starting at byte 0. 2) Send no unsolicited data but send immediate data with the command PDU. In this case the F bit will be set, and the pdu's data length will be non-zero. The initiator is waiting for an R2T starting just after the data length. 3) Send unsolicited data but no immediate data with the command PDU. In this case, the F bit is not set and the pdu's data length will be 0. The initiator has just promised to send FirstBurstSize worth of data (up to the command max of course). Any subsequent R2Ts will start after FirstBurstSize. 4) Send unsolicited data and immediate data with the command PDU. In this case, the F bit is not set, and the pdu's data length will be non-zero. The initiator has just promised to send FirstBurstSize - pdu data len worht of data in subseqent DATA-OUT pdus. Any subsequent R2Ts will start after FirstBurstSize. Initial negotiations will possibly rule out some of these choices. If InitialR2T=Yes, options 3 & 4 go away. If ImmediateData=NO, options 2 & 4 go away. The important thing though is that as soon as the target processes the PDU, it knows which case it's in. It need not wait for future transmissions to figure out what to do, as you were describing in your question. Take care, Bill From owner-ips@ece.cmu.edu Wed Jun 12 15:57:39 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11187 for ; Wed, 12 Jun 2002 15:57:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CJP4f21333 for ips-outgoing; Wed, 12 Jun 2002 15:25:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CJP2w21326 for ; Wed, 12 Jun 2002 15:25:02 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5CJMLML047268; Wed, 12 Jun 2002 21:22:21 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5CJMKM78744; Wed, 12 Jun 2002 21:22:20 +0200 To: Santosh Rao Cc: ips@ece.cmu.edu, santoshr@hpcuhe.cup.hp.com MIME-Version: 1.0 Subject: Re: iSCSI-Asynch event code X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 12 Jun 2002 22:22:20 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 12/06/2002 22:22:20, Serialize complete at 12/06/2002 22:22:20 Content-Type: multipart/alternative; boundary="=_alternative 0069DEACC2256BD6_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0069DEACC2256BD6_= Content-Type: text/plain; charset="us-ascii" Logout login is far too painful. If negotiations (even vendor specific) have to be possible we need this. As for the lateness and I am sorry I did not see it earlier. However it is not a difficult addition (it has no timing associated) and it meant only as a way to kick-on a negotiation. Julo Santosh Rao Sent by: santoshr@hpcuhe.cup.hp.com 06/12/2002 09:41 PM Please respond to Santosh Rao To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI-Asynch event code Why is this needed ? The target can just send an async event to drop the connection or request a connection logout, and the connection can be re-established allowing for new negotiation. I don't see the point of making this change so late in the game. There exist mechanisms such as target driven connection logout/drop which can be used to achieve the same effect. In any case, what do you do if the initiator does not respond with a text message ? The target would end up dropping the cxn with an async message in this case, causing a re-login and thus, re-negotiation. To summarize, I don't see a need for this change, since there are simpler mechanisms to achieve the same effect. In particular, given that we are so close to the finish line, I suggest that we not make this change, but instead, use the async cxn/ssn logout/drop mechanisms. Rgds, Santosh Julian Satran wrote: > > Dear colleagues, > > I plan to add to the text in 9.9.1 an additional event code as > follows. It is needed for completeness. > > 4 - target requests parameter negotiation on this connection. The > initiator MUST honor this request by issuing a Text Request (that can > be empty) on the same connection as early as possible unless a Text > Request is already pending on the connection or by issuing a Logout > Request. > Julo -- The world is so fast that there are days when the person who says it can't be done is interrupted by the person who is doing it. ~ Anon --=_alternative 0069DEACC2256BD6_= Content-Type: text/html; charset="us-ascii"
Logout login is far too painful. If negotiations (even vendor specific) have to be possible we need this.
As for the lateness and I am sorry I did not see it earlier. However it is not  a difficult addition (it has no timing associated) and it meant only as a way to kick-on a negotiation.

Julo


Santosh Rao <santoshr@cup.hp.com>
Sent by: santoshr@hpcuhe.cup.hp.com

06/12/2002 09:41 PM
Please respond to Santosh Rao

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        Re: iSCSI-Asynch event code

       



Why is this needed ? The target can just send an async event to drop the
connection or request a connection logout, and the connection can be
re-established allowing for new negotiation.

I don't see the point of making this change so late in the game. There
exist mechanisms such as target driven connection logout/drop which can
be used to achieve the same effect.

In any case, what do you do if the initiator does not respond with a
text message ? The target would end up dropping the cxn with an async
message in this case, causing a re-login and thus, re-negotiation.

To summarize, I don't see a need for this change, since there are
simpler mechanisms to achieve the same effect. In particular, given that
we are so close to the finish line, I suggest that we not make this
change, but instead, use the async cxn/ssn logout/drop mechanisms.

Rgds,
Santosh


Julian Satran wrote:
>
> Dear colleagues,
>
> I plan to add to the text in 9.9.1 an additional event code as
> follows. It is needed for completeness.
>
> 4 - target requests parameter negotiation on this connection. The
> initiator MUST honor this request by issuing a Text Request (that can
> be empty) on the same connection as early as possible unless a Text
> Request is already pending on the connection or by issuing a Logout
> Request.
> Julo

--
The world is so fast that there are days when the person who says
it can't be done is interrupted by the person who is doing it.
                ~ Anon

--=_alternative 0069DEACC2256BD6_=-- From owner-ips@ece.cmu.edu Wed Jun 12 15:59:14 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11237 for ; Wed, 12 Jun 2002 15:59:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CJjb222643 for ips-outgoing; Wed, 12 Jun 2002 15:45:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CJjYw22631 for ; Wed, 12 Jun 2002 15:45:34 -0400 (EDT) Received: from london ([192.168.1.81]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id MAA20172; Wed, 12 Jun 2002 12:43:37 -0700 (PDT) From: "Rod Harrison" To: "Santosh Rao" , "Julian Satran" Cc: Subject: RE: iSCSI-Asynch event code Date: Wed, 12 Jun 2002 14:45:57 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3D0795D3.92AA67CC@cup.hp.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Santosh, There is a slight difference where the new event gives us more than we have. If a target requests a logout there is no guarantee the initiator will ever log that connection back in again. The reason I suggested we allow the initiator to bypass the login timeouts if it logged out as a result of the new event was because the target isn't asking for a logout to reduce resource commitments, so there seems to be no need to wait for what may be a long time to re-login. I think that would still be a worthy addition, perhaps with a parameter in the negotiation request that allows an immediate login if the logout option is taken. The target would never have to drop the connection because the initiator MUST either negotiate or logout. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Santosh Rao Sent: Wednesday, June 12, 2002 1:41 PM To: Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iSCSI-Asynch event code Why is this needed ? The target can just send an async event to drop the connection or request a connection logout, and the connection can be re-established allowing for new negotiation. I don't see the point of making this change so late in the game. There exist mechanisms such as target driven connection logout/drop which can be used to achieve the same effect. In any case, what do you do if the initiator does not respond with a text message ? The target would end up dropping the cxn with an async message in this case, causing a re-login and thus, re-negotiation. To summarize, I don't see a need for this change, since there are simpler mechanisms to achieve the same effect. In particular, given that we are so close to the finish line, I suggest that we not make this change, but instead, use the async cxn/ssn logout/drop mechanisms. Rgds, Santosh Julian Satran wrote: > > Dear colleagues, > > I plan to add to the text in 9.9.1 an additional event code as > follows. It is needed for completeness. > > 4 - target requests parameter negotiation on this connection. The > initiator MUST honor this request by issuing a Text Request (that can > be empty) on the same connection as early as possible unless a Text > Request is already pending on the connection or by issuing a Logout > Request. > Julo -- The world is so fast that there are days when the person who says it can't be done is interrupted by the person who is doing it. ~ Anon From owner-ips@ece.cmu.edu Wed Jun 12 16:00:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11269 for ; Wed, 12 Jun 2002 16:00:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CJCNM20461 for ips-outgoing; Wed, 12 Jun 2002 15:12:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CJCLw20454; Wed, 12 Jun 2002 15:12:21 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5CJC7Ui089892; Wed, 12 Jun 2002 21:12:07 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5CJC6r80650; Wed, 12 Jun 2002 21:12:06 +0200 To: Steve Senum Cc: ietf-ips , owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: 7.2.1 CHAP Considerations (12-98) X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 12 Jun 2002 22:12:06 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 12/06/2002 22:12:06, Serialize complete at 12/06/2002 22:12:06 Content-Type: multipart/alternative; boundary="=_alternative 00695B66C2256BD6_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00695B66C2256BD6_= Content-Type: text/plain; charset="us-ascii" can you elaborate? Julo Steve Senum Sent by: owner-ips@ece.cmu.edu 06/12/2002 09:32 PM Please respond to Steve Senum To: ietf-ips cc: Subject: iSCSI: 7.2.1 CHAP Considerations (12-98) I have a concern over the wording of the following text from section 7.2.1 (12-98 version): When CHAP is used with secret shorter than 96 bits, a compliant implementation MUST NOT continue with the login unless it can verify that IPsec encryption is being used to protect the connection. I know the above is attempt to "put some teeth" into the requirements to make the use of CHAP secure, but I believe there are common cases where the length of the CHAP secret cannot be verified, such as when a RADIUS server is being used. Regards, Steve Senum --=_alternative 00695B66C2256BD6_= Content-Type: text/html; charset="us-ascii"
can you elaborate? Julo


Steve Senum <ssenum@cisco.com>
Sent by: owner-ips@ece.cmu.edu

06/12/2002 09:32 PM
Please respond to Steve Senum

       
        To:        ietf-ips <ips@ece.cmu.edu>
        cc:        
        Subject:        iSCSI: 7.2.1 CHAP Considerations (12-98)

       


I have a concern over the wording of the
following text from section 7.2.1 (12-98 version):

   When CHAP is used with secret shorter than 96 bits,
   a compliant implementation MUST NOT continue with
   the login unless it can verify that IPsec encryption
   is being used to protect the connection.

I know the above is attempt to "put some teeth" into
the requirements to make the use of CHAP secure,
but I believe there are common cases where the
length of the CHAP secret cannot be verified, such
as when a RADIUS server is being used.

Regards,
Steve Senum

--=_alternative 00695B66C2256BD6_=-- From owner-ips@ece.cmu.edu Wed Jun 12 16:04:17 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11350 for ; Wed, 12 Jun 2002 16:04:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CJYeC21874 for ips-outgoing; Wed, 12 Jun 2002 15:34:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CJYbw21869; Wed, 12 Jun 2002 15:34:37 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id E9CD49FDE; Wed, 12 Jun 2002 13:34:36 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 8F00B347; Wed, 12 Jun 2002 13:34:36 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 12 Jun 2002 13:34:36 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 13:34:35 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E43BE@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: dyoung@rhapsodynetworks.com, Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Date: Wed, 12 Jun 2002 13:34:34 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-ff9413fc-ac8f-4d85-aff2-e2ba899ad1c7" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-ff9413fc-ac8f-4d85-aff2-e2ba899ad1c7 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21248.2E218850" ------_=_NextPart_001_01C21248.2E218850 Content-Type: text/plain; charset="iso-8859-1" Dennis, The target can tell from the command whether there will be unsolicited data or not. bit 0 of the Flags and Task Attributes field ( the F bit) in the SCSI Command PDU is 1 if there are no unsolicited Data-Out PDUs. Also, if there is unsolicited data, the amount of unsolicited data sent is the lesser of the data transfer length or FirstBurstSize so if bit 0 indicates unsolicited data will be sent, the target knows where its first R2T will start. Pat -----Original Message----- From: Dennis Young [mailto:dyoung@rhapsodynetworks.com] Sent: Wednesday, June 12, 2002 10:05 AM To: 'Julian Satran' Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Julian, This leads me to a more interesting question. A session with InitialR2T=No in effect, i.e. unsolicited Data-out allowed, could cause unintended waste of bandwidth, depending on how fast the target sends our R2T in response to the SCSI Write. If the target sees the unsolicited Data-out PDU before building the R2T, then everything is fine. If the target doesn't see the unsolicited Data-out PDU before building the R2T, the R2T would request the same portion of data in the unsolicited Data-out, thus bandwidth is wasted. The question is, how can a target be smart about this? Should the target wait a moment for the possible unsolicited Data-out after receiving each SCSI Write, this sounds kludgy. Also, why do we need the unsolicited Data-out PDU feature when there is ImmediateData? Regards, Dennis -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 6:05 AM To: Dennis Young Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iscsi: unsolicited data question yes - julo Dennis Young Sent by: owner-ips@ece.cmu.edu 06/12/2002 06:20 AM Please respond to Dennis Young To: ips@ece.cmu.edu cc: Subject: iscsi: unsolicited data question I have a question which has been asked before, but I couldn't find a direct answer in the archive. The table on page 200 of draft 12 doesn't directly answer this question either. The first paragraph on page 36 of draft 12 says "Targets operate in either solicitied (R2T) data mode or unsolicited (non R2T) data mode." tells me that a target, at all times during a data sequence transfer, can be one or the other, but not both (non R2T for the initial data out, R2T for the remaining data). Is this correct? Thanks, Dennis ---snip from an old email dated 3/30/2001--- " Hi Julian Sorry if I'm covering old ground... Is it possible to use unsolicited data for the first burst and then request any remaining data using R2T? For example, if the target has a previously allocated buffer available (length defined by FirstBurstSize) for unsolicited data, then once the initiator has sent unsolicited data up to and including this amount then the remaining data (if any) can be requested using R2T once the target has the buffer space available. ...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail: matthewb@bri.hp.com " ------_=_NextPart_001_01C21248.2E218850 Content-Type: text/html; charset="iso-8859-1"

Dennis,
 
The target can tell from the command whether there will be unsolicited data or not. bit 0 of the Flags and Task Attributes field ( the F bit) in the SCSI Command PDU is 1 if there are no unsolicited Data-Out PDUs. Also, if there is unsolicited data, the amount of unsolicited data sent is the lesser of the data transfer length or FirstBurstSize so if bit 0 indicates unsolicited data will be sent, the target knows where its first R2T will start.
 
Pat
 
 
-----Original Message-----
From: Dennis Young [mailto:dyoung@rhapsodynetworks.com]
Sent: Wednesday, June 12, 2002 10:05 AM
To: 'Julian Satran'
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iscsi: unsolicited data question

Julian,
 
This leads me to a more interesting question.
A session with InitialR2T=No in effect, i.e. unsolicited Data-out
allowed, could cause unintended waste of bandwidth, depending on
how fast the target sends our R2T in response to the SCSI Write.
 
If the target sees the unsolicited Data-out PDU before building the
R2T, then everything is fine. 
If the target doesn't see the unsolicited Data-out PDU before building
the R2T, the R2T would request the same portion of data in the
unsolicited Data-out, thus bandwidth is wasted.
 
The question is, how can a target be smart about this?
Should the target wait a moment for the possible unsolicited Data-out
after receiving each SCSI Write, this sounds kludgy.
 
Also, why do we need the unsolicited Data-out PDU feature when
there is ImmediateData?
 
Regards,
Dennis
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 12, 2002 6:05 AM
To: Dennis Young
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iscsi: unsolicited data question


yes - julo


Dennis Young <dyoung@rhapsodynetworks.com>
Sent by: owner-ips@ece.cmu.edu

06/12/2002 06:20 AM
Please respond to Dennis Young

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iscsi: unsolicited data question

       


I have a question which has been asked before, but I couldn't find a direct
answer in the archive.  The table on page 200 of draft 12 doesn't directly
answer this question either.

The first paragraph on page 36 of draft 12 says "Targets operate in either
solicitied (R2T) data mode or unsolicited (non R2T) data mode."
tells me that a target, at all times during a data sequence transfer, can be

one or the other, but not both (non R2T for the initial data out, R2T for
the
remaining data).  Is this correct?

Thanks,
Dennis

---snip from an old email dated 3/30/2001---

" Hi Julian
Sorry if I'm covering old ground... Is it possible to use unsolicited data
for the first burst and then request any remaining data using R2T? For
example, if the target has a previously allocated buffer available (length
defined by FirstBurstSize) for unsolicited data, then once the initiator has
sent unsolicited data up to and including this amount then the remaining
data (if any) can be requested using R2T once the target has the buffer
space available.
...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail:
matthewb@bri.hp.com "




------_=_NextPart_001_01C21248.2E218850-- ------=_NextPartTM-000-ff9413fc-ac8f-4d85-aff2-e2ba899ad1c7-- From owner-ips@ece.cmu.edu Wed Jun 12 16:05:55 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11475 for ; Wed, 12 Jun 2002 16:05:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CJvo723451 for ips-outgoing; Wed, 12 Jun 2002 15:57:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CJvlw23441 for ; Wed, 12 Jun 2002 15:57:47 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id ABCFC30706; Wed, 12 Jun 2002 15:57:46 -0400 (EDT) Date: Wed, 12 Jun 2002 12:55:37 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Santosh Rao Cc: Julian Satran , Subject: Re: iSCSI-Asynch event code In-Reply-To: <3D0795D3.92AA67CC@cup.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Wed, 12 Jun 2002, Santosh Rao wrote: > Why is this needed ? The target can just send an async event to drop the > connection or request a connection logout, and the connection can be > re-established allowing for new negotiation. Isn't that a bit severe? That strikes me as kinda like saying you don't need an off switch on your car radio because you can just go out and unplug the car battery. > I don't see the point of making this change so late in the game. There > exist mechanisms such as target driven connection logout/drop which can > be used to achieve the same effect. Then why do we permit any parameter renegotiation at all? Why not just always require connection logout/drop to renegotiate? > In any case, what do you do if the initiator does not respond with a > text message ? The target would end up dropping the cxn with an async > message in this case, causing a re-login and thus, re-negotiation. > > To summarize, I don't see a need for this change, since there are > simpler mechanisms to achieve the same effect. In particular, given that > we are so close to the finish line, I suggest that we not make this > change, but instead, use the async cxn/ssn logout/drop mechanisms. I think the point is that if we don't do this, then all the effort put into being able to renegotiate parameters (MaxRecvPDUDataSize in particular) only works half way - how can the target initiate such a negotiation? If we do as you suggest (which we certainly can choose to do), then why support any FFP renegotiations? Take care, Bill From owner-ips@ece.cmu.edu Wed Jun 12 16:06:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11492 for ; Wed, 12 Jun 2002 16:06:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CJZNm21921 for ips-outgoing; Wed, 12 Jun 2002 15:35:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CJZLw21915 for ; Wed, 12 Jun 2002 15:35:21 -0400 (EDT) Received: from london ([192.168.1.81]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id MAA14101; Wed, 12 Jun 2002 12:33:39 -0700 (PDT) From: "Rod Harrison" To: "Mallikarjun C." Cc: Subject: RE: iSCSI: changing MaxPDUDataLength Date: Wed, 12 Jun 2002 14:35:58 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <004701c2123a$a1f64670$edd52b0f@rose.hp.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mallikarjun, I had tracked your earlier comments, I was just responding to Eddy's concern that there is a need for a "good time" from the target's perspective and saying I don't believe quiescing the connection would be an issue from an initiator's perspective. I still don't, I think the imitator has enough tools to avoid quiescing a connection if it believes that to be a bad thing. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Mallikarjun C. Sent: Wednesday, June 12, 2002 12:58 PM To: Rod Harrison Cc: ips@ece.cmu.edu Subject: Re: iSCSI: changing MaxPDUDataLength Rod, If you had tracked my earlier comments, you'd notice that I'm arguing that there's no specific reason for a "good time". Certain hardware implementations may choose to effect the change only on Data-In sequence boundaries, but the basic nature of text negotiation allows for that flexibility. Yes, as you suggest, we have a variety of other options including dropping the I/Os, or the connection etc. But the point in allowing dynamic redeclaration of this key is to make iSCSI adapt to but not be impacted by, lower-level dynamics - similar to TCP. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Rod Harrison" To: "Mallikarjun C." ; "Eddy Quicksall" ; "Julian Satran" Cc: Sent: Tuesday, June 11, 2002 4:15 PM Subject: RE: iSCSI: changing MaxPDUDataLength > Mallikarjun , > > The current wording doesn't appear to prevent the initiator from > staging new commands whilst the negotiation is in process and > therefore the target may never find a "good time" to end the > negotiation sequence. > > I don't think idling the connection would be a big issue in the event > of PMTU change since the worst case is that existing commands have to > run to completion using the inefficient PMTU. The initiator also has > the options of aborting and restarting the commands if they can't > complete with the old PMTU, or better, open another connection with > the appropriate MaxPDUDataLength and change the command allegiance. > > - Rod > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Mallikarjun C. > Sent: Tuesday, June 11, 2002 2:35 PM > To: Eddy Quicksall; Julian Satran > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: changing MaxPDUDataLength > > > Eddy, > > I am not clear on why you think the target code becomes messy on > a PDU size change. The last para in section 4.4 states the > following - > > "Parameters negotiated by a text exchange negotiation sequence become > effective only after the negotiation sequence is completed." > > Since the target gets to complete a text negotiation with a Text > Response > PDU, it can time the applicability of a changed > MaxRecvDataSegmentLength. > > Requiring that an initiator must idle the connection before changing > this > parameter, IMHO, is counter-productive when there's a dynamic PMTU > degradation in the presence of long-running commands (writes in > particular). > Once the initiator starts the renegotiation, target would ideally want > to quickly > renegotiate its receive size as well to receive ULPDU-contained > segments. > > In short, seems to me that the draft is saying what you would like. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > > ----- Original Message ----- > From: "Eddy Quicksall" > To: "Julian Satran" > Cc: > Sent: Tuesday, June 11, 2002 7:56 AM > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > I think it should be a requirement because if it is not, all target > code > > will have to have the messy code. Or, we could say that if it is not > idle > > commands, then the target may reject it. > > > > Eddy > > > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Tuesday, June 11, 2002 9:11 AM > > To: Eddy Quicksall > > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > That is a fair request - we may slip in a recommendation to that > effect (in > > chapter 11?) > > > > Julo > > > > > > > > Eddy Quicksall > > > > > > 06/11/2002 04:28 AM > > Please respond to Eddy Quicksall > > > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > How about if we say that an initiator must not change the > MaxPDUDataSize > > unless it first idles the commands (at least the ones with the R > bit) or if > > ErrorRecoveryLevel==0? > > > > That would simplify target code greatly and would meet the design > goals; and > > since it should be rare to change it, it would be of little impact > to idle > > the commands for a split second. > > > > > > Eddy > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Monday, June 10, 2002 8:06 PM > > To: Eddy Quicksall > > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > I said only that when you change length you can ask for all PDUs > after the > > ack! (no need to keep a tall - the old offsets are good up to the > hole). > > > > Julo > > > > > > Eddy Quicksall > > > > > > 06/11/2002 12:32 AM > > Please respond to Eddy Quicksall > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > Julian, > > > > Another problem here is that the target has to calculate the offset > from the > > DataSN #. And as BegRun can be any value. E.g., BegRun=4 and > RunLngth=0 > > means starting DataSN=4, send all the data for that sequence. > > > > I think it would be a performance hit and waist of memory to keep a > tally of > > all PDU sizes just for an occasional SNACK. > > > > It's not that it can't be done ... it is more that it is messy and I > think > > there is a solution that will satisfy the design requirements but > keep the > > software simpler. > > > > Eddy > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Saturday, June 08, 2002 10:16 PM > > To: Eddy Quicksall > > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > That is not completely accurate. > > The only problem is when PDU size decreases and then SNACK must be > for all > > data. > > Target can also keep a mapping of numbers/to offsets (the list > should be > > small and if it gets long ask for ack (A-bit). > > > > Julo > > > > Eddy Quicksall > > Sent by: owner-ips@ece.cmu.edu > > > > > > 06/08/2002 10:54 PM > > Please respond to Eddy Quicksall > > > > > > To: pat_thaler@agilent.com > > cc: ips@ece.cmu.edu > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > > > Thanks, > > > > As a target, I won't be able to let it change until all of the > outstanding > > commands are finished (running with ErrorRecoveryLevel>=1). This is > because > > I must use the PDU size to compute the offset from a SNACK's > > BegRun/RunLength. > > > > So, I plan to not give the text response for a MaxPDURecvDataLength > in FFP > > until I get back an ExpStatSN == next StatSN. > > > > This will cause a delay of unknown time before the PDU size can > actually > > change ... do you see any problem with this? > > > > Eddy > > > > -----Original Message----- > > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > > Sent: Friday, June 07, 2002 1:13 PM > > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > Eddy, > > > > If one uses a message sync and steering that relys on the transport > segments > > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if > the path > > MTU changes one would want to change the PDU data length to fit the > new path > > MTU. > > > > Pat > > > > -----Original Message----- > > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > > Sent: Wednesday, June 05, 2002 12:24 PM > > To: ips@ece.cmu.edu > > Subject: iSCSI: changing MaxPDUDataLength > > > > > > Does anybody know a case where it is necessary to support a new PDU > data > > length during full feature phase? > > > > Eddy > > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Wed Jun 12 16:10:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11576 for ; Wed, 12 Jun 2002 16:10:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CJwDV23482 for ips-outgoing; Wed, 12 Jun 2002 15:58:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CJwBw23477 for ; Wed, 12 Jun 2002 15:58:12 -0400 (EDT) Received: from cisco.com (dhcp-161-44-68-217.cisco.com [161.44.68.217]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA24538; Wed, 12 Jun 2002 15:58:04 -0400 (EDT) Message-ID: <3D07A7CB.7791E3AB@cisco.com> Date: Wed, 12 Jun 2002 14:58:03 -0500 From: Steve Senum X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Satran CC: ietf-ips Subject: Re: iSCSI: 7.2.1 CHAP Considerations (12-98) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, In the case where an iSCSI Target is authenticating an iSCSI Initiator, the Target sends a CHAP challenge and identifier, and the Initiator sends back a CHAP response and username. In the case were the Target is using the RADIUS protocol, these four pieces of information are sent by the Target to a RADIUS server, which simply gives an accept or reject reply. The target never has access to the CHAP secret (which is good), hence no check can be made on its length. Regards, Steve Senum Julian Satran wrote: > > can you elaborate? Julo > > Steve Senum > Sent by: owner-ips@ece.cmu.edu To: ietf-ips > > 06/12/2002 09:32 PM cc: > Please respond to Steve Senum Subject: iSCSI: 7.2.1 CHAP > Considerations (12-98) > > > > I have a concern over the wording of the > following text from section 7.2.1 (12-98 version): > > When CHAP is used with secret shorter than 96 bits, > a compliant implementation MUST NOT continue with > the login unless it can verify that IPsec encryption > is being used to protect the connection. > > I know the above is attempt to "put some teeth" into > the requirements to make the use of CHAP secure, > but I believe there are common cases where the > length of the CHAP secret cannot be verified, such > as when a RADIUS server is being used. > > Regards, > Steve Senum From owner-ips@ece.cmu.edu Wed Jun 12 16:31:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12175 for ; Wed, 12 Jun 2002 16:31:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CJjM122601 for ips-outgoing; Wed, 12 Jun 2002 15:45:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CJjKw22593; Wed, 12 Jun 2002 15:45:20 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 4982512C4; Wed, 12 Jun 2002 13:45:19 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 134AE63C; Wed, 12 Jun 2002 13:45:19 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 12 Jun 2002 13:45:19 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 13:45:19 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E43C2@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: dyoung@rhapsodynetworks.com, Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Date: Wed, 12 Jun 2002 13:45:17 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-e3a8e1eb-3750-4446-bafe-f1cb9e535a5d" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-e3a8e1eb-3750-4446-bafe-f1cb9e535a5d Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21249.ADA3F030" ------_=_NextPart_001_01C21249.ADA3F030 Content-Type: text/plain; charset="iso-8859-1" Dennis, FirstBurstSize may be larger than MaxRecvPDUDataSize so InitialR2T=No can allow one to send more unsolicited data than immediate data alone. Also, an implementation may set ImmediateData=No because it prefers to handle command and data in separate PDUs but still accept unsolicited data by setting InitialR2T=No. Pat -----Original Message----- From: Dennis Young [mailto:dyoung@rhapsodynetworks.com] Sent: Wednesday, June 12, 2002 10:50 AM To: 'Julian Satran' Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Are you saying that, for a session that has InitialR2T=No in effect, the initiator must send all its data as unsolicited first, up to the amount negotiated in FirstBurstSize, before it waits for a R2T from the target? Can you shed some light on why we need unsolicited Data-out PDU when there is ImmediateData, seems like they both serve the same purpose, having both of them only make the spec more complex. Thanks, -Dennis -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 10:19 AM To: Dennis Young Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question This is the reason why the initiator is required to send ALL unsolicited data (target can count on it and start sending R2Ts as soon as it sees the first header> Neither bandwidth nor latency are wasted. Julo Dennis Young 06/12/2002 08:05 PM Please respond to Dennis Young To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Julian, This leads me to a more interesting question. A session with InitialR2T=No in effect, i.e. unsolicited Data-out allowed, could cause unintended waste of bandwidth, depending on how fast the target sends our R2T in response to the SCSI Write. If the target sees the unsolicited Data-out PDU before building the R2T, then everything is fine. If the target doesn't see the unsolicited Data-out PDU before building the R2T, the R2T would request the same portion of data in the unsolicited Data-out, thus bandwidth is wasted. The question is, how can a target be smart about this? Should the target wait a moment for the possible unsolicited Data-out after receiving each SCSI Write, this sounds kludgy. Also, why do we need the unsolicited Data-out PDU feature when there is ImmediateData? Regards, Dennis -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 6:05 AM To: Dennis Young Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iscsi: unsolicited data question yes - julo Dennis Young Sent by: owner-ips@ece.cmu.edu 06/12/2002 06:20 AM Please respond to Dennis Young To: ips@ece.cmu.edu cc: Subject: iscsi: unsolicited data question I have a question which has been asked before, but I couldn't find a direct answer in the archive. The table on page 200 of draft 12 doesn't directly answer this question either. The first paragraph on page 36 of draft 12 says "Targets operate in either solicitied (R2T) data mode or unsolicited (non R2T) data mode." tells me that a target, at all times during a data sequence transfer, can be one or the other, but not both (non R2T for the initial data out, R2T for the remaining data). Is this correct? Thanks, Dennis ---snip from an old email dated 3/30/2001--- " Hi Julian Sorry if I'm covering old ground... Is it possible to use unsolicited data for the first burst and then request any remaining data using R2T? For example, if the target has a previously allocated buffer available (length defined by FirstBurstSize) for unsolicited data, then once the initiator has sent unsolicited data up to and including this amount then the remaining data (if any) can be requested using R2T once the target has the buffer space available. ...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail: matthewb@bri.hp.com " ------_=_NextPart_001_01C21249.ADA3F030 Content-Type: text/html; charset="iso-8859-1"
Dennis,
 
FirstBurstSize may be larger than MaxRecvPDUDataSize so InitialR2T=No can allow one to send more unsolicited data than immediate data alone. Also, an implementation may set ImmediateData=No because it prefers to handle command and data in separate PDUs but still accept unsolicited data by setting InitialR2T=No.
 
Pat
 
 
-----Original Message-----
From: Dennis Young [mailto:dyoung@rhapsodynetworks.com]
Sent: Wednesday, June 12, 2002 10:50 AM
To: 'Julian Satran'
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iscsi: unsolicited data question

Are you saying that, for a session that has InitialR2T=No in effect, the initiator
must send all its data as unsolicited first, up to the amount negotiated in
FirstBurstSize, before it waits for a R2T from the target? 
 
Can you shed some light on why we need unsolicited Data-out PDU when there 
is ImmediateData, seems like they both serve the same purpose, having both of
them only make the spec more complex.
 
Thanks,
-Dennis
 
 -----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 12, 2002 10:19 AM
To: Dennis Young
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iscsi: unsolicited data question


This is the reason why the initiator is required to send ALL unsolicited data (target can count on it and start sending R2Ts as soon as it sees the first header>
Neither bandwidth nor latency are wasted.

Julo


Dennis Young <dyoung@rhapsodynetworks.com>

06/12/2002 08:05 PM
Please respond to Dennis Young

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
        Subject:        RE: iscsi: unsolicited data question

       


Julian,
 
This leads me to a more interesting question.
A session with InitialR2T=No in effect, i.e. unsolicited Data-out
allowed, could cause unintended waste of bandwidth, depending on
how fast the target sends our R2T in response to the SCSI Write.
 
If the target sees the unsolicited Data-out PDU before building the
R2T, then everything is fine.
If the target doesn't see the unsolicited Data-out PDU before building
the R2T, the R2T would request the same portion of data in the
unsolicited Data-out, thus bandwidth is wasted.
 
The question is, how can a target be smart about this?
Should the target wait a moment for the possible unsolicited Data-out
after receiving each SCSI Write, this sounds kludgy.
 
Also, why do we need the unsolicited Data-out PDU feature when
there is ImmediateData?
 
Regards,
Dennis
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 12, 2002 6:05 AM
To: Dennis Young
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iscsi: unsolicited data question


yes - julo

Dennis Young <dyoung@rhapsodynetworks.com>
Sent by: owner-ips@ece.cmu.edu

06/12/2002 06:20 AM
Please respond to Dennis Young

       
       To:        ips@ece.cmu.edu
       cc:        
       Subject:        iscsi: unsolicited data question

     



I have a question which has been asked before, but I couldn't find a direct
answer in the archive.  The table on page 200 of draft 12 doesn't directly
answer this question either.

The first paragraph on page 36 of draft 12 says "Targets operate in either
solicitied (R2T) data mode or unsolicited (non R2T) data mode."
tells me that a target, at all times during a data sequence transfer, can be

one or the other, but not both (non R2T for the initial data out, R2T for
the
remaining data).  Is this correct?

Thanks,
Dennis

---snip from an old email dated 3/30/2001---

" Hi Julian
Sorry if I'm covering old ground... Is it possible to use unsolicited data
for the first burst and then request any remaining data using R2T? For
example, if the target has a previously allocated buffer available (length
defined by FirstBurstSize) for unsolicited data, then once the initiator has
sent unsolicited data up to and including this amount then the remaining
data (if any) can be requested using R2T once the target has the buffer
space available.
...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail:
matthewb@bri.hp.com "





------_=_NextPart_001_01C21249.ADA3F030-- ------=_NextPartTM-000-e3a8e1eb-3750-4446-bafe-f1cb9e535a5d-- From owner-ips@ece.cmu.edu Wed Jun 12 16:47:29 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12469 for ; Wed, 12 Jun 2002 16:47:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CJxIr23559 for ips-outgoing; Wed, 12 Jun 2002 15:59:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CJxHw23555 for ; Wed, 12 Jun 2002 15:59:17 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 95A3FA8B6; Wed, 12 Jun 2002 13:59:16 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 76D3F2C6; Wed, 12 Jun 2002 13:59:16 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 12 Jun 2002 13:59:16 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 13:59:16 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E43D4@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI: CRC description Date: Wed, 12 Jun 2002 13:59:15 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-1bc0f9d3-cd00-4b0c-b40e-f356583a85ae" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-1bc0f9d3-cd00-4b0c-b40e-f356583a85ae Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2124B.A1196B40" ------_=_NextPart_001_01C2124B.A1196B40 Content-Type: text/plain; charset="iso-8859-1" Julian, I agree it is frustrating but I suggested text that would have been clear. This doesn't have to go on and on but the text has to be clear. The recent changes split the information on how to use the CRC between a paragraph near the front (which only applies to the CRC calculation) and 11.1 on page 209. Vince's comment on emphasis was about the magic number order and I don't have any problem with that text. I am just asking you to use similar text in describing how the CRC is appended as that you already use to describe the formation of the polynomial M(x): "- The n bits of the bit-stream are considered coefficients of a polynomial M(x) of order n-1, with bit 7 of byte 0 being x^(n-1)." The text that is confusing says that the CRC is appended with x^31 term followed by x^30 term isn't useful as the bits only are that way in some hypothetical data stream and are in the packet in the opposite order (within each byte). As I pointed out in a separate message, the text that was added on bit order is inaccurate because it only applies to CRC and does not apply to the other cases where bits have positional significance (e.g. numbers, polynomial significance for authentication and encryption). Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 11:41 AM To: ips@ece.cmu.edu Subject: RE: iSCSI: CRC description Importance: High The thing about this text that is going on and on is very frustrating. First Vince insisted on emphasis. Now you find it confusing. I gave it as a quiz to a undergraduate class and no one made a mistake. How much effort do you think I will spend on it? And who are the people that are confused? Julo pat_thaler@agilent.com 06/12/2002 09:24 PM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI: CRC description Julian, The changes to the text on CRC are a step down rather than up in clarity. In particular: " - In the bit stream mentioned above the CRC bits are appended to the message bits with x^31 first followed by x^30 etc. In the examples provided in Appendix B.4 - CRC Examples, the value is outlined as a word sent or received and therefore the CRC bits are mapped into the CRC word according to Section 1.3.4 Bit Rule - i.e., the x^31 coefficient in bit 7 of the first byte of the digest continuing to through the byte the x^24 coefficient in bit 0 of the first ! byte, continuing with the x^23 coefficient in bit 7 of second byte through x^0 in bit 7 of the last byte. This statement will be very confusing to readers. The there is no abstract bit stream in which the CRC bits follow each other. Trying to specify the CRC with respect a bit stream will just lead to confusion. The old text with the changes I had suggested would provide more clarity. Also, there is no MUST on the CRC computation method. Using a compatible computation method is necessary to produce interoperability so there should be a MUST. I suggest the following which should allow for compatible variations in implementation: Replace, "The CRC should be calculated as follows:" with "The CRC MUST be calculated using a method that produces the same result as the following process:" Regards, Pat ------_=_NextPart_001_01C2124B.A1196B40 Content-Type: text/html; charset="iso-8859-1"
Julian,
 
I agree it is frustrating but I suggested text that would have been clear. This doesn't have to go on and on but the text has to be clear. The recent changes split the information on how to use the CRC between a paragraph near the front (which only applies to the CRC calculation) and 11.1 on page 209.
 
Vince's comment on emphasis was about the magic number order and I don't have any problem with that text.
 
I am just asking you to use similar text in describing how the CRC is appended as that you already use to describe the formation of the polynomial M(x): "- The n bits of the bit-stream are considered coefficients of a polynomial M(x) of order n-1, with bit 7 of byte 0 being x^(n-1)." The text that is confusing says that the CRC is appended with x^31 term followed by x^30 term isn't useful as the bits only are that way in some hypothetical data stream and are in the packet in the opposite order (within each byte).
 
As I pointed out in a separate message, the text that was added on bit order is inaccurate because it only applies to CRC and does not apply to the other cases where bits have positional significance (e.g. numbers, polynomial significance for authentication and encryption).
 
Pat
 
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 12, 2002 11:41 AM
To: ips@ece.cmu.edu
Subject: RE: iSCSI: CRC description
Importance: High


The thing about this text that is going on and on is very frustrating.
First Vince insisted on emphasis.
Now you find it confusing.

I gave it as a quiz to a undergraduate class and no one made a mistake.

How much effort do you think I will spend on it? And who are the people that are confused?

Julo


pat_thaler@agilent.com

06/12/2002 09:24 PM
Please respond to pat_thaler

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
        Subject:        RE: iSCSI: CRC description

       


Julian,
 
The changes to the text on CRC are a step down rather than up in clarity.
 
In particular:

 " - In the bit stream mentioned above the CRC bits are appended   to the message bits with x^31 first followed by x^30 etc. In   the examples provided in Appendix B.4 - CRC Examples, the   value is outlined as a word sent or received and therefore   the CRC bits are mapped into the CRC word according to Section   1.3.4 Bit Rule - i.e., the x^31 coefficient in bit 7 of   the first byte of the digest continuing to through the byte the x^24 coefficient in bit 0 of the first ! byte, continuing with the x^23 coefficient in bit 7 of second byte through x^0 in bit 7 of the last byte.  

This statement will be very confusing to readers. The there is no abstract bit stream in which the CRC bits follow each other. Trying to specify the CRC with respect a bit stream will just lead to confusion. The old text with the changes I had suggested would provide more clarity.

Also, there is no MUST on the CRC computation method. Using a compatible computation method is necessary to produce interoperability so there should be a MUST. I suggest the following  which should allow for compatible variations in implementation:

Replace, "The CRC should be calculated as follows:" with "The CRC MUST be calculated using a method that produces the same result as the following process:"

Regards,
Pat

------_=_NextPart_001_01C2124B.A1196B40-- ------=_NextPartTM-000-1bc0f9d3-cd00-4b0c-b40e-f356583a85ae-- From owner-ips@ece.cmu.edu Wed Jun 12 16:57:17 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12714 for ; Wed, 12 Jun 2002 16:57:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CKPPB25305 for ips-outgoing; Wed, 12 Jun 2002 16:25:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CKPLw25289; Wed, 12 Jun 2002 16:25:21 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 9C73C30706; Wed, 12 Jun 2002 16:25:20 -0400 (EDT) Date: Wed, 12 Jun 2002 13:23:12 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Dennis Young Cc: "'Julian Satran'" , , Subject: RE: iscsi: unsolicited data question In-Reply-To: <45BEF1D68145D51186C100B0D0AABE659E016D@med.corp.rhapsodynetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Wed, 12 Jun 2002, Dennis Young wrote: > Are you saying that, for a session that has InitialR2T=No in effect, the > initiator > must send all its data as unsolicited first, up to the amount negotiated in > FirstBurstSize, before it waits for a R2T from the target? No. See the note I sent which crossed this one in the mail. If the initiator doesn't set the F bit in the command PDU (and InitialR2T=No), then it indicates that it will act as if it has already received an R2T for up to FirstBurstSize worth of the data. However the initiator can CHOOSE to set the F bit, and then it will send no more data until it receives an R2T. > Can you shed some light on why we need unsolicited Data-out PDU when there > is ImmediateData, seems like they both serve the same purpose, having both > of > them only make the spec more complex. How big do you think FirstBurstSize and MaxRecvPDUDataSize will be? The defaults are 64k and 8k respectively. So with InitialR2T=No and default numbers, 8 PDUs worth of data can be sent w/o need for an R2T, whereas with just immediate data, only 1 PDUs worth of data won't need to wait. While I don't have a histogram of typical i/o sizes (and even that would be OS and task-set specific), I expect that a good number will be in the 8k to 64k range. So unsolicited data permit writes of those sizes to not need to wait for the target to send an R2T. Take care, Bill From owner-ips@ece.cmu.edu Wed Jun 12 16:57:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12749 for ; Wed, 12 Jun 2002 16:57:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CKYr925990 for ips-outgoing; Wed, 12 Jun 2002 16:34:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CKYpw25986 for ; Wed, 12 Jun 2002 16:34:51 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5CKYbML018102; Wed, 12 Jun 2002 22:34:37 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5CKYar85664; Wed, 12 Jun 2002 22:34:36 +0200 To: Steve Senum Cc: ietf-ips MIME-Version: 1.0 Subject: Re: iSCSI: 7.2.1 CHAP Considerations (12-98) X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 12 Jun 2002 23:34:36 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 12/06/2002 23:34:36, Serialize complete at 12/06/2002 23:34:36 Content-Type: multipart/alternative; boundary="=_alternative 00709A7BC2256BD6_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00709A7BC2256BD6_= Content-Type: text/plain; charset="us-ascii" Steve, The text is not explicit about how the secret length gets to iSCSI. It can be an administrative interface/action. Julo Steve Senum 06/12/2002 10:58 PM Please respond to Steve Senum To: Julian Satran/Haifa/IBM@IBMIL cc: ietf-ips Subject: Re: iSCSI: 7.2.1 CHAP Considerations (12-98) Julian, In the case where an iSCSI Target is authenticating an iSCSI Initiator, the Target sends a CHAP challenge and identifier, and the Initiator sends back a CHAP response and username. In the case were the Target is using the RADIUS protocol, these four pieces of information are sent by the Target to a RADIUS server, which simply gives an accept or reject reply. The target never has access to the CHAP secret (which is good), hence no check can be made on its length. Regards, Steve Senum Julian Satran wrote: > > can you elaborate? Julo > > Steve Senum > Sent by: owner-ips@ece.cmu.edu To: ietf-ips > > 06/12/2002 09:32 PM cc: > Please respond to Steve Senum Subject: iSCSI: 7.2.1 CHAP > Considerations (12-98) > > > > I have a concern over the wording of the > following text from section 7.2.1 (12-98 version): > > When CHAP is used with secret shorter than 96 bits, > a compliant implementation MUST NOT continue with > the login unless it can verify that IPsec encryption > is being used to protect the connection. > > I know the above is attempt to "put some teeth" into > the requirements to make the use of CHAP secure, > but I believe there are common cases where the > length of the CHAP secret cannot be verified, such > as when a RADIUS server is being used. > > Regards, > Steve Senum --=_alternative 00709A7BC2256BD6_= Content-Type: text/html; charset="us-ascii"
Steve,

The text is not explicit about how the secret length gets to iSCSI.
It can be an administrative interface/action.

Julo


Steve Senum <ssenum@cisco.com>

06/12/2002 10:58 PM
Please respond to Steve Senum

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ietf-ips <ips@ece.cmu.edu>
        Subject:        Re: iSCSI: 7.2.1 CHAP Considerations (12-98)

       


Julian,

In the case where an iSCSI Target is authenticating
an iSCSI Initiator, the Target sends a CHAP
challenge and identifier, and the Initiator sends
back a CHAP response and username.

In the case were the Target is using the RADIUS
protocol, these four pieces of information are
sent by the Target to a RADIUS server, which
simply gives an accept or reject reply.  The target
never has access to the CHAP secret (which is good),
hence no check can be made on its length.

Regards,
Steve Senum

Julian Satran wrote:
>
> can you elaborate? Julo
>
>   Steve Senum <ssenum@cisco.com>
>   Sent by: owner-ips@ece.cmu.edu         To:        ietf-ips
>                                  <ips@ece.cmu.edu>
>   06/12/2002 09:32 PM                    cc:
>   Please respond to Steve Senum          Subject:        iSCSI: 7.2.1 CHAP
>                                  Considerations (12-98)
>
>
>
> I have a concern over the wording of the
> following text from section 7.2.1 (12-98 version):
>
>    When CHAP is used with secret shorter than 96 bits,
>    a compliant implementation MUST NOT continue with
>    the login unless it can verify that IPsec encryption
>    is being used to protect the connection.
>
> I know the above is attempt to "put some teeth" into
> the requirements to make the use of CHAP secure,
> but I believe there are common cases where the
> length of the CHAP secret cannot be verified, such
> as when a RADIUS server is being used.
>
> Regards,
> Steve Senum

--=_alternative 00709A7BC2256BD6_=-- From owner-ips@ece.cmu.edu Wed Jun 12 16:59:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12783 for ; Wed, 12 Jun 2002 16:59:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CKf9B26436 for ips-outgoing; Wed, 12 Jun 2002 16:41:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13705.mail.yahoo.com (web13705.mail.yahoo.com [216.136.175.138]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g5CKf7w26431 for ; Wed, 12 Jun 2002 16:41:07 -0400 (EDT) Message-ID: <20020612204106.13576.qmail@web13705.mail.yahoo.com> Received: from [192.55.52.4] by web13705.mail.yahoo.com via HTTP; Wed, 12 Jun 2002 13:41:06 PDT Date: Wed, 12 Jun 2002 13:41:06 -0700 (PDT) From: Martins Krikis Subject: Re: iSCSI-Asynch event code To: ips@ece.cmu.edu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I don't mind this code being added for completeness sake, nor will I be overly disappointed if it isn't. If it is added, however, perhaps we should go half a step farther and demand that the Text Request coming from the initiator MUST be empty? That way the target is really "in charge" and may _originate_ any key negotiable in FFP. Just my $.02. Comments? Martins Krikis, Intel Corp. Disclaimer: These are my opinions and may not be my employer's. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Wed Jun 12 16:59:40 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12796 for ; Wed, 12 Jun 2002 16:59:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CKoG926953 for ips-outgoing; Wed, 12 Jun 2002 16:50:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CKoFw26946 for ; Wed, 12 Jun 2002 16:50:15 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 3756530706; Wed, 12 Jun 2002 16:50:10 -0400 (EDT) Date: Wed, 12 Jun 2002 13:48:01 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Julian Satran Cc: Subject: RE: iSCSI: CRC description In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Wed, 12 Jun 2002, Julian Satran wrote: > The thing about this text that is going on and on is very frustrating. > First Vince insisted on emphasis. > Now you find it confusing. > > I gave it as a quiz to a undergraduate class and no one made a mistake. > > How much effort do you think I will spend on it? And who are the people > that are confused? I'm not sure how much effort you need to spend on this. I'll admit I was one of the people confused, but that was more about CRC methods and the bit reflection we have happening than anything else. The only thing I might suggest would be to include parameters appropriate for one of the CRC libraries. For instance including settings for Ross Williams's CRC discussion could be quite useful, and remove much ambiguity. If there still is confusion and size becomes a concern, perhaps we should generate an ID covering the CRC process. Something like draft-ietf-tsvwg-sctpcsum-07.txt but for iSCSI. > pat_thaler@agilent.com > 06/12/2002 09:24 PM > Please respond to pat_thaler > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu > Subject: RE: iSCSI: CRC description > > > > Julian, > > The changes to the text on CRC are a step down rather than up in clarity. > > In particular: > " - In the bit stream mentioned above the CRC bits are appended to the message bits with x^31 first followed by x^30 etc. In the examples provided in Appendix B.4 - CRC Examples, the value is outlined as a word sent or received and therefore the CRC bits are mapped into the CRC word according to Section 1.3.4 Bit Rule - i.e., the x^31 coefficient in bit 7 of the first byte of the digest continuing to through the byte the x^24 > coefficient in bit 0 of the first byte, continuing with the x^23 > coefficient in bit 7 of second byte through x^0 in bit 7 of the last byte. Shouldn't that be "x^0 in bit 0 of the last byte"? > Replace, "The CRC should be calculated as follows:" with "The CRC MUST be > calculated using a method that produces the same result as the following > process:" > Regards, > Pat Take care, Bill From owner-ips@ece.cmu.edu Wed Jun 12 16:59:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12813 for ; Wed, 12 Jun 2002 16:59:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CKmqr26876 for ips-outgoing; Wed, 12 Jun 2002 16:48:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CKmpw26872 for ; Wed, 12 Jun 2002 16:48:51 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 16:48:45 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564BF3D@CORPMX14> From: Black_David@emc.com To: ssenum@cisco.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: 7.2.1 CHAP Considerations (12-98) Date: Wed, 12 Jun 2002 16:47:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I think the essential condition here is that the "do not continue if secret is shorter than 96 bits" criteria should apply only to implementations that know and use the secret (i.e., generators of CHAP responses, and recipients of those responses that do their own verification as opposed to outsourcing that verification to something like a RADIUS server). Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Steve Senum [mailto:ssenum@cisco.com] > Sent: Wednesday, June 12, 2002 3:58 PM > To: Julian Satran > Cc: ietf-ips > Subject: Re: iSCSI: 7.2.1 CHAP Considerations (12-98) > > > Julian, > > In the case where an iSCSI Target is authenticating > an iSCSI Initiator, the Target sends a CHAP > challenge and identifier, and the Initiator sends > back a CHAP response and username. > > In the case were the Target is using the RADIUS > protocol, these four pieces of information are > sent by the Target to a RADIUS server, which > simply gives an accept or reject reply. The target > never has access to the CHAP secret (which is good), > hence no check can be made on its length. > > Regards, > Steve Senum > > Julian Satran wrote: > > > > can you elaborate? Julo > > > > Steve Senum > > Sent by: owner-ips@ece.cmu.edu To: ietf-ips > > > > 06/12/2002 09:32 PM cc: > > Please respond to Steve Senum Subject: > iSCSI: 7.2.1 CHAP > > Considerations (12-98) > > > > > > > > I have a concern over the wording of the > > following text from section 7.2.1 (12-98 version): > > > > When CHAP is used with secret shorter than 96 bits, > > a compliant implementation MUST NOT continue with > > the login unless it can verify that IPsec encryption > > is being used to protect the connection. > > > > I know the above is attempt to "put some teeth" into > > the requirements to make the use of CHAP secure, > > but I believe there are common cases where the > > length of the CHAP secret cannot be verified, such > > as when a RADIUS server is being used. > > > > Regards, > > Steve Senum > From owner-ips@ece.cmu.edu Wed Jun 12 17:04:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12979 for ; Wed, 12 Jun 2002 17:04:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CKsSU27281 for ips-outgoing; Wed, 12 Jun 2002 16:54:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g5CKsQw27275 for ; Wed, 12 Jun 2002 16:54:26 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g5CKsHp05111 for ; Wed, 12 Jun 2002 16:54:17 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g5CKsGc05093; Wed, 12 Jun 2002 16:54:16 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g5CKsF305720; Wed, 12 Jun 2002 16:54:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15623.46331.263000.340611@gargle.gargle.HOWL> Date: Wed, 12 Jun 2002 16:54:19 -0400 From: Paul Koning To: santoshr@cup.hp.com Cc: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: Re: iSCSI-Asynch event code References: <3D0795D3.92AA67CC@cup.hp.com> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 12 June 2002) by Santosh Rao: > > Why is this needed ? The target can just send an async event to drop the > connection or request a connection logout, and the connection can be > re-established allowing for new negotiation. > > I don't see the point of making this change so late in the game. There > exist mechanisms such as target driven connection logout/drop which can > be used to achieve the same effect. I agree. paul From owner-ips@ece.cmu.edu Wed Jun 12 17:23:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13505 for ; Wed, 12 Jun 2002 17:23:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CL1Or27703 for ips-outgoing; Wed, 12 Jun 2002 17:01:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13708.mail.yahoo.com (web13708.mail.yahoo.com [216.136.175.141]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g5CL1Mw27698 for ; Wed, 12 Jun 2002 17:01:22 -0400 (EDT) Message-ID: <20020612210121.40631.qmail@web13708.mail.yahoo.com> Received: from [192.55.52.3] by web13708.mail.yahoo.com via HTTP; Wed, 12 Jun 2002 14:01:21 PDT Date: Wed, 12 Jun 2002 14:01:21 -0700 (PDT) From: Martins Krikis Subject: base64 byte-length formula To: ips@ece.cmu.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I don't particularly care, but the formula given on page 71 of 12-98 is wrong (and I've mentioned it a few times already). A very simple counterexample: 0 base64 digits should result in a 0-byte binary string. According to the given formula, floor((0 + 3) * 3 / 4) - 0) = 2. Another, more realistic but just as simple one: 4 base64 digits should result in a 3-byte binary string. According to the given formula, floor((4 + 3) * 3 / 4) - 0) = 5. The given formula also fails for n = 3 (mod 4). The correct formula, IMO is the following: floor(n * 3 / 4). In other words, there is no need to even count the equivalence signs at the end, nor to add any constants. Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be my employer's. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Wed Jun 12 17:26:06 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13628 for ; Wed, 12 Jun 2002 17:26:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CL3Ob27833 for ips-outgoing; Wed, 12 Jun 2002 17:03:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g5CL3Nw27828 for ; Wed, 12 Jun 2002 17:03:23 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g5CL3Hp05368 for ; Wed, 12 Jun 2002 17:03:17 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g5CL3Gc05353; Wed, 12 Jun 2002 17:03:16 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g5CL3GJ06111; Wed, 12 Jun 2002 17:03:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15623.46871.610000.121698@gargle.gargle.HOWL> Date: Wed, 12 Jun 2002 17:03:19 -0400 From: Paul Koning To: rod.harrison@windriver.com Cc: santoshr@cup.hp.com, Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI-Asynch event code References: <3D0795D3.92AA67CC@cup.hp.com> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 12 June 2002) by Rod Harrison: > Santosh, > > There is a slight difference where the new event gives us more than > we have. If a target requests a logout there is no guarantee the > initiator will ever log that connection back in again. Why wouldn't it? > The reason I suggested we allow the initiator to bypass the login > timeouts if it logged out as a result of the new event was because the > target isn't asking for a logout to reduce resource commitments, so > there seems to be no need to wait for what may be a long time to > re-login. I don't see any reason for the initiator to assume that a timeout is needed after a target logout request. Guessing at "resource commitments" as the reason for the request sounds like a risky thing to do -- the reason might be something quite different and the conclusions you draw from this guess (i.e., "wait a while") may be entirely inappropriate. paul From owner-ips@ece.cmu.edu Wed Jun 12 17:51:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14592 for ; Wed, 12 Jun 2002 17:51:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CLKFI28900 for ips-outgoing; Wed, 12 Jun 2002 17:20:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CLKDw28896 for ; Wed, 12 Jun 2002 17:20:13 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 17:19:57 -0400 Message-ID: From: Eddy Quicksall To: "Mallikarjun C." Cc: ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Date: Wed, 12 Jun 2002 17:19:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Mallikarjun, This is not a case of arguing ... we are simply trying to understand each others point over EMAIL, which is difficult at best. Please try to work with me instead of against me. I could be wrong but I just need a little more cooperation instead of using the overworked terms like "if you will just read ...". You went into enough detail in one EMAIL to show that it is a messy job. When a solution is too messy and hard to explain, it is usually a clue that something needs to be simplified ... and that is what I am after. So far, I have not been able to catch the reason why we could not simply specify that the initiator must idle the commands before issuing a new size. Julian hinted that it would be a performance hit but I don't believe that will be a performance hit because it should be rare. Please explain why it would be a performance hit. I would also like to know why the SNACK just doesn't simply ask for an offset and a data length because that would simplify everything. Could you please explain that? You mention data-out below but I'm not talking about data-out, I'm talking about data-in. I don't know what this has to do with a long write. Can you please explain that? BTW, I don't have much background in ULPDU so maybe that is the key as to why the initiator can't idle first. Can you please explain that? In re-reading your statement below, I am wondering if you understand the problem ... The problem is that when a SNACK is sent and the PDU sizes have changed due to MaxPDUDataSegmentLength, then it puts a burden on the target to compute the proper offset of the BegRun (a.k.a messy). This is solved by the target in at least two ways: 1) The target can record the last PDU size when the change takes place. But it would also have to keep track of the number of already completed PDU's per outstanding command. This is because some commands may have missing PDU's with the old size and others may have missing PDU's with the new size. To make matters worse, some commands could have n PDUs already sent and others could have m PDUs already sent. If you want, I could make up a diagram of this and send it to you. 2) The target could "force an idle of data-in commands" (by queuing them) before it responds to the change request. Doing this would probably be no different than the initiator doing it but it would be easier and less intrusive for the initiator to do it. Eddy -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com] Sent: Wednesday, June 12, 2002 2:06 PM To: Eddy Quicksall; Rod Harrison; Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iSCSI: changing MaxPDUDataLength I am afraid this thread is going in circles, let me respond to this message before I rest my case on this topic. > I think you have misunderstood something... I'm not suggesting that you > mandate "no text negotiation till quiesced". I'm suggesting that only when > Max length changes and then only for the READS. This suggestion is to > simplify the logic you point out below. > > What are the harmful effects you mention below? As I earlier hinted twice, the Data-Out PDUs will not be ULPDU-contained anymore - and that could mean target would need to spend more memory/bus bandwidth/computation to deal with those till the long write is done. I do not understand your specific proposal yet. If you're arguing that a special case be made for reads, a cogent, clear rationale for the special case, coupled with the specifics of your proposal, would help the WG consider this further. Based on my current understanding of your position, I currently don't see the need for the special case. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com > > Eddy > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Tuesday, June 11, 2002 8:54 PM > To: Eddy Quicksall; Julian Satran > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: changing MaxPDUDataLength > > > > Can you suggest how this would be handled otherwise? > > I earlier said I will not get into implementation details, I will > however provide a generic answer. > > Given that the changed PDU size is not specific to one command, > I see the history of "past max PDU size(s)" as a connection attribute. > All you need on a per-task basis is really the value of one DataSN > *where* it had changed. > > We could further debate how to deal with multiple number of PDU size > changes during the life of an I/O - but I'm reluctant to be involved in that > debate because a) it's most unlikely, and b) there's no hard requirement > that > the target must always satisfy SNACKs under extreme conditions, and finally > c) it's too implementation-specific to be discussed on the ips reflector. > > Finally, I'd like to remind you that mandating "no text negotiation till > quiesced" > has harmful effects on targets dealing with long writes and wanting ULPDU- > containment - whose case you may be arguing. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > > ----- Original Message ----- > From: "Eddy Quicksall" > To: "Mallikarjun C." ; "Julian Satran" > > Cc: > Sent: Tuesday, June 11, 2002 4:45 PM > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > Consider the following (using Julian's suggestion): > > > > -> cmd 1 > > -> req to change to length 2 > > -> cmd 2 > > > > <- stat 1 > > <- data 2, PDU 0, Length 1 > > > > -> cmd 3, ack 1 so change the length > > > > <- data 2, PDU 1, Length 2 > > > > -> SNACK data 2, PDU 1 > > > > So we have to calculate the offset for Data 2, PDU 1 using old length and > > send data after that offset using new length. That means keeping track of > > PDU lengths which I would like to avoid. > > > > Or, the target would have to force idling of commands before it gives the > > response to the change. > > > > Can you suggest how this would be handled otherwise? > > > > Eddy > > > > -----Original Message----- > > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > > Sent: Tuesday, June 11, 2002 6:57 PM > > To: Eddy Quicksall; Julian Satran > > Cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: changing MaxPDUDataLength > > > > > > Eddy, > > > > I am not sure if you're agreeing with me or not... but let me add some > > comments. > > > > I don't expect the change in PDU size to happen frequently - no change > > in what I earlier said. > > > > You are making an assumption that a target must record the PDU size for > > every > > PDU if SNACKs are to be satisfied across changed > MaxRecvDataSegmentLength. > > > > As Julian earlier said, you don't have to. I will not go into > > implementation details, but > > I believe just the value of the DataSN from which the new size is > effective > > should > > be all that's needed. Besides, the spec guarantees that only RunLength=0 > is > > used > > on any SNACK after the change. > > > > You are also implying that targets can declare their changed > > MaxRecvDataSegmentLength > > anytime just for writes. There are two problems with this - a) reads and > > writes may both > > be active in the typical case on an iSCSI connection, and b) a target can > > declare its changed > > value only if an initiator is allowed to start the Text Request (and I > > thought you were suggesting > > that we explicitly disallow that). > > > > Hope that clears it up. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > > cbm@rose.hp.com > > > > > > ----- Original Message ----- > > From: "Eddy Quicksall" > > To: "Mallikarjun C." ; "Julian Satran" > > > > Cc: > > Sent: Tuesday, June 11, 2002 3:18 PM > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > You are correct and that is exactly how I have had to code it. With fast > > > path and slow path code split between processors, it becomes even worse. > > > > > > When I read your comments on why the PDU size could change (from way > back > > in > > > March I think), I got did not get the impression that it would happen > very > > > often and that in fact it may only happen when you are maintaining > > > allegiance to another connection. > > > > > > If it is something that is not going to happen very often, then it would > > be > > > so much easier to have the initiator idle the commands first (all it > > really > > > needs to do is idle the READ commands). If it is going to change so > often > > > that idling would be degrading, I suspect that just doing the > negotiation > > > that often would itself be degrading. > > > > > > And, be aware that the target will probably idle the R commands. > > Otherwise, > > > it will have to track PDU sizes and that would be really > > > "counter-productive" (especially when there should be no SNACKs on a > good > > > connection anyway). > > > > > > I don't see any problem with the target negotiating its size at any > time. > > > And the initiator would not have to idle the WRITE or no-data commands. > > > > > > Eddy > > > > > > -----Original Message----- > > > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > > > Sent: Tuesday, June 11, 2002 3:35 PM > > > To: Eddy Quicksall; Julian Satran > > > Cc: ips@ece.cmu.edu > > > Subject: Re: iSCSI: changing MaxPDUDataLength > > > > > > > > > Eddy, > > > > > > I am not clear on why you think the target code becomes messy on > > > a PDU size change. The last para in section 4.4 states the following - > > > > > > "Parameters negotiated by a text exchange negotiation sequence become > > > effective only after the negotiation sequence is completed." > > > > > > Since the target gets to complete a text negotiation with a Text > Response > > > PDU, it can time the applicability of a changed > MaxRecvDataSegmentLength. > > > > > > Requiring that an initiator must idle the connection before changing > this > > > parameter, IMHO, is counter-productive when there's a dynamic PMTU > > > degradation in the presence of long-running commands (writes in > > particular). > > > Once the initiator starts the renegotiation, target would ideally want > to > > > quickly > > > renegotiate its receive size as well to receive ULPDU-contained > segments. > > > > > > In short, seems to me that the draft is saying what you would like. > > > -- > > > Mallikarjun > > > > > > Mallikarjun Chadalapaka > > > Networked Storage Architecture > > > Network Storage Solutions > > > Hewlett-Packard MS 5668 > > > Roseville CA 95747 > > > cbm@rose.hp.com > > > > > > > > > ----- Original Message ----- > > > From: "Eddy Quicksall" > > > To: "Julian Satran" > > > Cc: > > > Sent: Tuesday, June 11, 2002 7:56 AM > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > I think it should be a requirement because if it is not, all target > code > > > > will have to have the messy code. Or, we could say that if it is not > > idle > > > > commands, then the target may reject it. > > > > > > > > Eddy > > > > > > > > -----Original Message----- > > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > > Sent: Tuesday, June 11, 2002 9:11 AM > > > > To: Eddy Quicksall > > > > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > > > > > That is a fair request - we may slip in a recommendation to that > effect > > > (in > > > > chapter 11?) > > > > > > > > Julo > > > > > > > > > > > > > > > > Eddy Quicksall > > > > > > > > > > > > 06/11/2002 04:28 AM > > > > Please respond to Eddy Quicksall > > > > > > > > > > > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > > > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > > > > > > > > > How about if we say that an initiator must not change the > MaxPDUDataSize > > > > unless it first idles the commands (at least the ones with the R bit) > or > > > if > > > > ErrorRecoveryLevel==0? > > > > > > > > That would simplify target code greatly and would meet the design > goals; > > > and > > > > since it should be rare to change it, it would be of little impact to > > idle > > > > the commands for a split second. > > > > > > > > > > > > Eddy > > > > -----Original Message----- > > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > > Sent: Monday, June 10, 2002 8:06 PM > > > > To: Eddy Quicksall > > > > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > I said only that when you change length you can ask for all PDUs after > > the > > > > ack! (no need to keep a tall - the old offsets are good up to the > hole). > > > > > > > > > > Julo > > > > > > > > > > > > Eddy Quicksall > > > > > > > > > > > > 06/11/2002 12:32 AM > > > > Please respond to Eddy Quicksall > > > > > > > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > > > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > > > > > > > > > > > > > Julian, > > > > > > > > Another problem here is that the target has to calculate the offset > from > > > the > > > > DataSN #. And as BegRun can be any value. E.g., BegRun=4 and > RunLngth=0 > > > > means starting DataSN=4, send all the data for that sequence. > > > > > > > > I think it would be a performance hit and waist of memory to keep a > > tally > > > of > > > > all PDU sizes just for an occasional SNACK. > > > > > > > > It's not that it can't be done ... it is more that it is messy and I > > think > > > > there is a solution that will satisfy the design requirements but keep > > the > > > > software simpler. > > > > > > > > Eddy > > > > -----Original Message----- > > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > > Sent: Saturday, June 08, 2002 10:16 PM > > > > To: Eddy Quicksall > > > > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > That is not completely accurate. > > > > The only problem is when PDU size decreases and then SNACK must be for > > all > > > > data. > > > > Target can also keep a mapping of numbers/to offsets (the list should > be > > > > small and if it gets long ask for ack (A-bit). > > > > > > > > Julo > > > > > > > > Eddy Quicksall > > > > Sent by: owner-ips@ece.cmu.edu > > > > > > > > > > > > 06/08/2002 10:54 PM > > > > Please respond to Eddy Quicksall > > > > > > > > > > > > To: pat_thaler@agilent.com > > > > cc: ips@ece.cmu.edu > > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > As a target, I won't be able to let it change until all of the > > outstanding > > > > commands are finished (running with ErrorRecoveryLevel>=1). This is > > > because > > > > I must use the PDU size to compute the offset from a SNACK's > > > > BegRun/RunLength. > > > > > > > > So, I plan to not give the text response for a MaxPDURecvDataLength in > > FFP > > > > until I get back an ExpStatSN == next StatSN. > > > > > > > > This will cause a delay of unknown time before the PDU size can > actually > > > > change ... do you see any problem with this? > > > > > > > > Eddy > > > > > > > > -----Original Message----- > > > > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > > > > Sent: Friday, June 07, 2002 1:13 PM > > > > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > Eddy, > > > > > > > > If one uses a message sync and steering that relys on the transport > > > segments > > > > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the > > path > > > > MTU changes one would want to change the PDU data length to fit the > new > > > path > > > > MTU. > > > > > > > > Pat > > > > > > > > -----Original Message----- > > > > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > > > > Sent: Wednesday, June 05, 2002 12:24 PM > > > > To: ips@ece.cmu.edu > > > > Subject: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > Does anybody know a case where it is necessary to support a new PDU > data > > > > length during full feature phase? > > > > > > > > Eddy > > > > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Wed Jun 12 17:52:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14630 for ; Wed, 12 Jun 2002 17:52:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CLEw428581 for ips-outgoing; Wed, 12 Jun 2002 17:14:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CLEtw28574; Wed, 12 Jun 2002 17:14:55 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id E5EABAD07; Wed, 12 Jun 2002 15:14:54 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 7A77E1CF; Wed, 12 Jun 2002 15:14:54 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 12 Jun 2002 15:14:52 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 15:14:51 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E440C@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com, cbm@rose.hp.com Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Date: Wed, 12 Jun 2002 15:14:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, It is equally likely that a Target could run into a reason to change PDUsize as for an Initiator. Therefore, I agree that there should be a way for the target to request that the initiator open a FFP negotiation and an Async message code is a good way to do that. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, June 11, 2002 2:28 PM To: Mallikarjun C. Cc: ips@ece.cmu.edu; Julian Satran; owner-ips@ece.cmu.edu Subject: Re: iSCSI: changing MaxPDUDataLength Importance: High Mallikarjun, The question was general and not specific to MaxRecv.... Although we say that negotiation is symmetric we don't have any mechanism through which a target can say it wants to start negotiation something (sort of similar but not as strong as a the "request logout" - "request to negotiate" that will require the initiator to issue a text request and kick-off a negotiation. Julo "Mallikarjun C." To: , Julian Satran/Haifa/IBM@IBMIL Sent by: cc: owner-ips@ece.cmu Subject: Re: iSCSI: changing MaxPDUDataLength .edu 06/11/2002 10:50 PM Please respond to "Mallikarjun C." > I also realized that we don't have "negotiation prompt" from the target. > I am not sure that we need one. I am not sure about it either. My preference is not to add this. It appears to me that a target does have the option of dropping the connection today if it can't work with non-ULPDU-contained segments for too long. I suspect that the target would do the same if (we introduced the "negotiation prompt" and) the initiator doesn't/couldn't honor the "negotiation prompt". Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Julian Satran" To: Sent: Tuesday, June 11, 2002 8:34 AM Subject: RE: iSCSI: changing MaxPDUDataLength > I suggest the following text in 11.13 > > A change of MaxRecvDataSegmentLength by an initiator or target > becomes effective after all commands preceding the negotiation > end-ing request have been processed by the target and their status > is acknowledged. > > I also realized that we don't have "negotiation prompt" from the target. > I am not sure that we need one. > If some of you think we need we may want one additional code in the Asynch > Message. > Please comment TODAY. > > Julo > ----- Forwarded by Julian Satran/Haifa/IBM on 06/11/2002 06:29 PM ----- > > Julian Satran > To: Eddy Quicksall > 06/11/2002 04:04 cc: ips@ece.cmu.edu, pat_thaler@agilent.com > PM From: Julian Satran/Haifa/IBM@IBMIL > Subject: RE: iSCSI: changing MaxPDUDataLength(Document link: Julian Satran - Mail) > > > > > > > > > > That is a fair request - we may slip in a recommendation to that effect (in > chapter 11?) > > Julo > > > > Eddy Quicksall > vivity.com> cc: ips@ece.cmu.edu, pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > 06/11/2002 04:28 > AM > Please respond to > Eddy Quicksall > > > > > > How about if we say that an initiator must not change the MaxPDUDataSize > unless it first idles the commands (at least the ones with the R bit) or if > ErrorRecoveryLevel==0? > > That would simplify target code greatly and would meet the design goals; > and since it should be rare to change it, it would be of little impact to > idle the commands for a split second. > > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Monday, June 10, 2002 8:06 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > I said only that when you change length you can ask for all PDUs > after the ack! (no need to keep a tall - the old offsets are good up > to the hole). > > Julo > > > Eddy Quicksall > To: Julian > Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu, > 06/11/2002 12:32 AM pat_thaler@agilent.com > Please respond to Eddy Quicksall Subject: RE: iSCSI: > changing MaxPDUDataLength > > > > > > > > Julian, > > Another problem here is that the target has to calculate the offset > from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and > RunLngth=0 means starting DataSN=4, send all the data for that > sequence. > > I think it would be a performance hit and waist of memory to keep a > tally of all PDU sizes just for an occasional SNACK. > > It's not that it can't be done ... it is more that it is messy and I > think there is a solution that will satisfy the design requirements > but keep the software simpler. > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Saturday, June 08, 2002 10:16 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > That is not completely accurate. > The only problem is when PDU size decreases and then SNACK must be > for all data. > Target can also keep a mapping of numbers/to offsets (the list should > be small and if it gets long ask for ack (A-bit). > > Julo > > Eddy Quicksall > To: > Sent by: owner-ips@ece.cmu.edu pat_thaler@agilent.com > cc: ips@ece.cmu.edu > Subject: RE: iSCSI: > 06/08/2002 10:54 PM changing MaxPDUDataLength > Please respond to Eddy Quicksall > > > > > > > > Thanks, > > As a target, I won't be able to let it change until all of the > outstanding > commands are finished (running with ErrorRecoveryLevel>=1). This is > because > I must use the PDU size to compute the offset from a SNACK's > BegRun/RunLength. > > So, I plan to not give the text response for a MaxPDURecvDataLength > in FFP > until I get back an ExpStatSN == next StatSN. > > This will cause a delay of unknown time before the PDU size can > actually > change ... do you see any problem with this? > > Eddy > > -----Original Message----- > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > Sent: Friday, June 07, 2002 1:13 PM > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > Subject: RE: iSCSI: changing MaxPDUDataLength > > > Eddy, > > If one uses a message sync and steering that relys on the transport > segments > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the > path > MTU changes one would want to change the PDU data length to fit the > new path > MTU. > > Pat > > -----Original Message----- > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > Sent: Wednesday, June 05, 2002 12:24 PM > To: ips@ece.cmu.edu > Subject: iSCSI: changing MaxPDUDataLength > > > Does anybody know a case where it is necessary to support a new PDU > data > length during full feature phase? > > Eddy > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > > > From owner-ips@ece.cmu.edu Wed Jun 12 18:24:27 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15387 for ; Wed, 12 Jun 2002 18:24:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CLsxf00951 for ips-outgoing; Wed, 12 Jun 2002 17:54:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CLsuw00943 for ; Wed, 12 Jun 2002 17:54:56 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 01EDB3E8D; Wed, 12 Jun 2002 15:54:56 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 922EEEE; Wed, 12 Jun 2002 15:54:55 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 12 Jun 2002 15:54:55 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 15:54:55 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E4423@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: ni1d@arrl.net, santoshr@cup.hp.com Cc: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI-Asynch event code Date: Wed, 12 Jun 2002 15:54:54 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Paul and Santosh, If this isn't needed, then I don't see why FFP negotiation is needed at all (other than to support discovery with SendTargets but that isn't really a negotiation). The initiator could also close and reopen the connection to change PDU size. If we support renegotiation of some keys during FFP for the initiator, then we should do it for the target as well. Otherwise we shouldn't support renegotiation at all. Pat -----Original Message----- From: Paul Koning [mailto:ni1d@arrl.net] Sent: Wednesday, June 12, 2002 1:54 PM To: santoshr@cup.hp.com Cc: Julian_Satran@il.ibm.com; ips@ece.cmu.edu Subject: Re: iSCSI-Asynch event code Excerpt of message (sent 12 June 2002) by Santosh Rao: > > Why is this needed ? The target can just send an async event to drop the > connection or request a connection logout, and the connection can be > re-established allowing for new negotiation. > > I don't see the point of making this change so late in the game. There > exist mechanisms such as target driven connection logout/drop which can > be used to achieve the same effect. I agree. paul From owner-ips@ece.cmu.edu Wed Jun 12 18:24:49 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15402 for ; Wed, 12 Jun 2002 18:24:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CLlPw00526 for ips-outgoing; Wed, 12 Jun 2002 17:47:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CLlNw00519 for ; Wed, 12 Jun 2002 17:47:23 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 8E645B6AA; Wed, 12 Jun 2002 15:47:22 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 6501523F; Wed, 12 Jun 2002 15:47:22 -0600 (MDT) Received: from 130.29.152.143 by axcsbh1.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 12 Jun 2002 15:47:22 -0600 Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 15:47:21 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E441C@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Martins Krikis , ips@ece.cmu.edu Subject: RE: iSCSI-Asynch event code Date: Wed, 12 Jun 2002 15:47:20 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Martins, I think this should be added, but I don't see any need to say that the initiator send an empty Text Request. It is possible (perhaps even likely in the event of a path change) that the initiator will decide to start a negotiation at the same time that the target sends the Asynch Message requesting negotiation. If so, the Initiator could send Text Negotiation before it has received (or processed) the message from the target. Therefore, the target has to accept the initiator starting the negotiation with its own keys. Also, all the standard keys currently allowed in FFP are declarations so it doesn't matter who offers keys first. An example: Initiator and target are using a sync steering method where PDUs are aligned to transport segments/packets. A path change occurs that reduces the path MTU. Both the initiator and target detect the new MTU. Async message request negotiation <- t i -> Text negotiation (MaxRecvPDUDataSize) -> t i <- Async message arrives but the negotiation has already started so the initiator doesn't need to take action on it. Regards, Pat -----Original Message----- From: Martins Krikis [mailto:mkrikis@yahoo.com] Sent: Wednesday, June 12, 2002 1:41 PM To: ips@ece.cmu.edu Subject: Re: iSCSI-Asynch event code I don't mind this code being added for completeness sake, nor will I be overly disappointed if it isn't. If it is added, however, perhaps we should go half a step farther and demand that the Text Request coming from the initiator MUST be empty? That way the target is really "in charge" and may _originate_ any key negotiable in FFP. Just my $.02. Comments? Martins Krikis, Intel Corp. Disclaimer: These are my opinions and may not be my employer's. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Wed Jun 12 18:25:46 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15437 for ; Wed, 12 Jun 2002 18:25:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CM4D501463 for ips-outgoing; Wed, 12 Jun 2002 18:04:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CM4Bw01459 for ; Wed, 12 Jun 2002 18:04:12 -0400 (EDT) Received: from london ([192.168.1.60]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id PAA17793; Wed, 12 Jun 2002 15:02:09 -0700 (PDT) From: "Rod Harrison" To: "Paul Koning" Cc: , , Subject: RE: iSCSI-Asynch event code Date: Wed, 12 Jun 2002 17:04:28 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <15623.46871.610000.121698@gargle.gargle.HOWL> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Paul Koning [mailto:ni1d@arrl.net] > Sent: Wednesday, June 12, 2002 4:03 PM > To: rod.harrison@windriver.com > Cc: santoshr@cup.hp.com; Julian_Satran@il.ibm.com; > ips@ece.cmu.edu > Subject: RE: iSCSI-Asynch event code > > > Excerpt of message (sent 12 June 2002) by Rod Harrison: > > Santosh, > > > > There is a slight difference where the new event > gives us more than > > we have. If a target requests a logout there is no > guarantee the > > initiator will ever log that connection back in again. > > Why wouldn't it? > Because it has been told to logout by the target so presumably the target doesn't want that connection in place. > > The reason I suggested we allow the initiator to > bypass the login > > timeouts if it logged out as a result of the new event > was because the > > target isn't asking for a logout to reduce resource > commitments, so > > there seems to be no need to wait for what may be a > long time to > > re-login. > > I don't see any reason for the initiator to assume that > a timeout is > needed after a target logout request. Guessing at "resource > commitments" as the reason for the request sounds like a > risky thing > to do -- the reason might be something quite different and the > conclusions you draw from this guess (i.e., "wait a > while") may be > entirely inappropriate. > I misread the DefaultTime2Wait key; I hadn't realised it referred only to unexpected connection termination. Somehow I had gotten the idea the initiator should wait this long before logging in again, and it was that I was objecting to in the negotiation event case. My mistake, sorry! However, we can turn this logic around, if a target requests an initiator logout a connection as a mechanism for instigating parameter negotiation there is certainly no guarantee the initiator will login again quickly, or indeed ever. You said "why wouldn't it", but why would it? The initiator could assign the released connection resources to another session and be unable to start another connection in the first session. DNS might be down, there are all sorts of things that can prevent a connection being established that don't effect an established connection. Unless we include language stating otherwise a target that requests a connection logout for any reason can't assume a reconnect will happen. - Rod > paul > > From owner-ips@ece.cmu.edu Wed Jun 12 18:26:25 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15464 for ; Wed, 12 Jun 2002 18:26:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CMKQt02312 for ips-outgoing; Wed, 12 Jun 2002 18:20:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from snjspop1.snjs.qwest.net (snjspop1.snjs.qwest.net [168.103.24.1]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g5CMKNw02300 for ; Wed, 12 Jun 2002 18:20:23 -0400 (EDT) Received: (qmail 58677 invoked from network); 12 Jun 2002 22:20:22 -0000 Received: from 168-103-214-76.dslgw2.snva.qwest.net (HELO theglowmonster) (168.103.214.76) by snjspop1.snjs.qwest.net with SMTP; 12 Jun 2002 22:20:22 -0000 Date: Wed, 12 Jun 2002 15:18:25 -0700 Message-ID: From: "Randy Jennings" To: "Martins Krikis" , ips@ece.cmu.edu Subject: RE: iSCSI-Asynch event code MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20020612204106.13576.qmail@web13705.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > If it is added, however, perhaps we should go half > a step farther and demand that the Text Request coming > from the initiator MUST be empty? That way the target > is > really "in charge" and may _originate_ any key > negotiable > in FFP. Just my $.02. Comments? I would say no. If the Initiator has a Text Negotiation in the queue, it should not have to clear it. Sincerely, Randy Data Transit From owner-ips@ece.cmu.edu Wed Jun 12 18:27:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15491 for ; Wed, 12 Jun 2002 18:27:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CM6gq01607 for ips-outgoing; Wed, 12 Jun 2002 18:06:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13709.mail.yahoo.com (web13709.mail.yahoo.com [216.136.175.251]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g5CM6fw01602 for ; Wed, 12 Jun 2002 18:06:41 -0400 (EDT) Message-ID: <20020612220640.85924.qmail@web13709.mail.yahoo.com> Received: from [192.55.52.3] by web13709.mail.yahoo.com via HTTP; Wed, 12 Jun 2002 15:06:40 PDT Date: Wed, 12 Jun 2002 15:06:40 -0700 (PDT) From: Martins Krikis Subject: RE: iSCSI-Asynch event code To: "THALER,PAT \(A-Roseville,ex1\)" Cc: ips@ece.cmu.edu In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00C5E441C@axcs04.cos.agilent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I know it doesn't matter for the current standard keys usable in FFP (it may matter for future keys or for some vendor keys). I agree that it cannot be guaranteed that the PDUs don't cross each other on the wire and that the target gets a non-empty Text Request. That's life. If it badly wants to be in "initiator's shoes" and be the originator, it can always try again. But at least I'm proposing to give it a chance, and a fairly decent one (albeit not a 100% guaranteed one) to be in charge. Alright, so may be the initiator SHOULD (not MUST) send an empty Text Request? This new event is about symmetry, right? Well, that (illusion of) symmetry will be more complete if the target is given a chance to _originate_ anything it wishes, not just opportunity to respond. Anyway, I don't really care. Including whether the new async event is added or not. Martins __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Wed Jun 12 18:27:40 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15504 for ; Wed, 12 Jun 2002 18:27:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CMCMJ01905 for ips-outgoing; Wed, 12 Jun 2002 18:12:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CMCKw01901 for ; Wed, 12 Jun 2002 18:12:20 -0400 (EDT) Received: from cisco.com (dhcp-161-44-68-217.cisco.com [161.44.68.217]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA06038; Wed, 12 Jun 2002 18:12:13 -0400 (EDT) Message-ID: <3D07C73C.888C1D3F@cisco.com> Date: Wed, 12 Jun 2002 17:12:12 -0500 From: Steve Senum X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Satran CC: ietf-ips Subject: Re: iSCSI: 7.2.1 CHAP Considerations (12-98) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, I don't see how this helps. Unless the Target is directly managing the CHAP secrets, I don't believe a check on the length of the secret is pratical. Steve Senum Julian Satran wrote: > > Steve, > > The text is not explicit about how the secret length gets to iSCSI. > It can be an administrative interface/action. > > Julo > > Steve Senum > To: Julian > Satran/Haifa/IBM@IBMIL > 06/12/2002 10:58 PM cc: ietf-ips > Please respond to Steve Senum Subject: Re: iSCSI: 7.2.1 CHAP > Considerations (12-98) > > > > Julian, > > In the case where an iSCSI Target is authenticating > an iSCSI Initiator, the Target sends a CHAP > challenge and identifier, and the Initiator sends > back a CHAP response and username. > > In the case were the Target is using the RADIUS > protocol, these four pieces of information are > sent by the Target to a RADIUS server, which > simply gives an accept or reject reply. The target > never has access to the CHAP secret (which is good), > hence no check can be made on its length. > > Regards, > Steve Senum > > Julian Satran wrote: > > > > can you elaborate? Julo > > > > Steve Senum > > Sent by: owner-ips@ece.cmu.edu To: ietf-ips > > > > 06/12/2002 09:32 PM cc: > > Please respond to Steve Senum Subject: iSCSI: 7.2.1 CHAP > > Considerations (12-98) > > > > > > > > I have a concern over the wording of the > > following text from section 7.2.1 (12-98 version): > > > > When CHAP is used with secret shorter than 96 bits, > > a compliant implementation MUST NOT continue with > > the login unless it can verify that IPsec encryption > > is being used to protect the connection. > > > > I know the above is attempt to "put some teeth" into > > the requirements to make the use of CHAP secure, > > but I believe there are common cases where the > > length of the CHAP secret cannot be verified, such > > as when a RADIUS server is being used. > > > > Regards, > > Steve Senum From owner-ips@ece.cmu.edu Wed Jun 12 18:36:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15633 for ; Wed, 12 Jun 2002 18:36:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CM37n01400 for ips-outgoing; Wed, 12 Jun 2002 18:03:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CM34w01392; Wed, 12 Jun 2002 18:03:04 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5CM2vML027364; Thu, 13 Jun 2002 00:02:57 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5CM2vr145608; Thu, 13 Jun 2002 00:02:57 +0200 To: Martins Krikis Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: base64 byte-length formula X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 13 Jun 2002 01:02:56 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 13/06/2002 01:02:58, Serialize complete at 13/06/2002 01:02:58 Content-Type: multipart/alternative; boundary="=_alternative 00766AABC2256BD6_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00766AABC2256BD6_= Content-Type: text/plain; charset="us-ascii" Sorry - It must have stayed in my pile. Your formula is not correct. The correct one is (n*3 + 3)/4 Julo Martins Krikis Sent by: owner-ips@ece.cmu.edu 06/13/2002 12:01 AM Please respond to Martins Krikis To: ips@ece.cmu.edu cc: Subject: base64 byte-length formula I don't particularly care, but the formula given on page 71 of 12-98 is wrong (and I've mentioned it a few times already). A very simple counterexample: 0 base64 digits should result in a 0-byte binary string. According to the given formula, floor((0 + 3) * 3 / 4) - 0) = 2. Another, more realistic but just as simple one: 4 base64 digits should result in a 3-byte binary string. According to the given formula, floor((4 + 3) * 3 / 4) - 0) = 5. The given formula also fails for n = 3 (mod 4). The correct formula, IMO is the following: floor(n * 3 / 4). In other words, there is no need to even count the equivalence signs at the end, nor to add any constants. Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be my employer's. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com --=_alternative 00766AABC2256BD6_= Content-Type: text/html; charset="us-ascii"
Sorry - It must have stayed in my pile. Your formula is not correct.
The correct one is (n*3 + 3)/4

Julo


Martins Krikis <mkrikis@yahoo.com>
Sent by: owner-ips@ece.cmu.edu

06/13/2002 12:01 AM
Please respond to Martins Krikis

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        base64 byte-length formula

       


I don't particularly care, but the formula given
on page 71 of 12-98 is wrong (and I've mentioned
it a few times already).

A very simple counterexample:

0 base64 digits should result in a 0-byte binary
string. According to the given formula,
floor((0 + 3) * 3 / 4) - 0) = 2.

Another, more realistic but just as simple one:

4 base64 digits should result in a 3-byte binary
string. According to the given formula,
floor((4 + 3) * 3 / 4) - 0) = 5.

The given formula also fails for n = 3 (mod 4).

The correct formula, IMO is the following:
floor(n * 3 / 4).

In other words, there is no need to even count
the equivalence signs at the end, nor to add
any constants.

Martins Krikis, Intel Corp.

Disclaimer: these opinions are mine and may
           not be my employer's.


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--=_alternative 00766AABC2256BD6_=-- From owner-ips@ece.cmu.edu Wed Jun 12 18:37:30 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15652 for ; Wed, 12 Jun 2002 18:37:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CMEQJ02018 for ips-outgoing; Wed, 12 Jun 2002 18:14:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CMEPw02013 for ; Wed, 12 Jun 2002 18:14:25 -0400 (EDT) Received: from cisco.com (dhcp-161-44-68-217.cisco.com [161.44.68.217]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA07603; Wed, 12 Jun 2002 18:14:12 -0400 (EDT) Message-ID: <3D07C7B4.A9DBE6D4@cisco.com> Date: Wed, 12 Jun 2002 17:14:12 -0500 From: Steve Senum X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Black_David@emc.com CC: ips@ece.cmu.edu Subject: Re: iSCSI: 7.2.1 CHAP Considerations (12-98) References: <277DD60FB639D511AC0400B0D068B71E0564BF3D@CORPMX14> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, What you state would be better, but that is not what the current text (as of 12-98) says. Steve Senum Black_David@emc.com wrote: > > I think the essential condition here is that the > "do not continue if secret is shorter than 96 bits" > criteria should apply only to implementations that > know and use the secret (i.e., generators of CHAP > responses, and recipients of those responses that > do their own verification as opposed to outsourcing > that verification to something like a RADIUS server). > > Thanks, > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > black_david@emc.com Cell: +1 (978) 394-7754 > --------------------------------------------------- > > > -----Original Message----- > > From: Steve Senum [mailto:ssenum@cisco.com] > > Sent: Wednesday, June 12, 2002 3:58 PM > > To: Julian Satran > > Cc: ietf-ips > > Subject: Re: iSCSI: 7.2.1 CHAP Considerations (12-98) > > > > > > Julian, > > > > In the case where an iSCSI Target is authenticating > > an iSCSI Initiator, the Target sends a CHAP > > challenge and identifier, and the Initiator sends > > back a CHAP response and username. > > > > In the case were the Target is using the RADIUS > > protocol, these four pieces of information are > > sent by the Target to a RADIUS server, which > > simply gives an accept or reject reply. The target > > never has access to the CHAP secret (which is good), > > hence no check can be made on its length. > > > > Regards, > > Steve Senum > > > > Julian Satran wrote: > > > > > > can you elaborate? Julo > > > > > > Steve Senum > > > Sent by: owner-ips@ece.cmu.edu To: ietf-ips > > > > > > 06/12/2002 09:32 PM cc: > > > Please respond to Steve Senum Subject: > > iSCSI: 7.2.1 CHAP > > > Considerations (12-98) > > > > > > > > > > > > I have a concern over the wording of the > > > following text from section 7.2.1 (12-98 version): > > > > > > When CHAP is used with secret shorter than 96 bits, > > > a compliant implementation MUST NOT continue with > > > the login unless it can verify that IPsec encryption > > > is being used to protect the connection. > > > > > > I know the above is attempt to "put some teeth" into > > > the requirements to make the use of CHAP secure, > > > but I believe there are common cases where the > > > length of the CHAP secret cannot be verified, such > > > as when a RADIUS server is being used. > > > > > > Regards, > > > Steve Senum > > From owner-ips@ece.cmu.edu Wed Jun 12 19:21:14 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16488 for ; Wed, 12 Jun 2002 19:21:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CMdPv03259 for ips-outgoing; Wed, 12 Jun 2002 18:39:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CMdNw03255 for ; Wed, 12 Jun 2002 18:39:23 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel12.hp.com (Postfix) with ESMTP id A7C9AE0034B; Wed, 12 Jun 2002 15:39:13 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id PAA04519; Wed, 12 Jun 2002 15:39:07 -0700 (PDT) Message-ID: <3D07CF80.CA8286BF@cup.hp.com> Date: Wed, 12 Jun 2002 15:47:28 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: pat_thaler@agilent.com Cc: ni1d@arrl.net, Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: Re: iSCSI-Asynch event code References: <1BEBA5E8600DD4119A50009027AF54A00C5E4423@axcs04.cos.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I don't see a need to allow key re-negotiation during FFP. The only key that is really required to be used in FFP is SendTargets. The keys that are permitted during FFP are : - SendTargets - TargetAlias - InitiatorAlias - TargetAddress - MaxRecvDataPDUSize (or whatever its latest name is) - Vendor Specific keys Of the above, the only real negotiation involves the MaxRecvPDUSize. I don't see any use of attempting to modify/negotiate/communicate the remaining keys during FFP (with the exception of SendTargets). I see no problem in forbidding key re-negotiation during FFP and handling PMTU changes by dropping the connection and allowing it to be re-established. There needs to be a conscious effort to simplify this login negotiation process and bound the complexity that's being heaped upon it. If we don't make the attempt to keep it simple, we are going to be bitten by a bunch of bugs in this area due to its complexity. This is one such area where we can choose not to increase the complexity of login negotiation. There have been some concerns raised about the initiator not logging back in upon a target driven logout. Such an initiator driver is a poor design. As long as an upper layer in the O.S. has an open pending on some LUN of that target port, it is the duty of the initiator driver to attempt to keep the I-T nexus established, and if there's a transient glitch in the I-T nexus, the initiator must attempt to re-login. An initiator that does not do this gets what it deserves. There's no need to add complexity to the spec in an attempt to deal with poor initiator implementations. The target need not care if the initiator does not log back, in this case. - Santosh pat_thaler@agilent.com wrote: > > Paul and Santosh, > > If this isn't needed, then I don't see why FFP negotiation is needed at all (other than to support discovery with SendTargets but that isn't really a negotiation). The initiator could also close and reopen the connection to change PDU size. If we support renegotiation of some keys during FFP for the initiator, then we should do it for the target as well. Otherwise we shouldn't support renegotiation at all. > > Pat > > -----Original Message----- > From: Paul Koning [mailto:ni1d@arrl.net] > Sent: Wednesday, June 12, 2002 1:54 PM > To: santoshr@cup.hp.com > Cc: Julian_Satran@il.ibm.com; ips@ece.cmu.edu > Subject: Re: iSCSI-Asynch event code > > Excerpt of message (sent 12 June 2002) by Santosh Rao: > > > > Why is this needed ? The target can just send an async event to drop the > > connection or request a connection logout, and the connection can be > > re-established allowing for new negotiation. > > > > I don't see the point of making this change so late in the game. There > > exist mechanisms such as target driven connection logout/drop which can > > be used to achieve the same effect. > > I agree. > > paul -- The world is so fast that there are days when the person who says it can't be done is interrupted by the person who is doing it. ~ Anon From owner-ips@ece.cmu.edu Wed Jun 12 19:23:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16573 for ; Wed, 12 Jun 2002 19:23:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CMnqH03793 for ips-outgoing; Wed, 12 Jun 2002 18:49:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CMnpw03789 for ; Wed, 12 Jun 2002 18:49:51 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 18:48:15 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564BF3F@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: RE: iSCSI-12-95: header digest error clarification Date: Wed, 12 Jun 2002 18:48:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Catching up on email after vacation ... This thread seems to have reached the right conclusion - it might be worth adding a sentence instructing implementers not to scan the incoming data stream for headers as the result can be confused by (things that look like) headers in data if one is not careful. It's important to avoid being confused in this fashion, but it's not easy. An implementation that doesn't get this right has no alternative but to close the connection on a header digest error. I bring this up here because I've been through the same issue with the FCIP draft in great detail. It is possible to tell real headers from false headers by scanning far enough and knowing what the maximum PDU size is - appendix D of the FCIP draft contains an example of such an algorithm. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Friday, May 31, 2002 5:58 PM > To: pat_thaler@agilent.com; Julian_Satran@il.ibm.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI-12-95: header digest error clarification > > > Pat, > > From: > To: ; ; > > Cc: > Sent: Friday, May 31, 2002 2:48 PM > Subject: RE: iSCSI-12-95: header digest error clarification > > > > Mallikarjun, > > > > I like it, but it has the same problem I pointed out to > Paul. Sync and steering > > (at least as in FIM and as in some of the other candidates) > doesn't necessarily > > allow one to determine PDU length. What it does allow is > identifing the start > > of a header (which may not be the next header after the bad PDU). > > > > One could use: > > "... MUST either discard the header and all data up to the > beginning of a later PDU > > when that location can be ascertained by other means (such > as the operation > > of a sync and steering layer) or close the connection." > > I see your point. I like this text, but perhaps suggest > "reliably" before "ascertained" > in the above. > > Thanks. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > > > > or (to avoid a messy long sentence): > > "... MUST either discard the header and all data up to the > beginning of a later PDU > > or close the connection. Since the digest error indicates > that the length field of the > > header may have been corrupted, the location of the > beginning of a later PDU > > needs to be ascertained by other reliable means (such as > the operation of a sync and > > steering layer)" > > > > > > Pat > > > > -----Original Message----- > > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > > Sent: Friday, May 31, 2002 12:39 PM > > To: pat_thaler@agilent.com; Julian_Satran@il.ibm.com > > Cc: ips@ece.cmu.edu > > Subject: Re: iSCSI-12-95: header digest error clarification > > > > > > Pat, > > > > I think I understand your concern that Section 6.5 almost makes > > it look as if PDU length can be ascertained on header digest errors > > just as in other cases. > > > > Your first formulation is closer to the level of detail I > would prefer. > > I'd however suggest text with a couple of tweaks. > > > > "... MUST discard the PDU when its length can be reliably > ascertained by other > > means (such as the operation of a sync and steering layer), > or close the connection." > > > > This should leave enough room for other implementation > options, while > > pointing out the utility of the sync and steering layer > defined in the spec in > > this error scenario. > > > > Regards. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > > cbm@rose.hp.com > > > > > > ----- Original Message ----- > > From: > > To: ; > > Cc: > > Sent: Friday, May 31, 2002 10:28 AM > > Subject: RE: iSCSI-12-95: header digest error clarification > > > > > > > Julian, > > > > > > I'm not sure how explicit we have to be about the > solution, but right now > > > there is a MUST that isn't really achievable. It says one > MUST discard the > > > PDU but the implementation doesn't know what the PDU is. > One possibility is: > > > > > > ... MUST close the connection or attempt to find a valid > header and discard > > > everything from the bad header to the valid header. > > > > > > or > > > > > > ... MUST attempt to discard the PDU. However, if the > length field was > > > corrupted, the boundary of the PDU is unclear. If the > apparent header > > > following the discarded PDU also has a digest error, the > initiator/target > > > MAY close the connection or attempt to find a valid > header and discard > > > everything from the bad header to the valid header. > > > > > > This leaves the options open to the implementor but puts > the MUST in terms > > > of what can be accomplished. The only reason to get more > explicit is concern > > > about data corruption if a false valid header is found in > looking for a good > > > header, but that is extremely low probablility. > > > > > > Regards, > > > Pat > > > > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Friday, May 31, 2002 4:43 AM > > > To: pat_thaler@agilent.com > > > Cc: ips@ece.cmu.edu > > > Subject: RE: iSCSI-12-95: header digest error clarification > > > > > > > > > > > > Pat, > > > > > > I avoided being specific because an earlier format for > headers that I > > > suggested and that included separate parity for the > length field got > > > rejected > > > (too complex). and I felt that all the solutions that you > mention are > > > implementation options. > > > Do you think that we have to be explicit about them? > > > > > > Regards, > > > Julo > > > > > > > > > > > > pat_thaler@agilent.com > > > > > > > > > 05/31/2002 03:20 AM > > > Please respond to pat_thaler > > > > > > > > > > > > To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu > > > cc: > > > Subject: RE: iSCSI-12-95: header digest > error clarification > > > > > > > > > > > > > > > Julian, > > > > > > There was a brief discussion of the issues raised by > header digest errors, > > > but nothing has made it into 6.5 Digest Errors. > > > > > > 6.5 says that a target or initiator receiving a PDU with > a header digest > > > error MUST silently discard the PDU. > > > > > > The problem is that it can't do that. A header digest > error means that > > > DataSegmentLength may have been corrupted so the receiver > doesn't know > > > where the PDU ends and the next begins. > > > > > > Possible resolutions: > > > > > > If FIM is enabled, silently discard everything from the > bad header to > > > the next start of header pointed to by a marker. > > > > > > If FIM is not enabled, chose one (or more of the following): > > > Assume that the DataSegmentLength is correct and check to > see if a > > > valid header including a valid header digest and CmdSN > begins at the > > > point indicated by the length. If it does, then drop the PDU as > > > indicated by the DataSegmentLength and resume processing the next > > > PDU. If the next header doesn't check, close the > connection or use the > > > next technique. > > > Downside: This entails a small risk that the > DataSegmentLength was wrong > > > but unluckily pointed into a part of the data stream that looked > > > like a valid header. Also, there may not be a next header to check > > > immediately so one may have to wait for an indeterminate > time before > > > closing this out. > > > > > > Search the data stream for a valid header. This gets kind of ugly > > > because headers are 48 bytes long (or longer with AHS) > but can start > > > every 4 bytes so one has check overlapping sets of bytes for a > > > correct CRC which either means it will be slow or one will need > > > multiple CRC checkers. Also, this has a significantly higher risk > > > of finding a false valid header. Therefore, this recovery method > > > should not be allowed. > > > > > > Close the connection. > > > > > > Regards, > > > Pat > > > > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Wednesday, May 29, 2002 3:02 PM > > > To: ips@ece.cmu.edu > > > Subject: iSCSI-12-95 > > > > > > > > > 12-95 is out. > > > It has the latest wording on security and text > negotiation (including the > > > spanning). > > > > > > Still to go - text fixes in chapter 11. > > > > > > Julo > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Wed Jun 12 19:23:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16588 for ; Wed, 12 Jun 2002 19:23:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CMuVZ04179 for ips-outgoing; Wed, 12 Jun 2002 18:56:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13705.mail.yahoo.com (web13705.mail.yahoo.com [216.136.175.138]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g5CMuTw04175 for ; Wed, 12 Jun 2002 18:56:29 -0400 (EDT) Message-ID: <20020612225628.34776.qmail@web13705.mail.yahoo.com> Received: from [192.55.52.1] by web13705.mail.yahoo.com via HTTP; Wed, 12 Jun 2002 15:56:28 PDT Date: Wed, 12 Jun 2002 15:56:28 -0700 (PDT) From: Martins Krikis Subject: Re: base64 byte-length formula To: Julian Satran Cc: ips@ece.cmu.edu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Sorry, I had missed to CC the previous to the list but I'm doing it with this. The way you understand base64 is not the way I understand it. Can somebody please chime in and set the record straight? Here is the relevant text from RFC 2045, describing the base64 encoding process. We are, of course, talking about decoding in these length-calculation formulas. More of my comments further down in text. Special processing is performed if fewer than 24 bits are available at the end of the data being encoded. A full encoding quantum is always completed at the end of a body. When fewer than 24 input bits are available in an input group, zero bits are added (on the right) to form an integral number of 6-bit groups. Padding at the end of the data is performed using the "=" character. Since all base64 input is an integral number of octets, only the following cases can arise: (1) the final quantum of encoding input is an integral multiple of 24 bits; here, the final unit of encoded output will be an integral multiple of 4 characters with no "=" padding, (2) the final quantum of encoding input is exactly 8 bits; here, the final unit of encoded output will be two characters followed by two "=" padding characters, or (3) the final quantum of encoding input is exactly 16 bits; here, the final unit of encoded output will be three characters followed by one "=" padding character. --- Julian Satran wrote: > comments in text - julo > > --- Julian Satran wrote: > > > Sorry - It must have stayed in my pile. Your > formula > > is not correct. > > The correct one is (n*3 + 3)/4 > > Do you have any counterexamples to my formula? > > +++ 1 b64 digit is one byte - according to you it is > 0 +++ 1 b64 digit is impossible. It would need 3 '='s at the end and such a case is not mentioned in the RFC. It would not describe a full byte either. > Here are a couple for yours (unless I'm totally > messed up and don't know how base64 encoding works): > > 3 base64 digits with 1 equivalence sign at the > end should result in a 2-byte binary string. > According to your new formula: > (3 * 3 + 3) / 4 = 3. > > +++ 3 b64 digits (18 bits) are 3 bytes +++ No, it's case (3) in the quote from RFC I made above, these 18 bits describe 2 full bytes, not 3 incomplete ones. > 2 base64 digits with 2 equivalence signs at the > end should result in a 1-byte binary string. > According to your new formula: > (2 * 3 + 3) / 4 = 2. > > +++ incorrect - 2 digits is 12 bit is 2 bytes +++ No, it's case (2) in the quote from RFC I made above, these 12 bits describe 1 full byte, not 2 incomplete ones. You really have to imagine the encoding process when thinking about how to decode. Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be my employer's. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Wed Jun 12 19:25:13 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16610 for ; Wed, 12 Jun 2002 19:25:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CN54M04621 for ips-outgoing; Wed, 12 Jun 2002 19:05:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CN51w04615; Wed, 12 Jun 2002 19:05:01 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5CN4tUi072344; Thu, 13 Jun 2002 01:04:55 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5CN4sM75096; Thu, 13 Jun 2002 01:04:54 +0200 To: Black_David@emc.com Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI-12-95: header digest error clarification X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 13 Jun 2002 02:04:52 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 13/06/2002 02:04:54, Serialize complete at 13/06/2002 02:04:54 Content-Type: multipart/alternative; boundary="=_alternative 007E149BC2256BD6_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 007E149BC2256BD6_= Content-Type: text/plain; charset="us-ascii" it is already there - for a while - Julo Black_David@emc.com Sent by: owner-ips@ece.cmu.edu 06/13/2002 01:48 AM Please respond to Black_David To: ips@ece.cmu.edu cc: Subject: RE: iSCSI-12-95: header digest error clarification Catching up on email after vacation ... This thread seems to have reached the right conclusion - it might be worth adding a sentence instructing implementers not to scan the incoming data stream for headers as the result can be confused by (things that look like) headers in data if one is not careful. It's important to avoid being confused in this fashion, but it's not easy. An implementation that doesn't get this right has no alternative but to close the connection on a header digest error. I bring this up here because I've been through the same issue with the FCIP draft in great detail. It is possible to tell real headers from false headers by scanning far enough and knowing what the maximum PDU size is - appendix D of the FCIP draft contains an example of such an algorithm. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Friday, May 31, 2002 5:58 PM > To: pat_thaler@agilent.com; Julian_Satran@il.ibm.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI-12-95: header digest error clarification > > > Pat, > > From: > To: ; ; > > Cc: > Sent: Friday, May 31, 2002 2:48 PM > Subject: RE: iSCSI-12-95: header digest error clarification > > > > Mallikarjun, > > > > I like it, but it has the same problem I pointed out to > Paul. Sync and steering > > (at least as in FIM and as in some of the other candidates) > doesn't necessarily > > allow one to determine PDU length. What it does allow is > identifing the start > > of a header (which may not be the next header after the bad PDU). > > > > One could use: > > "... MUST either discard the header and all data up to the > beginning of a later PDU > > when that location can be ascertained by other means (such > as the operation > > of a sync and steering layer) or close the connection." > > I see your point. I like this text, but perhaps suggest > "reliably" before "ascertained" > in the above. > > Thanks. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > > > > or (to avoid a messy long sentence): > > "... MUST either discard the header and all data up to the > beginning of a later PDU > > or close the connection. Since the digest error indicates > that the length field of the > > header may have been corrupted, the location of the > beginning of a later PDU > > needs to be ascertained by other reliable means (such as > the operation of a sync and > > steering layer)" > > > > > > Pat > > > > -----Original Message----- > > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > > Sent: Friday, May 31, 2002 12:39 PM > > To: pat_thaler@agilent.com; Julian_Satran@il.ibm.com > > Cc: ips@ece.cmu.edu > > Subject: Re: iSCSI-12-95: header digest error clarification > > > > > > Pat, > > > > I think I understand your concern that Section 6.5 almost makes > > it look as if PDU length can be ascertained on header digest errors > > just as in other cases. > > > > Your first formulation is closer to the level of detail I > would prefer. > > I'd however suggest text with a couple of tweaks. > > > > "... MUST discard the PDU when its length can be reliably > ascertained by other > > means (such as the operation of a sync and steering layer), > or close the connection." > > > > This should leave enough room for other implementation > options, while > > pointing out the utility of the sync and steering layer > defined in the spec in > > this error scenario. > > > > Regards. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > > cbm@rose.hp.com > > > > > > ----- Original Message ----- > > From: > > To: ; > > Cc: > > Sent: Friday, May 31, 2002 10:28 AM > > Subject: RE: iSCSI-12-95: header digest error clarification > > > > > > > Julian, > > > > > > I'm not sure how explicit we have to be about the > solution, but right now > > > there is a MUST that isn't really achievable. It says one > MUST discard the > > > PDU but the implementation doesn't know what the PDU is. > One possibility is: > > > > > > ... MUST close the connection or attempt to find a valid > header and discard > > > everything from the bad header to the valid header. > > > > > > or > > > > > > ... MUST attempt to discard the PDU. However, if the > length field was > > > corrupted, the boundary of the PDU is unclear. If the > apparent header > > > following the discarded PDU also has a digest error, the > initiator/target > > > MAY close the connection or attempt to find a valid > header and discard > > > everything from the bad header to the valid header. > > > > > > This leaves the options open to the implementor but puts > the MUST in terms > > > of what can be accomplished. The only reason to get more > explicit is concern > > > about data corruption if a false valid header is found in > looking for a good > > > header, but that is extremely low probablility. > > > > > > Regards, > > > Pat > > > > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Friday, May 31, 2002 4:43 AM > > > To: pat_thaler@agilent.com > > > Cc: ips@ece.cmu.edu > > > Subject: RE: iSCSI-12-95: header digest error clarification > > > > > > > > > > > > Pat, > > > > > > I avoided being specific because an earlier format for > headers that I > > > suggested and that included separate parity for the > length field got > > > rejected > > > (too complex). and I felt that all the solutions that you > mention are > > > implementation options. > > > Do you think that we have to be explicit about them? > > > > > > Regards, > > > Julo > > > > > > > > > > > > pat_thaler@agilent.com > > > > > > > > > 05/31/2002 03:20 AM > > > Please respond to pat_thaler > > > > > > > > > > > > To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu > > > cc: > > > Subject: RE: iSCSI-12-95: header digest > error clarification > > > > > > > > > > > > > > > Julian, > > > > > > There was a brief discussion of the issues raised by > header digest errors, > > > but nothing has made it into 6.5 Digest Errors. > > > > > > 6.5 says that a target or initiator receiving a PDU with > a header digest > > > error MUST silently discard the PDU. > > > > > > The problem is that it can't do that. A header digest > error means that > > > DataSegmentLength may have been corrupted so the receiver > doesn't know > > > where the PDU ends and the next begins. > > > > > > Possible resolutions: > > > > > > If FIM is enabled, silently discard everything from the > bad header to > > > the next start of header pointed to by a marker. > > > > > > If FIM is not enabled, chose one (or more of the following): > > > Assume that the DataSegmentLength is correct and check to > see if a > > > valid header including a valid header digest and CmdSN > begins at the > > > point indicated by the length. If it does, then drop the PDU as > > > indicated by the DataSegmentLength and resume processing the next > > > PDU. If the next header doesn't check, close the > connection or use the > > > next technique. > > > Downside: This entails a small risk that the > DataSegmentLength was wrong > > > but unluckily pointed into a part of the data stream that looked > > > like a valid header. Also, there may not be a next header to check > > > immediately so one may have to wait for an indeterminate > time before > > > closing this out. > > > > > > Search the data stream for a valid header. This gets kind of ugly > > > because headers are 48 bytes long (or longer with AHS) > but can start > > > every 4 bytes so one has check overlapping sets of bytes for a > > > correct CRC which either means it will be slow or one will need > > > multiple CRC checkers. Also, this has a significantly higher risk > > > of finding a false valid header. Therefore, this recovery method > > > should not be allowed. > > > > > > Close the connection. > > > > > > Regards, > > > Pat > > > > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Wednesday, May 29, 2002 3:02 PM > > > To: ips@ece.cmu.edu > > > Subject: iSCSI-12-95 > > > > > > > > > 12-95 is out. > > > It has the latest wording on security and text > negotiation (including the > > > spanning). > > > > > > Still to go - text fixes in chapter 11. > > > > > > Julo > > > > > > > > > > > > > > > --=_alternative 007E149BC2256BD6_= Content-Type: text/html; charset="us-ascii"
it is already there - for a while - Julo


Black_David@emc.com
Sent by: owner-ips@ece.cmu.edu

06/13/2002 01:48 AM
Please respond to Black_David

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        RE: iSCSI-12-95: header digest error clarification

       


Catching up on email after vacation ...

This thread seems to have reached the right conclusion - it
might be worth adding a sentence instructing implementers not
to scan the incoming data stream for headers as the result can
be confused by (things that look like) headers in data if one
is not careful.  It's important to avoid being confused in this
fashion, but it's not easy.  An implementation that doesn't
get this right has no alternative but to close the connection
on a header digest error.

I bring this up here because I've been through the same issue
with the FCIP draft in great detail.  It is possible to tell
real headers from false headers by scanning far enough and
knowing what the maximum PDU size is - appendix D of the FCIP
draft contains an example of such an algorithm.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
black_david@emc.com         Cell: +1 (978) 394-7754
---------------------------------------------------


> -----Original Message-----
> From: Mallikarjun C. [mailto:cbm@rose.hp.com]
> Sent: Friday, May 31, 2002 5:58 PM
> To: pat_thaler@agilent.com; Julian_Satran@il.ibm.com
> Cc: ips@ece.cmu.edu
> Subject: Re: iSCSI-12-95: header digest error clarification
>
>
> Pat,
>
> From: <pat_thaler@agilent.com>
> To: <cbm@rose.hp.com>; <pat_thaler@agilent.com>;
> <Julian_Satran@il.ibm.com>
> Cc: <ips@ece.cmu.edu>
> Sent: Friday, May 31, 2002 2:48 PM
> Subject: RE: iSCSI-12-95: header digest error clarification
>
>
> > Mallikarjun,
> >
> > I like it, but it has the same problem I pointed out to
> Paul. Sync and steering
> > (at least as in FIM and as in some of the other candidates)
> doesn't necessarily
> > allow one to determine PDU length. What it does allow is
> identifing the start
> > of a header (which may not be the next header after the bad PDU).
> >
> > One could use:
> > "... MUST either discard the header and all data up to the
> beginning of a later PDU
> > when that location can be ascertained by other means (such
> as the operation
> > of a sync and steering layer) or close the connection."
>
> I see your point.  I like this text, but perhaps suggest
> "reliably" before "ascertained"
> in the above.
>
> Thanks.
> --
> Mallikarjun
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions
> Hewlett-Packard MS 5668
> Roseville CA 95747
> cbm@rose.hp.com
>
> >
> > or (to avoid a messy long sentence):
> > "... MUST either discard the header and all data up to the
> beginning of a later PDU
> > or close the connection. Since the digest error indicates
> that the length field of the
> > header may have been corrupted, the location of the
> beginning of a later PDU
> > needs to be ascertained by other reliable means (such as
> the operation of a sync and
> > steering layer)"
> >
> >
> > Pat
> >
> > -----Original Message-----
> > From: Mallikarjun C. [mailto:cbm@rose.hp.com]
> > Sent: Friday, May 31, 2002 12:39 PM
> > To: pat_thaler@agilent.com; Julian_Satran@il.ibm.com
> > Cc: ips@ece.cmu.edu
> > Subject: Re: iSCSI-12-95: header digest error clarification
> >
> >
> > Pat,
> >
> > I think I understand your concern that Section 6.5 almost makes
> > it look as if PDU length can be ascertained on header digest errors
> > just as in other cases.
> >
> > Your first formulation is closer to the level of detail I
> would prefer.
> > I'd however suggest text with a couple of tweaks.
> >
> > "... MUST discard the PDU when its length can be reliably
> ascertained by other
> > means (such as the operation of a sync and steering layer),
> or close the connection."
> >
> > This should leave enough room for other implementation
> options, while
> > pointing out the utility of the sync and steering layer
> defined in the spec in
> > this error scenario.
> >
> > Regards.
> > --
> > Mallikarjun
> >
> > Mallikarjun Chadalapaka
> > Networked Storage Architecture
> > Network Storage Solutions
> > Hewlett-Packard MS 5668
> > Roseville CA 95747
> > cbm@rose.hp.com
> >
> >
> > ----- Original Message -----
> > From: <pat_thaler@agilent.com>
> > To: <Julian_Satran@il.ibm.com>; <pat_thaler@agilent.com>
> > Cc: <ips@ece.cmu.edu>
> > Sent: Friday, May 31, 2002 10:28 AM
> > Subject: RE: iSCSI-12-95: header digest error clarification
> >
> >
> > > Julian,
> > >  
> > > I'm not sure how explicit we have to be about the
> solution, but right now
> > > there is a MUST that isn't really achievable. It says one
> MUST discard the
> > > PDU but the implementation doesn't know what the PDU is.
> One possibility is:
> > >  
> > > ... MUST close the connection or attempt to find a valid
> header and discard
> > > everything from the bad header to the valid header.
> > >  
> > > or
> > >  
> > > ... MUST attempt to discard the PDU. However, if the
> length field was
> > > corrupted, the boundary of the PDU is unclear. If the
> apparent header
> > > following the discarded PDU also has a digest error, the
> initiator/target
> > > MAY close the connection or attempt to find a valid
> header and discard
> > > everything from the bad header to the valid header.
> > >  
> > > This leaves the options open to the implementor but puts
> the MUST in terms
> > > of what can be accomplished. The only reason to get more
> explicit is concern
> > > about data corruption if a false valid header is found in
> looking for a good
> > > header, but that is extremely low probablility.
> > >  
> > > Regards,
> > > Pat
> > >  
> > > -----Original Message-----
> > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > > Sent: Friday, May 31, 2002 4:43 AM
> > > To: pat_thaler@agilent.com
> > > Cc: ips@ece.cmu.edu
> > > Subject: RE: iSCSI-12-95: header digest error clarification
> > >
> > >
> > >
> > > Pat,
> > >
> > > I avoided being specific because an earlier format for
> headers that I
> > > suggested and that included separate parity for the
> length field got
> > > rejected
> > > (too complex). and I felt that all the solutions that you
> mention are
> > > implementation options.
> > > Do you think that we have to be explicit about them?
> > >
> > > Regards,
> > > Julo
> > >
> > >
> > >
> > > pat_thaler@agilent.com
> > >
> > >
> > > 05/31/2002 03:20 AM
> > > Please respond to pat_thaler
> > >
> > >
> > >        
> > >         To:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> > >         cc:        
> > >         Subject:        RE: iSCSI-12-95: header digest
> error clarification
> > >
> > >        
> > >
> > >
> > > Julian,
> > >
> > > There was a brief discussion of the issues raised by
> header digest errors,
> > > but nothing has made it into 6.5 Digest Errors.
> > >
> > > 6.5 says that a target or initiator receiving a PDU with
> a header digest
> > > error MUST silently discard the PDU.
> > >
> > > The problem is that it can't do that. A header digest
> error means that
> > > DataSegmentLength may have been corrupted so the receiver
> doesn't know
> > > where the PDU ends and the next begins.
> > >
> > > Possible resolutions:
> > >
> > > If FIM is enabled, silently discard everything from the
> bad header to
> > > the next start of header pointed to by a marker.
> > >
> > > If FIM is not enabled, chose one (or more of the following):
> > > Assume that the DataSegmentLength is correct and check to
> see if a
> > > valid header including a valid header digest and CmdSN
> begins at the
> > > point indicated by the length. If it does, then drop the PDU as
> > > indicated by the DataSegmentLength and resume processing the next
> > > PDU. If the next header doesn't check, close the
> connection or use the
> > > next technique.
> > > Downside: This entails a small risk that the
> DataSegmentLength was wrong
> > > but unluckily pointed into a part of the data stream that looked
> > > like a valid header. Also, there may not be a next header to check
> > > immediately so one may have to wait for an indeterminate
> time before
> > > closing this out.
> > >
> > > Search the data stream for a valid header. This gets kind of ugly
> > > because headers are 48 bytes long (or longer with AHS)
> but can start
> > > every 4 bytes so one has check overlapping sets of bytes for a
> > > correct CRC which either means it will be slow or one will need
> > > multiple CRC checkers. Also, this has a significantly higher risk
> > > of finding a false valid header. Therefore, this recovery method
> > > should not be allowed.
> > >
> > > Close the connection.
> > >
> > > Regards,
> > > Pat
> > >
> > > -----Original Message-----
> > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > > Sent: Wednesday, May 29, 2002 3:02 PM
> > > To: ips@ece.cmu.edu
> > > Subject: iSCSI-12-95
> > >
> > >
> > > 12-95 is out.
> > > It has the latest wording on security and text
> negotiation (including the
> > > spanning).
> > >
> > > Still to go - text fixes in chapter 11.
> > >
> > > Julo
> > >
> > >
> > >
> > >
> >
>


--=_alternative 007E149BC2256BD6_=-- From owner-ips@ece.cmu.edu Wed Jun 12 19:43:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16915 for ; Wed, 12 Jun 2002 19:43:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CNYEI05987 for ips-outgoing; Wed, 12 Jun 2002 19:34:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13702.mail.yahoo.com (web13702.mail.yahoo.com [216.136.175.135]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g5CNYCw05980 for ; Wed, 12 Jun 2002 19:34:12 -0400 (EDT) Message-ID: <20020612233411.45125.qmail@web13702.mail.yahoo.com> Received: from [192.55.52.4] by web13702.mail.yahoo.com via HTTP; Wed, 12 Jun 2002 16:34:11 PDT Date: Wed, 12 Jun 2002 16:34:11 -0700 (PDT) From: Martins Krikis Subject: Re: base64 byte-length formula To: Julian Satran Cc: ips@ece.cmu.edu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- Julian Satran wrote: > The difference between our formulas is that I > (mistakenly) took 1 digit as > a possible string (or 5, 9 etc.) > For those you need the +3 TERM. > > For all the good length 2,3,4 6,7,8 etc the two > formulas are equivalent. No they are not. They are only equivalent for n = 0 (mod 4). So I'm still insisting that n * 3 / 4 is the simplest right formula. Martins Krikis, Intel Corp. Disclaimer: these are my opinions and may not be Intel's. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Wed Jun 12 19:54:08 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17031 for ; Wed, 12 Jun 2002 19:54:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CNIjk05295 for ips-outgoing; Wed, 12 Jun 2002 19:18:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CNIiw05289 for ; Wed, 12 Jun 2002 19:18:44 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5CNIZe24947; Wed, 12 Jun 2002 19:18:35 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g5CNIY723814; Wed, 12 Jun 2002 19:18:34 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 19:17:03 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564BF41@CORPMX14> From: Black_David@emc.com To: cbm@rose.hp.com Cc: ips@ece.cmu.edu Subject: RE: IPS schedule for Yokohama Date: Wed, 12 Jun 2002 19:17:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > David, > > Can you please comment on the IPS schedule for Yokohama? > > I know that the agenda is open to changes, but a confirmation of > the IPS meetings in Yokohama and a rough agenda if so, would help. We're on the agenda: http://www.ietf.org/meetings/agenda_54.txt As of this writing, IPS is meeting Monday evening and Tuesday afternoon. We requested less time 3.5 hours vs. 5 in the past) because a lot of our protocols are close to done. Elizabeth and I will start to work on the IPS agenda in the near future. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Jun 12 19:54:46 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17081 for ; Wed, 12 Jun 2002 19:54:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CNRof05694 for ips-outgoing; Wed, 12 Jun 2002 19:27:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CNRmw05688 for ; Wed, 12 Jun 2002 19:27:48 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 19:27:41 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564BF42@CORPMX14> From: Black_David@emc.com To: ssenum@cisco.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: 7.2.1 CHAP Considerations (12-98) Date: Wed, 12 Jun 2002 19:26:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Yes, my intent was to modify the draft text to include the "essential condition" described below. --David > -----Original Message----- > From: Steve Senum [mailto:ssenum@cisco.com] > Sent: Wednesday, June 12, 2002 6:14 PM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: 7.2.1 CHAP Considerations (12-98) > > > David, > > What you state would be better, but that is > not what the current text (as of 12-98) says. > > Steve Senum > > Black_David@emc.com wrote: > > > > I think the essential condition here is that the > > "do not continue if secret is shorter than 96 bits" > > criteria should apply only to implementations that > > know and use the secret (i.e., generators of CHAP > > responses, and recipients of those responses that > > do their own verification as opposed to outsourcing > > that verification to something like a RADIUS server). > > > > Thanks, > > --David > > --------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > > black_david@emc.com Cell: +1 (978) 394-7754 > > --------------------------------------------------- > > > > > -----Original Message----- > > > From: Steve Senum [mailto:ssenum@cisco.com] > > > Sent: Wednesday, June 12, 2002 3:58 PM > > > To: Julian Satran > > > Cc: ietf-ips > > > Subject: Re: iSCSI: 7.2.1 CHAP Considerations (12-98) > > > > > > > > > Julian, > > > > > > In the case where an iSCSI Target is authenticating > > > an iSCSI Initiator, the Target sends a CHAP > > > challenge and identifier, and the Initiator sends > > > back a CHAP response and username. > > > > > > In the case were the Target is using the RADIUS > > > protocol, these four pieces of information are > > > sent by the Target to a RADIUS server, which > > > simply gives an accept or reject reply. The target > > > never has access to the CHAP secret (which is good), > > > hence no check can be made on its length. > > > > > > Regards, > > > Steve Senum > > > > > > Julian Satran wrote: > > > > > > > > can you elaborate? Julo > > > > > > > > Steve Senum > > > > Sent by: owner-ips@ece.cmu.edu To: ietf-ips > > > > > > > > 06/12/2002 09:32 PM cc: > > > > Please respond to Steve Senum Subject: > > > iSCSI: 7.2.1 CHAP > > > > Considerations (12-98) > > > > > > > > > > > > > > > > I have a concern over the wording of the > > > > following text from section 7.2.1 (12-98 version): > > > > > > > > When CHAP is used with secret shorter than 96 bits, > > > > a compliant implementation MUST NOT continue with > > > > the login unless it can verify that IPsec encryption > > > > is being used to protect the connection. > > > > > > > > I know the above is attempt to "put some teeth" into > > > > the requirements to make the use of CHAP secure, > > > > but I believe there are common cases where the > > > > length of the CHAP secret cannot be verified, such > > > > as when a RADIUS server is being used. > > > > > > > > Regards, > > > > Steve Senum > > > > From owner-ips@ece.cmu.edu Wed Jun 12 19:58:36 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17146 for ; Wed, 12 Jun 2002 19:58:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CNf0906285 for ips-outgoing; Wed, 12 Jun 2002 19:41:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CNexw06280 for ; Wed, 12 Jun 2002 19:40:59 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 7722D9E78; Wed, 12 Jun 2002 17:40:58 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 027C91CF; Wed, 12 Jun 2002 17:40:58 -0600 (MDT) Received: from 130.29.152.143 by axcsbh1.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 12 Jun 2002 17:40:58 -0600 Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 17:40:57 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E444C@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Eddy Quicksall , "Robert D. Russell" , Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: MaxRecvPDULength question Date: Wed, 12 Jun 2002 17:40:57 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Robert, The reason for size rather than length in the name is that the other parameters limiting length/size of data transfers use size (MaxBurstSize and FirstBurstSize). I don't really care whether "size" or "length" is used to describe the number of bytes sent, but we should consistantly use the same term for the same meaning. The rest of the document uses a mix of length and size. Length appears more frequently (largely because of its use in field names in packet formats), but size predominates in the key names where a change affects implementations. Regards, Pat -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Monday, June 10, 2002 1:58 PM To: Robert D. Russell; Julian_Satran@il.ibm.com; ips@ece.cmu.edu Subject: RE: MaxRecvPDULength question Below it says: "The DataSegmentLength in a Text *Request* MUST NOT exceed the iSCSI initiator's MaxRecvDataSegmentLength (a per connection and per direction negotiated parameter)." But it seems it should say "Response". Eddy -----Original Message----- From: Robert D. Russell [mailto:rdr@io.iol.unh.edu] Sent: Monday, June 10, 2002 3:43 AM To: Julian_Satran@il.ibm.com; ips@ece.cmu.edu Subject: Re: MaxRecvPDULength question Julian: It has been stated several times that at this late stage we should not be requesting changes that are just preferences. Nevertheless, due to apparent misunderstandings of its meaning, the key named MaxRecvPDULength in draft 12 is apparently going to have its name changed in draft 13. Fine. No problem. However, to remove all possibility of future misunderstandings, why don't we give it a name that says precisely what it is: MaxRecvDataSegmentLength That way, the first sentence in the third paragraph of section 9.7.1 would begin: "DataSegmentLength MUST not exceed MaxRecvDataSegmentLength for the direction it is sent ..." which seems to me to be the classic definition of a maximum. The issue of changing the name from MaxRecvPDULength started with an e-mail sent by Luben Tuikov on 21 May (who, by the way, did NOT want to change the name, just its meaning), and was followed by a short flurry of e-mails under the thread "MaxRecvPDULength question". Some of the names suggested on that thread were: MaxRecvDataLength (21 May by Paul Konig) MaxRecvDataSegmentSize (21 May by Pat Thaler) MaxRecvDataSegSize (21 May by Pat Thaler) MaxRecvPDUDataSize (22 May by Pat Thaler) and what got into the draft was this last suggestion by Pat. I don't believe there was a consensus for this choice (probably, as was stated by Pat several times, because most people don't really see the need for a renaming and didn't bother to participate in the thread). Therefore, I would ask you to reconsider the new name and ask for consensus on the new choice. I believe the name MaxRecvDataSegmentLength is so closely linked to the name DataSegmentLength that its meaning should be clear to even a first-time reader, especially given the statement in section 9.7.1 quoted above. Furthermore, there clearly is the concept of DataSegmentLength elsewhere in the standard -- every PDU has a DataSegmentLength field. I could find no concept of PDUDataSize (or even "data size") elsewhere in the current draft. Whether or not this renaming happens (again), I believe there should be the following rewordings to be more precise in order to avoid any ambiguities and/or future misinterpretations. The first sentence in section 9.10.5 should be changed to read: "The DataSegmentLength in a Text Request MUST NOT exceed the iSCSI target's MaxRecvDataSegmentLength (a per connection and per direction negotiated parameter)." and the first sentence in section 9.11.6 should be changed to read: "The DataSegmentLength in a Text Request MUST NOT exceed the iSCSI initiator's MaxRecvDataSegmentLength (a per connection and per direction negotiated parameter)." Finally, two sentences in section 11.13 should be changed to read: "The initiator or target declares the maximum DataSegmentLength in bytes it can receive in an iSCSI PDU." and "The transmitter (initiator or target) is required to send PDUs with a DataSegmentLength not exceeding MaxRecvDataSegmentLength of the receiver." Thank you for your consideration, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Wed Jun 12 19:58:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17159 for ; Wed, 12 Jun 2002 19:58:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CNPbm05612 for ips-outgoing; Wed, 12 Jun 2002 19:25:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CNPZw05608 for ; Wed, 12 Jun 2002 19:25:35 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5CNPSML023678; Thu, 13 Jun 2002 01:25:28 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5CNPSr25264; Thu, 13 Jun 2002 01:25:28 +0200 To: Martins Krikis Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: base64 byte-length formula X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 13 Jun 2002 02:25:28 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 13/06/2002 02:25:28, Serialize complete at 13/06/2002 02:25:28 Content-Type: multipart/alternative; boundary="=_alternative 008080D9C2256BD6_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 008080D9C2256BD6_= Content-Type: text/plain; charset="us-ascii" The difference between our formulas is that I (mistakenly) took 1 digit as a possible string (or 5, 9 etc.) For those you need the +3 TERM. For all the good length 2,3,4 6,7,8 etc the two formulas are equivalent. Julo Martins Krikis 06/13/2002 01:56 AM Please respond to Martins Krikis To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: base64 byte-length formula Sorry, I had missed to CC the previous to the list but I'm doing it with this. The way you understand base64 is not the way I understand it. Can somebody please chime in and set the record straight? Here is the relevant text from RFC 2045, describing the base64 encoding process. We are, of course, talking about decoding in these length-calculation formulas. More of my comments further down in text. Special processing is performed if fewer than 24 bits are available at the end of the data being encoded. A full encoding quantum is always completed at the end of a body. When fewer than 24 input bits are available in an input group, zero bits are added (on the right) to form an integral number of 6-bit groups. Padding at the end of the data is performed using the "=" character. Since all base64 input is an integral number of octets, only the following cases can arise: (1) the final quantum of encoding input is an integral multiple of 24 bits; here, the final unit of encoded output will be an integral multiple of 4 characters with no "=" padding, (2) the final quantum of encoding input is exactly 8 bits; here, the final unit of encoded output will be two characters followed by two "=" padding characters, or (3) the final quantum of encoding input is exactly 16 bits; here, the final unit of encoded output will be three characters followed by one "=" padding character. --- Julian Satran wrote: > comments in text - julo > > --- Julian Satran wrote: > > > Sorry - It must have stayed in my pile. Your > formula > > is not correct. > > The correct one is (n*3 + 3)/4 > > Do you have any counterexamples to my formula? > > +++ 1 b64 digit is one byte - according to you it is > 0 +++ 1 b64 digit is impossible. It would need 3 '='s at the end and such a case is not mentioned in the RFC. It would not describe a full byte either. > Here are a couple for yours (unless I'm totally > messed up and don't know how base64 encoding works): > > 3 base64 digits with 1 equivalence sign at the > end should result in a 2-byte binary string. > According to your new formula: > (3 * 3 + 3) / 4 = 3. > > +++ 3 b64 digits (18 bits) are 3 bytes +++ No, it's case (3) in the quote from RFC I made above, these 18 bits describe 2 full bytes, not 3 incomplete ones. > 2 base64 digits with 2 equivalence signs at the > end should result in a 1-byte binary string. > According to your new formula: > (2 * 3 + 3) / 4 = 2. > > +++ incorrect - 2 digits is 12 bit is 2 bytes +++ No, it's case (2) in the quote from RFC I made above, these 12 bits describe 1 full byte, not 2 incomplete ones. You really have to imagine the encoding process when thinking about how to decode. Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be my employer's. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com --=_alternative 008080D9C2256BD6_= Content-Type: text/html; charset="us-ascii"
The difference between our formulas is that I (mistakenly) took 1 digit as a possible string (or 5, 9 etc.)
For those you need the +3 TERM.

For all the good length 2,3,4 6,7,8 etc the two formulas are equivalent.

Julo



Martins Krikis <mkrikis@yahoo.com>

06/13/2002 01:56 AM
Please respond to Martins Krikis

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        Re: base64 byte-length formula

       


Sorry, I had missed to CC the previous to the list
but I'm doing it with this. The way you understand
base64 is not the way I understand it. Can somebody
please chime in and set the record straight?

Here is the relevant text from RFC 2045, describing
the base64 encoding process. We are, of course,
talking about decoding in these length-calculation
formulas. More of my comments further down in text.

<RFC 2045 QUOTE>
 Special processing is performed if fewer
 than 24 bits are available
 at the end of the data being encoded.  
 A full encoding quantum is
 always completed at the end of a body.  
 When fewer than 24 input bits
 are available in an input group, zero
 bits are added (on the right)
 to form an integral number of 6-bit groups.  
 Padding at the end of
 the data is performed using the "=" character.
 Since all base64
 input is an integral number of octets,
 only the following cases can
 arise: (1) the final quantum of encoding
 input is an integral
 multiple of 24 bits; here, the final
 unit of encoded output will be
 an integral multiple of 4 characters
 with no "=" padding, (2) the
 final quantum of encoding input is
 exactly 8 bits; here, the final
 unit of encoded output will be two
 characters followed by two "="
 padding characters, or (3) the final
 quantum of encoding input is
 exactly 16 bits; here, the final
 unit of encoded output will be three
 characters followed by one "=" padding
 character.
</RFC 2045 QUOTE>

--- Julian Satran <Julian_Satran@il.ibm.com> wrote:

> comments in text - julo
>
> --- Julian Satran <Julian_Satran@il.ibm.com> wrote:
>
> > Sorry - It must have stayed in my pile. Your
> formula
> > is not correct.
> > The correct one is (n*3 + 3)/4
>
> Do you have any counterexamples to my formula?
>
> +++ 1 b64 digit is one byte - according to you it is
> 0 +++

1 b64 digit is impossible. It would need 3 '='s
at the end and such a case is not mentioned in
the RFC. It would not describe a full byte either.

> Here are a couple for yours (unless I'm totally
> messed up and don't know how base64 encoding works):
>
> 3 base64 digits with 1 equivalence sign at the
> end should result in a 2-byte binary string.
> According to your new formula:
> (3 * 3 + 3) / 4 = 3.
>
> +++ 3 b64 digits (18 bits) are 3 bytes +++

No, it's case (3) in the quote from RFC I made
above, these 18 bits describe 2 full bytes,
not 3 incomplete ones.

> 2 base64 digits with 2 equivalence signs at the
> end should result in a 1-byte binary string.
> According to your new formula:
> (2 * 3 + 3) / 4 = 2.
>
> +++ incorrect - 2 digits is 12 bit is 2 bytes +++

No, it's case (2) in the quote from RFC I made
above, these 12 bits describe 1 full byte, not
2 incomplete ones.

You really have to imagine the encoding process
when thinking about how to decode.

Martins Krikis, Intel Corp.

Disclaimer: these opinions are mine and
           may not be my employer's.


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--=_alternative 008080D9C2256BD6_=-- From owner-ips@ece.cmu.edu Wed Jun 12 20:37:52 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17682 for ; Wed, 12 Jun 2002 20:37:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CNuag06966 for ips-outgoing; Wed, 12 Jun 2002 19:56:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CNuYw06960; Wed, 12 Jun 2002 19:56:34 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5CNuRUi089856; Thu, 13 Jun 2002 01:56:27 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5CNuRM99468; Thu, 13 Jun 2002 01:56:27 +0200 To: Martins Krikis Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: base64 byte-length formula X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 13 Jun 2002 02:56:26 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 13/06/2002 02:56:27, Serialize complete at 13/06/2002 02:56:27 Content-Type: multipart/alternative; boundary="=_alternative 0082C452C2256BD6_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0082C452C2256BD6_= Content-Type: text/plain; charset="us-ascii" I said already that your formula is correct. I do not understand why you say that the 2 formulas are not equivalent for all the lengths (good aor bad)? I would appreciate if you respond although you don't have to. Julo Martins Krikis Sent by: owner-ips@ece.cmu.edu 06/13/2002 02:34 AM Please respond to Martins Krikis To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: base64 byte-length formula --- Julian Satran wrote: > The difference between our formulas is that I > (mistakenly) took 1 digit as > a possible string (or 5, 9 etc.) > For those you need the +3 TERM. > > For all the good length 2,3,4 6,7,8 etc the two > formulas are equivalent. No they are not. They are only equivalent for n = 0 (mod 4). So I'm still insisting that n * 3 / 4 is the simplest right formula. Martins Krikis, Intel Corp. Disclaimer: these are my opinions and may not be Intel's. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com --=_alternative 0082C452C2256BD6_= Content-Type: text/html; charset="us-ascii"
I said already that your formula is correct.
I do not understand why you say that the 2 formulas are not equivalent for all the lengths (good aor bad)?
I would appreciate if you respond although you don't have to.

Julo


Martins Krikis <mkrikis@yahoo.com>
Sent by: owner-ips@ece.cmu.edu

06/13/2002 02:34 AM
Please respond to Martins Krikis

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        Re: base64 byte-length formula

       



--- Julian Satran <Julian_Satran@il.ibm.com> wrote:

> The difference between our formulas is that I
> (mistakenly) took 1 digit as
> a possible string (or 5, 9 etc.)
> For those you need the +3 TERM.
>
> For all the good length 2,3,4 6,7,8 etc the two
> formulas are equivalent.

No they are not. They are only equivalent for
n = 0 (mod 4). So I'm still insisting that
n * 3 / 4 is the simplest right formula.

Martins Krikis, Intel Corp.

Disclaimer: these are my opinions and
           may not be Intel's.


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--=_alternative 0082C452C2256BD6_=-- From owner-ips@ece.cmu.edu Wed Jun 12 20:49:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18028 for ; Wed, 12 Jun 2002 20:49:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5D0cpc08861 for ips-outgoing; Wed, 12 Jun 2002 20:38:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5D0cow08857 for ; Wed, 12 Jun 2002 20:38:50 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 20:37:14 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564BF44@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSCSI: Implementation identification keys Date: Wed, 12 Jun 2002 20:37:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk The signal to noise ratio on the X-keys thread is getting rather low, hence the deliberate change of subject. A major problem is that there are two motivations for the proposed keys, as Bill Studenmund summarized: > A) makes it easy to identify vendor/product/rev. All you have to do is > capture a session (tcpdump/ethereal), and you have it. Info is in one > place. > > B) Identify system on other side of connection/session to turn on/off > quirk support. A) is a fine motivation, but B) is problematic, and it appears to be the more important one from discussion on the list. I'm rather uncomfortable surrendering to this motivation this early in the game. This position is similar to the reason why we had to stop the practice of incrementing the iSCSI version number every time the revision number of the draft changed -- I think it's still the case that the right thing to do in the IETF process is to aim for interoperability in the standard rather than put in support for divergent implementations. That said, the "quirk support" may be inevitable, and the quirks are hard to stamp out once one goes down that path. For example, EMC's support matrix (published on our web site) includes quirk support for SCSI and Fibre Channel (and yes, there are a number of parallel SCSI quirks, even though parallel SCSI has been around for a very long time). I think the use of X- keys and shoehorning this into the main iSCSI draft at this late stage is inappropriate - IMHO, this should be done right or not at all. I believe the best course of action would be for those interested in this sort of feature (and you know who you are from the list discussion) to write up a separate draft introducing new keys that we can consider separately. At this juncture, it appears to me that insisting on having this in the main iSCSI draft is likely to result in delay - based on the list discussion, I think rough consensus is going to be hard to reach on this one, hence the desire for a second draft that can take as long as it needs. This gets to the next point I wanted to get to. IETF process does not require rewriting an entire RFC in order to make changes - a new RFC can update an existing RFC, and hence it's possible to make small changes fairly quickly (without reopening everything in the RFC for changes). Of course "fairly quickly" depends on there being rough consensus for the changes ... but there's no need to go through resolution of everything that anyone might want to change/improve/remove/etc. in the main iSCSI document just to make minor changes (e.g., for interoperability problems), and iSCSI was designed so that logon negotiation would be extensible. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Jun 12 20:53:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18076 for ; Wed, 12 Jun 2002 20:53:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5D0XTg08573 for ips-outgoing; Wed, 12 Jun 2002 20:33:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5D0XRw08568; Wed, 12 Jun 2002 20:33:27 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 91E4FFE7; Wed, 12 Jun 2002 18:33:26 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 34DD21EE; Wed, 12 Jun 2002 18:33:26 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 12 Jun 2002 18:33:23 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 18:33:23 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E445F@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com, mkrikis@yahoo.com Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: base64 byte-length formula Date: Wed, 12 Jun 2002 18:33:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, The formula in 12-97 is: ((the integer part of)((n+3)*3/4) - m) Martins formula 3*3/4 where / indictates integer divide. The encoding of 1 octet in base64 results in 2 characters plus 2 equal signs. n=2, m=2. Martins formula = 2 *3/4 = 1 (truncated to an integer) right answer integer part of ((2+3)*3/4)-1 = (integer part of 15/4) - 2 = 3 - 2 = 1 right answer The encoding of 2 octets in base64 results in 3 characters plus one equal sign. n=3, m=1. Martins formula = 3 *3/4 = 2 (truncated to an integer) right answer integer part of ((3+3)*3/4)-1 = (integer part of 18/4) -1 = 4 - 1 = 3 wrong answer The encoding of 3 octets in base64 results in 4 characters plus no equal sign. n=4, m=0. Martins formula = 4 *3/4 = 3 (truncated to an integer) right answer integer part of ((4+3)*3/4)-1 = (integer part of 21/4) -0 = 5 - 1 = 4 wrong answer Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 4:56 PM To: Martins Krikis Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: base64 byte-length formula I said already that your formula is correct. I do not understand why you say that the 2 formulas are not equivalent for all the lengths (good aor bad)? I would appreciate if you respond although you don't have to. Julo Martins Krikis Sent by: owner-ips@ece.cmu.edu 06/13/2002 02:34 AM Please respond to Martins Krikis To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: base64 byte-length formula --- Julian Satran wrote: > The difference between our formulas is that I > (mistakenly) took 1 digit as > a possible string (or 5, 9 etc.) > For those you need the +3 TERM. > > For all the good length 2,3,4 6,7,8 etc the two > formulas are equivalent. No they are not. They are only equivalent for n = 0 (mod 4). So I'm still insisting that n * 3 / 4 is the simplest right formula. Martins Krikis, Intel Corp. Disclaimer: these are my opinions and may not be Intel's. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Wed Jun 12 21:18:13 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18358 for ; Wed, 12 Jun 2002 21:18:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5D0cGk08815 for ips-outgoing; Wed, 12 Jun 2002 20:38:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13708.mail.yahoo.com (web13708.mail.yahoo.com [216.136.175.141]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g5D0cEw08811 for ; Wed, 12 Jun 2002 20:38:15 -0400 (EDT) Message-ID: <20020613003814.73881.qmail@web13708.mail.yahoo.com> Received: from [192.55.52.4] by web13708.mail.yahoo.com via HTTP; Wed, 12 Jun 2002 17:38:14 PDT Date: Wed, 12 Jun 2002 17:38:14 -0700 (PDT) From: Martins Krikis Subject: Re: base64 byte-length formula To: Julian Satran Cc: ips@ece.cmu.edu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk > I do not understand why you say that the 2 formulas > are not equivalent for > all the lengths (good aor bad)? Because floor((n * 3 + 3) / 4) > floor(n * 3 / 4) for n such as 2, 3, 6, 7, etc. (Also for 1, 5, etc, but those are bad lengths.) BTW, my apologies for forgetting "iSCSI" in front of the subject line. Martins Krikis, Intel Corp. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Wed Jun 12 21:19:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18409 for ; Wed, 12 Jun 2002 21:19:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5D10mr09821 for ips-outgoing; Wed, 12 Jun 2002 21:00:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from med.corp.rhapsodynetworks.com (64-160-62-201.rhapsodynetworks.com [64.160.62.201] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5D10kw09814; Wed, 12 Jun 2002 21:00:46 -0400 (EDT) Received: by med.corp.rhapsodynetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 18:00:39 -0700 Message-ID: <45BEF1D68145D51186C100B0D0AABE659E017A@med.corp.rhapsodynetworks.com> From: Dennis Young To: "'Julian Satran'" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Date: Wed, 12 Jun 2002 18:00:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21275.BB736250" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21275.BB736250 Content-Type: text/plain; charset="iso-8859-1" Thanks to yours and others' explanation, now I am more clear, but I have another question: Based on your reply, and let me emphasize it by repeating the 4th paragraph on page 42 of draft 12-98: "... If any non-immediate unsolicited data are sent, the total unsolicited data MUST be either the negotiated amount or all the data if the total amount is less than the negotiated amount for unsolicited data. ..." With this rule, do we still need the F bit in the Data-out (both for the solicited and unsolicited Data-out)? The F bit seems redundant since the target has enough information to figure out the final unsolicited Data-out and the final solicited Data-out (based on the FirstBurstSize, Offset and DataSegmentLength in the Data-out, and the ExpectedDataTransferLength in the corresponding SCSI Write PDU). Thanks, Dennis -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 11:21 AM To: Dennis Young Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question You are wrong about waiting - read my previous text. You need unsolicited as the amount in one PDU may not be all you want. Julo Dennis Young Sent by: owner-ips@ece.cmu.edu 06/12/2002 08:49 PM Please respond to Dennis Young To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Are you saying that, for a session that has InitialR2T=No in effect, the initiator must send all its data as unsolicited first, up to the amount negotiated in FirstBurstSize, before it waits for a R2T from the target? Can you shed some light on why we need unsolicited Data-out PDU when there is ImmediateData, seems like they both serve the same purpose, having both of them only make the spec more complex. Thanks, -Dennis -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 10:19 AM To: Dennis Young Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question This is the reason why the initiator is required to send ALL unsolicited data (target can count on it and start sending R2Ts as soon as it sees the first header> Neither bandwidth nor latency are wasted. Julo Dennis Young 06/12/2002 08:05 PM Please respond to Dennis Young To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Julian, This leads me to a more interesting question. A session with InitialR2T=No in effect, i.e. unsolicited Data-out allowed, could cause unintended waste of bandwidth, depending on how fast the target sends our R2T in response to the SCSI Write. If the target sees the unsolicited Data-out PDU before building the R2T, then everything is fine. If the target doesn't see the unsolicited Data-out PDU before building the R2T, the R2T would request the same portion of data in the unsolicited Data-out, thus bandwidth is wasted. The question is, how can a target be smart about this? Should the target wait a moment for the possible unsolicited Data-out after receiving each SCSI Write, this sounds kludgy. Also, why do we need the unsolicited Data-out PDU feature when there is ImmediateData? Regards, Dennis -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 6:05 AM To: Dennis Young Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iscsi: unsolicited data question yes - julo Dennis Young Sent by: owner-ips@ece.cmu.edu 06/12/2002 06:20 AM Please respond to Dennis Young To: ips@ece.cmu.edu cc: Subject: iscsi: unsolicited data question I have a question which has been asked before, but I couldn't find a direct answer in the archive. The table on page 200 of draft 12 doesn't directly answer this question either. The first paragraph on page 36 of draft 12 says "Targets operate in either solicitied (R2T) data mode or unsolicited (non R2T) data mode." tells me that a target, at all times during a data sequence transfer, can be one or the other, but not both (non R2T for the initial data out, R2T for the remaining data). Is this correct? Thanks, Dennis ---snip from an old email dated 3/30/2001--- " Hi Julian Sorry if I'm covering old ground... Is it possible to use unsolicited data for the first burst and then request any remaining data using R2T? For example, if the target has a previously allocated buffer available (length defined by FirstBurstSize) for unsolicited data, then once the initiator has sent unsolicited data up to and including this amount then the remaining data (if any) can be requested using R2T once the target has the buffer space available. ...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail: matthewb@bri.hp.com " ------_=_NextPart_001_01C21275.BB736250 Content-Type: text/html; charset="iso-8859-1"
Thanks to yours and others' explanation, now I am more clear, but I have
another question:
 
Based on your reply, and let me emphasize it by repeating the 4th paragraph
on page 42 of draft 12-98:
    "... If any non-immediate unsolicited data are sent, the total unsolicited
    data MUST be either the negotiated amount or all the data if the total
    amount is less than the negotiated amount for unsolicited data. ..."
 
With this rule, do we still need the F bit in the Data-out (both for the solicited
and unsolicited Data-out)?  The F bit seems redundant since the target has
enough information to figure out the final unsolicited Data-out and the final 
solicited Data-out (based on the FirstBurstSize, Offset and DataSegmentLength
in the Data-out, and the ExpectedDataTransferLength in the corresponding
SCSI Write PDU). 
 
Thanks,
Dennis
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 12, 2002 11:21 AM
To: Dennis Young
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iscsi: unsolicited data question


You are wrong about waiting - read my previous text.
You need unsolicited as the amount in one PDU may not be all you want.

Julo


Dennis Young <dyoung@rhapsodynetworks.com>
Sent by: owner-ips@ece.cmu.edu

06/12/2002 08:49 PM
Please respond to Dennis Young

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
        Subject:        RE: iscsi: unsolicited data question

       


Are you saying that, for a session that has InitialR2T=No in effect, the initiator
must send all its data as unsolicited first, up to the amount negotiated in
FirstBurstSize, before it waits for a R2T from the target?
 
Can you shed some light on why we need unsolicited Data-out PDU when there
is ImmediateData, seems like they both serve the same purpose, having both of
them only make the spec more complex.
 
Thanks,
-Dennis
 
 -----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 12, 2002 10:19 AM
To: Dennis Young
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iscsi: unsolicited data question


This is the reason why the initiator is required to send ALL unsolicited data (target can count on it and start sending R2Ts as soon as it sees the first header>
Neither bandwidth nor latency are wasted.

Julo

Dennis Young <dyoung@rhapsodynetworks.com>

06/12/2002 08:05 PM
Please respond to Dennis Young

       
       To:        Julian Satran/Haifa/IBM@IBMIL
       cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
       Subject:        RE: iscsi: unsolicited data question

     



Julian,
 
This leads me to a more interesting question.
A session with InitialR2T=No in effect, i.e. unsolicited Data-out
allowed, could cause unintended waste of bandwidth, depending on
how fast the target sends our R2T in response to the SCSI Write.
 
If the target sees the unsolicited Data-out PDU before building the
R2T, then everything is fine.
If the target doesn't see the unsolicited Data-out PDU before building
the R2T, the R2T would request the same portion of data in the
unsolicited Data-out, thus bandwidth is wasted.
 
The question is, how can a target be smart about this?
Should the target wait a moment for the possible unsolicited Data-out
after receiving each SCSI Write, this sounds kludgy.
 
Also, why do we need the unsolicited Data-out PDU feature when
there is ImmediateData?
 
Regards,
Dennis
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 12, 2002 6:05 AM
To: Dennis Young
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iscsi: unsolicited data question


yes - julo
Dennis Young <dyoung@rhapsodynetworks.com>
Sent by: owner-ips@ece.cmu.edu

06/12/2002 06:20 AM
Please respond to Dennis Young

       
      To:        ips@ece.cmu.edu
      cc:        
      Subject:        iscsi: unsolicited data question

     




I have a question which has been asked before, but I couldn't find a direct
answer in the archive.  The table on page 200 of draft 12 doesn't directly
answer this question either.

The first paragraph on page 36 of draft 12 says "Targets operate in either
solicitied (R2T) data mode or unsolicited (non R2T) data mode."
tells me that a target, at all times during a data sequence transfer, can be

one or the other, but not both (non R2T for the initial data out, R2T for
the
remaining data).  Is this correct?

Thanks,
Dennis

---snip from an old email dated 3/30/2001---

" Hi Julian
Sorry if I'm covering old ground... Is it possible to use unsolicited data
for the first burst and then request any remaining data using R2T? For
example, if the target has a previously allocated buffer available (length
defined by FirstBurstSize) for unsolicited data, then once the initiator has
sent unsolicited data up to and including this amount then the remaining
data (if any) can be requested using R2T once the target has the buffer
space available.
...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail:
matthewb@bri.hp.com "






------_=_NextPart_001_01C21275.BB736250-- From owner-ips@ece.cmu.edu Wed Jun 12 21:39:53 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18677 for ; Wed, 12 Jun 2002 21:39:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5D1EKF10451 for ips-outgoing; Wed, 12 Jun 2002 21:14:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5D1D3w10377 for ; Wed, 12 Jun 2002 21:13:03 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 21:12:57 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564BF46@CORPMX14> From: Black_David@emc.com To: mmorrison@istor.com Cc: ips@ece.cmu.edu Subject: RE: target reset Date: Wed, 12 Jun 2002 21:11:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > Sorry for being obtuse, but I don't understand your response. > > Are you saying 'yes, cancel all operations == clear task set > description' > - or - > 'yes, the statement has another meaning' > I believe Julian meant the former accompanied by a pointer to SAM-2 for details on what happens to operations from initiators other than the one that sent the task management request. --David > On Wed, 2002-06-12 at 09:15, Julian Satran wrote: > yes it means cancel all operations - look for the fine differences > on cancelling other initiators tasks. > That is a SAM issue that we don't want to touch! > > Julo > > > > > Michael Morrison > > Sent by: > owner-ips@ece.cmu.edu > > 06/12/2002 02:04 AM > Please respond to > Michael Morrison > > > To: > iSCSI > > cc: > Subject: > target reset > > > > > On page 148 of draft 12-97, in the paragraph ... > > "For the TARGET WARM RESET and TARGET COLD RESET functions, the > target > cancels all pending operations. Both functions are equivalent to > the > Target Reset function specified by [SAM2]. They can affect many > other > initiators" > > In these cases, SAM2 refers to Logical Unit Reset, which refers to > Aborting Tasks. > > This implies to me that TARGET RESET (WARM or COLD) is > equivalent to > CLEAR TASK SET. The behavior in the iSCSI draft for > CLEAR TASK SET > is > fairly well described. Is the > description presented in the discussion on CLEAR TASK SET supposed > to > define "cancels all pending operations?" Or does this statement > have > another meaning? > > > > > From owner-ips@ece.cmu.edu Wed Jun 12 23:35:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20995 for ; Wed, 12 Jun 2002 23:35:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5D2sjb14740 for ips-outgoing; Wed, 12 Jun 2002 22:54:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5D2sgw14735 for ; Wed, 12 Jun 2002 22:54:43 -0400 (EDT) Received: from london ([192.168.1.16]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id TAA17135; Wed, 12 Jun 2002 19:52:46 -0700 (PDT) From: "Rod Harrison" To: "Santosh Rao" , Cc: , , Subject: RE: iSCSI-Asynch event code Date: Wed, 12 Jun 2002 21:55:04 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3D07CF80.CA8286BF@cup.hp.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Santosh, If there were only one connection per session I would agree, but I think you are overlooking the multiple connection case. If an initiator has say 10 connections in a session and the target requests a logout of one of them what motivation does the initiator have to reopen that connection in a timely manner? And as I mentioned, the initiator may be unable to connect to the target for many reasons. The spec doesn't mandate an initiator re-login in a connection and any target design that assumes it will is a bad one. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Santosh Rao Sent: Wednesday, June 12, 2002 5:47 PM To: pat_thaler@agilent.com Cc: ni1d@arrl.net; Julian_Satran@il.ibm.com; ips@ece.cmu.edu Subject: Re: iSCSI-Asynch event code I don't see a need to allow key re-negotiation during FFP. The only key that is really required to be used in FFP is SendTargets. The keys that are permitted during FFP are : - SendTargets - TargetAlias - InitiatorAlias - TargetAddress - MaxRecvDataPDUSize (or whatever its latest name is) - Vendor Specific keys Of the above, the only real negotiation involves the MaxRecvPDUSize. I don't see any use of attempting to modify/negotiate/communicate the remaining keys during FFP (with the exception of SendTargets). I see no problem in forbidding key re-negotiation during FFP and handling PMTU changes by dropping the connection and allowing it to be re-established. There needs to be a conscious effort to simplify this login negotiation process and bound the complexity that's being heaped upon it. If we don't make the attempt to keep it simple, we are going to be bitten by a bunch of bugs in this area due to its complexity. This is one such area where we can choose not to increase the complexity of login negotiation. There have been some concerns raised about the initiator not logging back in upon a target driven logout. Such an initiator driver is a poor design. As long as an upper layer in the O.S. has an open pending on some LUN of that target port, it is the duty of the initiator driver to attempt to keep the I-T nexus established, and if there's a transient glitch in the I-T nexus, the initiator must attempt to re-login. An initiator that does not do this gets what it deserves. There's no need to add complexity to the spec in an attempt to deal with poor initiator implementations. The target need not care if the initiator does not log back, in this case. - Santosh pat_thaler@agilent.com wrote: > > Paul and Santosh, > > If this isn't needed, then I don't see why FFP negotiation is needed at all (other than to support discovery with SendTargets but that isn't really a negotiation). The initiator could also close and reopen the connection to change PDU size. If we support renegotiation of some keys during FFP for the initiator, then we should do it for the target as well. Otherwise we shouldn't support renegotiation at all. > > Pat > > -----Original Message----- > From: Paul Koning [mailto:ni1d@arrl.net] > Sent: Wednesday, June 12, 2002 1:54 PM > To: santoshr@cup.hp.com > Cc: Julian_Satran@il.ibm.com; ips@ece.cmu.edu > Subject: Re: iSCSI-Asynch event code > > Excerpt of message (sent 12 June 2002) by Santosh Rao: > > > > Why is this needed ? The target can just send an async event to drop the > > connection or request a connection logout, and the connection can be > > re-established allowing for new negotiation. > > > > I don't see the point of making this change so late in the game. There > > exist mechanisms such as target driven connection logout/drop which can > > be used to achieve the same effect. > > I agree. > > paul -- The world is so fast that there are days when the person who says it can't be done is interrupted by the person who is doing it. ~ Anon From owner-ips@ece.cmu.edu Wed Jun 12 23:36:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21015 for ; Wed, 12 Jun 2002 23:36:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5D344915190 for ips-outgoing; Wed, 12 Jun 2002 23:04:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5D342w15184 for ; Wed, 12 Jun 2002 23:04:02 -0400 (EDT) Received: from xparelay2.corp.hp.com (xparelay2.corp.hp.com [15.58.137.112]) by palrel11.hp.com (Postfix) with ESMTP id 22FC5600376 for ; Wed, 12 Jun 2002 20:03:57 -0700 (PDT) Received: from xpabh3.corp.hp.com (xpabh3.corp.hp.com [15.58.136.223]) by xparelay2.corp.hp.com (Postfix) with ESMTP id 1BB54AC for ; Wed, 12 Jun 2002 20:03:57 -0700 (PDT) Received: by xpabh3.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 20:03:56 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF662@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: ips@ece.cmu.edu Subject: RE: iSCSI: Implementation identification keys Date: Wed, 12 Jun 2002 20:03:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk David, Thanks for the concise summary. I have been silent on this thread hoping it would die it's own death, since we long ago agreed not to add any more gratuitous keys that weren't required for protocol functionality (see the old threads on "TargetAlias" and "SendTargets"). Otherwise, the list of things "it would be nice to have" will never end. Some posters seem to think that a lack of comment indicates support, so I'd like to add my voice to Pat's against the proposed vendor/product/rev keys for all the reasons that have been sited so many times on this list. Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Wednesday, June 12, 2002 5:37 PM > To: ips@ece.cmu.edu > Subject: iSCSI: Implementation identification keys > > > The signal to noise ratio on the X-keys thread is getting rather low, > hence the deliberate change of subject. > > A major problem is that there are two motivations for the proposed > keys, as Bill Studenmund summarized: > > > A) makes it easy to identify vendor/product/rev. All you > have to do is > > capture a session (tcpdump/ethereal), and you have it. Info > is in one > > place. > > > > B) Identify system on other side of connection/session to > turn on/off > > quirk support. > > A) is a fine motivation, but B) is problematic, and it > appears to be the > more important one from discussion on the list. I'm rather > uncomfortable > surrendering to this motivation this early in the game. This position > is similar to the reason why we had to stop the practice of > incrementing > the iSCSI version number every time the revision number of the draft > changed -- I think it's still the case that the right thing > to do in the > IETF process is to aim for interoperability in the standard > rather than > put in support for divergent implementations. > > That said, the "quirk support" may be inevitable, and the quirks are > hard to stamp out once one goes down that path. For example, EMC's > support matrix (published on our web site) includes quirk support for > SCSI and Fibre Channel (and yes, there are a number of parallel SCSI > quirks, even though parallel SCSI has been around for a very > long time). > > I think the use of X- keys and shoehorning this into the main > iSCSI draft > at this late stage is inappropriate - IMHO, this should be > done right or not > at all. I believe the best course of action would be for > those interested > in this sort of feature (and you know who you are from the > list discussion) > to write up a separate draft introducing new keys that we can consider > separately. At this juncture, it appears to me that > insisting on having > this in the main iSCSI draft is likely to result in delay - based on > the list discussion, I think rough consensus is going to be > hard to reach > on this one, hence the desire for a second draft that can > take as long as > it needs. > > This gets to the next point I wanted to get to. IETF process does not > require rewriting an entire RFC in order to make changes - a > new RFC can > update an existing RFC, and hence it's possible to make small changes > fairly quickly (without reopening everything in the RFC for changes). > Of course "fairly quickly" depends on there being rough consensus for > the changes ... but there's no need to go through resolution > of everything > that anyone might want to change/improve/remove/etc. in the main iSCSI > document just to make minor changes (e.g., for > interoperability problems), > and iSCSI was designed so that logon negotiation would be extensible. > > Thanks, > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > black_david@emc.com Cell: +1 (978) 394-7754 > --------------------------------------------------- > From owner-ips@ece.cmu.edu Thu Jun 13 03:23:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03429 for ; Thu, 13 Jun 2002 03:22:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5D6Ze724173 for ips-outgoing; Thu, 13 Jun 2002 02:35:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail7.nc.rr.com (fe7.southeast.rr.com [24.93.67.54]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5D6Zcw24169 for ; Thu, 13 Jun 2002 02:35:38 -0400 (EDT) Received: from mail pickup service by mail7.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 02:08:39 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 16:17:59 -0400 Received: from engine.ieee.org (engine.ieee.org [140.98.193.23]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AKHxIa017210 for ; Mon, 10 Jun 2002 16:17:59 -0400 (EDT) Received: from ece.cmu.edu (gemini3.ieee.org [140.98.193.25]) by engine.ieee.org (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5AKHjB14853; Mon, 10 Jun 2002 16:17:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AJvBE08892 for ips-outgoing; Mon, 10 Jun 2002 15:57:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AJv8w08884 for ; Mon, 10 Jun 2002 15:57:08 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 5FEF830706; Mon, 10 Jun 2002 15:57:07 -0400 (EDT) Date: Mon, 10 Jun 2002 12:54:59 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Michael Smith Cc: Subject: Re: iSCSI: AHS use In-Reply-To: <034670D62D19D31180990090277A37B702437BC0@mercury.corp.iready.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Mon, 10 Jun 2002, Michael Smith wrote: > I have some questions on the current AHS descriptions in 12-97. I just > tripped over this, so I think maybe others might too. [snip] > 2. However, in the PDU format diagram on p. 131 of 12-97 it is not clear > that we have the option of zero, one or more Additional Header Segments. > After I re-read things a few times, and apologies if I have this wrong, I > think that the use of multiple Additional Header Segments is along these > lines: > > (a) Use one and only one Additional Header Segment for an extended CDB (SPC > calls this a variable-length CDB). This extended CDB (or variable-length > CDB) Additional Header Segment must immediately follow the BHS. (A suggested > exact use definition of this type of Additional Header Segment coming up.) > > (b) Use one and only one Additional Header Segment for an Bidirectional > Expected Read-Data Length. This Bidirectional Expected Read-Data Length > Additional Header Segment must immediately follow the BHS. > > (c) Use of more than one Additional Header Segment is left up to the user. > > How many Additional Header Segments were we expecting to be able to be used? > Would this maximum length of Additional Header Segments be limited only by > the TotalAHSLength (8-bit field measuring length in four-byte words or > ((2**8) - 1) * 4 bytes or roughly 1 kbyte)? Can we follow an extended CDB > Additional Header Segment or a Bidirectional Expected Read-Data Length > Additional Header Segment by one or more user-defined Additional Header > Segment? > > Did I get this anywhere close to correct? Not sure about correct, but you got it as I understand it. :-) The one thing I'm not sure about is the use of, "must immediately follow the BHS." I agree it must be in the AHS associated with the BHS, but if you have a variable-length command (with CDB spill) which is also a bidi command, you will have both an (a) and a (b), and only one can immediately follow the BHS. :-) > 3. In one of Bob Russell's emails we have the following, which does seem to > make the use of multiple Additional Header Segments a little clearer to me: > > > [quote http://www.pdl.cmu.edu/mailinglists/ips/mail/msg03784.html] > > [view in fixed-width font on wide window] > +------------------------+ > | required BHS | > fixed length of 48 bytes > +------------------------+ > | optional AHS 1 |\ > | - - - - - - - - - - - | \ > | optional AHS 2 | \ > | - - - - - - - - - - - | > total length in AHS_length field in BHS > | . . . . | / > | - - - - - - - - - - - | / > | optional AHS n |/ > +------------------------+ > | optional header digest | -- covers preceding (48 + AHS_length) bytes > +------------------------+ > | |\ > | optional data | > total length in DATA_length field in BHS > | |/ > +------------------------+ > | optional data digest | -- covers preceding (DATA_length) bytes > +------------------------+ > > [end view in fixed-width font on wide window] > > [end quote http://www.pdl.cmu.edu/mailinglists/ips/mail/msg03784.html] > > Is it possible to add something like this picture to the format diagram on > p.131. I wouldn't ask if I hadn't tripped myself up on this already. I think such a diagram would help too. > 4. On p. 139 of 12-97 we have the following: [snip text suggestion] > There are 16 bytes in the CDB field to accommodate bytes 0-15 of the > commonly used CDBs. An Extended CDB AHS MUST be used to contain bytes 16-259 > of a variable-length CDB [SPC]. Sounds like a good change too. Take care, Bill From owner-ips@ece.cmu.edu Thu Jun 13 03:26:12 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03548 for ; Thu, 13 Jun 2002 03:26:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5D6dta24337 for ips-outgoing; Thu, 13 Jun 2002 02:39:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail7.nc.rr.com (fe7.southeast.rr.com [24.93.67.54]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5D6dsw24333 for ; Thu, 13 Jun 2002 02:39:54 -0400 (EDT) Received: from mail pickup service by mail7.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 02:08:45 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 16:17:53 -0400 Received: from ruebert.ieee.org (ruebert.ieee.org [140.98.193.10]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AKHrIa016889 for ; Mon, 10 Jun 2002 16:17:53 -0400 (EDT) Received: from ece.cmu.edu (gemini2.ieee.org [140.98.193.20]) by ruebert.ieee.org (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5AKHbq03383; Mon, 10 Jun 2002 16:17:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AKA9U09683 for ips-outgoing; Mon, 10 Jun 2002 16:10:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AKA8w09679 for ; Mon, 10 Jun 2002 16:10:08 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 27F429A34; Mon, 10 Jun 2002 14:10:07 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 6B98914E; Mon, 10 Jun 2002 14:10:06 -0600 (MDT) Received: from 130.29.152.143 by axcsbh1.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 10 Jun 2002 14:10:06 -0600 Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 14:10:05 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E3E67@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Ken Sandars , "THALER"@ece.cmu.edu Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys Date: Mon, 10 Jun 2002 14:10:00 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Ken, The incentive is that, in my experience, when products interoperate out of the chute (because the spec is clear) the market grows quickly. When interoperability is a nightmare built in by testing and tweaks, then markets grow slowly. Ambiguities need to be fixed. A number that have been raised recently have been fixed. If there are ones you feel haven't been addressed, I would like to see them fixed. That is what we should do rather than planning on building in work arounds. Regards, Pat -----Original Message----- From: Ken Sandars [mailto:ksandars@eurologic.com] Sent: Friday, June 07, 2002 10:54 AM To: pat_thaler@agilent.com; ni1d@arrl.net; bmastors@allocity.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys Hi Pat, Paul, Bob, There is no disputing the fact that identifying brokeness and fixing it is the right way to go. Now while it's nice to lend our mental muscles to the task of identifying these problems, it's pretty difficult to compel other vendors to fix something which is broken wrt to the spec, when it works with some other products in the marketplace. The unfortunate reality is that certain problems have been long identified (over half a year in some cases), and remain unfixed. Our approach is to implement the spec. As we encounter problems we fix our broken bits and notify the partner of the issue - in most cases this has worked well and they have fixed their problems too. However, we are compelled to put work-arounds in our system in order to interoperate with those who have have fielded systems which remain broken. At this stage, unless the intiator is known, we turn all the work-arounds on. This has an impact on performance. We'd like to avoid this. We want to see iSCSI run at the speed of a thousand startled gazelles. We want to see all iSCSI offerings interoperate. We don't want to see the management of these things as a nightmare. I think the use of the proposed keys will only assist implementers by providing additonal information - which can be used or ignored. Oh, and we won't send them from our target if the initiator doesn't send them, as there may be some initiator which doesn't handle the X- keys! (I have further comments inline): On Thursday 06 June 2002 11:31 pm, pat_thaler@agilent.com wrote: > Paul, > > I agree. This would also create a testing nightmare for initiator > developers. If the initiator has adapts itself for n targets then > it has n different personalities that all need to be tested. > As Bob Mastors said, it's already in there, so it's being done. And testers are meant to have nightmares! It's their job ;-) > We have interoperability testing to help us find and fix > spec ambiguities that cause interoperability problems. > Yep - we find them, and they ignore them, so this doesn't get us over the finish line. > The way to build market for iSCSI is to have interoperability - > not to have cases wher Brand_x Target doesn't work with Brand_y > Initiator because Brand_y doesn't have the tweak profile for > Brand_x. > As I noted above, we interoperate, but at the cost of performance. > Regards, > Pat > > -----Original Message----- > From: Paul Koning [mailto:ni1d@arrl.net] > Sent: Thursday, June 06, 2002 1:06 PM > To: bmastors@allocity.com > Cc: ksandars@eurologic.com; ips@ece.cmu.edu > Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys > > >>>>> "Bob" == Bob Mastors writes: > > Bob> I like it. Otherwise the user has to configure the initiator > Bob> with the target type and the target with the initiator type. It > Bob> is unlikely that this problem will disappear for a long time if > Bob> ever. As the threads on the C bit has shown there will be lots > Bob> of ways to implement the spec and probably no device will > Bob> correctly support all possibilities. I am already putting "if > Bob> (vendor)" code in my implementation. Maybe in a few years I will > Bob> not need it. But until then it would be nice if I could > Bob> dynamically determine vendor information for iscsi so the user > Bob> does not have to configure it. > > Oh boy, now I'm well and truly frightened. Welcome to my nightmare! > > I read your message as saying that there isn't going to be > interoperability for several years. I'm a lot more optimistic than that - these problems should be gone within a year of the draft becoming a standard. In the meantime, we DO interoperate, just in a hobbled mode for unknown initiators. > Sorather than create a serious > incentive for implementers to fix their defects, Can you suggest what this incentive might be? > we should implement a > way to have them report which collection of defects they implement so > we can invoke workaround collection #42. Of course, the larger the > collection of crocks we work around, the larger the number of bugs in > implementations that everyone else will have to work around. > Sounds messy to me. It comes down to this: we work by default in a mode to achieve maximum interoperability, albeit at the expense of some performance/reliability features. If an initiator lets our target know what it is, and we recognise its lack of the known quirks, we remove the work-arounds. Our tester's nightmares, our developer's pain to identify and create work-arounds, and at no cost to the standards track. And it's all optional. > In the words of a well known American, "Just Say NO". OK - but think carefully before following the advice of famous Americans - didn't some other well known American spell tomato with an 'e'? ;-) > > paul Cheers, Ken -- Ken Sandars Eurologic Systems Ltd ksandars@eurologic.com From owner-ips@ece.cmu.edu Thu Jun 13 05:25:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05457 for ; Thu, 13 Jun 2002 05:25:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5D8QD528381 for ips-outgoing; Thu, 13 Jun 2002 04:26:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail7.nc.rr.com (mail7.southeast.rr.com [24.93.67.54]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5D8QAw28376 for ; Thu, 13 Jun 2002 04:26:10 -0400 (EDT) Received: from mail pickup service by mail7.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 04:21:15 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Jun 2002 16:37:00 -0400 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5BKb1a2007803 for ; Tue, 11 Jun 2002 16:37:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BJZdf29042 for ips-outgoing; Tue, 11 Jun 2002 15:35:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BJZbw29038 for ; Tue, 11 Jun 2002 15:35:37 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel11.hp.com (Postfix) with ESMTP id 8F2A46007A9; Tue, 11 Jun 2002 12:35:29 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id MAA04831; Tue, 11 Jun 2002 12:37:17 -0700 (PDT) Message-ID: <002001c2117f$24527e20$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Eddy Quicksall" , "Julian Satran" Cc: References: Subject: Re: iSCSI: changing MaxPDUDataLength Date: Tue, 11 Jun 2002 12:35:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Eddy, I am not clear on why you think the target code becomes messy on a PDU size change. The last para in section 4.4 states the following - "Parameters negotiated by a text exchange negotiation sequence become effective only after the negotiation sequence is completed." Since the target gets to complete a text negotiation with a Text Response PDU, it can time the applicability of a changed MaxRecvDataSegmentLength. Requiring that an initiator must idle the connection before changing this parameter, IMHO, is counter-productive when there's a dynamic PMTU degradation in the presence of long-running commands (writes in particular). Once the initiator starts the renegotiation, target would ideally want to quickly renegotiate its receive size as well to receive ULPDU-contained segments. In short, seems to me that the draft is saying what you would like. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Eddy Quicksall" To: "Julian Satran" Cc: Sent: Tuesday, June 11, 2002 7:56 AM Subject: RE: iSCSI: changing MaxPDUDataLength > I think it should be a requirement because if it is not, all target code > will have to have the messy code. Or, we could say that if it is not idle > commands, then the target may reject it. > > Eddy > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Tuesday, June 11, 2002 9:11 AM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > That is a fair request - we may slip in a recommendation to that effect (in > chapter 11?) > > Julo > > > > Eddy Quicksall > > > 06/11/2002 04:28 AM > Please respond to Eddy Quicksall > > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > How about if we say that an initiator must not change the MaxPDUDataSize > unless it first idles the commands (at least the ones with the R bit) or if > ErrorRecoveryLevel==0? > > That would simplify target code greatly and would meet the design goals; and > since it should be rare to change it, it would be of little impact to idle > the commands for a split second. > > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Monday, June 10, 2002 8:06 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > I said only that when you change length you can ask for all PDUs after the > ack! (no need to keep a tall - the old offsets are good up to the hole). > > Julo > > > Eddy Quicksall > > > 06/11/2002 12:32 AM > Please respond to Eddy Quicksall > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > Julian, > > Another problem here is that the target has to calculate the offset from the > DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 > means starting DataSN=4, send all the data for that sequence. > > I think it would be a performance hit and waist of memory to keep a tally of > all PDU sizes just for an occasional SNACK. > > It's not that it can't be done ... it is more that it is messy and I think > there is a solution that will satisfy the design requirements but keep the > software simpler. > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Saturday, June 08, 2002 10:16 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > That is not completely accurate. > The only problem is when PDU size decreases and then SNACK must be for all > data. > Target can also keep a mapping of numbers/to offsets (the list should be > small and if it gets long ask for ack (A-bit). > > Julo > > Eddy Quicksall > Sent by: owner-ips@ece.cmu.edu > > > 06/08/2002 10:54 PM > Please respond to Eddy Quicksall > > > To: pat_thaler@agilent.com > cc: ips@ece.cmu.edu > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > Thanks, > > As a target, I won't be able to let it change until all of the outstanding > commands are finished (running with ErrorRecoveryLevel>=1). This is because > I must use the PDU size to compute the offset from a SNACK's > BegRun/RunLength. > > So, I plan to not give the text response for a MaxPDURecvDataLength in FFP > until I get back an ExpStatSN == next StatSN. > > This will cause a delay of unknown time before the PDU size can actually > change ... do you see any problem with this? > > Eddy > > -----Original Message----- > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > Sent: Friday, June 07, 2002 1:13 PM > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > Subject: RE: iSCSI: changing MaxPDUDataLength > > > Eddy, > > If one uses a message sync and steering that relys on the transport segments > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path > MTU changes one would want to change the PDU data length to fit the new path > MTU. > > Pat > > -----Original Message----- > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > Sent: Wednesday, June 05, 2002 12:24 PM > To: ips@ece.cmu.edu > Subject: iSCSI: changing MaxPDUDataLength > > > Does anybody know a case where it is necessary to support a new PDU data > length during full feature phase? > > Eddy > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > From owner-ips@ece.cmu.edu Thu Jun 13 05:26:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05495 for ; Thu, 13 Jun 2002 05:26:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5D961m00008 for ips-outgoing; Thu, 13 Jun 2002 05:06:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail7.nc.rr.com (mail7.southeast.rr.com [24.93.67.54]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5D95xw29996 for ; Thu, 13 Jun 2002 05:05:59 -0400 (EDT) Received: from mail pickup service by mail7.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 02:13:03 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Jun 2002 17:57:29 -0400 Received: from engine.ieee.org (engine.ieee.org [140.98.193.23]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5BLGmbC015220 for ; Tue, 11 Jun 2002 17:16:48 -0400 (EDT) Received: from ece.cmu.edu (gemini2.ieee.org [140.98.193.20]) by engine.ieee.org (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5BLGbB01752; Tue, 11 Jun 2002 17:16:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BKqQ603958 for ips-outgoing; Tue, 11 Jun 2002 16:52:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from astutenetworks.com (2.astutenetworks.com [216.142.74.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BKqNw03951 for ; Tue, 11 Jun 2002 16:52:23 -0400 (EDT) Received: from amirdesktop (dhcp62 [172.21.2.62]) by astutenetworks.com (8.11.6/8.11.2) with SMTP id g5BKpA909685; Tue, 11 Jun 2002 13:51:10 -0700 From: "Amir Shalit" To: "Mallikarjun C." , "Eddy Quicksall" , "Julian Satran" Cc: Subject: RE: iSCSI: changing MaxPDUDataLength Date: Tue, 11 Jun 2002 13:51:08 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <002001c2117f$24527e20$edd52b0f@rose.hp.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mallikarjun, The initiator can wait for all outstanding sequences to get acknowledged prior to negotiating MaxPDUDataLength change. That will work well for long-running commands and simplify target management. Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Mallikarjun C. Sent: Tuesday, June 11, 2002 12:35 PM To: Eddy Quicksall; Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iSCSI: changing MaxPDUDataLength Eddy, I am not clear on why you think the target code becomes messy on a PDU size change. The last para in section 4.4 states the following - "Parameters negotiated by a text exchange negotiation sequence become effective only after the negotiation sequence is completed." Since the target gets to complete a text negotiation with a Text Response PDU, it can time the applicability of a changed MaxRecvDataSegmentLength. Requiring that an initiator must idle the connection before changing this parameter, IMHO, is counter-productive when there's a dynamic PMTU degradation in the presence of long-running commands (writes in particular). Once the initiator starts the renegotiation, target would ideally want to quickly renegotiate its receive size as well to receive ULPDU-contained segments. In short, seems to me that the draft is saying what you would like. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Eddy Quicksall" To: "Julian Satran" Cc: Sent: Tuesday, June 11, 2002 7:56 AM Subject: RE: iSCSI: changing MaxPDUDataLength > I think it should be a requirement because if it is not, all target code > will have to have the messy code. Or, we could say that if it is not idle > commands, then the target may reject it. > > Eddy > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Tuesday, June 11, 2002 9:11 AM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > That is a fair request - we may slip in a recommendation to that effect (in > chapter 11?) > > Julo > > > > Eddy Quicksall > > > 06/11/2002 04:28 AM > Please respond to Eddy Quicksall > > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > How about if we say that an initiator must not change the MaxPDUDataSize > unless it first idles the commands (at least the ones with the R bit) or if > ErrorRecoveryLevel==0? > > That would simplify target code greatly and would meet the design goals; and > since it should be rare to change it, it would be of little impact to idle > the commands for a split second. > > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Monday, June 10, 2002 8:06 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > I said only that when you change length you can ask for all PDUs after the > ack! (no need to keep a tall - the old offsets are good up to the hole). > > Julo > > > Eddy Quicksall > > > 06/11/2002 12:32 AM > Please respond to Eddy Quicksall > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > Julian, > > Another problem here is that the target has to calculate the offset from the > DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 > means starting DataSN=4, send all the data for that sequence. > > I think it would be a performance hit and waist of memory to keep a tally of > all PDU sizes just for an occasional SNACK. > > It's not that it can't be done ... it is more that it is messy and I think > there is a solution that will satisfy the design requirements but keep the > software simpler. > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Saturday, June 08, 2002 10:16 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > That is not completely accurate. > The only problem is when PDU size decreases and then SNACK must be for all > data. > Target can also keep a mapping of numbers/to offsets (the list should be > small and if it gets long ask for ack (A-bit). > > Julo > > Eddy Quicksall > Sent by: owner-ips@ece.cmu.edu > > > 06/08/2002 10:54 PM > Please respond to Eddy Quicksall > > > To: pat_thaler@agilent.com > cc: ips@ece.cmu.edu > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > Thanks, > > As a target, I won't be able to let it change until all of the outstanding > commands are finished (running with ErrorRecoveryLevel>=1). This is because > I must use the PDU size to compute the offset from a SNACK's > BegRun/RunLength. > > So, I plan to not give the text response for a MaxPDURecvDataLength in FFP > until I get back an ExpStatSN == next StatSN. > > This will cause a delay of unknown time before the PDU size can actually > change ... do you see any problem with this? > > Eddy > > -----Original Message----- > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > Sent: Friday, June 07, 2002 1:13 PM > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > Subject: RE: iSCSI: changing MaxPDUDataLength > > > Eddy, > > If one uses a message sync and steering that relys on the transport segments > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path > MTU changes one would want to change the PDU data length to fit the new path > MTU. > > Pat > > -----Original Message----- > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > Sent: Wednesday, June 05, 2002 12:24 PM > To: ips@ece.cmu.edu > Subject: iSCSI: changing MaxPDUDataLength > > > Does anybody know a case where it is necessary to support a new PDU data > length during full feature phase? > > Eddy > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > From owner-ips@ece.cmu.edu Thu Jun 13 05:27:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05508 for ; Thu, 13 Jun 2002 05:27:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5D8t6K29520 for ips-outgoing; Thu, 13 Jun 2002 04:55:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5D8t4w29516 for ; Thu, 13 Jun 2002 04:55:04 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5D8si4L047530; Thu, 13 Jun 2002 10:54:45 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5D8sgB120764; Thu, 13 Jun 2002 10:54:42 +0200 Importance: Normal Subject: RE: iSCSI: 7.2.1 CHAP Considerations (12-98) To: Black_David@emc.com Cc: ssenum@cisco.com, ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Ofer Biran" Date: Thu, 13 Jun 2002 11:53:52 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 13/06/2002 11:54:42 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk How about: When CHAP is used with secret shorter than 96 bits, a compliant implementation MUST NOT continue with the login step in which it should send a CHAP response (CHAP_R - see 10.5) unless it can verify that IPsec encryption is being used to protect the connection. On initiator-only authentication this puts the responsibility only on the initiator implementation who surely knows the secret and its length. Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 Black_David@emc.com@ece.cmu.edu on 13/06/2002 02:26:07 Please respond to Black_David@emc.com Sent by: owner-ips@ece.cmu.edu To: ssenum@cisco.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: 7.2.1 CHAP Considerations (12-98) Yes, my intent was to modify the draft text to include the "essential condition" described below. --David > -----Original Message----- > From: Steve Senum [mailto:ssenum@cisco.com] > Sent: Wednesday, June 12, 2002 6:14 PM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: 7.2.1 CHAP Considerations (12-98) > > > David, > > What you state would be better, but that is > not what the current text (as of 12-98) says. > > Steve Senum > > Black_David@emc.com wrote: > > > > I think the essential condition here is that the > > "do not continue if secret is shorter than 96 bits" > > criteria should apply only to implementations that > > know and use the secret (i.e., generators of CHAP > > responses, and recipients of those responses that > > do their own verification as opposed to outsourcing > > that verification to something like a RADIUS server). > > > > Thanks, > > --David > > --------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > > black_david@emc.com Cell: +1 (978) 394-7754 > > --------------------------------------------------- > > > > > -----Original Message----- > > > From: Steve Senum [mailto:ssenum@cisco.com] > > > Sent: Wednesday, June 12, 2002 3:58 PM > > > To: Julian Satran > > > Cc: ietf-ips > > > Subject: Re: iSCSI: 7.2.1 CHAP Considerations (12-98) > > > > > > > > > Julian, > > > > > > In the case where an iSCSI Target is authenticating > > > an iSCSI Initiator, the Target sends a CHAP > > > challenge and identifier, and the Initiator sends > > > back a CHAP response and username. > > > > > > In the case were the Target is using the RADIUS > > > protocol, these four pieces of information are > > > sent by the Target to a RADIUS server, which > > > simply gives an accept or reject reply. The target > > > never has access to the CHAP secret (which is good), > > > hence no check can be made on its length. > > > > > > Regards, > > > Steve Senum > > > > > > Julian Satran wrote: > > > > > > > > can you elaborate? Julo > > > > > > > > Steve Senum > > > > Sent by: owner-ips@ece.cmu.edu To: ietf-ips > > > > > > > > 06/12/2002 09:32 PM cc: > > > > Please respond to Steve Senum Subject: > > > iSCSI: 7.2.1 CHAP > > > > Considerations (12-98) > > > > > > > > > > > > > > > > I have a concern over the wording of the > > > > following text from section 7.2.1 (12-98 version): > > > > > > > > When CHAP is used with secret shorter than 96 bits, > > > > a compliant implementation MUST NOT continue with > > > > the login unless it can verify that IPsec encryption > > > > is being used to protect the connection. > > > > > > > > I know the above is attempt to "put some teeth" into > > > > the requirements to make the use of CHAP secure, > > > > but I believe there are common cases where the > > > > length of the CHAP secret cannot be verified, such > > > > as when a RADIUS server is being used. > > > > > > > > Regards, > > > > Steve Senum > > > > From owner-ips@ece.cmu.edu Thu Jun 13 06:51:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06679 for ; Thu, 13 Jun 2002 06:51:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DA4pn13214 for ips-outgoing; Thu, 13 Jun 2002 06:04:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DA4ow13210 for ; Thu, 13 Jun 2002 06:04:50 -0400 (EDT) Received: from mail pickup service by mail5.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 06:04:46 -0400 Received: from mail pickup service by mail5.nc.rr.com with Microsoft SMTPSVC; Tue, 11 Jun 2002 15:31:56 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 20:10:39 -0400 Received: from ruebert.ieee.org (ruebert.ieee.org [140.98.193.10]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5B0AetH016353 for ; Mon, 10 Jun 2002 20:10:40 -0400 (EDT) Received: from ece.cmu.edu (gemini3.ieee.org [140.98.193.25]) by ruebert.ieee.org (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5B0AUq01119; Mon, 10 Jun 2002 20:10:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5B05tG21664 for ips-outgoing; Mon, 10 Jun 2002 20:05:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5B05mw21657 for ; Mon, 10 Jun 2002 20:05:52 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5B05c7n015650; Tue, 11 Jun 2002 02:05:39 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5B05cD61504; Tue, 11 Jun 2002 02:05:38 +0200 To: Eddy Quicksall Cc: ips@ece.cmu.edu, pat_thaler@agilent.com MIME-Version: 1.0 Subject: RE: iSCSI: changing MaxPDUDataLength X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 11 Jun 2002 03:05:36 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 11/06/2002 03:05:38, Serialize complete at 11/06/2002 03:05:38 Content-Type: multipart/alternative; boundary="=_alternative 0000306FC2256BD5_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0000306FC2256BD5_= Content-Type: text/plain; charset="us-ascii" I said only that when you change length you can ask for all PDUs after the ack! (no need to keep a tall - the old offsets are good up to the hole). Julo Eddy Quicksall 06/11/2002 12:32 AM Please respond to Eddy Quicksall To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength Julian, Another problem here is that the target has to calculate the offset from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 means starting DataSN=4, send all the data for that sequence. I think it would be a performance hit and waist of memory to keep a tally of all PDU sizes just for an occasional SNACK. It's not that it can't be done ... it is more that it is messy and I think there is a solution that will satisfy the design requirements but keep the software simpler. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, June 08, 2002 10:16 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength That is not completely accurate. The only problem is when PDU size decreases and then SNACK must be for all data. Target can also keep a mapping of numbers/to offsets (the list should be small and if it gets long ask for ack (A-bit). Julo Eddy Quicksall Sent by: owner-ips@ece.cmu.edu 06/08/2002 10:54 PM Please respond to Eddy Quicksall To: pat_thaler@agilent.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Thanks, As a target, I won't be able to let it change until all of the outstanding commands are finished (running with ErrorRecoveryLevel>=1). This is because I must use the PDU size to compute the offset from a SNACK's BegRun/RunLength. So, I plan to not give the text response for a MaxPDURecvDataLength in FFP until I get back an ExpStatSN == next StatSN. This will cause a delay of unknown time before the PDU size can actually change ... do you see any problem with this? Eddy -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Friday, June 07, 2002 1:13 PM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Eddy, If one uses a message sync and steering that relys on the transport segments carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path MTU changes one would want to change the PDU data length to fit the new path MTU. Pat -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Wednesday, June 05, 2002 12:24 PM To: ips@ece.cmu.edu Subject: iSCSI: changing MaxPDUDataLength Does anybody know a case where it is necessary to support a new PDU data length during full feature phase? Eddy mailto: Eddy_Quicksall@iVivity.com --=_alternative 0000306FC2256BD5_= Content-Type: text/html; charset="us-ascii"
I said only that when you change length you can ask for all PDUs after the ack! (no need to keep a tall - the old offsets are good up to the hole).

Julo


Eddy Quicksall <eddy_quicksall@ivivity.com>

06/11/2002 12:32 AM
Please respond to Eddy Quicksall

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu, pat_thaler@agilent.com
        Subject:        RE: iSCSI: changing MaxPDUDataLength

       


Julian,
 
Another problem here is that the target has to calculate the offset from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 means starting DataSN=4, send all the data for that sequence.
 
I think it would be a performance hit and waist of memory to keep a tally of all PDU sizes just for an occasional SNACK.
 
It's not that it can't be done ... it is more that it is messy and I think there is a solution that will satisfy the design requirements but keep the software simpler.
 
Eddy
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, June 08, 2002 10:16 PM
To: Eddy Quicksall
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com
Subject: RE: iSCSI: changing MaxPDUDataLength

That is not completely accurate.
The only problem is when PDU size decreases and then SNACK must be for all data.
Target can also keep a mapping of numbers/to offsets (the list should be small and if it gets long ask for ack (A-bit).

Julo

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

06/08/2002 10:54 PM
Please respond to Eddy Quicksall

       
       To:        pat_thaler@agilent.com
       cc:        ips@ece.cmu.edu
       Subject:        RE: iSCSI: changing MaxPDUDataLength

     



Thanks,

As a target, I won't be able to let it change until all of the outstanding
commands are finished (running with ErrorRecoveryLevel>=1). This is because
I must use the PDU size to compute the offset from a SNACK's
BegRun/RunLength.

So, I plan to not give the text response for a MaxPDURecvDataLength in FFP
until I get back an ExpStatSN == next StatSN.

This will cause a delay of unknown time before the PDU size can actually
change ... do you see any problem with this?

Eddy

-----Original Message-----
From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]
Sent: Friday, June 07, 2002 1:13 PM
To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu
Subject: RE: iSCSI: changing MaxPDUDataLength


Eddy,

If one uses a message sync and steering that relys on the transport segments
carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path
MTU changes one would want to change the PDU data length to fit the new path
MTU.

Pat

-----Original Message-----
From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com]
Sent: Wednesday, June 05, 2002 12:24 PM
To: ips@ece.cmu.edu
Subject: iSCSI: changing MaxPDUDataLength


Does anybody know a case where it is necessary to support a new PDU data
length during full feature phase?

Eddy
mailto: Eddy_Quicksall@iVivity.com

--=_alternative 0000306FC2256BD5_=-- From owner-ips@ece.cmu.edu Thu Jun 13 08:13:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08843 for ; Thu, 13 Jun 2002 08:13:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DBVA116565 for ips-outgoing; Thu, 13 Jun 2002 07:31:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DBV8w16560 for ; Thu, 13 Jun 2002 07:31:08 -0400 (EDT) Received: from mail pickup service by mail5.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 07:21:32 -0400 Received: from mail pickup service by mail5.nc.rr.com with Microsoft SMTPSVC; Tue, 11 Jun 2002 15:40:57 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 17:04:52 -0400 Received: from engine.ieee.org (engine.ieee.org [140.98.193.23]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AL4rtH013128 for ; Mon, 10 Jun 2002 17:04:53 -0400 (EDT) Received: from ece.cmu.edu (gemini3.ieee.org [140.98.193.25]) by engine.ieee.org (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5AL4CB01410; Mon, 10 Jun 2002 17:04:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AKeHt11551 for ips-outgoing; Mon, 10 Jun 2002 16:40:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AKeFw11544 for ; Mon, 10 Jun 2002 16:40:15 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g5AKfZu10001; Mon, 10 Jun 2002 16:41:35 -0400 Message-ID: <3D050E99.1A33B188@splentec.com> Date: Mon, 10 Jun 2002 16:39:53 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: pat_thaler@agilent.com CC: wrstuden@wasabisystems.com, rsnively@Brocade.COM, ksandars@eurologic.com, ips@ece.cmu.edu Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys References: <1BEBA5E8600DD4119A50009027AF54A00C5E3E7B@axcs04.cos.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit pat_thaler@agilent.com wrote: > > Luben, > > An IETF standard is suppose to produce interoperability. Therefore, when > there is a MAY in the standard, it should be because each side can choose > either option and they will interoperate independent of which they choose. > For example: > > "iSCSI targets and initiators MUST support at least one TCP connection > and MAY support several connections in a session." > A device that supports only one connection per session will interoperate > (over one connection) to a device that supports multiple connections. Pat, please read carefully my reply to Paul. "a target MAY close the connection or may offer its own acceptable values" and "receiving non-offered value is a protocol error" doesn't interoperate. -- Luben From owner-ips@ece.cmu.edu Thu Jun 13 08:15:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08885 for ; Thu, 13 Jun 2002 08:15:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DBvS617867 for ips-outgoing; Thu, 13 Jun 2002 07:57:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DBvQw17863 for ; Thu, 13 Jun 2002 07:57:26 -0400 (EDT) Received: from mail pickup service by mail5.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 07:47:41 -0400 Received: from mail pickup service by mail5.nc.rr.com with Microsoft SMTPSVC; Tue, 11 Jun 2002 15:47:18 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 15:37:25 -0400 Received: from ruebert.ieee.org (ruebert.ieee.org [140.98.193.10]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AIwlIa003424 for ; Mon, 10 Jun 2002 14:58:47 -0400 (EDT) Received: from ece.cmu.edu (gemini3.ieee.org [140.98.193.25]) by ruebert.ieee.org (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5AIwQq01421; Mon, 10 Jun 2002 14:58:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AIrG805023 for ips-outgoing; Mon, 10 Jun 2002 14:53:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AIrEw05019 for ; Mon, 10 Jun 2002 14:53:14 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 24FFE30706; Mon, 10 Jun 2002 14:53:14 -0400 (EDT) Date: Mon, 10 Jun 2002 11:51:05 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Luben Tuikov Cc: Robert Snively , "'Ken Sandars'" , "Ips Reflector (E-mail)" Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys In-Reply-To: <3D04EED2.5043DCBF@splentec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Mon, 10 Jun 2002, Luben Tuikov wrote: > Bill Studenmund wrote: > > > > I must say that's not what I had in mind when I coined the phrase. I don't > > think the fact we let folks make different choices at MAY points is bad. > > That's the point. > > You (as Paul) didn't read this sentence (quoted here from above): Yes, I did. > Any time you see ``MAY'' or ``may'' in the draft and a target > and initiator arrive at different outcomes _just_ by taking one > or the other route, you have ``compliant-non-interoperability''. > > Which is what you are describing in more ``baby-terms'' below. No, that's not the same thing. You are saying EVERY may/MAY is a problem. I disagree with that. I'll agree that SOME may be a problem, and that we want to find them. The difference is that the ones I recall describe one side as being able to make a choice. If that choice is clearly communicated to the other side, then we are fine. I think we communicate that all of the time, but would appreciate finding out if we don't. > Read my reply to Paul, where I give 2 links to emails > where this is described well -- this has since been fixed > in the draft. Cool! > > *Those* are what I was thinking of when I came up with compliant-non- > > interoperability. :-) > > But you are merely repeating what I'm saying above... (and in my previous > email). No, the difference is I don't think that a MAY automatically lands us in trouble. I agree that most trouble cases start with a MAY, but I don't think the presence of a MAY automatically leads us to trouble. Take care, Bill From owner-ips@ece.cmu.edu Thu Jun 13 08:57:39 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10232 for ; Thu, 13 Jun 2002 08:57:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DCEJH18624 for ips-outgoing; Thu, 13 Jun 2002 08:14:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail7.nc.rr.com (mail7.southeast.rr.com [24.93.67.54]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DCEHw18620 for ; Thu, 13 Jun 2002 08:14:17 -0400 (EDT) Received: from mail pickup service by mail7.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 07:30:45 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 16:52:05 -0400 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AKq5tH014746 for ; Mon, 10 Jun 2002 16:52:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AKUKe10935 for ips-outgoing; Mon, 10 Jun 2002 16:30:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AKUIw10931 for ; Mon, 10 Jun 2002 16:30:18 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g5AKVqu09901; Mon, 10 Jun 2002 16:31:52 -0400 Message-ID: <3D050C52.5379887@splentec.com> Date: Mon, 10 Jun 2002 16:30:10 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Bill Studenmund CC: Robert Snively , "'Ken Sandars'" , "Ips Reflector (E-mail)" Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bill Studenmund wrote: > > On Mon, 10 Jun 2002, Luben Tuikov wrote: > > > Any time you see ``MAY'' or ``may'' in the draft and a target > > and initiator arrive at different outcomes _just_ by taking one > > or the other route, you have ``compliant-non-interoperability''. > > > > Which is what you are describing in more ``baby-terms'' below. > > No, that's not the same thing. You are saying EVERY may/MAY is a problem. > I disagree with that. I'll agree that SOME may be a problem, and that we > want to find them. > ``Any time'' doesn't imply ``EVERY may/MAY''! Look, I used the conjunctive ``and''. Here: (Every time ... MAY or may) AND (target/initiator arrive at different outcomes) THEN problem. -- Luben From owner-ips@ece.cmu.edu Thu Jun 13 09:01:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10318 for ; Thu, 13 Jun 2002 09:00:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DCY0O19654 for ips-outgoing; Thu, 13 Jun 2002 08:34:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DAUSw14241 for ; Thu, 13 Jun 2002 06:30:29 -0400 (EDT) Received: from mail pickup service by mail5.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 06:29:22 -0400 Received: from mail pickup service by mail5.nc.rr.com with Microsoft SMTPSVC; Tue, 11 Jun 2002 15:32:34 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 13:26:10 -0400 Received: from ruebert.ieee.org (ruebert.ieee.org [140.98.193.10]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AHQAtH000063 for ; Mon, 10 Jun 2002 13:26:10 -0400 (EDT) Received: from ece.cmu.edu (gemini2.ieee.org [140.98.193.20]) by ruebert.ieee.org (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5AHPtq25164; Mon, 10 Jun 2002 13:25:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AHFQ429224 for ips-outgoing; Mon, 10 Jun 2002 13:15:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from emailO.iomega.com (email.iomega.com [147.178.1.2]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g5AELYw18416 for ; Mon, 10 Jun 2002 10:21:34 -0400 (EDT) Received: from ROYNTEX01.iomega.com by emailO.iomega.com via smtpd (for ECE.CMU.EDU [128.2.136.200]) with SMTP; 10 Jun 2002 14:21:33 UT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: RE: iSCSI variable CDB length Date: Mon, 10 Jun 2002 08:21:33 -0600 Message-ID: <0FA2250F5A23D64FBD983956F9B286433D7DA5@royntex01.iomegacorp.com> Thread-Topic: iSCSI variable CDB length Thread-Index: AcIQH0lWMOySNpHGT82GQVWwjRz6UwAZ0omAAADPgNw= From: "Pat LaVarre" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ece.cmu.edu id g5AELYw18420 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit > restricting the maximum CDB length to 260 bytes. Max allowed is 260 = 8 + 252, yes. Max expressible is 263 = 8 + 255. We can only hope nobody visits the land between max allowed and max expressible. > That field must be a multiple of 4 The day's soon coming when people will prefer multiples of 8 ... Pat LaVarre -----Original Message----- From: Elliott, Robert (Server Storage) [mailto:Elliott@hp.com] Sent: Mon 6/10/2002 8:01 AM To: ips@ece.cmu.edu Cc: Subject: RE: iSCSI variable CDB length > -----Original Message----- > From: Michael J. S. Smith (PacBell) [mailto:smithmjs@pacbell.net] > Sent: Sunday, June 09, 2002 2:24 PM > Subject: variable CDB length > > I'm trying to bound some of the iSCSI structures. This email > is regarding the AHS for extended CDBs. > > The following (page 37 of the PDF, page 7 in the draft page > numbering) is from ftp://ftp.t10.org/t10/drafts/spc3/spc3r07.pdf. > [quote] > Command descriptor block (CDB): The structure used to communicate > commands from an application client to a device server. A CDB may > have a fixed length of up to 16 bytes or a variable length of > between 12 and 260 bytes. > [end quote] > > I can't find another reference within the 442 pages of the 07 > draft of SPC-3 to the 260-byte maximum length for a > variable-length CDB. > > 1. Is the 260-byte figure in the definitions section of the > 07 draft of SPC-3 correct? The variable length CDB structure (spc3r07 table 7) has an 8 byte header, with a one byte ADDITIONAL CDB LENGTH field indicating the additional size in bytes. That field must be a multiple of 4, so the maximum value is 252, restricting the maximum CDB length to 260 bytes. > 2. Is it intended that the maximum length of ExtendedCDB > field in the iSCSI Extended CDB AHS comes from SPC-3? The iSCSI AHS carries bytes 16-259 of a variable length CDB. The 2-byte AHSLength field needs to contain a value big enough to hold the CDB. It should be 8 less than the ADDITIONAL CDB LENGTH field in the CDB itself. > ... > Mike Smith > CTO, iReady -- Rob Elliott, elliott@hp.com Industry Standard Server Storage Advanced Technology Hewlett-Packard From owner-ips@ece.cmu.edu Thu Jun 13 09:04:26 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10472 for ; Thu, 13 Jun 2002 09:04:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DBnfJ17425 for ips-outgoing; Thu, 13 Jun 2002 07:49:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DBndw17421 for ; Thu, 13 Jun 2002 07:49:39 -0400 (EDT) Received: from mail pickup service by mail5.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 07:34:24 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Wed, 12 Jun 2002 09:14:12 -0400 Received: from ruebert.ieee.org (ruebert.ieee.org [140.98.193.10]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5CDEBbC017656 for ; Wed, 12 Jun 2002 09:14:11 -0400 (EDT) Received: from ece.cmu.edu (gemini3.ieee.org [140.98.193.25]) by ruebert.ieee.org (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5CDCuq14293; Wed, 12 Jun 2002 09:12:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CD4fb26711 for ips-outgoing; Wed, 12 Jun 2002 09:04:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CD4dw26706 for ; Wed, 12 Jun 2002 09:04:39 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5CD4RZm022696; Wed, 12 Jun 2002 15:04:27 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5CD4NM24942; Wed, 12 Jun 2002 15:04:23 +0200 To: "Rod Harrison" Cc: "Mallikarjun C." , ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: changing MaxPDUDataLength X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 12 Jun 2002 16:04:14 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 12/06/2002 16:04:26, Serialize complete at 12/06/2002 16:04:26 Content-Type: multipart/alternative; boundary="=_alternative 004731E7C2256BD6_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004731E7C2256BD6_= Content-Type: text/plain; charset="us-ascii" Rod, It is clearly missing. I was thinking at something benign like using it an indication that target wants to negotiate. Logout - inititaor is always free to use but it may want to issue a text. Julo "Rod Harrison" 06/12/2002 02:57 AM Please respond to "Rod Harrison" To: Julian Satran/Haifa/IBM@IBMIL, "Mallikarjun C." cc: Subject: RE: iSCSI: changing MaxPDUDataLength I'm torn, I don't want to make this sort of change late on but I think it would be a good thing in the long term. How about adding the additional async message code and saying upon receipt the initiator MAY start a negotiation sequence or logout and re-login the connection immediately without having to wait for the negotiated timeouts? - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Tuesday, June 11, 2002 4:28 PM To: Mallikarjun C. Cc: ips@ece.cmu.edu; Julian Satran; owner-ips@ece.cmu.edu Subject: Re: iSCSI: changing MaxPDUDataLength Importance: High Mallikarjun, The question was general and not specific to MaxRecv.... Although we say that negotiation is symmetric we don't have any mechanism through which a target can say it wants to start negotiation something (sort of similar but not as strong as a the "request logout" - "request to negotiate" that will require the initiator to issue a text request and kick-off a negotiation. Julo "Mallikarjun C." To: , Julian Satran/Haifa/IBM@IBMIL Sent by: cc: owner-ips@ece.cmu Subject: Re: iSCSI: changing MaxPDUDataLength .edu 06/11/2002 10:50 PM Please respond to "Mallikarjun C." > I also realized that we don't have "negotiation prompt" from the target. > I am not sure that we need one. I am not sure about it either. My preference is not to add this. It appears to me that a target does have the option of dropping the connection today if it can't work with non-ULPDU-contained segments for too long. I suspect that the target would do the same if (we introduced the "negotiation prompt" and) the initiator doesn't/couldn't honor the "negotiation prompt". Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Julian Satran" To: Sent: Tuesday, June 11, 2002 8:34 AM Subject: RE: iSCSI: changing MaxPDUDataLength > I suggest the following text in 11.13 > > A change of MaxRecvDataSegmentLength by an initiator or target > becomes effective after all commands preceding the negotiation > end-ing request have been processed by the target and their status > is acknowledged. > > I also realized that we don't have "negotiation prompt" from the target. > I am not sure that we need one. > If some of you think we need we may want one additional code in the Asynch > Message. > Please comment TODAY. > > Julo > ----- Forwarded by Julian Satran/Haifa/IBM on 06/11/2002 06:29 PM ----- > > Julian Satran > To: Eddy Quicksall > 06/11/2002 04:04 cc: ips@ece.cmu.edu, pat_thaler@agilent.com > PM From: Julian Satran/Haifa/IBM@IBMIL > Subject: RE: iSCSI: changing MaxPDUDataLength(Document link: Julian Satran - Mail) > > > > > > > > > > That is a fair request - we may slip in a recommendation to that effect (in > chapter 11?) > > Julo > > > > Eddy Quicksall > vivity.com> cc: ips@ece.cmu.edu, pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > 06/11/2002 04:28 > AM > Please respond to > Eddy Quicksall > > > > > > How about if we say that an initiator must not change the MaxPDUDataSize > unless it first idles the commands (at least the ones with the R bit) or if > ErrorRecoveryLevel==0? > > That would simplify target code greatly and would meet the design goals; > and since it should be rare to change it, it would be of little impact to > idle the commands for a split second. > > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Monday, June 10, 2002 8:06 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > I said only that when you change length you can ask for all PDUs > after the ack! (no need to keep a tall - the old offsets are good up > to the hole). > > Julo > > > Eddy Quicksall > To: Julian > Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu, > 06/11/2002 12:32 AM pat_thaler@agilent.com > Please respond to Eddy Quicksall Subject: RE: iSCSI: > changing MaxPDUDataLength > > > > > > > > Julian, > > Another problem here is that the target has to calculate the offset > from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and > RunLngth=0 means starting DataSN=4, send all the data for that > sequence. > > I think it would be a performance hit and waist of memory to keep a > tally of all PDU sizes just for an occasional SNACK. > > It's not that it can't be done ... it is more that it is messy and I > think there is a solution that will satisfy the design requirements > but keep the software simpler. > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Saturday, June 08, 2002 10:16 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > That is not completely accurate. > The only problem is when PDU size decreases and then SNACK must be > for all data. > Target can also keep a mapping of numbers/to offsets (the list should > be small and if it gets long ask for ack (A-bit). > > Julo > > Eddy Quicksall > To: > Sent by: owner-ips@ece.cmu.edu pat_thaler@agilent.com > cc: ips@ece.cmu.edu > Subject: RE: iSCSI: > 06/08/2002 10:54 PM changing MaxPDUDataLength > Please respond to Eddy Quicksall > > > > > > > > Thanks, > > As a target, I won't be able to let it change until all of the > outstanding > commands are finished (running with ErrorRecoveryLevel>=1). This is > because > I must use the PDU size to compute the offset from a SNACK's > BegRun/RunLength. > > So, I plan to not give the text response for a MaxPDURecvDataLength > in FFP > until I get back an ExpStatSN == next StatSN. > > This will cause a delay of unknown time before the PDU size can > actually > change ... do you see any problem with this? > > Eddy > > -----Original Message----- > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > Sent: Friday, June 07, 2002 1:13 PM > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > Subject: RE: iSCSI: changing MaxPDUDataLength > > > Eddy, > > If one uses a message sync and steering that relys on the transport > segments > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the > path > MTU changes one would want to change the PDU data length to fit the > new path > MTU. > > Pat > > -----Original Message----- > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > Sent: Wednesday, June 05, 2002 12:24 PM > To: ips@ece.cmu.edu > Subject: iSCSI: changing MaxPDUDataLength > > > Does anybody know a case where it is necessary to support a new PDU > data > length during full feature phase? > > Eddy > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > > > --=_alternative 004731E7C2256BD6_= Content-Type: text/html; charset="us-ascii"
Rod,

It is clearly missing. I was thinking at something benign like using it an indication that target wants to negotiate.
Logout - inititaor is always free to use but it may want to issue a text.

Julo


"Rod Harrison" <rod.harrison@windriver.com>

06/12/2002 02:57 AM
Please respond to "Rod Harrison"

       
        To:        Julian Satran/Haifa/IBM@IBMIL, "Mallikarjun C." <cbm@rose.hp.com>
        cc:        <ips@ece.cmu.edu>
        Subject:        RE: iSCSI: changing MaxPDUDataLength

       



                I'm torn, I don't want to make this sort of change late on but I
think it would be a good thing in the long term.

                How about adding the additional async message code and saying upon
receipt the initiator MAY start a negotiation sequence or logout and
re-login the connection immediately without having to wait for the
negotiated timeouts?

                - Rod

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Julian Satran
Sent: Tuesday, June 11, 2002 4:28 PM
To: Mallikarjun C.
Cc: ips@ece.cmu.edu; Julian Satran; owner-ips@ece.cmu.edu
Subject: Re: iSCSI: changing MaxPDUDataLength
Importance: High



Mallikarjun,

The question was general and not specific to MaxRecv....
Although we say that negotiation is symmetric we don't have any
mechanism
through which a target can say it wants to start negotiation something
(sort of similar but not as strong as a the "request logout" -
"request to
negotiate" that will require the initiator to issue a text request and
kick-off a negotiation.

Julo



                     "Mallikarjun C."
                     <cbm@rose.hp.com>        To:
<ips@ece.cmu.edu>, Julian Satran/Haifa/IBM@IBMIL
                     Sent by:                 cc:
                     owner-ips@ece.cmu        Subject:  Re: iSCSI:
changing MaxPDUDataLength
                     .edu


                     06/11/2002 10:50
                     PM
                     Please respond to
                     "Mallikarjun C."





>  I also realized that we don't have "negotiation prompt" from the
target.
>  I am not sure that we need one.

I am not sure about it either.

My preference is not to add this.  It appears to me that a target does
have
the option of dropping the connection today if it can't work with
non-ULPDU-contained
segments for too long.  I suspect that the target would do the same if
(we
introduced the "negotiation prompt" and) the initiator
doesn't/couldn't
honor the
"negotiation prompt".

Thanks.
--
Mallikarjun

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


----- Original Message -----
From: "Julian Satran" <Julian_Satran@il.ibm.com>
To: <ips@ece.cmu.edu>
Sent: Tuesday, June 11, 2002 8:34 AM
Subject: RE: iSCSI: changing MaxPDUDataLength


> I suggest the following text in 11.13
>
>        A change of MaxRecvDataSegmentLength by an initiator or
target
>        becomes effective after all commands preceding the
negotiation
>        end-ing request have been processed by the target and their
status
>        is acknowledged.
>
>  I also realized that we don't have "negotiation prompt" from the
target.
>  I am not sure that we need one.
>  If some of you think we need we may want one additional code in the
Asynch
>  Message.
>  Please comment TODAY.
>
>  Julo
> ----- Forwarded by Julian Satran/Haifa/IBM on 06/11/2002 06:29
PM -----
>
>                       Julian Satran
>                                                To:      Eddy
Quicksall
<eddy_quicksall@ivivity.com>
>                       06/11/2002 04:04         cc:
ips@ece.cmu.edu,
pat_thaler@agilent.com

>                       PM                       From:    Julian
Satran/Haifa/IBM@IBMIL
>                                                Subject: RE: iSCSI:
changing MaxPDUDataLength(Document link:
Julian Satran - Mail)
>
>
>
>
>
>
>
>
>
> That is a fair request - we may slip in a recommendation to that
effect
(in
> chapter 11?)
>
> Julo
>
>
>
>                       Eddy Quicksall
>                       <eddy_quicksall@i        To:       Julian
Satran/Haifa/IBM@IBMIL
>                       vivity.com>              cc:
ips@ece.cmu.edu,
pat_thaler@agilent.com
>                                                Subject:  RE: iSCSI:
changing MaxPDUDataLength
>                       06/11/2002 04:28
>                       AM
>                       Please respond to
>                       Eddy Quicksall
>
>
>
>
>
> How about if we say that an initiator must not change the
MaxPDUDataSize
> unless it first idles the commands (at least the ones with the R
bit) or
if
> ErrorRecoveryLevel==0?
>
> That would simplify target code greatly and would meet the design
goals;
> and since it should be rare to change it, it would be of little
impact to
> idle the commands for a split second.
>
>
> Eddy
>       -----Original Message-----
>       From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
>       Sent: Monday, June 10, 2002 8:06 PM
>       To: Eddy Quicksall
>       Cc: ips@ece.cmu.edu; pat_thaler@agilent.com
>       Subject: RE: iSCSI: changing MaxPDUDataLength
>
>
>       I said only that when you change length you can ask for all
PDUs
>       after the ack! (no need to keep a tall - the old offsets are
good
up
>       to the hole).
>
>       Julo
>
>
>    Eddy Quicksall
>    <eddy_quicksall@ivivity.com>              To:        Julian
>                                      Satran/Haifa/IBM@IBMIL
>                                              cc:
ips@ece.cmu.edu,
>    06/11/2002 12:32 AM               pat_thaler@agilent.com
>    Please respond to Eddy Quicksall          Subject:        RE:
iSCSI:
>                                      changing MaxPDUDataLength
>
>
>
>
>
>
>
>       Julian,
>
>       Another problem here is that the target has to calculate the
offset
>       from the DataSN #. And as BegRun can be any value. E.g.,
BegRun=4
and
>       RunLngth=0 means starting DataSN=4, send all the data for that
>       sequence.
>
>       I think it would be a performance hit and waist of memory to
keep a
>       tally of all PDU sizes just for an occasional SNACK.
>
>       It's not that it can't be done ... it is more that it is messy
and
I
>       think there is a solution that will satisfy the design
requirements
>       but keep the software simpler.
>
>       Eddy
>       -----Original Message-----
>       From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
>       Sent: Saturday, June 08, 2002 10:16 PM
>       To: Eddy Quicksall
>       Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu;
pat_thaler@agilent.com
>       Subject: RE: iSCSI: changing MaxPDUDataLength
>
>
>       That is not completely accurate.
>       The only problem is when PDU size decreases and then SNACK
must be
>       for all data.
>       Target can also keep a mapping of numbers/to offsets (the list
should
>       be small and if it gets long ask for ack (A-bit).
>
>       Julo
>
>    Eddy Quicksall
>    <eddy_quicksall@ivivity.com>             To:
>    Sent by: owner-ips@ece.cmu.edu    pat_thaler@agilent.com
>                                             cc:
ips@ece.cmu.edu
>                                             Subject:        RE:
iSCSI:
>    06/08/2002 10:54 PM               changing MaxPDUDataLength
>    Please respond to Eddy Quicksall
>
>
>
>
>
>
>
>       Thanks,
>
>       As a target, I won't be able to let it change until all of the
>       outstanding
>       commands are finished (running with ErrorRecoveryLevel>=1).
This is
>       because
>       I must use the PDU size to compute the offset from a SNACK's
>       BegRun/RunLength.
>
>       So, I plan to not give the text response for a
MaxPDURecvDataLength
>       in FFP
>       until I get back an ExpStatSN == next StatSN.
>
>       This will cause a delay of unknown time before the PDU size
can
>       actually
>       change ... do you see any problem with this?
>
>       Eddy
>
>       -----Original Message-----
>       From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]
>       Sent: Friday, June 07, 2002 1:13 PM
>       To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu
>       Subject: RE: iSCSI: changing MaxPDUDataLength
>
>
>       Eddy,
>
>       If one uses a message sync and steering that relys on the
transport
>       segments
>       carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then
if
the
>       path
>       MTU changes one would want to change the PDU data length to
fit the
>       new path
>       MTU.
>
>       Pat
>
>       -----Original Message-----
>       From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com]
>       Sent: Wednesday, June 05, 2002 12:24 PM
>       To: ips@ece.cmu.edu
>       Subject: iSCSI: changing MaxPDUDataLength
>
>
>       Does anybody know a case where it is necessary to support a
new PDU
>       data
>       length during full feature phase?
>
>       Eddy
>       mailto: Eddy_Quicksall@iVivity.com
>
>
>
>
>
>
>
>
>
>

--=_alternative 004731E7C2256BD6_=-- From owner-ips@ece.cmu.edu Thu Jun 13 09:53:39 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12481 for ; Thu, 13 Jun 2002 09:53:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DCvNF20813 for ips-outgoing; Thu, 13 Jun 2002 08:57:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DCvGw20789 for ; Thu, 13 Jun 2002 08:57:16 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5DCv5f9043046; Thu, 13 Jun 2002 14:57:06 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5DCv5B83032; Thu, 13 Jun 2002 14:57:05 +0200 To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu, mkrikis@yahoo.com, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: base64 byte-length formula X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 13 Jun 2002 15:57:03 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 13/06/2002 15:57:05, Serialize complete at 13/06/2002 15:57:05 Content-Type: multipart/alternative; boundary="=_alternative 0046B153C2256BD7_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0046B153C2256BD7_= Content-Type: text/plain; charset="us-ascii" Pat, I think you are talking about the formula in 12-96 and I am talking about the one in 12-98. Martins formula and mine are equivalent for good encodings. As I said I made it up only to account for encodings that are in fact impossible - like 1, 4 ... 4*n+1 base 64 digits. And I will put in Martins formula with a note about the impossible numbers. Can we stop this thread? Julo pat_thaler@agilent.com 06/13/2002 03:33 AM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL, mkrikis@yahoo.com cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: base64 byte-length formula Julian, The formula in 12-97 is: ((the integer part of)((n+3)*3/4) - m) Martins formula 3*3/4 where / indictates integer divide. The encoding of 1 octet in base64 results in 2 characters plus 2 equal signs. n=2, m=2. Martins formula = 2 *3/4 = 1 (truncated to an integer) right answer integer part of ((2+3)*3/4)-1 = (integer part of 15/4) - 2 = 3 - 2 = 1 right answer The encoding of 2 octets in base64 results in 3 characters plus one equal sign. n=3, m=1. Martins formula = 3 *3/4 = 2 (truncated to an integer) right answer integer part of ((3+3)*3/4)-1 = (integer part of 18/4) -1 = 4 - 1 = 3 wrong answer The encoding of 3 octets in base64 results in 4 characters plus no equal sign. n=4, m=0. Martins formula = 4 *3/4 = 3 (truncated to an integer) right answer integer part of ((4+3)*3/4)-1 = (integer part of 21/4) -0 = 5 - 1 = 4 wrong answer Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 4:56 PM To: Martins Krikis Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: base64 byte-length formula I said already that your formula is correct. I do not understand why you say that the 2 formulas are not equivalent for all the lengths (good aor bad)? I would appreciate if you respond although you don't have to. Julo Martins Krikis Sent by: owner-ips@ece.cmu.edu 06/13/2002 02:34 AM Please respond to Martins Krikis To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: base64 byte-length formula --- Julian Satran wrote: > The difference between our formulas is that I > (mistakenly) took 1 digit as > a possible string (or 5, 9 etc.) > For those you need the +3 TERM. > > For all the good length 2,3,4 6,7,8 etc the two > formulas are equivalent. No they are not. They are only equivalent for n = 0 (mod 4). So I'm still insisting that n * 3 / 4 is the simplest right formula. Martins Krikis, Intel Corp. Disclaimer: these are my opinions and may not be Intel's. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com --=_alternative 0046B153C2256BD7_= Content-Type: text/html; charset="us-ascii"
Pat,

I think you are talking about the formula in 12-96 and I am talking about the one in 12-98.
Martins formula and mine are equivalent for good encodings.
As I said I made it up only to account for encodings that are in fact impossible - like 1, 4 ... 4*n+1 base 64 digits.
And I will  put in Martins formula with a note about the impossible numbers.
Can we stop this thread?

Julo


pat_thaler@agilent.com

06/13/2002 03:33 AM
Please respond to pat_thaler

       
        To:        Julian Satran/Haifa/IBM@IBMIL, mkrikis@yahoo.com
        cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
        Subject:        RE: base64 byte-length formula

       


Julian,

The formula in 12-97 is:
((the integer part of)((n+3)*3/4) - m)

Martins formula 3*3/4 where / indictates integer divide.

The encoding of 1 octet in base64 results in 2 characters plus 2 equal
signs.
n=2, m=2.

Martins formula = 2 *3/4 = 1 (truncated to an integer)  right answer

integer part of ((2+3)*3/4)-1 = (integer part of 15/4) - 2 = 3 - 2 = 1 right
answer


The encoding of 2 octets in base64 results in 3 characters plus one equal
sign.
n=3, m=1.

Martins formula = 3 *3/4 = 2 (truncated to an integer)  right answer

integer part of ((3+3)*3/4)-1 = (integer part of 18/4) -1 = 4 - 1 = 3 wrong
answer

The encoding of 3 octets in base64 results in 4 characters plus no equal
sign.
n=4, m=0.

Martins formula = 4 *3/4 = 3 (truncated to an integer)  right answer

integer part of ((4+3)*3/4)-1 = (integer part of 21/4) -0 = 5 - 1 = 4 wrong
answer

Pat

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 12, 2002 4:56 PM
To: Martins Krikis
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: base64 byte-length formula



I said already that your formula is correct.
I do not understand why you say that the 2 formulas are not equivalent for
all the lengths (good aor bad)?
I would appreciate if you respond although you don't have to.

Julo


Martins Krikis <mkrikis@yahoo.com>
Sent by: owner-ips@ece.cmu.edu
06/13/2002 02:34 AM
Please respond to Martins Krikis
       
       To:        Julian Satran/Haifa/IBM@IBMIL
       cc:        ips@ece.cmu.edu
       Subject:        Re: base64 byte-length formula

     



--- Julian Satran <Julian_Satran@il.ibm.com> wrote:

> The difference between our formulas is that I
> (mistakenly) took 1 digit as
> a possible string (or 5, 9 etc.)
> For those you need the +3 TERM.
>
> For all the good length 2,3,4 6,7,8 etc the two
> formulas are equivalent.

No they are not. They are only equivalent for
n = 0 (mod 4). So I'm still insisting that
n * 3 / 4 is the simplest right formula.

Martins Krikis, Intel Corp.

Disclaimer: these are my opinions and
          may not be Intel's.


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--=_alternative 0046B153C2256BD7_=-- From owner-ips@ece.cmu.edu Thu Jun 13 09:54:29 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12540 for ; Thu, 13 Jun 2002 09:54:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DDSmt22556 for ips-outgoing; Thu, 13 Jun 2002 09:28:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DDSkw22552 for ; Thu, 13 Jun 2002 09:28:46 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5DDSDE8033618; Thu, 13 Jun 2002 15:28:14 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5DDSCq119102; Thu, 13 Jun 2002 15:28:12 +0200 To: "Ofer Biran" Cc: Black_David@emc.com, ips@ece.cmu.edu, owner-ips@ece.cmu.edu, ssenum@cisco.com MIME-Version: 1.0 Subject: RE: iSCSI: 7.2.1 CHAP Considerations (12-98) X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 13 Jun 2002 16:28:10 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 13/06/2002 16:28:12, Serialize complete at 13/06/2002 16:28:12 Content-Type: multipart/alternative; boundary="=_alternative 0049E7EBC2256BD7_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0049E7EBC2256BD7_= Content-Type: text/plain; charset="us-ascii" The text I would suggest in 7.2.1 is: If an initiator or target generates or verifies a CHAP secret that has less than 96 random bits then IPsec encryption (according to the implementation requirements in Section 7.3.2 Confidentiality) MUST be used to protect the connection. Moreover, in this case IKE authenti-cation with group pre-shared keys SHOULD NOT be used unless it is not essential to protect group members against off-line dictionary attacks by other members. When CHAP is used with secret shorter than 96 bits, a compliant implementation MUST NOT continue with the login unless it can verify that IPsec encryption is being used to protect the connection. Julo Ofer Biran/Haifa/IBM@IBMIL Sent by: owner-ips@ece.cmu.edu 06/13/2002 11:53 AM Please respond to Ofer Biran To: Black_David@emc.com cc: ssenum@cisco.com, ips@ece.cmu.edu Subject: RE: iSCSI: 7.2.1 CHAP Considerations (12-98) How about: When CHAP is used with secret shorter than 96 bits, a compliant implementation MUST NOT continue with the login step in which it should send a CHAP response (CHAP_R - see 10.5) unless it can verify that IPsec encryption is being used to protect the connection. On initiator-only authentication this puts the responsibility only on the initiator implementation who surely knows the secret and its length. Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 Black_David@emc.com@ece.cmu.edu on 13/06/2002 02:26:07 Please respond to Black_David@emc.com Sent by: owner-ips@ece.cmu.edu To: ssenum@cisco.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: 7.2.1 CHAP Considerations (12-98) Yes, my intent was to modify the draft text to include the "essential condition" described below. --David > -----Original Message----- > From: Steve Senum [mailto:ssenum@cisco.com] > Sent: Wednesday, June 12, 2002 6:14 PM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: 7.2.1 CHAP Considerations (12-98) > > > David, > > What you state would be better, but that is > not what the current text (as of 12-98) says. > > Steve Senum > > Black_David@emc.com wrote: > > > > I think the essential condition here is that the > > "do not continue if secret is shorter than 96 bits" > > criteria should apply only to implementations that > > know and use the secret (i.e., generators of CHAP > > responses, and recipients of those responses that > > do their own verification as opposed to outsourcing > > that verification to something like a RADIUS server). > > > > Thanks, > > --David > > --------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > > black_david@emc.com Cell: +1 (978) 394-7754 > > --------------------------------------------------- > > > > > -----Original Message----- > > > From: Steve Senum [mailto:ssenum@cisco.com] > > > Sent: Wednesday, June 12, 2002 3:58 PM > > > To: Julian Satran > > > Cc: ietf-ips > > > Subject: Re: iSCSI: 7.2.1 CHAP Considerations (12-98) > > > > > > > > > Julian, > > > > > > In the case where an iSCSI Target is authenticating > > > an iSCSI Initiator, the Target sends a CHAP > > > challenge and identifier, and the Initiator sends > > > back a CHAP response and username. > > > > > > In the case were the Target is using the RADIUS > > > protocol, these four pieces of information are > > > sent by the Target to a RADIUS server, which > > > simply gives an accept or reject reply. The target > > > never has access to the CHAP secret (which is good), > > > hence no check can be made on its length. > > > > > > Regards, > > > Steve Senum > > > > > > Julian Satran wrote: > > > > > > > > can you elaborate? Julo > > > > > > > > Steve Senum > > > > Sent by: owner-ips@ece.cmu.edu To: ietf-ips > > > > > > > > 06/12/2002 09:32 PM cc: > > > > Please respond to Steve Senum Subject: > > > iSCSI: 7.2.1 CHAP > > > > Considerations (12-98) > > > > > > > > > > > > > > > > I have a concern over the wording of the > > > > following text from section 7.2.1 (12-98 version): > > > > > > > > When CHAP is used with secret shorter than 96 bits, > > > > a compliant implementation MUST NOT continue with > > > > the login unless it can verify that IPsec encryption > > > > is being used to protect the connection. > > > > > > > > I know the above is attempt to "put some teeth" into > > > > the requirements to make the use of CHAP secure, > > > > but I believe there are common cases where the > > > > length of the CHAP secret cannot be verified, such > > > > as when a RADIUS server is being used. > > > > > > > > Regards, > > > > Steve Senum > > > > --=_alternative 0049E7EBC2256BD7_= Content-Type: text/html; charset="us-ascii"
The text I would suggest in 7.2.1 is:

If an initiator or target generates or verifies a CHAP secret that has less than 96 random bits then IPsec encryption (according to the implementation requirements in Section 7.3.2 Confidentiality) MUST be used to protect the connection. Moreover, in this case IKE authenti-cation with group pre-shared keys SHOULD NOT be used unless it is not essential to protect group members against off-line dictionary attacks by other members. When CHAP is used with secret shorter than 96 bits, a compliant implementation MUST NOT continue with the login unless it can verify that IPsec encryption is being used to protect the connection.

Julo


Ofer Biran/Haifa/IBM@IBMIL
Sent by: owner-ips@ece.cmu.edu

06/13/2002 11:53 AM
Please respond to Ofer Biran

       
        To:        Black_David@emc.com
        cc:        ssenum@cisco.com, ips@ece.cmu.edu
        Subject:        RE: iSCSI: 7.2.1 CHAP Considerations (12-98)

       



How about:

 When CHAP is used with secret shorter than 96 bits,
 a compliant implementation MUST NOT continue with
 the login step in which it should send a CHAP response
 (CHAP_R - see 10.5) unless it can verify that IPsec
 encryption is being used to protect the connection.

On initiator-only authentication this puts the responsibility
only on the initiator implementation who surely knows the
secret and its length.


 Regards,
    Ofer


Ofer Biran
Storage and Systems Technology
IBM Research Lab in Haifa
biran@il.ibm.com  972-4-8296253


Black_David@emc.com@ece.cmu.edu on 13/06/2002 02:26:07

Please respond to Black_David@emc.com

Sent by:    owner-ips@ece.cmu.edu


To:    ssenum@cisco.com
cc:    ips@ece.cmu.edu
Subject:    RE: iSCSI: 7.2.1 CHAP Considerations (12-98)



Yes, my intent was to modify the draft text to include the
"essential condition" described below.  --David

> -----Original Message-----
> From: Steve Senum [mailto:ssenum@cisco.com]
> Sent: Wednesday, June 12, 2002 6:14 PM
> To: Black_David@emc.com
> Cc: ips@ece.cmu.edu
> Subject: Re: iSCSI: 7.2.1 CHAP Considerations (12-98)
>
>
> David,
>
> What you state would be better, but that is
> not what the current text (as of 12-98) says.
>
> Steve Senum
>
> Black_David@emc.com wrote:
> >
> > I think the essential condition here is that the
> > "do not continue if secret is shorter than 96 bits"
> > criteria should apply only to implementations that
> > know and use the secret (i.e., generators of CHAP
> > responses, and recipients of those responses that
> > do their own verification as opposed to outsourcing
> > that verification to something like a RADIUS server).
> >
> > Thanks,
> > --David
> > ---------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > +1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
> > black_david@emc.com         Cell: +1 (978) 394-7754
> > ---------------------------------------------------
> >
> > > -----Original Message-----
> > > From: Steve Senum [mailto:ssenum@cisco.com]
> > > Sent: Wednesday, June 12, 2002 3:58 PM
> > > To: Julian Satran
> > > Cc: ietf-ips
> > > Subject: Re: iSCSI: 7.2.1 CHAP Considerations (12-98)
> > >
> > >
> > > Julian,
> > >
> > > In the case where an iSCSI Target is authenticating
> > > an iSCSI Initiator, the Target sends a CHAP
> > > challenge and identifier, and the Initiator sends
> > > back a CHAP response and username.
> > >
> > > In the case were the Target is using the RADIUS
> > > protocol, these four pieces of information are
> > > sent by the Target to a RADIUS server, which
> > > simply gives an accept or reject reply.  The target
> > > never has access to the CHAP secret (which is good),
> > > hence no check can be made on its length.
> > >
> > > Regards,
> > > Steve Senum
> > >
> > > Julian Satran wrote:
> > > >
> > > > can you elaborate? Julo
> > > >
> > > >   Steve Senum <ssenum@cisco.com>
> > > >   Sent by: owner-ips@ece.cmu.edu         To:        ietf-ips
> > > >                                  <ips@ece.cmu.edu>
> > > >   06/12/2002 09:32 PM                    cc:
> > > >   Please respond to Steve Senum          Subject:
> > > iSCSI: 7.2.1 CHAP
> > > >                                  Considerations (12-98)
> > > >
> > > >
> > > >
> > > > I have a concern over the wording of the
> > > > following text from section 7.2.1 (12-98 version):
> > > >
> > > >    When CHAP is used with secret shorter than 96 bits,
> > > >    a compliant implementation MUST NOT continue with
> > > >    the login unless it can verify that IPsec encryption
> > > >    is being used to protect the connection.
> > > >
> > > > I know the above is attempt to "put some teeth" into
> > > > the requirements to make the use of CHAP secure,
> > > > but I believe there are common cases where the
> > > > length of the CHAP secret cannot be verified, such
> > > > as when a RADIUS server is being used.
> > > >
> > > > Regards,
> > > > Steve Senum
> > >
>

--=_alternative 0049E7EBC2256BD7_=-- From owner-ips@ece.cmu.edu Thu Jun 13 09:58:26 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12721 for ; Thu, 13 Jun 2002 09:58:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DDI3b21930 for ips-outgoing; Thu, 13 Jun 2002 09:18:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DDHtw21921; Thu, 13 Jun 2002 09:18:00 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5DDHl4L055790; Thu, 13 Jun 2002 15:17:47 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5DDHhB41086; Thu, 13 Jun 2002 15:17:47 +0200 To: Dennis Young Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iscsi: unsolicited data question X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 13 Jun 2002 16:17:39 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 13/06/2002 16:17:47, Serialize complete at 13/06/2002 16:17:47 Content-Type: multipart/alternative; boundary="=_alternative 0048349FC2256BD7_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0048349FC2256BD7_= Content-Type: text/plain; charset="us-ascii" Not exactly - an initiator may decide to send only non immediate or only immediate in the first case the absence of F is the sign of things to come and in the later F indicates nothing will come. The later is allowed. Julo Dennis Young 06/13/2002 04:00 AM Please respond to Dennis Young To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Thanks to yours and others' explanation, now I am more clear, but I have another question: Based on your reply, and let me emphasize it by repeating the 4th paragraph on page 42 of draft 12-98: "... If any non-immediate unsolicited data are sent, the total unsolicited data MUST be either the negotiated amount or all the data if the total amount is less than the negotiated amount for unsolicited data. ..." With this rule, do we still need the F bit in the Data-out (both for the solicited and unsolicited Data-out)? The F bit seems redundant since the target has enough information to figure out the final unsolicited Data-out and the final solicited Data-out (based on the FirstBurstSize, Offset and DataSegmentLength in the Data-out, and the ExpectedDataTransferLength in the corresponding SCSI Write PDU). Thanks, Dennis -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 11:21 AM To: Dennis Young Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question You are wrong about waiting - read my previous text. You need unsolicited as the amount in one PDU may not be all you want. Julo Dennis Young Sent by: owner-ips@ece.cmu.edu 06/12/2002 08:49 PM Please respond to Dennis Young To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Are you saying that, for a session that has InitialR2T=No in effect, the initiator must send all its data as unsolicited first, up to the amount negotiated in FirstBurstSize, before it waits for a R2T from the target? Can you shed some light on why we need unsolicited Data-out PDU when there is ImmediateData, seems like they both serve the same purpose, having both of them only make the spec more complex. Thanks, -Dennis -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 10:19 AM To: Dennis Young Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question This is the reason why the initiator is required to send ALL unsolicited data (target can count on it and start sending R2Ts as soon as it sees the first header> Neither bandwidth nor latency are wasted. Julo Dennis Young 06/12/2002 08:05 PM Please respond to Dennis Young To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Julian, This leads me to a more interesting question. A session with InitialR2T=No in effect, i.e. unsolicited Data-out allowed, could cause unintended waste of bandwidth, depending on how fast the target sends our R2T in response to the SCSI Write. If the target sees the unsolicited Data-out PDU before building the R2T, then everything is fine. If the target doesn't see the unsolicited Data-out PDU before building the R2T, the R2T would request the same portion of data in the unsolicited Data-out, thus bandwidth is wasted. The question is, how can a target be smart about this? Should the target wait a moment for the possible unsolicited Data-out after receiving each SCSI Write, this sounds kludgy. Also, why do we need the unsolicited Data-out PDU feature when there is ImmediateData? Regards, Dennis -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 6:05 AM To: Dennis Young Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iscsi: unsolicited data question yes - julo Dennis Young Sent by: owner-ips@ece.cmu.edu 06/12/2002 06:20 AM Please respond to Dennis Young To: ips@ece.cmu.edu cc: Subject: iscsi: unsolicited data question I have a question which has been asked before, but I couldn't find a direct answer in the archive. The table on page 200 of draft 12 doesn't directly answer this question either. The first paragraph on page 36 of draft 12 says "Targets operate in either solicitied (R2T) data mode or unsolicited (non R2T) data mode." tells me that a target, at all times during a data sequence transfer, can be one or the other, but not both (non R2T for the initial data out, R2T for the remaining data). Is this correct? Thanks, Dennis ---snip from an old email dated 3/30/2001--- " Hi Julian Sorry if I'm covering old ground... Is it possible to use unsolicited data for the first burst and then request any remaining data using R2T? For example, if the target has a previously allocated buffer available (length defined by FirstBurstSize) for unsolicited data, then once the initiator has sent unsolicited data up to and including this amount then the remaining data (if any) can be requested using R2T once the target has the buffer space available. ...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail: matthewb@bri.hp.com " --=_alternative 0048349FC2256BD7_= Content-Type: text/html; charset="us-ascii"
Not exactly - an initiator may decide to send only non immediate or only immediate in the first case the absence of F is the sign of things to come and in the later F indicates nothing will come. The later is allowed.

Julo


Dennis Young <dyoung@rhapsodynetworks.com>

06/13/2002 04:00 AM
Please respond to Dennis Young

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
        Subject:        RE: iscsi: unsolicited data question

       


Thanks to yours and others' explanation, now I am more clear, but I have
another question:
 
Based on your reply, and let me emphasize it by repeating the 4th paragraph
on page 42 of draft 12-98:
    "... If any non-immediate unsolicited data are sent, the total unsolicited
    data MUST be either the negotiated amount or all the data if the total
    amount is less than the negotiated amount for unsolicited data. ..."
 
With this rule, do we still need the F bit in the Data-out (both for the solicited
and unsolicited Data-out)?  The F bit seems redundant since the target has
enough information to figure out the final unsolicited Data-out and the final
solicited Data-out (based on the FirstBurstSize, Offset and DataSegmentLength
in the Data-out, and the ExpectedDataTransferLength in the corresponding
SCSI Write PDU).
 
Thanks,
Dennis
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 12, 2002 11:21 AM
To: Dennis Young
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iscsi: unsolicited data question

You are wrong about waiting - read my previous text.
You need unsolicited as the amount in one PDU may not be all you want.

Julo

Dennis Young <dyoung@rhapsodynetworks.com>
Sent by: owner-ips@ece.cmu.edu

06/12/2002 08:49 PM
Please respond to Dennis Young

       
       To:        Julian Satran/Haifa/IBM@IBMIL
       cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
       Subject:        RE: iscsi: unsolicited data question

     



Are you saying that, for a session that has InitialR2T=No in effect, the initiator
must send all its data as unsolicited first, up to the amount negotiated in
FirstBurstSize, before it waits for a R2T from the target?
 
Can you shed some light on why we need unsolicited Data-out PDU when there
is ImmediateData, seems like they both serve the same purpose, having both of
them only make the spec more complex.
 
Thanks,
-Dennis
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 12, 2002 10:19 AM
To: Dennis Young
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iscsi: unsolicited data question


This is the reason why the initiator is required to send ALL unsolicited data (target can count on it and start sending R2Ts as soon as it sees the first header>
Neither bandwidth nor latency are wasted.

Julo
Dennis Young <dyoung@rhapsodynetworks.com>

06/12/2002 08:05 PM
Please respond to Dennis Young

       
      To:        Julian Satran/Haifa/IBM@IBMIL
      cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
      Subject:        RE: iscsi: unsolicited data question

     




Julian,

This leads me to a more interesting question.
A session with InitialR2T=No in effect, i.e. unsolicited Data-out
allowed, could cause unintended waste of bandwidth, depending on
how fast the target sends our R2T in response to the SCSI Write.

If the target sees the unsolicited Data-out PDU before building the
R2T, then everything is fine.
If the target doesn't see the unsolicited Data-out PDU before building
the R2T, the R2T would request the same portion of data in the
unsolicited Data-out, thus bandwidth is wasted.

The question is, how can a target be smart about this?
Should the target wait a moment for the possible unsolicited Data-out
after receiving each SCSI Write, this sounds kludgy.

Also, why do we need the unsolicited Data-out PDU feature when
there is ImmediateData?

Regards,
Dennis

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 12, 2002 6:05 AM
To: Dennis Young
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iscsi: unsolicited data question


yes - julo
Dennis Young <dyoung@rhapsodynetworks.com>
Sent by: owner-ips@ece.cmu.edu

06/12/2002 06:20 AM
Please respond to Dennis Young

       
     To:        ips@ece.cmu.edu
     cc:        
     Subject:        iscsi: unsolicited data question

   





I have a question which has been asked before, but I couldn't find a direct
answer in the archive.  The table on page 200 of draft 12 doesn't directly
answer this question either.

The first paragraph on page 36 of draft 12 says "Targets operate in either
solicitied (R2T) data mode or unsolicited (non R2T) data mode."
tells me that a target, at all times during a data sequence transfer, can be

one or the other, but not both (non R2T for the initial data out, R2T for
the
remaining data).  Is this correct?

Thanks,
Dennis

---snip from an old email dated 3/30/2001---

" Hi Julian
Sorry if I'm covering old ground... Is it possible to use unsolicited data
for the first burst and then request any remaining data using R2T? For
example, if the target has a previously allocated buffer available (length
defined by FirstBurstSize) for unsolicited data, then once the initiator has
sent unsolicited data up to and including this amount then the remaining
data (if any) can be requested using R2T once the target has the buffer
space available.
...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail:
matthewb@bri.hp.com "

--=_alternative 0048349FC2256BD7_=-- From owner-ips@ece.cmu.edu Thu Jun 13 11:19:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17200 for ; Thu, 13 Jun 2002 11:19:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DEQYE26052 for ips-outgoing; Thu, 13 Jun 2002 10:26:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail4.nc.rr.com (fe4.southeast.rr.com [24.93.67.51]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DEQVw26048 for ; Thu, 13 Jun 2002 10:26:31 -0400 (EDT) Received: from mail pickup service by mail4.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 10:23:18 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 15:20:47 -0400 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AJKlIa022738 for ; Mon, 10 Jun 2002 15:20:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AIrG805023 for ips-outgoing; Mon, 10 Jun 2002 14:53:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AIrEw05019 for ; Mon, 10 Jun 2002 14:53:14 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 24FFE30706; Mon, 10 Jun 2002 14:53:14 -0400 (EDT) Date: Mon, 10 Jun 2002 11:51:05 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Luben Tuikov Cc: Robert Snively , "'Ken Sandars'" , "Ips Reflector (E-mail)" Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys In-Reply-To: <3D04EED2.5043DCBF@splentec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Mon, 10 Jun 2002, Luben Tuikov wrote: > Bill Studenmund wrote: > > > > I must say that's not what I had in mind when I coined the phrase. I don't > > think the fact we let folks make different choices at MAY points is bad. > > That's the point. > > You (as Paul) didn't read this sentence (quoted here from above): Yes, I did. > Any time you see ``MAY'' or ``may'' in the draft and a target > and initiator arrive at different outcomes _just_ by taking one > or the other route, you have ``compliant-non-interoperability''. > > Which is what you are describing in more ``baby-terms'' below. No, that's not the same thing. You are saying EVERY may/MAY is a problem. I disagree with that. I'll agree that SOME may be a problem, and that we want to find them. The difference is that the ones I recall describe one side as being able to make a choice. If that choice is clearly communicated to the other side, then we are fine. I think we communicate that all of the time, but would appreciate finding out if we don't. > Read my reply to Paul, where I give 2 links to emails > where this is described well -- this has since been fixed > in the draft. Cool! > > *Those* are what I was thinking of when I came up with compliant-non- > > interoperability. :-) > > But you are merely repeating what I'm saying above... (and in my previous > email). No, the difference is I don't think that a MAY automatically lands us in trouble. I agree that most trouble cases start with a MAY, but I don't think the presence of a MAY automatically leads us to trouble. Take care, Bill From owner-ips@ece.cmu.edu Thu Jun 13 11:24:52 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17519 for ; Thu, 13 Jun 2002 11:24:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DEKm525674 for ips-outgoing; Thu, 13 Jun 2002 10:20:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DEKjw25667; Thu, 13 Jun 2002 10:20:45 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5DEKXE8006954; Thu, 13 Jun 2002 16:20:35 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5DEKUB22892; Thu, 13 Jun 2002 16:20:31 +0200 To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Importance: High MIME-Version: 1.0 Subject: Re: iSCSI: 12-97 Bit Rule X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 13 Jun 2002 17:20:28 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 13/06/2002 17:20:30, Serialize complete at 13/06/2002 17:20:30 Content-Type: multipart/alternative; boundary="=_alternative 004DE626C2256BD7_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004DE626C2256BD7_= Content-Type: text/plain; charset="us-ascii" I took out completely the bit rule. I reformulated the CRC text as: The CRC MUST be calculated by a method that produces the same results as the following process: - The PDU bits are considered as the coefficients of a polyno-mial M(x) of degree n-1; bit 7 of the lowest numbered byte is considered the most significant bit (x^n-1), followed by bit 6 of the lowest numbered byte and through bit 0 of the high-est numbered byte (x^0). - The most significant 32 bits are complemented. - The polynomial is multiplied by x^32 then divided by G(x). The generator polynomial produces a remainder R(x) of degree <= 31. - The coefficients of R(x) are considered a 32 bit sequence. - The bit sequence is complemented and the result is the CRC. - the CRC bits are mapped into the digest word - the x^31 coef-ficient in bit 7 of the lowest numbered byte of the digest continuing to through the byte up to the x^24 coefficient in bit 0 of the lowest numbered byte, continuing with the x^23 coefficient in bit 7 of next byte through x^0 in bit 0 of the highest numbered byte. - Computing the CRC over any segment (data or header) extended to include the CRC built using the generator 0x11edc6f41 will get always the value 0x1c2d19ed as its final CRC. This value is given here in its polynomial form - i.e. not mapped as the digest word I hope you will find it less confusing Julo pat_thaler@agilent.com 06/12/2002 08:41 PM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: iSCSI: 12-97 Bit Rule Julian, The bit rule added to 12-97 (1.3.4 page 31) is inconsistant with the clauses above it: Word Rule, Half-Word Rule and Byte Rule. It says "when the sequence of bits has a positional significance (e.g., a modulo 2 polynomial) then bit 7 of the lowest numbered byte is considered the most significant bit (2**n), followed by ...." When bits represent a number, they have positional significance so that sentence applies. However, the other rules apply the opposite significance to the bits within each byte. Also, note that bits represent polynomials at other times than the CRC such as for the purpose of authentication or encryption algorithms and those algorithms do not necessarily use the bit significance of the Bit Rule. The bit rule only applies to bit significance for CRC calculation. Bit Rule should be CRC Bit Rule and the associated text should make it clear that it only applies to the CRC calculation. Since it only applies there, it would be kinder to the reader to put the text in 11.1 rather than making the reader of 11.1 look nearly 200 pages back in the spec. Regards, Pat --=_alternative 004DE626C2256BD7_= Content-Type: text/html; charset="us-ascii"
I took out completely the bit rule.
I reformulated the CRC text as:

The CRC MUST be calculated by a method that produces the same results as the following process:

 - The PDU bits are considered as the coefficients of a polyno-mial M(x) of degree n-1; bit 7 of the lowest numbered byte is considered the most significant bit (x^n-1), followed by bit 6 of the lowest numbered byte and through bit 0 of the high-est numbered byte (x^0).

- The most significant 32 bits are complemented.

- The polynomial is multiplied by x^32 then divided by G(x). The generator polynomial produces a remainder R(x) of degree <= 31.

- The coefficients of R(x) are considered a 32 bit sequence.

- The bit sequence is complemented and the result is the CRC.

- the CRC bits are mapped into the digest word - the x^31 coef-ficient in bit 7 of the lowest numbered byte of the digest continuing to through the byte up to the x^24 coefficient in bit 0 of the lowest numbered byte, continuing with the x^23 coefficient in bit 7 of next byte through x^0 in bit 0 of the highest numbered byte.

- Computing the CRC over any segment (data or header) extended to include the CRC built using the generator 0x11edc6f41 will get always the value 0x1c2d19ed as its final CRC. This value is given here in its polynomial form - i.e. not mapped as the digest word

I hope you will find it less confusing

Julo



pat_thaler@agilent.com

06/12/2002 08:41 PM
Please respond to pat_thaler

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
        Subject:        iSCSI: 12-97 Bit Rule

       


Julian,
 
The bit rule added to 12-97 (1.3.4 page 31) is inconsistant with the clauses above it: Word Rule,  Half-Word Rule and Byte Rule.
 
It says "when the sequence of bits has a positional significance (e.g., a modulo 2 polynomial) then bit 7 of the lowest numbered byte is considered the most significant bit (2**n), followed by ...."
 
When bits represent a number, they have positional significance so that sentence applies. However, the other rules apply the opposite significance to the bits within each byte.
 
Also, note that bits represent polynomials at other times than the CRC such as for the purpose of authentication or encryption algorithms and those algorithms do not necessarily use the bit significance of the Bit Rule. The bit rule only applies to bit significance for CRC calculation.
 
Bit Rule should be CRC Bit Rule and the associated text should make it clear that it only applies to the CRC calculation. Since it only applies there, it would be kinder to the reader to put the text in 11.1 rather than making the reader of 11.1 look nearly 200 pages back in the spec.
 
Regards,
Pat

--=_alternative 004DE626C2256BD7_=-- From owner-ips@ece.cmu.edu Thu Jun 13 11:27:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17619 for ; Thu, 13 Jun 2002 11:27:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DEQUP26043 for ips-outgoing; Thu, 13 Jun 2002 10:26:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail4.nc.rr.com (fe4.southeast.rr.com [24.93.67.51]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DEQTw26039 for ; Thu, 13 Jun 2002 10:26:29 -0400 (EDT) Received: from mail pickup service by mail4.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 10:23:31 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 18:33:46 -0400 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5ALQwtH022737 for ; Mon, 10 Jun 2002 17:26:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AKeHt11551 for ips-outgoing; Mon, 10 Jun 2002 16:40:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AKeFw11544 for ; Mon, 10 Jun 2002 16:40:15 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g5AKfZu10001; Mon, 10 Jun 2002 16:41:35 -0400 Message-ID: <3D050E99.1A33B188@splentec.com> Date: Mon, 10 Jun 2002 16:39:53 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: pat_thaler@agilent.com CC: wrstuden@wasabisystems.com, rsnively@Brocade.COM, ksandars@eurologic.com, ips@ece.cmu.edu Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys References: <1BEBA5E8600DD4119A50009027AF54A00C5E3E7B@axcs04.cos.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit pat_thaler@agilent.com wrote: > > Luben, > > An IETF standard is suppose to produce interoperability. Therefore, when > there is a MAY in the standard, it should be because each side can choose > either option and they will interoperate independent of which they choose. > For example: > > "iSCSI targets and initiators MUST support at least one TCP connection > and MAY support several connections in a session." > A device that supports only one connection per session will interoperate > (over one connection) to a device that supports multiple connections. Pat, please read carefully my reply to Paul. "a target MAY close the connection or may offer its own acceptable values" and "receiving non-offered value is a protocol error" doesn't interoperate. -- Luben From owner-ips@ece.cmu.edu Thu Jun 13 12:15:30 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20087 for ; Thu, 13 Jun 2002 12:15:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DFCpK28981 for ips-outgoing; Thu, 13 Jun 2002 11:12:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DFCnw28974 for ; Thu, 13 Jun 2002 11:12:49 -0400 (EDT) Received: from cisco.com (dhcp-161-44-68-217.cisco.com [161.44.68.217]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA21910; Thu, 13 Jun 2002 11:12:42 -0400 (EDT) Message-ID: <3D08B669.3324F757@cisco.com> Date: Thu, 13 Jun 2002 10:12:41 -0500 From: Steve Senum X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Satran CC: ietf-ips Subject: Re: iSCSI: 7.2.1 CHAP Considerations (12-98) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, Better, but I would suggest: If an initiator or target generates or verifies a CHAP secret that has less than 96 random bits then IPsec encryption (according to the implementation requirements in Section 7.3.2 Confidentiality) MUST be used to protect the connection. Moreover, in this case IKE authentication with group pre-shared keys SHOULD NOT be used unless it is not essential to protect group members against off-line dictionary attacks by other members, and an implementation MUST NOT continue with the login unless it can verify that IPsec encryption is being used to protect the connection. I want to more strongly tie the last requirement to the initial condition. Further comments on this text: 1. I would suggest changing "96 random bits" to "96 bits". I don't think it is practical to verify the number of random bits in a single secret. 2. I would suggest changing the final "MUST NOT" to a "SHOULD NOT". As with IKE pre-shared keys, the need to protect against off-line dictionary attacks is ultimately a local deployment consideration. Regards, Steve Senum Julian Satran wrote: > > The text I would suggest in 7.2.1 is: > > If an initiator or target generates or verifies a CHAP secret that has less > than 96 random bits then IPsec encryption (according to the implementation > requirements in Section 7.3.2 Confidentiality) MUST be used to protect the > connection. Moreover, in this case IKE authenti-cation with group pre-shared > keys SHOULD NOT be used unless it is not essential to protect group members > against off-line dictionary attacks by other members. When CHAP is used with > secret shorter than 96 bits, a compliant implementation MUST NOT continue with > the login unless it can verify that IPsec encryption is being used to protect > the connection. > > Julo > From owner-ips@ece.cmu.edu Thu Jun 13 12:55:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21830 for ; Thu, 13 Jun 2002 12:55:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DGboA04786 for ips-outgoing; Thu, 13 Jun 2002 12:37:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g5DGbnw04782 for ; Thu, 13 Jun 2002 12:37:49 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g5DGbhp21075 for ; Thu, 13 Jun 2002 12:37:43 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g5DGbhc21063; Thu, 13 Jun 2002 12:37:43 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g5DGbgh08692; Thu, 13 Jun 2002 12:37:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15624.51802.656000.948714@gargle.gargle.HOWL> Date: Thu, 13 Jun 2002 12:37:46 -0400 From: Paul Koning To: ssenum@cisco.com Cc: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: Re: iSCSI: 7.2.1 CHAP Considerations (12-98) References: <3D08B669.3324F757@cisco.com> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 13 June 2002) by Steve Senum: > Further comments on this text: > > 1. I would suggest changing "96 random bits" to "96 bits". > I don't think it is practical to verify the number of random bits > in a single secret. That's certainly true. > 2. I would suggest changing the final "MUST NOT" to a "SHOULD NOT". > As with IKE pre-shared keys, the need to protect against off-line > dictionary attacks is ultimately a local deployment consideration. I agree. paul From owner-ips@ece.cmu.edu Thu Jun 13 12:56:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21848 for ; Thu, 13 Jun 2002 12:56:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DGMc803809 for ips-outgoing; Thu, 13 Jun 2002 12:22:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail4.nc.rr.com (fe4.southeast.rr.com [24.93.67.51]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DGMaw03800 for ; Thu, 13 Jun 2002 12:22:36 -0400 (EDT) Received: from mail pickup service by mail4.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 12:19:19 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Jun 2002 15:48:58 -0400 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5BJmsbC012505 for ; Tue, 11 Jun 2002 15:48:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BIshK26554 for ips-outgoing; Tue, 11 Jun 2002 14:54:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BIsfw26550 for ; Tue, 11 Jun 2002 14:54:41 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel10.hp.com (Postfix) with ESMTP id BE02BC00311; Tue, 11 Jun 2002 11:54:35 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id LAA08672; Tue, 11 Jun 2002 11:54:30 -0700 (PDT) Message-ID: <3D064959.660D58EC@cup.hp.com> Date: Tue, 11 Jun 2002 12:02:49 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: Bill Studenmund Cc: ips@ece.cmu.edu Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I don't see why this thread is going forever. There are other scsi transports that deal with these types of issues without having to define scsi transport protocol keys to indicate vendor_id, product_id and product_rev. You can do one of the following : a) Parse out the DNS name of the target device from the exchanged TargetName key, if you're an initiator. Similarly, parse out the DNS name of the initiator from the exchanged InitiatorName key, if you're a target. Use the DNS name as an indication of which device you're speaking to and add your device specific tweaks based on this. If the InitiatorName or TargetName is in EUI-64 format, you can obtain the vendor_id information from the upper 3 bytes of the EUI-64 name. b) Send INQUIRY to LUN 0 to determine the vendor_id, product_id and product_revisison_level of the device. Use this data to perform any device specific tweaks in your software/firmware. c) Provide out-of-band static configuration mechanisms in your initiator or target to assign a vendor specific identity to 1 or more initiators or targets. This allows the target configuration personnel to configure the device appropriately for the initiators it is speaking to. I don't see any need to be defining iscsi login keys to duplicate the vendor_id, product_id information. - Santosh Bill Studenmund wrote: > > On Mon, 10 Jun 2002, David Robinson wrote: > > > > What happens if we're somewhere inbetween? Or what if we find an issue > > > where 80% of the implementations all chose the same way? > > > > > > I'm trying to scope out the shades of gray we might run into. > > > > > > As a reminder about the IETF standards process, RFC2026. The IPS > > working group is driving towards "Proposed Standard" which > > by definition: "Implementors should treat Proposed Standards as > > immature specifications." The next step is "Draft Standard" > > where there is expectation that changes will be made between > > Proposed and Draft. "A Draft Standard is normally considered > > to be a final specification..." > > > > To move from Proposed to Draft is where two independant implementations > > are required and where the "80%" implementation problems are caught > > and fixed. > > > > The RFC we are driving towards is just the first step in a long > > path, there will be plenty of opportunities to fix "bugs" that > > are found we real implementations are built. Thus vendor specific > > keys are not needed, what we have today is not going to be > > the "Internet Standard." > > So what do we tell our customers? Our paying, cranky customers? That they > are part of the great iSCSI experiment? Or worse yet, what are you going > to tell your sales folks when a big sale doesn't go because of some > interop quirk? Try again in 6 months when the equipment has already been > bought? :-) > > I'm not saying we shouldn't work (hard) to fix all the problems we can. > > I'm saying that a policy of, "You loose," to the customers who run into an > interop problem is impolite. :-| > > Take care, > > Bill -- The world is so fast that there are days when the person who says it can't be done is interrupted by the person who is doing it. ~ Anon From owner-ips@ece.cmu.edu Thu Jun 13 12:57:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21885 for ; Thu, 13 Jun 2002 12:57:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DGMhq03818 for ips-outgoing; Thu, 13 Jun 2002 12:22:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail7.nc.rr.com (mail7.southeast.rr.com [24.93.67.54]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DGMfw03813 for ; Thu, 13 Jun 2002 12:22:41 -0400 (EDT) Received: from mail pickup service by mail7.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 05:31:19 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 16:33:59 -0400 Received: from engine.ieee.org (engine.ieee.org [140.98.193.23]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AKXxtH023938 for ; Mon, 10 Jun 2002 16:33:59 -0400 (EDT) Received: from ece.cmu.edu (gemini3.ieee.org [140.98.193.25]) by engine.ieee.org (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5AKXXB20409; Mon, 10 Jun 2002 16:33:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AKUKe10935 for ips-outgoing; Mon, 10 Jun 2002 16:30:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AKUIw10931 for ; Mon, 10 Jun 2002 16:30:18 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g5AKVqu09901; Mon, 10 Jun 2002 16:31:52 -0400 Message-ID: <3D050C52.5379887@splentec.com> Date: Mon, 10 Jun 2002 16:30:10 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Bill Studenmund CC: Robert Snively , "'Ken Sandars'" , "Ips Reflector (E-mail)" Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bill Studenmund wrote: > > On Mon, 10 Jun 2002, Luben Tuikov wrote: > > > Any time you see ``MAY'' or ``may'' in the draft and a target > > and initiator arrive at different outcomes _just_ by taking one > > or the other route, you have ``compliant-non-interoperability''. > > > > Which is what you are describing in more ``baby-terms'' below. > > No, that's not the same thing. You are saying EVERY may/MAY is a problem. > I disagree with that. I'll agree that SOME may be a problem, and that we > want to find them. > ``Any time'' doesn't imply ``EVERY may/MAY''! Look, I used the conjunctive ``and''. Here: (Every time ... MAY or may) AND (target/initiator arrive at different outcomes) THEN problem. -- Luben From owner-ips@ece.cmu.edu Thu Jun 13 12:58:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21946 for ; Thu, 13 Jun 2002 12:58:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DGYRe04571 for ips-outgoing; Thu, 13 Jun 2002 12:34:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DGYOw04563; Thu, 13 Jun 2002 12:34:24 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 28D8A12EB; Thu, 13 Jun 2002 10:34:23 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1.cos.agilent.com (Postfix) with SMTP id C5E14136; Thu, 13 Jun 2002 10:34:22 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 13 Jun 2002 10:33:59 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Jun 2002 10:33:58 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E4587@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com, pat_thaler@agilent.com Cc: ips@ece.cmu.edu, mkrikis@yahoo.com, owner-ips@ece.cmu.edu Subject: RE: base64 byte-length formula Date: Thu, 13 Jun 2002 10:33:55 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-710464f1-e7aa-435a-996a-b029a7a94644" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-710464f1-e7aa-435a-996a-b029a7a94644 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C212F8.1C736870" ------_=_NextPart_001_01C212F8.1C736870 Content-Type: text/plain; charset="iso-8859-1" Julian, I was using the formula in 12-97 as I stated. The formulas on 12-96 page 70, 12-97 page 71 and 12-98 page 71 all look the same to me. Changing to Martin's formula will solve the problem as would removing the formula altogether. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, June 13, 2002 5:57 AM To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu; mkrikis@yahoo.com; owner-ips@ece.cmu.edu Subject: RE: base64 byte-length formula Pat, I think you are talking about the formula in 12-96 and I am talking about the one in 12-98. Martins formula and mine are equivalent for good encodings. As I said I made it up only to account for encodings that are in fact impossible - like 1, 4 ... 4*n+1 base 64 digits. And I will put in Martins formula with a note about the impossible numbers. Can we stop this thread? Julo pat_thaler@agilent.com 06/13/2002 03:33 AM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL, mkrikis@yahoo.com cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: base64 byte-length formula Julian, The formula in 12-97 is: ((the integer part of)((n+3)*3/4) - m) Martins formula 3*3/4 where / indictates integer divide. The encoding of 1 octet in base64 results in 2 characters plus 2 equal signs. n=2, m=2. Martins formula = 2 *3/4 = 1 (truncated to an integer) right answer integer part of ((2+3)*3/4)-1 = (integer part of 15/4) - 2 = 3 - 2 = 1 right answer The encoding of 2 octets in base64 results in 3 characters plus one equal sign. n=3, m=1. Martins formula = 3 *3/4 = 2 (truncated to an integer) right answer integer part of ((3+3)*3/4)-1 = (integer part of 18/4) -1 = 4 - 1 = 3 wrong answer The encoding of 3 octets in base64 results in 4 characters plus no equal sign. n=4, m=0. Martins formula = 4 *3/4 = 3 (truncated to an integer) right answer integer part of ((4+3)*3/4)-1 = (integer part of 21/4) -0 = 5 - 1 = 4 wrong answer Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 4:56 PM To: Martins Krikis Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: base64 byte-length formula I said already that your formula is correct. I do not understand why you say that the 2 formulas are not equivalent for all the lengths (good aor bad)? I would appreciate if you respond although you don't have to. Julo Martins Krikis Sent by: owner-ips@ece.cmu.edu 06/13/2002 02:34 AM Please respond to Martins Krikis To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: base64 byte-length formula --- Julian Satran wrote: > The difference between our formulas is that I > (mistakenly) took 1 digit as > a possible string (or 5, 9 etc.) > For those you need the +3 TERM. > > For all the good length 2,3,4 6,7,8 etc the two > formulas are equivalent. No they are not. They are only equivalent for n = 0 (mod 4). So I'm still insisting that n * 3 / 4 is the simplest right formula. Martins Krikis, Intel Corp. Disclaimer: these are my opinions and may not be Intel's. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com ------_=_NextPart_001_01C212F8.1C736870 Content-Type: text/html; charset="iso-8859-1"
Julian,
 
I was using the formula in 12-97 as I stated. The formulas on 12-96 page 70, 12-97 page 71 and 12-98 page 71 all look the same to me. Changing to Martin's formula will solve the problem as would removing the formula altogether.
 
Regards,
Pat
 
 -----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, June 13, 2002 5:57 AM
To: pat_thaler@agilent.com
Cc: ips@ece.cmu.edu; mkrikis@yahoo.com; owner-ips@ece.cmu.edu
Subject: RE: base64 byte-length formula


Pat,

I think you are talking about the formula in 12-96 and I am talking about the one in 12-98.
Martins formula and mine are equivalent for good encodings.
As I said I made it up only to account for encodings that are in fact impossible - like 1, 4 ... 4*n+1 base 64 digits.
And I will  put in Martins formula with a note about the impossible numbers.
Can we stop this thread?

Julo


pat_thaler@agilent.com

06/13/2002 03:33 AM
Please respond to pat_thaler

       
        To:        Julian Satran/Haifa/IBM@IBMIL, mkrikis@yahoo.com
        cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
        Subject:        RE: base64 byte-length formula

       


Julian,

The formula in 12-97 is:
((the integer part of)((n+3)*3/4) - m)

Martins formula 3*3/4 where / indictates integer divide.

The encoding of 1 octet in base64 results in 2 characters plus 2 equal
signs.
n=2, m=2.

Martins formula = 2 *3/4 = 1 (truncated to an integer)  right answer

integer part of ((2+3)*3/4)-1 = (integer part of 15/4) - 2 = 3 - 2 = 1 right
answer


The encoding of 2 octets in base64 results in 3 characters plus one equal
sign.
n=3, m=1.

Martins formula = 3 *3/4 = 2 (truncated to an integer)  right answer

integer part of ((3+3)*3/4)-1 = (integer part of 18/4) -1 = 4 - 1 = 3 wrong
answer

The encoding of 3 octets in base64 results in 4 characters plus no equal
sign.
n=4, m=0.

Martins formula = 4 *3/4 = 3 (truncated to an integer)  right answer

integer part of ((4+3)*3/4)-1 = (integer part of 21/4) -0 = 5 - 1 = 4 wrong
answer

Pat

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 12, 2002 4:56 PM
To: Martins Krikis
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: base64 byte-length formula



I said already that your formula is correct.
I do not understand why you say that the 2 formulas are not equivalent for
all the lengths (good aor bad)?
I would appreciate if you respond although you don't have to.

Julo


Martins Krikis <mkrikis@yahoo.com>
Sent by: owner-ips@ece.cmu.edu
06/13/2002 02:34 AM
Please respond to Martins Krikis
       
       To:        Julian Satran/Haifa/IBM@IBMIL
       cc:        ips@ece.cmu.edu
       Subject:        Re: base64 byte-length formula

     



--- Julian Satran <Julian_Satran@il.ibm.com> wrote:

> The difference between our formulas is that I
> (mistakenly) took 1 digit as
> a possible string (or 5, 9 etc.)
> For those you need the +3 TERM.
>
> For all the good length 2,3,4 6,7,8 etc the two
> formulas are equivalent.

No they are not. They are only equivalent for
n = 0 (mod 4). So I'm still insisting that
n * 3 / 4 is the simplest right formula.

Martins Krikis, Intel Corp.

Disclaimer: these are my opinions and
          may not be Intel's.


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com


------_=_NextPart_001_01C212F8.1C736870-- ------=_NextPartTM-000-710464f1-e7aa-435a-996a-b029a7a94644-- From owner-ips@ece.cmu.edu Thu Jun 13 13:02:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22129 for ; Thu, 13 Jun 2002 13:02:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DGG9E03374 for ips-outgoing; Thu, 13 Jun 2002 12:16:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail4.nc.rr.com (fe4.southeast.rr.com [24.93.67.51]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DGG7w03369 for ; Thu, 13 Jun 2002 12:16:07 -0400 (EDT) Received: from mail pickup service by mail4.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 12:15:53 -0400 Received: from mail pickup service by mail4.nc.rr.com with Microsoft SMTPSVC; Tue, 11 Jun 2002 21:47:53 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 18:41:14 -0400 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AMfEtH029631 for ; Mon, 10 Jun 2002 18:41:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5ALWWP14568 for ips-outgoing; Mon, 10 Jun 2002 17:32:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5ALWTw14561 for ; Mon, 10 Jun 2002 17:32:30 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 17:32:29 -0400 Message-ID: From: Eddy Quicksall To: Julian Satran Cc: ips@ece.cmu.edu, pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength Date: Mon, 10 Jun 2002 17:32:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C210C6.52695900" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C210C6.52695900 Content-Type: text/plain; charset="iso-8859-1" Julian, Another problem here is that the target has to calculate the offset from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 means starting DataSN=4, send all the data for that sequence. I think it would be a performance hit and waist of memory to keep a tally of all PDU sizes just for an occasional SNACK. It's not that it can't be done ... it is more that it is messy and I think there is a solution that will satisfy the design requirements but keep the software simpler. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, June 08, 2002 10:16 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength That is not completely accurate. The only problem is when PDU size decreases and then SNACK must be for all data. Target can also keep a mapping of numbers/to offsets (the list should be small and if it gets long ask for ack (A-bit). Julo Eddy Quicksall Sent by: owner-ips@ece.cmu.edu 06/08/2002 10:54 PM Please respond to Eddy Quicksall To: pat_thaler@agilent.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Thanks, As a target, I won't be able to let it change until all of the outstanding commands are finished (running with ErrorRecoveryLevel>=1). This is because I must use the PDU size to compute the offset from a SNACK's BegRun/RunLength. So, I plan to not give the text response for a MaxPDURecvDataLength in FFP until I get back an ExpStatSN == next StatSN. This will cause a delay of unknown time before the PDU size can actually change ... do you see any problem with this? Eddy -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Friday, June 07, 2002 1:13 PM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Eddy, If one uses a message sync and steering that relys on the transport segments carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path MTU changes one would want to change the PDU data length to fit the new path MTU. Pat -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Wednesday, June 05, 2002 12:24 PM To: ips@ece.cmu.edu Subject: iSCSI: changing MaxPDUDataLength Does anybody know a case where it is necessary to support a new PDU data length during full feature phase? Eddy mailto: Eddy_Quicksall@iVivity.com ------_=_NextPart_001_01C210C6.52695900 Content-Type: text/html; charset="iso-8859-1"
Julian,
 
Another problem here is that the target has to calculate the offset from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 means starting DataSN=4, send all the data for that sequence.
 
I think it would be a performance hit and waist of memory to keep a tally of all PDU sizes just for an occasional SNACK.
 
It's not that it can't be done ... it is more that it is messy and I think there is a solution that will satisfy the design requirements but keep the software simpler.
 
Eddy
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, June 08, 2002 10:16 PM
To: Eddy Quicksall
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com
Subject: RE: iSCSI: changing MaxPDUDataLength


That is not completely accurate.
The only problem is when PDU size decreases and then SNACK must be for all data.
Target can also keep a mapping of numbers/to offsets (the list should be small and if it gets long ask for ack (A-bit).

Julo


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

06/08/2002 10:54 PM
Please respond to Eddy Quicksall

       
        To:        pat_thaler@agilent.com
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: changing MaxPDUDataLength

       


Thanks,

As a target, I won't be able to let it change until all of the outstanding
commands are finished (running with ErrorRecoveryLevel>=1). This is because
I must use the PDU size to compute the offset from a SNACK's
BegRun/RunLength.

So, I plan to not give the text response for a MaxPDURecvDataLength in FFP
until I get back an ExpStatSN == next StatSN.

This will cause a delay of unknown time before the PDU size can actually
change ... do you see any problem with this?

Eddy

-----Original Message-----
From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]
Sent: Friday, June 07, 2002 1:13 PM
To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu
Subject: RE: iSCSI: changing MaxPDUDataLength


Eddy,

If one uses a message sync and steering that relys on the transport segments
carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path
MTU changes one would want to change the PDU data length to fit the new path
MTU.

Pat

-----Original Message-----
From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com]
Sent: Wednesday, June 05, 2002 12:24 PM
To: ips@ece.cmu.edu
Subject: iSCSI: changing MaxPDUDataLength


Does anybody know a case where it is necessary to support a new PDU data
length during full feature phase?

Eddy
mailto: Eddy_Quicksall@iVivity.com



------_=_NextPart_001_01C210C6.52695900-- From owner-ips@ece.cmu.edu Thu Jun 13 13:05:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22199 for ; Thu, 13 Jun 2002 13:05:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DG3vM02585 for ips-outgoing; Thu, 13 Jun 2002 12:03:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DG3tw02581 for ; Thu, 13 Jun 2002 12:03:55 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5DG3fE8086968; Thu, 13 Jun 2002 18:03:41 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5DG3eB152132; Thu, 13 Jun 2002 18:03:40 +0200 To: Steve Senum Cc: ietf-ips MIME-Version: 1.0 Subject: Re: iSCSI: 7.2.1 CHAP Considerations (12-98) X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 13 Jun 2002 19:03:38 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 13/06/2002 19:03:40, Serialize complete at 13/06/2002 19:03:40 Content-Type: multipart/alternative; boundary="=_alternative 00583133C2256BD7_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00583133C2256BD7_= Content-Type: text/plain; charset="us-ascii" Steve, Ofer already suggested 2 - I just forgot - so that is fine. As for the 96 bits - that is a semantic issue - if you know that the 96 bits you generate are not random (e.g., extend a weak password) then the length is not enough. It is not supposed to check randomness - that is an administration part that is specified earlier. Julo Steve Senum 06/13/2002 06:12 PM Please respond to Steve Senum To: Julian Satran/Haifa/IBM@IBMIL cc: ietf-ips Subject: Re: iSCSI: 7.2.1 CHAP Considerations (12-98) Julian, Better, but I would suggest: If an initiator or target generates or verifies a CHAP secret that has less than 96 random bits then IPsec encryption (according to the implementation requirements in Section 7.3.2 Confidentiality) MUST be used to protect the connection. Moreover, in this case IKE authentication with group pre-shared keys SHOULD NOT be used unless it is not essential to protect group members against off-line dictionary attacks by other members, and an implementation MUST NOT continue with the login unless it can verify that IPsec encryption is being used to protect the connection. I want to more strongly tie the last requirement to the initial condition. Further comments on this text: 1. I would suggest changing "96 random bits" to "96 bits". I don't think it is practical to verify the number of random bits in a single secret. 2. I would suggest changing the final "MUST NOT" to a "SHOULD NOT". As with IKE pre-shared keys, the need to protect against off-line dictionary attacks is ultimately a local deployment consideration. Regards, Steve Senum Julian Satran wrote: > > The text I would suggest in 7.2.1 is: > > If an initiator or target generates or verifies a CHAP secret that has less > than 96 random bits then IPsec encryption (according to the implementation > requirements in Section 7.3.2 Confidentiality) MUST be used to protect the > connection. Moreover, in this case IKE authenti-cation with group pre-shared > keys SHOULD NOT be used unless it is not essential to protect group members > against off-line dictionary attacks by other members. When CHAP is used with > secret shorter than 96 bits, a compliant implementation MUST NOT continue with > the login unless it can verify that IPsec encryption is being used to protect > the connection. > > Julo > --=_alternative 00583133C2256BD7_= Content-Type: text/html; charset="us-ascii"
Steve,

Ofer already suggested 2 - I just forgot - so that is fine.

As for the 96 bits - that is a semantic issue - if you know that the 96 bits you generate are not random (e.g., extend a weak password) then the length is not enough.
It is not supposed to check randomness - that is an administration part that is specified earlier.

Julo


Steve Senum <ssenum@cisco.com>

06/13/2002 06:12 PM
Please respond to Steve Senum

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ietf-ips <ips@ece.cmu.edu>
        Subject:        Re: iSCSI: 7.2.1 CHAP Considerations (12-98)

       


Julian,

Better, but I would suggest:

If an initiator or target generates or verifies a CHAP secret that has less
than 96 random bits then IPsec encryption (according to the implementation
requirements in Section 7.3.2 Confidentiality) MUST be used to protect the
connection. Moreover, in this case IKE authentication with group pre-shared
keys SHOULD NOT be used unless it is not essential to protect group members
against off-line dictionary attacks by other members, and an implementation
MUST NOT continue with the login unless it can verify that IPsec encryption
is being used to protect the connection.

I want to more strongly tie the last requirement to the initial condition.

Further comments on this text:

1. I would suggest changing "96 random bits" to "96 bits".
I don't think it is practical to verify the number of random bits
in a single secret.

2. I would suggest changing the final "MUST NOT" to a "SHOULD NOT".
As with IKE pre-shared keys, the need to protect against off-line
dictionary attacks is ultimately a local deployment consideration.


Regards,
Steve Senum

Julian Satran wrote:
>
> The text I would suggest in 7.2.1 is:
>
> If an initiator or target generates or verifies a CHAP secret that has less
> than 96 random bits then IPsec encryption (according to the implementation
> requirements in Section 7.3.2 Confidentiality) MUST be used to protect the
> connection. Moreover, in this case IKE authenti-cation with group pre-shared
> keys SHOULD NOT be used unless it is not essential to protect group members
> against off-line dictionary attacks by other members. When CHAP is used with
> secret shorter than 96 bits, a compliant implementation MUST NOT continue with
> the login unless it can verify that IPsec encryption is being used to protect
> the connection.
>
> Julo
>

--=_alternative 00583133C2256BD7_=-- From owner-ips@ece.cmu.edu Thu Jun 13 13:56:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23808 for ; Thu, 13 Jun 2002 13:56:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DH6dv06627 for ips-outgoing; Thu, 13 Jun 2002 13:06:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail4.nc.rr.com (fe4.southeast.rr.com [24.93.67.51]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DH6aw06621; Thu, 13 Jun 2002 13:06:36 -0400 (EDT) Received: from mail pickup service by mail4.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 13:00:52 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Jun 2002 19:00:23 -0400 Received: from engine.ieee.org (engine.ieee.org [140.98.193.23]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5BN0NbC009849 for ; Tue, 11 Jun 2002 19:00:23 -0400 (EDT) Received: from ece.cmu.edu (gemini3.ieee.org [140.98.193.25]) by engine.ieee.org (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5BN0FB07447; Tue, 11 Jun 2002 19:00:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BMocw10196 for ips-outgoing; Tue, 11 Jun 2002 18:50:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BMoYw10181; Tue, 11 Jun 2002 18:50:34 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5BMoRYj060852; Wed, 12 Jun 2002 00:50:27 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5BMoQp125010; Wed, 12 Jun 2002 00:50:27 +0200 Importance: High Subject: Re: iSCSI: changing MaxPDUDataLength To: "Mallikarjun C." Cc: ips@ece.cmu.edu, "Julian Satran" , owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Wed, 12 Jun 2002 00:28:28 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 12/06/2002 01:50:27 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mallikarjun, The question was general and not specific to MaxRecv.... Although we say that negotiation is symmetric we don't have any mechanism through which a target can say it wants to start negotiation something (sort of similar but not as strong as a the "request logout" - "request to negotiate" that will require the initiator to issue a text request and kick-off a negotiation. Julo "Mallikarjun C." To: , Julian Satran/Haifa/IBM@IBMIL Sent by: cc: owner-ips@ece.cmu Subject: Re: iSCSI: changing MaxPDUDataLength .edu 06/11/2002 10:50 PM Please respond to "Mallikarjun C." > I also realized that we don't have "negotiation prompt" from the target. > I am not sure that we need one. I am not sure about it either. My preference is not to add this. It appears to me that a target does have the option of dropping the connection today if it can't work with non-ULPDU-contained segments for too long. I suspect that the target would do the same if (we introduced the "negotiation prompt" and) the initiator doesn't/couldn't honor the "negotiation prompt". Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Julian Satran" To: Sent: Tuesday, June 11, 2002 8:34 AM Subject: RE: iSCSI: changing MaxPDUDataLength > I suggest the following text in 11.13 > > A change of MaxRecvDataSegmentLength by an initiator or target > becomes effective after all commands preceding the negotiation > end-ing request have been processed by the target and their status > is acknowledged. > > I also realized that we don't have "negotiation prompt" from the target. > I am not sure that we need one. > If some of you think we need we may want one additional code in the Asynch > Message. > Please comment TODAY. > > Julo > ----- Forwarded by Julian Satran/Haifa/IBM on 06/11/2002 06:29 PM ----- > > Julian Satran > To: Eddy Quicksall > 06/11/2002 04:04 cc: ips@ece.cmu.edu, pat_thaler@agilent.com > PM From: Julian Satran/Haifa/IBM@IBMIL > Subject: RE: iSCSI: changing MaxPDUDataLength(Document link: Julian Satran - Mail) > > > > > > > > > > That is a fair request - we may slip in a recommendation to that effect (in > chapter 11?) > > Julo > > > > Eddy Quicksall > vivity.com> cc: ips@ece.cmu.edu, pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > 06/11/2002 04:28 > AM > Please respond to > Eddy Quicksall > > > > > > How about if we say that an initiator must not change the MaxPDUDataSize > unless it first idles the commands (at least the ones with the R bit) or if > ErrorRecoveryLevel==0? > > That would simplify target code greatly and would meet the design goals; > and since it should be rare to change it, it would be of little impact to > idle the commands for a split second. > > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Monday, June 10, 2002 8:06 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > I said only that when you change length you can ask for all PDUs > after the ack! (no need to keep a tall - the old offsets are good up > to the hole). > > Julo > > > Eddy Quicksall > To: Julian > Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu, > 06/11/2002 12:32 AM pat_thaler@agilent.com > Please respond to Eddy Quicksall Subject: RE: iSCSI: > changing MaxPDUDataLength > > > > > > > > Julian, > > Another problem here is that the target has to calculate the offset > from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and > RunLngth=0 means starting DataSN=4, send all the data for that > sequence. > > I think it would be a performance hit and waist of memory to keep a > tally of all PDU sizes just for an occasional SNACK. > > It's not that it can't be done ... it is more that it is messy and I > think there is a solution that will satisfy the design requirements > but keep the software simpler. > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Saturday, June 08, 2002 10:16 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > That is not completely accurate. > The only problem is when PDU size decreases and then SNACK must be > for all data. > Target can also keep a mapping of numbers/to offsets (the list should > be small and if it gets long ask for ack (A-bit). > > Julo > > Eddy Quicksall > To: > Sent by: owner-ips@ece.cmu.edu pat_thaler@agilent.com > cc: ips@ece.cmu.edu > Subject: RE: iSCSI: > 06/08/2002 10:54 PM changing MaxPDUDataLength > Please respond to Eddy Quicksall > > > > > > > > Thanks, > > As a target, I won't be able to let it change until all of the > outstanding > commands are finished (running with ErrorRecoveryLevel>=1). This is > because > I must use the PDU size to compute the offset from a SNACK's > BegRun/RunLength. > > So, I plan to not give the text response for a MaxPDURecvDataLength > in FFP > until I get back an ExpStatSN == next StatSN. > > This will cause a delay of unknown time before the PDU size can > actually > change ... do you see any problem with this? > > Eddy > > -----Original Message----- > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > Sent: Friday, June 07, 2002 1:13 PM > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > Subject: RE: iSCSI: changing MaxPDUDataLength > > > Eddy, > > If one uses a message sync and steering that relys on the transport > segments > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the > path > MTU changes one would want to change the PDU data length to fit the > new path > MTU. > > Pat > > -----Original Message----- > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > Sent: Wednesday, June 05, 2002 12:24 PM > To: ips@ece.cmu.edu > Subject: iSCSI: changing MaxPDUDataLength > > > Does anybody know a case where it is necessary to support a new PDU > data > length during full feature phase? > > Eddy > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > > > From owner-ips@ece.cmu.edu Thu Jun 13 13:59:51 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23926 for ; Thu, 13 Jun 2002 13:59:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DH3H506431 for ips-outgoing; Thu, 13 Jun 2002 13:03:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from med.corp.rhapsodynetworks.com (64-160-62-201.rhapsodynetworks.com [64.160.62.201] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DH39w06417; Thu, 13 Jun 2002 13:03:09 -0400 (EDT) Received: by med.corp.rhapsodynetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Jun 2002 10:03:02 -0700 Message-ID: <45BEF1D68145D51186C100B0D0AABE659E017C@med.corp.rhapsodynetworks.com> From: Dennis Young To: "'Julian Satran'" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Date: Thu, 13 Jun 2002 10:02:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C212FC.2AB44130" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C212FC.2AB44130 Content-Type: text/plain; charset="iso-8859-1" I think you are refering to the F bit in the SCSI Write. I was talking about the F bit in the Data-out. Please confirm. Thanks, Dennis -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, June 13, 2002 6:18 AM To: Dennis Young Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Not exactly - an initiator may decide to send only non immediate or only immediate in the first case the absence of F is the sign of things to come and in the later F indicates nothing will come. The later is allowed. Julo Dennis Young 06/13/2002 04:00 AM Please respond to Dennis Young To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Thanks to yours and others' explanation, now I am more clear, but I have another question: Based on your reply, and let me emphasize it by repeating the 4th paragraph on page 42 of draft 12-98: "... If any non-immediate unsolicited data are sent, the total unsolicited data MUST be either the negotiated amount or all the data if the total amount is less than the negotiated amount for unsolicited data. ..." With this rule, do we still need the F bit in the Data-out (both for the solicited and unsolicited Data-out)? The F bit seems redundant since the target has enough information to figure out the final unsolicited Data-out and the final solicited Data-out (based on the FirstBurstSize, Offset and DataSegmentLength in the Data-out, and the ExpectedDataTransferLength in the corresponding SCSI Write PDU). Thanks, Dennis -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 11:21 AM To: Dennis Young Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question You are wrong about waiting - read my previous text. You need unsolicited as the amount in one PDU may not be all you want. Julo Dennis Young Sent by: owner-ips@ece.cmu.edu 06/12/2002 08:49 PM Please respond to Dennis Young To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Are you saying that, for a session that has InitialR2T=No in effect, the initiator must send all its data as unsolicited first, up to the amount negotiated in FirstBurstSize, before it waits for a R2T from the target? Can you shed some light on why we need unsolicited Data-out PDU when there is ImmediateData, seems like they both serve the same purpose, having both of them only make the spec more complex. Thanks, -Dennis -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 10:19 AM To: Dennis Young Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question This is the reason why the initiator is required to send ALL unsolicited data (target can count on it and start sending R2Ts as soon as it sees the first header> Neither bandwidth nor latency are wasted. Julo Dennis Young 06/12/2002 08:05 PM Please respond to Dennis Young To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Julian, This leads me to a more interesting question. A session with InitialR2T=No in effect, i.e. unsolicited Data-out allowed, could cause unintended waste of bandwidth, depending on how fast the target sends our R2T in response to the SCSI Write. If the target sees the unsolicited Data-out PDU before building the R2T, then everything is fine. If the target doesn't see the unsolicited Data-out PDU before building the R2T, the R2T would request the same portion of data in the unsolicited Data-out, thus bandwidth is wasted. The question is, how can a target be smart about this? Should the target wait a moment for the possible unsolicited Data-out after receiving each SCSI Write, this sounds kludgy. Also, why do we need the unsolicited Data-out PDU feature when there is ImmediateData? Regards, Dennis -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 6:05 AM To: Dennis Young Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iscsi: unsolicited data question yes - julo Dennis Young Sent by: owner-ips@ece.cmu.edu 06/12/2002 06:20 AM Please respond to Dennis Young To: ips@ece.cmu.edu cc: Subject: iscsi: unsolicited data question I have a question which has been asked before, but I couldn't find a direct answer in the archive. The table on page 200 of draft 12 doesn't directly answer this question either. The first paragraph on page 36 of draft 12 says "Targets operate in either solicitied (R2T) data mode or unsolicited (non R2T) data mode." tells me that a target, at all times during a data sequence transfer, can be one or the other, but not both (non R2T for the initial data out, R2T for the remaining data). Is this correct? Thanks, Dennis ---snip from an old email dated 3/30/2001--- " Hi Julian Sorry if I'm covering old ground... Is it possible to use unsolicited data for the first burst and then request any remaining data using R2T? For example, if the target has a previously allocated buffer available (length defined by FirstBurstSize) for unsolicited data, then once the initiator has sent unsolicited data up to and including this amount then the remaining data (if any) can be requested using R2T once the target has the buffer space available. ...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail: matthewb@bri.hp.com " ------_=_NextPart_001_01C212FC.2AB44130 Content-Type: text/html; charset="iso-8859-1"
I think you are refering to the F bit in the SCSI Write.  I was talking about the F bit in the Data-out.
Please confirm.
Thanks,
Dennis
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, June 13, 2002 6:18 AM
To: Dennis Young
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iscsi: unsolicited data question


Not exactly - an initiator may decide to send only non immediate or only immediate in the first case the absence of F is the sign of things to come and in the later F indicates nothing will come. The later is allowed.

Julo


Dennis Young <dyoung@rhapsodynetworks.com>

06/13/2002 04:00 AM
Please respond to Dennis Young

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
        Subject:        RE: iscsi: unsolicited data question

       


Thanks to yours and others' explanation, now I am more clear, but I have
another question:
 
Based on your reply, and let me emphasize it by repeating the 4th paragraph
on page 42 of draft 12-98:
    "... If any non-immediate unsolicited data are sent, the total unsolicited
    data MUST be either the negotiated amount or all the data if the total
    amount is less than the negotiated amount for unsolicited data. ..."
 
With this rule, do we still need the F bit in the Data-out (both for the solicited
and unsolicited Data-out)?  The F bit seems redundant since the target has
enough information to figure out the final unsolicited Data-out and the final
solicited Data-out (based on the FirstBurstSize, Offset and DataSegmentLength
in the Data-out, and the ExpectedDataTransferLength in the corresponding
SCSI Write PDU).
 
Thanks,
Dennis
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 12, 2002 11:21 AM
To: Dennis Young
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iscsi: unsolicited data question


You are wrong about waiting - read my previous text.
You need unsolicited as the amount in one PDU may not be all you want.

Julo

Dennis Young <dyoung@rhapsodynetworks.com>
Sent by: owner-ips@ece.cmu.edu

06/12/2002 08:49 PM
Please respond to Dennis Young

       
       To:        Julian Satran/Haifa/IBM@IBMIL
       cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
       Subject:        RE: iscsi: unsolicited data question

     



Are you saying that, for a session that has InitialR2T=No in effect, the initiator
must send all its data as unsolicited first, up to the amount negotiated in
FirstBurstSize, before it waits for a R2T from the target?
 
Can you shed some light on why we need unsolicited Data-out PDU when there
is ImmediateData, seems like they both serve the same purpose, having both of
them only make the spec more complex.
 
Thanks,
-Dennis
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 12, 2002 10:19 AM
To: Dennis Young
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iscsi: unsolicited data question


This is the reason why the initiator is required to send ALL unsolicited data (target can count on it and start sending R2Ts as soon as it sees the first header>
Neither bandwidth nor latency are wasted.

Julo
Dennis Young <dyoung@rhapsodynetworks.com>

06/12/2002 08:05 PM
Please respond to Dennis Young

       
      To:        Julian Satran/Haifa/IBM@IBMIL
      cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
      Subject:        RE: iscsi: unsolicited data question

     




Julian,

This leads me to a more interesting question.
A session with InitialR2T=No in effect, i.e. unsolicited Data-out
allowed, could cause unintended waste of bandwidth, depending on
how fast the target sends our R2T in response to the SCSI Write.

If the target sees the unsolicited Data-out PDU before building the
R2T, then everything is fine.
If the target doesn't see the unsolicited Data-out PDU before building
the R2T, the R2T would request the same portion of data in the
unsolicited Data-out, thus bandwidth is wasted.

The question is, how can a target be smart about this?
Should the target wait a moment for the possible unsolicited Data-out
after receiving each SCSI Write, this sounds kludgy.

Also, why do we need the unsolicited Data-out PDU feature when
there is ImmediateData?

Regards,
Dennis

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 12, 2002 6:05 AM
To: Dennis Young
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iscsi: unsolicited data question


yes - julo
Dennis Young <dyoung@rhapsodynetworks.com>
Sent by: owner-ips@ece.cmu.edu

06/12/2002 06:20 AM
Please respond to Dennis Young

       
     To:        ips@ece.cmu.edu
     cc:        
     Subject:        iscsi: unsolicited data question

   





I have a question which has been asked before, but I couldn't find a direct
answer in the archive.  The table on page 200 of draft 12 doesn't directly
answer this question either.

The first paragraph on page 36 of draft 12 says "Targets operate in either
solicitied (R2T) data mode or unsolicited (non R2T) data mode."
tells me that a target, at all times during a data sequence transfer, can be

one or the other, but not both (non R2T for the initial data out, R2T for
the
remaining data).  Is this correct?

Thanks,
Dennis

---snip from an old email dated 3/30/2001---

" Hi Julian
Sorry if I'm covering old ground... Is it possible to use unsolicited data
for the first burst and then request any remaining data using R2T? For
example, if the target has a previously allocated buffer available (length
defined by FirstBurstSize) for unsolicited data, then once the initiator has
sent unsolicited data up to and including this amount then the remaining
data (if any) can be requested using R2T once the target has the buffer
space available.
...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail:
matthewb@bri.hp.com "







------_=_NextPart_001_01C212FC.2AB44130-- From owner-ips@ece.cmu.edu Thu Jun 13 14:55:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25989 for ; Thu, 13 Jun 2002 14:54:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DIF3G11224 for ips-outgoing; Thu, 13 Jun 2002 14:15:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DIF2w11220 for ; Thu, 13 Jun 2002 14:15:02 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g5DIGPu30688; Thu, 13 Jun 2002 14:16:25 -0400 Message-ID: <3D08E11A.A93B9C08@splentec.com> Date: Thu, 13 Jun 2002 14:14:50 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Julian Satran CC: iSCSI Subject: Re: iSCSI: 12-97 Bit Rule References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian Satran wrote: > > I took out completely the bit rule. > I reformulated the CRC text as: > > The CRC MUST be calculated by a method that produces the same results as the following process: > > - The PDU bits are considered as the coefficients of a polyno-mial M(x) of degree n-1; bit 7 of > the lowest numbered byte is considered the most significant bit (x^n-1), followed by bit 6 of the > lowest numbered byte and through bit 0 of the high-est numbered byte (x^0). This description, taken by itself, as you quote it here, mentions bit 7 of a byte. Normally, bit 7 of a byte is the Most Significant bit (MSb). But somewhere you MUST mention that bit 7 is, contrary to all intuition, the LSb, NOT, as many of us would assume, the MSb. (I.e. the _bit_ ordering as per the PDU template doesn't imply bit significance, or does it?) I.e. you need to mention that the bytes are mirrored. Here it is, again: 1) The bytes of the message form a bit stream, ordered Most Significant Byte (MSB), Most Significant bit (MSb) in memory, i.e. Big endian on bytes, Big endian on bits. Call this bit stream P. 2) The bytes of P are mirrored, thus forming byte 0, LSb first to MSb, then byte 1, LSb first to MSb, etc, (Big endian on Bytes, Little endian on bits), this forms the bit sequence A = {a_0, a_1, ..., a_(n-1)}. 3) The first 32 bits of A are complemented (a_0 to a_31). 4) The bits of A are considered coefficients of M(x), where M(x) = a_0 x^(n-1) + ... + a_(n-1) x^0. 5) The polynomial M(x) is multiplied by x^32, then divided by G(x), where G(x) is the polynomial representation of 0x11edc6f41. This produces a remainder R(x) of degree <= 31. 6) The coefficients of R(x) are considered a 32 bit sequence, R(x) = r_31 x^31 + ... + r_0 x^0. 7) R(x) is complemented and mirrored, the result is CRC(x). 8) The message sent is P and appended at the end are the bit coefficients of CRC(x), with x^31 bit coefficient first, then x^30, etc. 9) A receiver of a "good" message sent as per step (8), will get the value 0x1c2d19ed as R(x) (steps (1) to (6)). Note that CRC(x) is a polynomial and independent of the machine's representation. For clarity, I've omitted the fact that x^0 = 1. So, steps 1 to 6 form ``R(x) = compute_crc(P)'', and steps 7 to 8 form ``Send_This = inject_crc(P, R(x))''. I.e. ``Magic_Value = compute_crc(inject_crc(P, compute_crc(P)))'' Thus, one sends ``inject_crc(P, compute_crc(P))'', and the receiver does ``Magic_Value =?= compute_crc(message_received)'', which is step 9. -- Luben From owner-ips@ece.cmu.edu Thu Jun 13 14:55:14 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25993 for ; Thu, 13 Jun 2002 14:55:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DICqt11029 for ips-outgoing; Thu, 13 Jun 2002 14:12:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DICow11024 for ; Thu, 13 Jun 2002 14:12:50 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel11.hp.com (Postfix) with ESMTP id 31F34600781; Thu, 13 Jun 2002 11:12:44 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id LAA28281; Thu, 13 Jun 2002 11:14:28 -0700 (PDT) Message-ID: <00a401c21305$e72549a0$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Santosh Rao" , Cc: "Paul Koning" , "Julian Satran" , References: <1BEBA5E8600DD4119A50009027AF54A00C5E4423@axcs04.cos.agilent.com> <3D07CF80.CA8286BF@cup.hp.com> Subject: Re: iSCSI-Asynch event code Date: Thu, 13 Jun 2002 11:12:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat: Even if the feature is not added, FFP negotiation still can be carried out when the initiator/both want(s) to renegotiate/redeclare certain keys. The new feature is needed only for one case - when the target wants to redeclare some key, and the initiator doesn't care so doesn't initiate a text request. There is such a theoretical possibility for Max... key. Santosh: This is not Login negotiation as you seem to suggest. The comment about initiator not being able to log back in after a connection drop may not be due to initiator implementation problems, as you think. I think the reference was to multi-initiator environments, with the connection resource on the target being taken away by a different initiator. I personally think there's some value in FFP negotiations. I have come around to the position that I'm mildly in favor of this feature - for the reason I described above to Pat. I still however tend to think that it's more useful for the future. Julian: I think you also need to state what the target may do if a negotiation prompt is not received within the expected time - similar to the logout request event. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Santosh Rao" To: Cc: ; ; Sent: Wednesday, June 12, 2002 3:47 PM Subject: Re: iSCSI-Asynch event code > > I don't see a need to allow key re-negotiation during FFP. The only key > that is really required to be used in FFP is SendTargets. > > The keys that are permitted during FFP are : > > - SendTargets > - TargetAlias > - InitiatorAlias > - TargetAddress > - MaxRecvDataPDUSize (or whatever its latest name is) > - Vendor Specific keys > > Of the above, the only real negotiation involves the MaxRecvPDUSize. I > don't see any use of attempting to modify/negotiate/communicate the > remaining keys during FFP (with the exception of SendTargets). > > I see no problem in forbidding key re-negotiation during FFP and > handling PMTU changes by dropping the connection and allowing it to be > re-established. > > There needs to be a conscious effort to simplify this login negotiation > process and bound the complexity that's being heaped upon it. If we > don't make the attempt to keep it simple, we are going to be bitten by a > bunch of bugs in this area due to its complexity. > > This is one such area where we can choose not to increase the complexity > of login negotiation. > > There have been some concerns raised about the initiator not logging > back in upon a target driven logout. Such an initiator driver is a poor > design. As long as an upper layer in the O.S. has an open pending on > some LUN of that target port, it is the duty of the initiator driver to > attempt to keep the I-T nexus established, and if there's a transient > glitch in the I-T nexus, the initiator must attempt to re-login. > > An initiator that does not do this gets what it deserves. There's no > need to add complexity to the spec in an attempt to deal with poor > initiator implementations. The target need not care if the initiator > does not log back, in this case. > > - Santosh > > > > pat_thaler@agilent.com wrote: > > > > Paul and Santosh, > > > > If this isn't needed, then I don't see why FFP negotiation is needed at all (other than to support discovery with SendTargets but that isn't really a negotiation). The initiator could also close and reopen the connection to change PDU size. If we support renegotiation of some keys during FFP for the initiator, then we should do it for the target as well. Otherwise we shouldn't support renegotiation at all. > > > > Pat > > > > -----Original Message----- > > From: Paul Koning [mailto:ni1d@arrl.net] > > Sent: Wednesday, June 12, 2002 1:54 PM > > To: santoshr@cup.hp.com > > Cc: Julian_Satran@il.ibm.com; ips@ece.cmu.edu > > Subject: Re: iSCSI-Asynch event code > > > > Excerpt of message (sent 12 June 2002) by Santosh Rao: > > > > > > Why is this needed ? The target can just send an async event to drop the > > > connection or request a connection logout, and the connection can be > > > re-established allowing for new negotiation. > > > > > > I don't see the point of making this change so late in the game. There > > > exist mechanisms such as target driven connection logout/drop which can > > > be used to achieve the same effect. > > > > I agree. > > > > paul > > -- > The world is so fast that there are days when the person who says > it can't be done is interrupted by the person who is doing it. > ~ Anon > From owner-ips@ece.cmu.edu Thu Jun 13 15:00:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26252 for ; Thu, 13 Jun 2002 14:59:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DHlQo09386 for ips-outgoing; Thu, 13 Jun 2002 13:47:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DHlLw09376; Thu, 13 Jun 2002 13:47:21 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5DHlFE8064568; Thu, 13 Jun 2002 19:47:15 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5DHl0q30640; Thu, 13 Jun 2002 19:47:00 +0200 To: Dennis Young Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iscsi: unsolicited data question X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 13 Jun 2002 20:46:50 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 13/06/2002 20:47:07, Serialize complete at 13/06/2002 20:47:07 Content-Type: multipart/alternative; boundary="=_alternative 00613E07C2256BD7_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00613E07C2256BD7_= Content-Type: text/plain; charset="us-ascii" Yes the F bit in Data is not strictly needed except to simplify target function, recovery and bidirectional command execution. Initiators may send data out-of-order (parameters control this and this might be needed in special circumstances - e.g., copy a disk to tape) and a target might have trouble keeping track of what it got or not (discarded PDUs due to errors make the picture even more complex). The F bit is a simple indication that says "that's it"! Julo Dennis Young 06/13/2002 08:02 PM Please respond to Dennis Young To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question I think you are refering to the F bit in the SCSI Write. I was talking about the F bit in the Data-out. Please confirm. Thanks, Dennis -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, June 13, 2002 6:18 AM To: Dennis Young Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Not exactly - an initiator may decide to send only non immediate or only immediate in the first case the absence of F is the sign of things to come and in the later F indicates nothing will come. The later is allowed. Julo Dennis Young 06/13/2002 04:00 AM Please respond to Dennis Young To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Thanks to yours and others' explanation, now I am more clear, but I have another question: Based on your reply, and let me emphasize it by repeating the 4th paragraph on page 42 of draft 12-98: "... If any non-immediate unsolicited data are sent, the total unsolicited data MUST be either the negotiated amount or all the data if the total amount is less than the negotiated amount for unsolicited data. ..." With this rule, do we still need the F bit in the Data-out (both for the solicited and unsolicited Data-out)? The F bit seems redundant since the target has enough information to figure out the final unsolicited Data-out and the final solicited Data-out (based on the FirstBurstSize, Offset and DataSegmentLength in the Data-out, and the ExpectedDataTransferLength in the corresponding SCSI Write PDU). Thanks, Dennis -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 11:21 AM To: Dennis Young Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question You are wrong about waiting - read my previous text. You need unsolicited as the amount in one PDU may not be all you want. Julo Dennis Young Sent by: owner-ips@ece.cmu.edu 06/12/2002 08:49 PM Please respond to Dennis Young To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Are you saying that, for a session that has InitialR2T=No in effect, the initiator must send all its data as unsolicited first, up to the amount negotiated in FirstBurstSize, before it waits for a R2T from the target? Can you shed some light on why we need unsolicited Data-out PDU when there is ImmediateData, seems like they both serve the same purpose, having both of them only make the spec more complex. Thanks, -Dennis -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 10:19 AM To: Dennis Young Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question This is the reason why the initiator is required to send ALL unsolicited data (target can count on it and start sending R2Ts as soon as it sees the first header> Neither bandwidth nor latency are wasted. Julo Dennis Young 06/12/2002 08:05 PM Please respond to Dennis Young To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Julian, This leads me to a more interesting question. A session with InitialR2T=No in effect, i.e. unsolicited Data-out allowed, could cause unintended waste of bandwidth, depending on how fast the target sends our R2T in response to the SCSI Write. If the target sees the unsolicited Data-out PDU before building the R2T, then everything is fine. If the target doesn't see the unsolicited Data-out PDU before building the R2T, the R2T would request the same portion of data in the unsolicited Data-out, thus bandwidth is wasted. The question is, how can a target be smart about this? Should the target wait a moment for the possible unsolicited Data-out after receiving each SCSI Write, this sounds kludgy. Also, why do we need the unsolicited Data-out PDU feature when there is ImmediateData? Regards, Dennis -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 6:05 AM To: Dennis Young Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iscsi: unsolicited data question yes - julo Dennis Young Sent by: owner-ips@ece.cmu.edu 06/12/2002 06:20 AM Please respond to Dennis Young To: ips@ece.cmu.edu cc: Subject: iscsi: unsolicited data question I have a question which has been asked before, but I couldn't find a direct answer in the archive. The table on page 200 of draft 12 doesn't directly answer this question either. The first paragraph on page 36 of draft 12 says "Targets operate in either solicitied (R2T) data mode or unsolicited (non R2T) data mode." tells me that a target, at all times during a data sequence transfer, can be one or the other, but not both (non R2T for the initial data out, R2T for the remaining data). Is this correct? Thanks, Dennis ---snip from an old email dated 3/30/2001--- " Hi Julian Sorry if I'm covering old ground... Is it possible to use unsolicited data for the first burst and then request any remaining data using R2T? For example, if the target has a previously allocated buffer available (length defined by FirstBurstSize) for unsolicited data, then once the initiator has sent unsolicited data up to and including this amount then the remaining data (if any) can be requested using R2T once the target has the buffer space available. ...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail: matthewb@bri.hp.com " --=_alternative 00613E07C2256BD7_= Content-Type: text/html; charset="us-ascii"
Yes the F bit in Data is not strictly needed except to simplify target function, recovery and bidirectional command execution.
Initiators may send data out-of-order (parameters control this and this might be needed in special circumstances - e.g., copy a disk to tape) and a target might have trouble keeping track of what it got or not (discarded PDUs due to errors make the picture even more complex). The F bit is a simple indication that says "that's it"!

Julo


Dennis Young <dyoung@rhapsodynetworks.com>

06/13/2002 08:02 PM
Please respond to Dennis Young

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
        Subject:        RE: iscsi: unsolicited data question

       


I think you are refering to the F bit in the SCSI Write.  I was talking about the F bit in the Data-out.
Please confirm.
Thanks,
Dennis
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, June 13, 2002 6:18 AM
To: Dennis Young
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iscsi: unsolicited data question

Not exactly - an initiator may decide to send only non immediate or only immediate in the first case the absence of F is the sign of things to come and in the later F indicates nothing will come. The later is allowed.

Julo

Dennis Young <dyoung@rhapsodynetworks.com>

06/13/2002 04:00 AM
Please respond to Dennis Young

       
       To:        Julian Satran/Haifa/IBM@IBMIL
       cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
       Subject:        RE: iscsi: unsolicited data question

     



Thanks to yours and others' explanation, now I am more clear, but I have
another question:
 
Based on your reply, and let me emphasize it by repeating the 4th paragraph
on page 42 of draft 12-98:
   "... If any non-immediate unsolicited data are sent, the total unsolicited
   data MUST be either the negotiated amount or all the data if the total
   amount is less than the negotiated amount for unsolicited data. ..."
 
With this rule, do we still need the F bit in the Data-out (both for the solicited
and unsolicited Data-out)?  The F bit seems redundant since the target has
enough information to figure out the final unsolicited Data-out and the final
solicited Data-out (based on the FirstBurstSize, Offset and DataSegmentLength
in the Data-out, and the ExpectedDataTransferLength in the corresponding
SCSI Write PDU).
 
Thanks,
Dennis
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 12, 2002 11:21 AM
To: Dennis Young
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iscsi: unsolicited data question


You are wrong about waiting - read my previous text.
You need unsolicited as the amount in one PDU may not be all you want.

Julo
Dennis Young <dyoung@rhapsodynetworks.com>
Sent by: owner-ips@ece.cmu.edu

06/12/2002 08:49 PM
Please respond to Dennis Young

       
      To:        Julian Satran/Haifa/IBM@IBMIL
      cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
      Subject:        RE: iscsi: unsolicited data question

     




Are you saying that, for a session that has InitialR2T=No in effect, the initiator
must send all its data as unsolicited first, up to the amount negotiated in
FirstBurstSize, before it waits for a R2T from the target?

Can you shed some light on why we need unsolicited Data-out PDU when there
is ImmediateData, seems like they both serve the same purpose, having both of
them only make the spec more complex.

Thanks,
-Dennis

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 12, 2002 10:19 AM
To: Dennis Young
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iscsi: unsolicited data question


This is the reason why the initiator is required to send ALL unsolicited data (target can count on it and start sending R2Ts as soon as it sees the first header>
Neither bandwidth nor latency are wasted.

Julo
Dennis Young <dyoung@rhapsodynetworks.com>

06/12/2002 08:05 PM
Please respond to Dennis Young

       
     To:        Julian Satran/Haifa/IBM@IBMIL
     cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
     Subject:        RE: iscsi: unsolicited data question

   





Julian,

This leads me to a more interesting question.
A session with InitialR2T=No in effect, i.e. unsolicited Data-out
allowed, could cause unintended waste of bandwidth, depending on
how fast the target sends our R2T in response to the SCSI Write.

If the target sees the unsolicited Data-out PDU before building the
R2T, then everything is fine.
If the target doesn't see the unsolicited Data-out PDU before building
the R2T, the R2T would request the same portion of data in the
unsolicited Data-out, thus bandwidth is wasted.

The question is, how can a target be smart about this?
Should the target wait a moment for the possible unsolicited Data-out
after receiving each SCSI Write, this sounds kludgy.

Also, why do we need the unsolicited Data-out PDU feature when
there is ImmediateData?

Regards,
Dennis

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 12, 2002 6:05 AM
To: Dennis Young
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iscsi: unsolicited data question


yes - julo
Dennis Young <dyoung@rhapsodynetworks.com>
Sent by: owner-ips@ece.cmu.edu

06/12/2002 06:20 AM
Please respond to Dennis Young

       
    To:        ips@ece.cmu.edu
    cc:        
    Subject:        iscsi: unsolicited data question

   






I have a question which has been asked before, but I couldn't find a direct
answer in the archive.  The table on page 200 of draft 12 doesn't directly
answer this question either.

The first paragraph on page 36 of draft 12 says "Targets operate in either
solicitied (R2T) data mode or unsolicited (non R2T) data mode."
tells me that a target, at all times during a data sequence transfer, can be

one or the other, but not both (non R2T for the initial data out, R2T for
the
remaining data).  Is this correct?

Thanks,
Dennis

---snip from an old email dated 3/30/2001---

" Hi Julian
Sorry if I'm covering old ground... Is it possible to use unsolicited data
for the first burst and then request any remaining data using R2T? For
example, if the target has a previously allocated buffer available (length
defined by FirstBurstSize) for unsolicited data, then once the initiator has
sent unsolicited data up to and including this amount then the remaining
data (if any) can be requested using R2T once the target has the buffer
space available.
...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail:
matthewb@bri.hp.com "

--=_alternative 00613E07C2256BD7_=-- From owner-ips@ece.cmu.edu Thu Jun 13 15:41:17 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27883 for ; Thu, 13 Jun 2002 15:41:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DIhvW13283 for ips-outgoing; Thu, 13 Jun 2002 14:43:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DIhsw13270 for ; Thu, 13 Jun 2002 14:43:54 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5DIhcE8056504; Thu, 13 Jun 2002 20:43:38 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5DIhSq58922; Thu, 13 Jun 2002 20:43:28 +0200 To: Luben Tuikov Cc: iSCSI , luben@ns.splentec.com MIME-Version: 1.0 Subject: Re: iSCSI: 12-97 Bit Rule X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 13 Jun 2002 21:27:54 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 13/06/2002 21:43:30, Serialize complete at 13/06/2002 21:43:30 Content-Type: multipart/alternative; boundary="=_alternative 00656193C2256BD7_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00656193C2256BD7_= Content-Type: text/plain; charset="us-ascii" Luben, The draft has figure that are an integral part of it. In every one of those bit 7 is the least significant. I don't know what your NORMALLY means. Julo Luben Tuikov Sent by: luben@ns.splentec.com 06/13/2002 09:14 PM Please respond to Luben Tuikov To: Julian Satran/Haifa/IBM@IBMIL cc: iSCSI Subject: Re: iSCSI: 12-97 Bit Rule Julian Satran wrote: > > I took out completely the bit rule. > I reformulated the CRC text as: > > The CRC MUST be calculated by a method that produces the same results as the following process: > > - The PDU bits are considered as the coefficients of a polyno-mial M(x) of degree n-1; bit 7 of > the lowest numbered byte is considered the most significant bit (x^n-1), followed by bit 6 of the > lowest numbered byte and through bit 0 of the high-est numbered byte (x^0). This description, taken by itself, as you quote it here, mentions bit 7 of a byte. Normally, bit 7 of a byte is the Most Significant bit (MSb). But somewhere you MUST mention that bit 7 is, contrary to all intuition, the LSb, NOT, as many of us would assume, the MSb. (I.e. the _bit_ ordering as per the PDU template doesn't imply bit significance, or does it?) I.e. you need to mention that the bytes are mirrored. Here it is, again: 1) The bytes of the message form a bit stream, ordered Most Significant Byte (MSB), Most Significant bit (MSb) in memory, i.e. Big endian on bytes, Big endian on bits. Call this bit stream P. 2) The bytes of P are mirrored, thus forming byte 0, LSb first to MSb, then byte 1, LSb first to MSb, etc, (Big endian on Bytes, Little endian on bits), this forms the bit sequence A = {a_0, a_1, ..., a_(n-1)}. 3) The first 32 bits of A are complemented (a_0 to a_31). 4) The bits of A are considered coefficients of M(x), where M(x) = a_0 x^(n-1) + ... + a_(n-1) x^0. 5) The polynomial M(x) is multiplied by x^32, then divided by G(x), where G(x) is the polynomial representation of 0x11edc6f41. This produces a remainder R(x) of degree <= 31. 6) The coefficients of R(x) are considered a 32 bit sequence, R(x) = r_31 x^31 + ... + r_0 x^0. 7) R(x) is complemented and mirrored, the result is CRC(x). 8) The message sent is P and appended at the end are the bit coefficients of CRC(x), with x^31 bit coefficient first, then x^30, etc. 9) A receiver of a "good" message sent as per step (8), will get the value 0x1c2d19ed as R(x) (steps (1) to (6)). Note that CRC(x) is a polynomial and independent of the machine's representation. For clarity, I've omitted the fact that x^0 = 1. So, steps 1 to 6 form ``R(x) = compute_crc(P)'', and steps 7 to 8 form ``Send_This = inject_crc(P, R(x))''. I.e. ``Magic_Value = compute_crc(inject_crc(P, compute_crc(P)))'' Thus, one sends ``inject_crc(P, compute_crc(P))'', and the receiver does ``Magic_Value =?= compute_crc(message_received)'', which is step 9. -- Luben --=_alternative 00656193C2256BD7_= Content-Type: text/html; charset="us-ascii"
Luben,

The draft has figure that are an integral part of it.
In every one of those bit 7 is the least significant.
I don't know what your NORMALLY means.
Julo


Luben Tuikov <luben@splentec.com>
Sent by: luben@ns.splentec.com

06/13/2002 09:14 PM
Please respond to Luben Tuikov

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        iSCSI <ips@ece.cmu.edu>
        Subject:        Re: iSCSI: 12-97 Bit Rule

       


Julian Satran wrote:
>
> I took out completely the bit rule.
> I reformulated the CRC text as:
>
> The CRC MUST be calculated by a method that produces the same results as the following process:
>
>  - The PDU bits are considered as the coefficients of a polyno-mial M(x) of degree n-1; bit 7 of
> the lowest numbered byte is considered the most significant bit (x^n-1), followed by bit 6 of the
> lowest numbered byte and through bit 0 of the high-est numbered byte (x^0).

This description, taken by itself, as you quote it here,
mentions bit 7 of a byte. Normally, bit 7 of a byte is
the Most Significant bit (MSb).

But somewhere you MUST mention that bit 7 is, contrary to all
intuition, the LSb, NOT, as many of us would assume, the MSb.
(I.e. the _bit_ ordering as per the PDU template doesn't
imply bit significance, or does it?)

I.e. you need to mention that the bytes are mirrored.

Here it is, again:

1) The bytes of the message form a bit stream, ordered
  Most Significant Byte (MSB), Most Significant bit (MSb)
  in memory, i.e. Big endian on bytes, Big endian on bits.
  Call this bit stream P.

2) The bytes of P are mirrored, thus forming byte 0, LSb
  first to MSb, then byte 1, LSb first to MSb, etc,
  (Big endian on Bytes, Little endian on bits), this forms the
  bit sequence A = {a_0, a_1, ..., a_(n-1)}.

3) The first 32 bits of A are complemented (a_0 to a_31).

4) The bits of A are considered coefficients of M(x),
  where M(x) = a_0 x^(n-1) + ... + a_(n-1) x^0.

5) The polynomial M(x) is multiplied by x^32, then divided by G(x),
  where G(x) is the polynomial representation of 0x11edc6f41.
  This produces a remainder R(x) of degree <= 31.

6) The coefficients of R(x) are considered a 32 bit sequence,
  R(x) = r_31 x^31 + ... + r_0 x^0.

7) R(x) is complemented and mirrored, the result is CRC(x).

8) The message sent is P and appended at the end are the
  bit coefficients of CRC(x), with x^31 bit coefficient
  first, then x^30, etc.

9) A receiver of a "good" message sent as per step (8),
  will get the value 0x1c2d19ed as R(x) (steps (1) to (6)).

Note that CRC(x) is a polynomial and independent of
the machine's representation.

For clarity, I've omitted the fact that x^0 = 1.

So, steps 1 to 6 form ``R(x) = compute_crc(P)'',
and steps 7 to 8 form ``Send_This = inject_crc(P, R(x))''.

I.e. ``Magic_Value = compute_crc(inject_crc(P, compute_crc(P)))''

Thus, one sends ``inject_crc(P, compute_crc(P))'',
and the receiver does ``Magic_Value =?= compute_crc(message_received)'',
which is step 9.

--
Luben

--=_alternative 00656193C2256BD7_=-- From owner-ips@ece.cmu.edu Thu Jun 13 15:43:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27993 for ; Thu, 13 Jun 2002 15:43:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DJJxO15450 for ips-outgoing; Thu, 13 Jun 2002 15:19:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DJJrw15432 for ; Thu, 13 Jun 2002 15:19:57 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g5DJLFu31107; Thu, 13 Jun 2002 15:21:15 -0400 Message-ID: <3D08F04D.7806C2D4@splentec.com> Date: Thu, 13 Jun 2002 15:19:41 -0400 From: Luben Tuikov Reply-To: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Julian Satran CC: iSCSI Subject: Re: iSCSI: 12-97 Bit Rule References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian Satran wrote: > > Luben, > > The draft has figure that are an integral part of it. > In every one of those bit 7 is the least significant. > I don't know what your NORMALLY means. Julian, any book you open on computer architecture, assumes that bit 7 is more significant than bit 6, simply because 2^7 > 2^6. Stipulating that bit 7 is less significant than bit 6, needs explicitly to be said so, NOT inferred from ``figures in the text''. Nevertheless, as you may have already noticed, the algorithm which I sent you, is _independent_ of iSCSI's implication that bit 7 is less significant than bit 6. So, anywhich way you order the bits in the bytes for the rest of the draft, the algoritm would produce the same results, simply because it explicitly mentions ordering in step 1 (and 2). -- Luben From owner-ips@ece.cmu.edu Thu Jun 13 15:58:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28452 for ; Thu, 13 Jun 2002 15:58:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DJe5H16666 for ips-outgoing; Thu, 13 Jun 2002 15:40:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DJe3w16658 for ; Thu, 13 Jun 2002 15:40:03 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5DJdf9h049914; Thu, 13 Jun 2002 21:39:41 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5DJdeq21730; Thu, 13 Jun 2002 21:39:40 +0200 To: Luben Tuikov Cc: iSCSI , luben@ns.splentec.com MIME-Version: 1.0 Subject: Re: iSCSI: 12-97 Bit Rule X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 13 Jun 2002 22:39:35 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 13/06/2002 22:39:40, Serialize complete at 13/06/2002 22:39:40 Content-Type: multipart/alternative; boundary="=_alternative 006B2C1AC2256BD7_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 006B2C1AC2256BD7_= Content-Type: text/plain; charset="us-ascii" Luben, We are writing based on IETF rules. You are not reading a book - you are reading an IETF draft! Julo Luben Tuikov Sent by: luben@ns.splentec.com 06/13/2002 10:19 PM Please respond to Luben Tuikov To: Julian Satran/Haifa/IBM@IBMIL cc: iSCSI Subject: Re: iSCSI: 12-97 Bit Rule Julian Satran wrote: > > Luben, > > The draft has figure that are an integral part of it. > In every one of those bit 7 is the least significant. > I don't know what your NORMALLY means. Julian, any book you open on computer architecture, assumes that bit 7 is more significant than bit 6, simply because 2^7 > 2^6. Stipulating that bit 7 is less significant than bit 6, needs explicitly to be said so, NOT inferred from ``figures in the text''. Nevertheless, as you may have already noticed, the algorithm which I sent you, is _independent_ of iSCSI's implication that bit 7 is less significant than bit 6. So, anywhich way you order the bits in the bytes for the rest of the draft, the algoritm would produce the same results, simply because it explicitly mentions ordering in step 1 (and 2). -- Luben --=_alternative 006B2C1AC2256BD7_= Content-Type: text/html; charset="us-ascii"
Luben,

We are writing based on IETF rules. You are not reading a book - you are reading an IETF draft!

Julo


Luben Tuikov <luben@splentec.com>
Sent by: luben@ns.splentec.com

06/13/2002 10:19 PM
Please respond to Luben Tuikov

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        iSCSI <ips@ece.cmu.edu>
        Subject:        Re: iSCSI: 12-97 Bit Rule

       


Julian Satran wrote:
>
> Luben,
>
> The draft has figure that are an integral part of it.
> In every one of those bit 7 is the least significant.
> I don't know what your NORMALLY means.

Julian, any book you open on computer architecture,
assumes that bit 7 is more significant than bit 6,
simply because 2^7 > 2^6.

Stipulating that bit 7 is less significant than
bit 6, needs explicitly to be said so, NOT
inferred from ``figures in the text''.

Nevertheless, as you may have already noticed,
the algorithm which I sent you, is _independent_
of iSCSI's implication that bit 7 is less significant
than bit 6.

So, anywhich way you order the bits in the bytes
for the rest of the draft, the algoritm would
produce the same results, simply because
it explicitly mentions ordering in step 1 (and 2).

--
Luben

--=_alternative 006B2C1AC2256BD7_=-- From owner-ips@ece.cmu.edu Thu Jun 13 16:15:10 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28981 for ; Thu, 13 Jun 2002 16:15:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DJIwg15347 for ips-outgoing; Thu, 13 Jun 2002 15:18:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DJItw15342 for ; Thu, 13 Jun 2002 15:18:55 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5DJIn4L046182; Thu, 13 Jun 2002 21:18:49 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5DJImq83742; Thu, 13 Jun 2002 21:18:48 +0200 To: "Mallikarjun C." Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: Fw: iSCSI: changing MaxPDUDataLength X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 13 Jun 2002 22:08:48 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 13/06/2002 22:18:48, Serialize complete at 13/06/2002 22:18:48 Content-Type: multipart/alternative; boundary="=_alternative 00690351C2256BD7_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00690351C2256BD7_= Content-Type: text/plain; charset="us-ascii" Mallikarjun pointed that to me - so - using offset in SNACK is not a practical proposition because the offset is not known. The initiator misses something - it does not know what; it knows only that it missed a number. keeping track of any byte sent (scoreboarding) is not something easily doable in SCSI - where the target is the "transfer master". I am a bit obscure but I assume that Eddy understands already. Julo "Mallikarjun C." 06/13/2002 09:57 PM Please respond to "Mallikarjun C." To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: Fw: iSCSI: changing MaxPDUDataLength ----- Original Message ----- From: "Eddy Quicksall" To: "Mallikarjun C." Sent: Thursday, June 13, 2002 4:51 AM Subject: RE: iSCSI: changing MaxPDUDataLength > I thought I always said that data-in was the issue. If I didn't make that > clear, I apologize. > > If there is no reason other than making a point and keeping consistency, can > you please talk over the likelihood of using an offset and data length > instead of BegRun and RunLength? If that were done, the target would not > have any issues to deal with. > > > >All you need on a per-task basis is really the value of one DataSN > >*where* it had changed. > > Yes, this is one thing I've been driving at. If hardware is independently > handling the transmission, it is likely in a loop sending PDU's with > MaxPDUDataSegmentLength. The firmware would have to pause the hardware; then > go to each TCB and record the current DataSN; then inform the hardware of > the new Length; then unpause the hardware. On most pieces of hardware I've > seen in the past with a pause feature, there has always been some sort of > oversight and a lot of ugly work around code had to be written. > > If there are different processors used (one for the fast path and one for > the slow path), then coordination between the processors has to take place > also. > > In hardware, it is not uncommon to keep the TCBs in very fast memory. That > type of design usually has a limit on memory because it is usually on chip. > Now, to ask for an extra DWORD in every TCB for something that is 99% of the > time unused is almost unheard of. If that DWORD were in external memory then > there would likely have to be code that touches that memory each time a TCB > is started (or finished). > > You're pseudo code below has a slight flaw. Since, in a single TCB, some > PDU's may have been transmitted with the old size and some with the new size > and then a BegRun is some number of PDU's into the new size, you have to > also use the new size and number of PDU's into the new size in your > calculation. Not difficult code but just adds to the messiness that I would > like to avoid. > > I've mentioned four things here that account for why I said it is messy. I > never tried to say its not doable or conceptually simple. > > Can you please consider using an offset? > > > > Eddy > > -----Original Message----- > From: Mallikarjun C. [ mailto:cbm@rose.hp.com] > Sent: Wednesday, June 12, 2002 9:03 PM > To: Eddy Quicksall > Subject: Re: iSCSI: changing MaxPDUDataLength > > > Eddy, > > Comments inline, I think it's best to take it off the list (at least for a > while). > > Caveat: I am *still* not clear on the specifics you have in mind. You > talked > about quiescing the commands, then data, then only read commands.... > > I have to apologize, but I am afraid I can't spend my cycles any further on > this thread. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > > ----- Original Message ----- > From: "Eddy Quicksall" > To: "Mallikarjun C." > Cc: > Sent: Wednesday, June 12, 2002 2:19 PM > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > Mallikarjun, > > > > This is not a case of arguing ... we are simply trying to understand each > > others point over EMAIL, which is difficult at best. Please try to work > with > > me instead of against me. > > I am fairly oblivious to the person arguing an issue, it's the issue and its > consequences that matter to me. > > >I could be wrong but I just need a little more > > cooperation instead of using the overworked terms like "if you will just > > read ...". > > Which I didn't say... > > > > > You went into enough detail in one EMAIL to show that it is a messy job. > > When a solution is too messy and hard to explain, it is usually a clue > that > > something needs to be simplified ... and that is what I am after. > > > > So far, I have not been able to catch the reason why we could not simply > > specify that the initiator must idle the commands before issuing a new > size. > > Julian hinted that it would be a performance hit but I don't believe that > > will be a performance hit because it should be rare. Please explain why it > > would be a performance hit. > > I can't explain what others said, but my point is that changing the PDU size > in the middle of the I/O *does not have to* cause the explosion of metadata > that you were fearing. > > > > > I would also like to know why the SNACK just doesn't simply ask for an > > offset and a data length because that would simplify everything. Could you > > please explain that? > > I think to make the point that data retransmission requests can only be made > at the PDU level, and also to be consistent with other types of SNACK > (status, > data ACK). > > > > > You mention data-out below but I'm not talking about data-out, I'm talking > > about data-in. > > But they may be related! Here's what I said earlier - > "a) reads and writes may both be active in the typical case on an iSCSI > connection," > I thought you were coming up with a rule that affects initiator iSCSI > layer's ability to quickly > react to PMTU changes. If so, it would impact both reads and writes. > > > > > BTW, I don't have much background in ULPDU so maybe that is the key as to > > why the initiator can't idle first. Can you please explain that? > > > > ULPDU means "ULP PDU" - ULP from the perspective of the framing layer. > Please refer TUF draft for details. > > > > > I don't know what this has to do with a long write. Can you please explain > > that? > > I already explained this..... > " As I earlier hinted twice, the Data-Out PDUs will not be ULPDU-contained > anymore - and that could mean target would need to spend more memory/bus > bandwidth/computation to deal with those till the long write is done. " > > > In re-reading your statement below, I am wondering if you understand the > > problem ... > > Yes, I do. > > >The problem is that when a SNACK is sent and the PDU sizes have > > changed due to MaxPDUDataSegmentLength, then it puts a burden on the > target > > to compute the proper offset of the BegRun (a.k.a messy). > > > > This is solved by the target in at least two ways: > > > > 1) The target can record the last PDU size when the change takes place. > But > > it would also have to keep track of the number of already completed PDU's > > per outstanding command. This is because some commands may have missing > > PDU's with the old size and others may have missing PDU's with the new > size. > > To make matters worse, some commands could have n PDUs already sent and > > others could have m PDUs already sent. If you want, I could make up a > > diagram of this and send it to you. > > Not necessary. I assume you're referring to read commands. I already > answered this - "Given that the changed PDU size is not specific to one > command, I see the history of "past max PDU size(s)" as a connection > attribute. All you need on a per-task basis is really the value of one > DataSN > *where* it had changed." [ Assume that this is a TCB element called > "PDU_size_changed_at". ] > > Thinking about all permutations could be distracting. All you want is > "given a > DataSN, translate it to a data offset without maintaining DataSN->PDU_size > records for each past PDU you had earlier sent". That should be quite > doable > with what I described > > if (TCB.PDU_size_changed_at is invalid) { > Offset = SNACK.BegRun*Connection.PDU_size; > } else { > Compute the offset based on whether BegRun is before or after > TCB.PDU_size_changed_at. Use Connection.Previous_PDU_size. > } > > The "if" condition computes to "true" 99% of the time. > > This is as explicit as I can be..... > > > > > 2) The target could "force an idle of data-in commands" (by queuing them) > > before it responds to the change request. Doing this would probably be no > > different than the initiator doing it but it would be easier and less > > intrusive for the initiator to do it. > > > > > > Eddy > > > > --=_alternative 00690351C2256BD7_= Content-Type: text/html; charset="us-ascii"
Mallikarjun pointed that to me - so - using offset in SNACK is not a practical proposition because the offset is not known.
The initiator misses something - it does not know what; it knows only that it missed a number.

keeping track of any byte sent (scoreboarding) is not something easily doable in SCSI - where the target is the "transfer master".
I am a bit obscure but I assume that Eddy understands already.

Julo


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

06/13/2002 09:57 PM
Please respond to "Mallikarjun C."

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        
        Subject:        Fw: iSCSI: changing MaxPDUDataLength

       


----- Original Message -----
From: "Eddy Quicksall" <eddy_quicksall@ivivity.com>
To: "Mallikarjun C." <cbm@rose.hp.com>
Sent: Thursday, June 13, 2002 4:51 AM
Subject: RE: iSCSI: changing MaxPDUDataLength


> I thought I always said that data-in was the issue. If I didn't make that
> clear, I apologize.
>
> If there is no reason other than making a point and keeping consistency, can
> you please talk over the likelihood of using an offset and data length
> instead of BegRun and RunLength? If that were done, the target would not
> have any issues to deal with.
>
>
> >All you need on a per-task basis is really the value of one DataSN
> >*where* it had changed.
>
> Yes, this is one thing I've been driving at. If hardware is independently
> handling the transmission, it is likely in a loop sending PDU's with
> MaxPDUDataSegmentLength. The firmware would have to pause the hardware; then
> go to each TCB and record the current DataSN; then inform the hardware of
> the new Length; then unpause the hardware. On most pieces of hardware I've
> seen in the past with a pause feature, there has always been some sort of
> oversight and a lot of ugly work around code had to be written.
>
> If there are different processors used (one for the fast path and one for
> the slow path), then coordination between the processors has to take place
> also.
>
> In hardware, it is not uncommon to keep the TCBs in very fast memory. That
> type of design usually has a limit on memory because it is usually on chip.
> Now, to ask for an extra DWORD in every TCB for something that is 99% of the
> time unused is almost unheard of. If that DWORD were in external memory then
> there would likely have to be code that touches that memory each time a TCB
> is started (or finished).
>
> You're pseudo code below has a slight flaw. Since, in a single TCB, some
> PDU's may have been transmitted with the old size and some with the new size
> and then a BegRun is some number of PDU's into the new size, you have to
> also use the new size and number of PDU's into the new size in your
> calculation. Not difficult code but just adds to the messiness that I would
> like to avoid.
>
> I've mentioned four things here that account for why I said it is messy. I
> never tried to say its not doable or conceptually simple.
>
> Can you please consider using an offset?
>
>
>
> Eddy
>
> -----Original Message-----
> From: Mallikarjun C. [  <mailto:cbm@rose.hp.com> mailto:cbm@rose.hp.com]
> Sent: Wednesday, June 12, 2002 9:03 PM
> To: Eddy Quicksall
> Subject: Re: iSCSI: changing MaxPDUDataLength
>
>
> Eddy,
>
> Comments inline, I think it's best to take it off the list (at least for a
> while).
>
> Caveat: I am *still* not clear on the specifics you have in mind.  You
> talked
> about quiescing the commands, then data, then only read commands....
>
> I have to apologize, but I am afraid I can't spend my cycles any further on
> this thread.
> --
> Mallikarjun
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions
> Hewlett-Packard MS 5668
> Roseville CA 95747
> cbm@rose.hp.com
>
>
> ----- Original Message -----
> From: "Eddy Quicksall" <eddy_quicksall@ivivity.com>
> To: "Mallikarjun C." <cbm@rose.hp.com>
> Cc: <ips@ece.cmu.edu>
> Sent: Wednesday, June 12, 2002 2:19 PM
> Subject: RE: iSCSI: changing MaxPDUDataLength
>
>
> > Mallikarjun,
> >
> > This is not a case of arguing ... we are simply trying to understand each
> > others point over EMAIL, which is difficult at best. Please try to work
> with
> > me instead of against me.
>
> I am fairly oblivious to the person arguing an issue, it's the issue and its
> consequences that matter to me.
>
> >I could be wrong but I just need a little more
> > cooperation instead of using the overworked terms like "if you will just
> > read ...".
>
> Which I didn't say...
>
> >
> > You went into enough detail in one EMAIL to show that it is a messy job.
> > When a solution is too messy and hard to explain, it is usually a clue
> that
> > something needs to be simplified ... and that is what I am after.
> >
> > So far, I have not been able to catch the reason why we could not simply
> > specify that the initiator must idle the commands before issuing a new
> size.
> > Julian hinted that it would be a performance hit but I don't believe that
> > will be a performance hit because it should be rare. Please explain why it
> > would be a performance hit.
>
> I can't explain what others said, but my point is that changing the PDU size
> in the middle of the I/O *does not have to* cause the explosion of metadata
> that you were fearing.
>
> >
> > I would also like to know why the SNACK just doesn't simply ask for an
> > offset and a data length because that would simplify everything. Could you
> > please explain that?
>
> I think to make the point that data retransmission requests can only be made
> at the PDU level, and also to be consistent with other types of SNACK
> (status,
> data ACK).
>
> >
> > You mention data-out below but I'm not talking about data-out, I'm talking
> > about data-in.
>
> But they may be related!  Here's what I said earlier -
>  "a) reads and writes may both be active in the typical case on an iSCSI
> connection,"
> I thought you were coming up with a rule that affects initiator iSCSI
> layer's ability to quickly
> react to PMTU changes.  If so, it would impact both reads and writes.
>
> >
> > BTW, I don't have much background in ULPDU so maybe that is the key as to
> > why the initiator can't idle first. Can you please explain that?
> >
>
> ULPDU means "ULP PDU" - ULP from the perspective of the framing layer.
> Please refer TUF draft for details.
>
> >
> > I don't know what this has to do with a long write. Can you please explain
> > that?
>
> I already explained this.....
>  " As I earlier hinted twice, the Data-Out PDUs will not be ULPDU-contained
>   anymore - and that could mean target would need to spend more memory/bus
>   bandwidth/computation to deal with those till the long write is done. "
>
> > In re-reading your statement below, I am wondering if you understand the
> > problem ...
>
> Yes, I do.
>
> >The problem is that when a SNACK is sent and the PDU sizes have
> > changed due to MaxPDUDataSegmentLength, then it puts a burden on the
> target
> > to compute the proper offset of the BegRun (a.k.a messy).
> >
> > This is solved by the target in at least two ways:
> >
> > 1) The target can record the last PDU size when the change takes place.
> But
> > it would also have to keep track of the number of already completed PDU's
> > per outstanding command. This is because some commands may have missing
> > PDU's with the old size and others may have missing PDU's with the new
> size.
> > To make matters worse, some commands could have n PDUs already sent and
> > others could have m PDUs already sent. If you want, I could make up a
> > diagram of this and send it to you.
>
> Not necessary.  I assume you're referring to read commands.  I already
> answered this - "Given that the changed PDU size is not specific to one
> command, I see the history of "past max PDU size(s)" as a connection
> attribute.  All you need on a per-task basis is really the value of one
> DataSN
> *where* it had changed." [ Assume that this is a TCB element called
> "PDU_size_changed_at". ]
>
> Thinking about all permutations could be distracting.  All you want is
> "given a
> DataSN, translate it to a data offset without maintaining DataSN->PDU_size
> records for each past PDU you had earlier sent".  That should be quite
> doable
> with what I described
>
> if (TCB.PDU_size_changed_at is invalid) {
>              Offset = SNACK.BegRun*Connection.PDU_size;
> } else {
>              Compute the offset based on whether BegRun is before or after
>              TCB.PDU_size_changed_at.  Use Connection.Previous_PDU_size.
> }
>
>  The "if" condition computes to "true" 99% of the time.
>
> This is as explicit as I can be.....
>
> >
> > 2) The target could "force an idle of data-in commands" (by queuing them)
> > before it responds to the change request. Doing this would probably be no
> > different than the initiator doing it but it would be easier and less
> > intrusive for the initiator to do it.
> >
> >
> > Eddy
>
>
>
>



--=_alternative 00690351C2256BD7_=-- From owner-ips@ece.cmu.edu Thu Jun 13 16:27:23 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29267 for ; Thu, 13 Jun 2002 16:27:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DK1Cn17972 for ips-outgoing; Thu, 13 Jun 2002 16:01:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DK19w17960 for ; Thu, 13 Jun 2002 16:01:09 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g5DK2Su31434; Thu, 13 Jun 2002 16:02:28 -0400 Message-ID: <3D08F9F6.6F9D96DC@splentec.com> Date: Thu, 13 Jun 2002 16:00:54 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Julian Satran , iSCSI Subject: Re: iSCSI: 12-97 Bit Rule References: <3D08E11A.A93B9C08@splentec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Luben Tuikov wrote: > 7) R(x) is complemented and mirrored, the result is CRC(x). ^ Missed here ``byte'', i.e. ``complemented and byte mirrored''. -- Luben From owner-ips@ece.cmu.edu Thu Jun 13 16:54:44 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29792 for ; Thu, 13 Jun 2002 16:54:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DKNSS19297 for ips-outgoing; Thu, 13 Jun 2002 16:23:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DKNQw19292 for ; Thu, 13 Jun 2002 16:23:26 -0400 (EDT) Received: from mail pickup service by mail8.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 16:08:27 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 16:44:45 -0400 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AKiftH010564 for ; Mon, 10 Jun 2002 16:44:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AJvBE08892 for ips-outgoing; Mon, 10 Jun 2002 15:57:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AJv8w08884 for ; Mon, 10 Jun 2002 15:57:08 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 5FEF830706; Mon, 10 Jun 2002 15:57:07 -0400 (EDT) Date: Mon, 10 Jun 2002 12:54:59 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Michael Smith Cc: Subject: Re: iSCSI: AHS use In-Reply-To: <034670D62D19D31180990090277A37B702437BC0@mercury.corp.iready.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Mon, 10 Jun 2002, Michael Smith wrote: > I have some questions on the current AHS descriptions in 12-97. I just > tripped over this, so I think maybe others might too. [snip] > 2. However, in the PDU format diagram on p. 131 of 12-97 it is not clear > that we have the option of zero, one or more Additional Header Segments. > After I re-read things a few times, and apologies if I have this wrong, I > think that the use of multiple Additional Header Segments is along these > lines: > > (a) Use one and only one Additional Header Segment for an extended CDB (SPC > calls this a variable-length CDB). This extended CDB (or variable-length > CDB) Additional Header Segment must immediately follow the BHS. (A suggested > exact use definition of this type of Additional Header Segment coming up.) > > (b) Use one and only one Additional Header Segment for an Bidirectional > Expected Read-Data Length. This Bidirectional Expected Read-Data Length > Additional Header Segment must immediately follow the BHS. > > (c) Use of more than one Additional Header Segment is left up to the user. > > How many Additional Header Segments were we expecting to be able to be used? > Would this maximum length of Additional Header Segments be limited only by > the TotalAHSLength (8-bit field measuring length in four-byte words or > ((2**8) - 1) * 4 bytes or roughly 1 kbyte)? Can we follow an extended CDB > Additional Header Segment or a Bidirectional Expected Read-Data Length > Additional Header Segment by one or more user-defined Additional Header > Segment? > > Did I get this anywhere close to correct? Not sure about correct, but you got it as I understand it. :-) The one thing I'm not sure about is the use of, "must immediately follow the BHS." I agree it must be in the AHS associated with the BHS, but if you have a variable-length command (with CDB spill) which is also a bidi command, you will have both an (a) and a (b), and only one can immediately follow the BHS. :-) > 3. In one of Bob Russell's emails we have the following, which does seem to > make the use of multiple Additional Header Segments a little clearer to me: > > > [quote http://www.pdl.cmu.edu/mailinglists/ips/mail/msg03784.html] > > [view in fixed-width font on wide window] > +------------------------+ > | required BHS | > fixed length of 48 bytes > +------------------------+ > | optional AHS 1 |\ > | - - - - - - - - - - - | \ > | optional AHS 2 | \ > | - - - - - - - - - - - | > total length in AHS_length field in BHS > | . . . . | / > | - - - - - - - - - - - | / > | optional AHS n |/ > +------------------------+ > | optional header digest | -- covers preceding (48 + AHS_length) bytes > +------------------------+ > | |\ > | optional data | > total length in DATA_length field in BHS > | |/ > +------------------------+ > | optional data digest | -- covers preceding (DATA_length) bytes > +------------------------+ > > [end view in fixed-width font on wide window] > > [end quote http://www.pdl.cmu.edu/mailinglists/ips/mail/msg03784.html] > > Is it possible to add something like this picture to the format diagram on > p.131. I wouldn't ask if I hadn't tripped myself up on this already. I think such a diagram would help too. > 4. On p. 139 of 12-97 we have the following: [snip text suggestion] > There are 16 bytes in the CDB field to accommodate bytes 0-15 of the > commonly used CDBs. An Extended CDB AHS MUST be used to contain bytes 16-259 > of a variable-length CDB [SPC]. Sounds like a good change too. Take care, Bill From owner-ips@ece.cmu.edu Thu Jun 13 17:02:54 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29960 for ; Thu, 13 Jun 2002 17:02:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DKbla20258 for ips-outgoing; Thu, 13 Jun 2002 16:37:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DKbjw20253 for ; Thu, 13 Jun 2002 16:37:45 -0400 (EDT) Received: from mail pickup service by mail8.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 16:15:33 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 21:04:07 -0400 Received: from ruebert.ieee.org (ruebert.ieee.org [140.98.193.10]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5B148Ia024238 for ; Mon, 10 Jun 2002 21:04:08 -0400 (EDT) Received: from ece.cmu.edu (gemini3.ieee.org [140.98.193.25]) by ruebert.ieee.org (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5B13Xq18319; Mon, 10 Jun 2002 21:03:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5B0s6r23557 for ips-outgoing; Mon, 10 Jun 2002 20:54:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5B0s5w23552 for ; Mon, 10 Jun 2002 20:54:05 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 64F5C30706; Mon, 10 Jun 2002 20:54:04 -0400 (EDT) Date: Mon, 10 Jun 2002 17:51:57 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Paul Koning Cc: , , , Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys In-Reply-To: <15621.17446.323000.879391@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Mon, 10 Jun 2002, Paul Koning wrote: > Excerpt of message (sent 10 June 2002) by Bill Studenmund: > > I expect iSCSI 2 (or 1.1) will be on the order of a year or more out from > > iSCSI. What does everyone else think? > > If the spec is as good as it should be, that's a fine time frame. But > if significant interop issues are found soon after RFC, then 1.1 will > have to happen a whole lot sooner. What happens if we're somewhere inbetween? Or what if we find an issue where 80% of the implementations all chose the same way? I'm trying to scope out the shades of gray we might run into. Take care, Bill From owner-ips@ece.cmu.edu Thu Jun 13 17:10:28 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00220 for ; Thu, 13 Jun 2002 17:10:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DKYI219976 for ips-outgoing; Thu, 13 Jun 2002 16:34:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DKYGw19970 for ; Thu, 13 Jun 2002 16:34:16 -0400 (EDT) Received: from mail pickup service by mail8.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 16:13:47 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 16:50:11 -0400 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AKoBIa012534 for ; Mon, 10 Jun 2002 16:50:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AKA9U09683 for ips-outgoing; Mon, 10 Jun 2002 16:10:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AKA8w09679 for ; Mon, 10 Jun 2002 16:10:08 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 27F429A34; Mon, 10 Jun 2002 14:10:07 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 6B98914E; Mon, 10 Jun 2002 14:10:06 -0600 (MDT) Received: from 130.29.152.143 by axcsbh1.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 10 Jun 2002 14:10:06 -0600 Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 14:10:05 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E3E67@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Ken Sandars , "THALER"@ece.cmu.edu Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys Date: Mon, 10 Jun 2002 14:10:00 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Ken, The incentive is that, in my experience, when products interoperate out of the chute (because the spec is clear) the market grows quickly. When interoperability is a nightmare built in by testing and tweaks, then markets grow slowly. Ambiguities need to be fixed. A number that have been raised recently have been fixed. If there are ones you feel haven't been addressed, I would like to see them fixed. That is what we should do rather than planning on building in work arounds. Regards, Pat -----Original Message----- From: Ken Sandars [mailto:ksandars@eurologic.com] Sent: Friday, June 07, 2002 10:54 AM To: pat_thaler@agilent.com; ni1d@arrl.net; bmastors@allocity.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys Hi Pat, Paul, Bob, There is no disputing the fact that identifying brokeness and fixing it is the right way to go. Now while it's nice to lend our mental muscles to the task of identifying these problems, it's pretty difficult to compel other vendors to fix something which is broken wrt to the spec, when it works with some other products in the marketplace. The unfortunate reality is that certain problems have been long identified (over half a year in some cases), and remain unfixed. Our approach is to implement the spec. As we encounter problems we fix our broken bits and notify the partner of the issue - in most cases this has worked well and they have fixed their problems too. However, we are compelled to put work-arounds in our system in order to interoperate with those who have have fielded systems which remain broken. At this stage, unless the intiator is known, we turn all the work-arounds on. This has an impact on performance. We'd like to avoid this. We want to see iSCSI run at the speed of a thousand startled gazelles. We want to see all iSCSI offerings interoperate. We don't want to see the management of these things as a nightmare. I think the use of the proposed keys will only assist implementers by providing additonal information - which can be used or ignored. Oh, and we won't send them from our target if the initiator doesn't send them, as there may be some initiator which doesn't handle the X- keys! (I have further comments inline): On Thursday 06 June 2002 11:31 pm, pat_thaler@agilent.com wrote: > Paul, > > I agree. This would also create a testing nightmare for initiator > developers. If the initiator has adapts itself for n targets then > it has n different personalities that all need to be tested. > As Bob Mastors said, it's already in there, so it's being done. And testers are meant to have nightmares! It's their job ;-) > We have interoperability testing to help us find and fix > spec ambiguities that cause interoperability problems. > Yep - we find them, and they ignore them, so this doesn't get us over the finish line. > The way to build market for iSCSI is to have interoperability - > not to have cases wher Brand_x Target doesn't work with Brand_y > Initiator because Brand_y doesn't have the tweak profile for > Brand_x. > As I noted above, we interoperate, but at the cost of performance. > Regards, > Pat > > -----Original Message----- > From: Paul Koning [mailto:ni1d@arrl.net] > Sent: Thursday, June 06, 2002 1:06 PM > To: bmastors@allocity.com > Cc: ksandars@eurologic.com; ips@ece.cmu.edu > Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys > > >>>>> "Bob" == Bob Mastors writes: > > Bob> I like it. Otherwise the user has to configure the initiator > Bob> with the target type and the target with the initiator type. It > Bob> is unlikely that this problem will disappear for a long time if > Bob> ever. As the threads on the C bit has shown there will be lots > Bob> of ways to implement the spec and probably no device will > Bob> correctly support all possibilities. I am already putting "if > Bob> (vendor)" code in my implementation. Maybe in a few years I will > Bob> not need it. But until then it would be nice if I could > Bob> dynamically determine vendor information for iscsi so the user > Bob> does not have to configure it. > > Oh boy, now I'm well and truly frightened. Welcome to my nightmare! > > I read your message as saying that there isn't going to be > interoperability for several years. I'm a lot more optimistic than that - these problems should be gone within a year of the draft becoming a standard. In the meantime, we DO interoperate, just in a hobbled mode for unknown initiators. > Sorather than create a serious > incentive for implementers to fix their defects, Can you suggest what this incentive might be? > we should implement a > way to have them report which collection of defects they implement so > we can invoke workaround collection #42. Of course, the larger the > collection of crocks we work around, the larger the number of bugs in > implementations that everyone else will have to work around. > Sounds messy to me. It comes down to this: we work by default in a mode to achieve maximum interoperability, albeit at the expense of some performance/reliability features. If an initiator lets our target know what it is, and we recognise its lack of the known quirks, we remove the work-arounds. Our tester's nightmares, our developer's pain to identify and create work-arounds, and at no cost to the standards track. And it's all optional. > In the words of a well known American, "Just Say NO". OK - but think carefully before following the advice of famous Americans - didn't some other well known American spell tomato with an 'e'? ;-) > > paul Cheers, Ken -- Ken Sandars Eurologic Systems Ltd ksandars@eurologic.com From owner-ips@ece.cmu.edu Thu Jun 13 17:37:30 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01231 for ; Thu, 13 Jun 2002 17:37:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DLCow22494 for ips-outgoing; Thu, 13 Jun 2002 17:12:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DLCow22490 for ; Thu, 13 Jun 2002 17:12:50 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Jun 2002 17:11:12 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564BF57@CORPMX14> From: Black_David@emc.com To: pat_thaler@agilent.com, ips@ece.cmu.edu Subject: RE: iSCSI: reflector duplicating messages? Date: Thu, 13 Jun 2002 17:11:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Yes, problem is being worked on. --David > -----Original Message----- > From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@agilent.com] > Sent: Thursday, June 13, 2002 5:06 PM > To: ips@ece.cmu.edu > Subject: iSCSI: reflector duplicating messages? > > > Hi, are other people seeing some messages from the reflector > multiple times (beyond the usual getting two copies because > the message is sent to ones own address and the reflector). > > Pat > From owner-ips@ece.cmu.edu Thu Jun 13 17:38:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01282 for ; Thu, 13 Jun 2002 17:38:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DLG3R22659 for ips-outgoing; Thu, 13 Jun 2002 17:16:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from opus.pdl.cmu.edu (root@OPUS.PDL.CMU.EDU [128.2.134.91]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DLG2w22654 for ; Thu, 13 Jun 2002 17:16:02 -0400 (EDT) Received: from opus.pdl.cmu.edu (bassoon@localhost [127.0.0.1]) by opus.pdl.cmu.edu (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA04987 for ; Thu, 13 Jun 2002 17:16:01 -0400 Message-Id: <200206132116.RAA04987@opus.pdl.cmu.edu> To: ips@ece.cmu.edu subject: multiple e-mail messages Date: Thu, 13 Jun 2002 17:16:01 -0400 From: Dave Nagle Sender: owner-ips@ece.cmu.edu Precedence: bulk Everyone, I've asked the computer facilities people to check into the multiple e-mail message problem. Hoping they can fix it w/in a few hours. dave............ From owner-ips@ece.cmu.edu Thu Jun 13 17:44:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01418 for ; Thu, 13 Jun 2002 17:44:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DL61o22087 for ips-outgoing; Thu, 13 Jun 2002 17:06:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DL60w22082 for ; Thu, 13 Jun 2002 17:06:00 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 48ED8BBEB for ; Thu, 13 Jun 2002 15:05:59 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with SMTP id E6A22D5 for ; Thu, 13 Jun 2002 15:05:57 -0600 (MDT) Received: from 130.29.152.143 by axcsbh1.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 13 Jun 2002 15:05:56 -0600 Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Jun 2002 15:05:56 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E4683@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: ips@ece.cmu.edu Subject: iSCSI: reflector duplicating messages? Date: Thu, 13 Jun 2002 15:05:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi, are other people seeing some messages from the reflector multiple times (beyond the usual getting two copies because the message is sent to ones own address and the reflector). Pat From owner-ips@ece.cmu.edu Thu Jun 13 17:46:32 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01478 for ; Thu, 13 Jun 2002 17:46:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DLTRE23478 for ips-outgoing; Thu, 13 Jun 2002 17:29:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DLTQw23474 for ; Thu, 13 Jun 2002 17:29:26 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 6343830706; Thu, 13 Jun 2002 17:29:25 -0400 (EDT) Date: Thu, 13 Jun 2002 14:27:14 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Luben Tuikov Cc: Julian Satran , iSCSI Subject: Re: iSCSI: 12-97 Bit Rule In-Reply-To: <3D08E11A.A93B9C08@splentec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 13 Jun 2002, Luben Tuikov wrote: > Julian Satran wrote: > > - The PDU bits are considered as the coefficients of a polyno-mial M(x) of degree n-1; bit 7 of > > the lowest numbered byte is considered the most significant bit (x^n-1), followed by bit 6 of the > > lowest numbered byte and through bit 0 of the high-est numbered byte (x^0). > > This description, taken by itself, as you quote it here, > mentions bit 7 of a byte. Normally, bit 7 of a byte is > the Most Significant bit (MSb). > > But somewhere you MUST mention that bit 7 is, contrary to all > intuition, the LSb, NOT, as many of us would assume, the MSb. > (I.e. the _bit_ ordering as per the PDU template doesn't > imply bit significance, or does it?) Uhm, that's standard practice for an IETF draft. While it may be counter-intuitive (I'd agree it is), it's standard practice with the ietf, and is used that way through the draft. Take care, Bill From owner-ips@ece.cmu.edu Thu Jun 13 17:47:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01495 for ; Thu, 13 Jun 2002 17:46:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DLMQN23058 for ips-outgoing; Thu, 13 Jun 2002 17:22:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DLMOw23053 for ; Thu, 13 Jun 2002 17:22:24 -0400 (EDT) Received: from mail pickup service by mail8.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 16:37:43 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 19:02:57 -0400 Received: from engine.ieee.org (engine.ieee.org [140.98.193.23]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5ALrYtH013346 for ; Mon, 10 Jun 2002 17:53:34 -0400 (EDT) Received: from ece.cmu.edu (gemini3.ieee.org [140.98.193.25]) by engine.ieee.org (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5ALrLB20615; Mon, 10 Jun 2002 17:53:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5ALWWP14568 for ips-outgoing; Mon, 10 Jun 2002 17:32:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5ALWTw14561 for ; Mon, 10 Jun 2002 17:32:30 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 17:32:29 -0400 Message-ID: From: Eddy Quicksall To: Julian Satran Cc: ips@ece.cmu.edu, pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength Date: Mon, 10 Jun 2002 17:32:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C210C6.52695900" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C210C6.52695900 Content-Type: text/plain; charset="iso-8859-1" Julian, Another problem here is that the target has to calculate the offset from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 means starting DataSN=4, send all the data for that sequence. I think it would be a performance hit and waist of memory to keep a tally of all PDU sizes just for an occasional SNACK. It's not that it can't be done ... it is more that it is messy and I think there is a solution that will satisfy the design requirements but keep the software simpler. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, June 08, 2002 10:16 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength That is not completely accurate. The only problem is when PDU size decreases and then SNACK must be for all data. Target can also keep a mapping of numbers/to offsets (the list should be small and if it gets long ask for ack (A-bit). Julo Eddy Quicksall Sent by: owner-ips@ece.cmu.edu 06/08/2002 10:54 PM Please respond to Eddy Quicksall To: pat_thaler@agilent.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Thanks, As a target, I won't be able to let it change until all of the outstanding commands are finished (running with ErrorRecoveryLevel>=1). This is because I must use the PDU size to compute the offset from a SNACK's BegRun/RunLength. So, I plan to not give the text response for a MaxPDURecvDataLength in FFP until I get back an ExpStatSN == next StatSN. This will cause a delay of unknown time before the PDU size can actually change ... do you see any problem with this? Eddy -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Friday, June 07, 2002 1:13 PM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Eddy, If one uses a message sync and steering that relys on the transport segments carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path MTU changes one would want to change the PDU data length to fit the new path MTU. Pat -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Wednesday, June 05, 2002 12:24 PM To: ips@ece.cmu.edu Subject: iSCSI: changing MaxPDUDataLength Does anybody know a case where it is necessary to support a new PDU data length during full feature phase? Eddy mailto: Eddy_Quicksall@iVivity.com ------_=_NextPart_001_01C210C6.52695900 Content-Type: text/html; charset="iso-8859-1"
Julian,
 
Another problem here is that the target has to calculate the offset from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 means starting DataSN=4, send all the data for that sequence.
 
I think it would be a performance hit and waist of memory to keep a tally of all PDU sizes just for an occasional SNACK.
 
It's not that it can't be done ... it is more that it is messy and I think there is a solution that will satisfy the design requirements but keep the software simpler.
 
Eddy
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, June 08, 2002 10:16 PM
To: Eddy Quicksall
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com
Subject: RE: iSCSI: changing MaxPDUDataLength


That is not completely accurate.
The only problem is when PDU size decreases and then SNACK must be for all data.
Target can also keep a mapping of numbers/to offsets (the list should be small and if it gets long ask for ack (A-bit).

Julo


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

06/08/2002 10:54 PM
Please respond to Eddy Quicksall

       
        To:        pat_thaler@agilent.com
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: changing MaxPDUDataLength

       


Thanks,

As a target, I won't be able to let it change until all of the outstanding
commands are finished (running with ErrorRecoveryLevel>=1). This is because
I must use the PDU size to compute the offset from a SNACK's
BegRun/RunLength.

So, I plan to not give the text response for a MaxPDURecvDataLength in FFP
until I get back an ExpStatSN == next StatSN.

This will cause a delay of unknown time before the PDU size can actually
change ... do you see any problem with this?

Eddy

-----Original Message-----
From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]
Sent: Friday, June 07, 2002 1:13 PM
To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu
Subject: RE: iSCSI: changing MaxPDUDataLength


Eddy,

If one uses a message sync and steering that relys on the transport segments
carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path
MTU changes one would want to change the PDU data length to fit the new path
MTU.

Pat

-----Original Message-----
From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com]
Sent: Wednesday, June 05, 2002 12:24 PM
To: ips@ece.cmu.edu
Subject: iSCSI: changing MaxPDUDataLength


Does anybody know a case where it is necessary to support a new PDU data
length during full feature phase?

Eddy
mailto: Eddy_Quicksall@iVivity.com



------_=_NextPart_001_01C210C6.52695900-- From owner-ips@ece.cmu.edu Thu Jun 13 17:47:39 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01559 for ; Thu, 13 Jun 2002 17:47:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DLcCk23943 for ips-outgoing; Thu, 13 Jun 2002 17:38:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DLcAw23938; Thu, 13 Jun 2002 17:38:10 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 91BE030706; Thu, 13 Jun 2002 17:38:09 -0400 (EDT) Date: Thu, 13 Jun 2002 14:35:58 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Julian Satran Cc: , , Subject: Re: iSCSI: 12-97 Bit Rule In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 13 Jun 2002, Julian Satran wrote: One minor question. > I took out completely the bit rule. > I reformulated the CRC text as: > > The CRC MUST be calculated by a method that produces the same results as > the following process: > > - The PDU bits are considered as the coefficients of a polyno-mial M(x) of > degree n-1; bit 7 of the lowest numbered byte is considered the most > significant bit (x^n-1), followed by bit 6 of the lowest numbered byte and > through bit 0 of the high-est numbered byte (x^0). > > - The most significant 32 bits are complemented. > > - The polynomial is multiplied by x^32 then divided by G(x). The generator > polynomial produces a remainder R(x) of degree <= 31. > > - The coefficients of R(x) are considered a 32 bit sequence. > > - The bit sequence is complemented and the result is the CRC. Call the above step 5. > - the CRC bits are mapped into the digest word - the x^31 coef-ficient in > bit 7 of the lowest numbered byte of the digest continuing to through the > byte up to the x^24 coefficient in bit 0 of the lowest numbered byte, > continuing with the x^23 coefficient in bit 7 of next byte through x^0 in > bit 0 of the highest numbered byte. > > - Computing the CRC over any segment (data or header) extended to include > the CRC built using the generator 0x11edc6f41 will get always the value > 0x1c2d19ed as its final CRC. This value is given here in its polynomial > form - i.e. not mapped as the digest word About the use of "final CRC" with respect to 0x1c2d19ed. Step 5 says the "CRC" is after the complementation, but my experiments indicate that 0x1c2d19ed is the uncomplimented result, and that the complimented result would be 0xe3d2e612. Thus 0xe3d2e612 would be the "CRC." > I hope you will find it less confusing I'm not sure what to do. The thoughts which come to my mind take up space. The simplest would be to mention what coefficents one uses in well-known crc packages. A more complex one would be to include source code, as the sctp crc draft did. Take care, Bill From owner-ips@ece.cmu.edu Thu Jun 13 18:00:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01901 for ; Thu, 13 Jun 2002 18:00:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DLeul24127 for ips-outgoing; Thu, 13 Jun 2002 17:40:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DLesw24123 for ; Thu, 13 Jun 2002 17:40:55 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g5DLgMu32077; Thu, 13 Jun 2002 17:42:22 -0400 Message-ID: <3D091160.F7C46A36@splentec.com> Date: Thu, 13 Jun 2002 17:40:48 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Bill Studenmund CC: iSCSI Subject: Re: iSCSI: 12-97 Bit Rule References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bill Studenmund wrote: > > On Thu, 13 Jun 2002, Luben Tuikov wrote: > > > Julian Satran wrote: > > > - The PDU bits are considered as the coefficients of a polyno-mial M(x) of degree n-1; bit 7 of > > > the lowest numbered byte is considered the most significant bit (x^n-1), followed by bit 6 of the > > > lowest numbered byte and through bit 0 of the high-est numbered byte (x^0). > > > > This description, taken by itself, as you quote it here, > > mentions bit 7 of a byte. Normally, bit 7 of a byte is > > the Most Significant bit (MSb). > > > > But somewhere you MUST mention that bit 7 is, contrary to all > > intuition, the LSb, NOT, as many of us would assume, the MSb. > > (I.e. the _bit_ ordering as per the PDU template doesn't > > imply bit significance, or does it?) > > Uhm, that's standard practice for an IETF draft. While it may be > counter-intuitive (I'd agree it is), it's standard practice with the ietf, > and is used that way through the draft. Other than _repeating_ what Julian has said, do you have a point? Anyway, if you had paid attention you'd have noticed that the algorithm I sent DOESN'T DEPEND on the bit numbering (7:0 or 0:7) of the draft. _This_ was the more important subject (and my point)... -- Luben From owner-ips@ece.cmu.edu Thu Jun 13 18:11:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02095 for ; Thu, 13 Jun 2002 18:11:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DLmkQ24547 for ips-outgoing; Thu, 13 Jun 2002 17:48:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DLmiw24542 for ; Thu, 13 Jun 2002 17:48:44 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 2696730706; Thu, 13 Jun 2002 17:48:44 -0400 (EDT) Date: Thu, 13 Jun 2002 14:46:32 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Luben Tuikov Cc: iSCSI Subject: Re: iSCSI: 12-97 Bit Rule In-Reply-To: <3D091160.F7C46A36@splentec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 13 Jun 2002, Luben Tuikov wrote: > Bill Studenmund wrote: > > > > On Thu, 13 Jun 2002, Luben Tuikov wrote: > > > > > (I.e. the _bit_ ordering as per the PDU template doesn't > > > imply bit significance, or does it?) > > > > Uhm, that's standard practice for an IETF draft. While it may be > > counter-intuitive (I'd agree it is), it's standard practice with the ietf, > > and is used that way through the draft. > > Other than _repeating_ what Julian has said, do you have a point? Yes, actually, I do. 1) An independent reader of the document agreed with the author as to the meaning of the bit ordering. This fact is important as authors (as I have found with most of the technical documents I have written) have an intimate association with the document, and as such may not see things as an independent reader would. 2) I wasn't repeating Julian, I was expressing my opinion. The fact we agree indicates that we agree. :-) > Anyway, if you had paid attention you'd have noticed > that the algorithm I sent DOESN'T DEPEND on the > bit numbering (7:0 or 0:7) of the draft. _This_ > was the more important subject (and my point)... Then why distract everyone by talking about bit sequence? Take care, Bill From owner-ips@ece.cmu.edu Thu Jun 13 18:32:11 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02657 for ; Thu, 13 Jun 2002 18:32:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DLxbA25238 for ips-outgoing; Thu, 13 Jun 2002 17:59:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DLxaw25234 for ; Thu, 13 Jun 2002 17:59:36 -0400 (EDT) Received: from mail pickup service by mail8.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 16:55:33 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 20:50:30 -0400 Received: from engine.ieee.org (engine.ieee.org [140.98.193.23]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5B0oUtH002387 for ; Mon, 10 Jun 2002 20:50:31 -0400 (EDT) Received: from ece.cmu.edu (gemini3.ieee.org [140.98.193.25]) by engine.ieee.org (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5B0oLB09890; Mon, 10 Jun 2002 20:50:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5B0SV622546 for ips-outgoing; Mon, 10 Jun 2002 20:28:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g5B0STw22542 for ; Mon, 10 Jun 2002 20:28:29 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g5B0SNp26963 for ; Mon, 10 Jun 2002 20:28:23 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g5B0SMc26945; Mon, 10 Jun 2002 20:28:22 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g5B0SKb15785; Mon, 10 Jun 2002 20:28:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15621.17446.323000.879391@gargle.gargle.HOWL> Date: Mon, 10 Jun 2002 20:28:22 -0400 From: Paul Koning To: wrstuden@wasabisystems.com Cc: pat_thaler@agilent.com, ksandars@eurologic.com, bmastors@allocity.com, ips@ece.cmu.edu Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys References: <1BEBA5E8600DD4119A50009027AF54A00C5E3E67@axcs04.cos.agilent.com> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 10 June 2002) by Bill Studenmund: >... 2) (and this is the bigger question) What do we do about bugs we find > *after* we get to RFC stage? > > Yes, we fix them in the next version. But how quickly are we going to get > that version out? > > Are we going to crank RFCs out as fast as Julian can make I-D drafts now? > I doubt it. If we were, then I think saying, "Update to the next version," > is a reasonable approach. > > I expect iSCSI 2 (or 1.1) will be on the order of a year or more out from > iSCSI. What does everyone else think? If the spec is as good as it should be, that's a fine time frame. But if significant interop issues are found soon after RFC, then 1.1 will have to happen a whole lot sooner. paul From owner-ips@ece.cmu.edu Thu Jun 13 18:35:51 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02765 for ; Thu, 13 Jun 2002 18:35:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DM0Sc25296 for ips-outgoing; Thu, 13 Jun 2002 18:00:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DM0Qw25292 for ; Thu, 13 Jun 2002 18:00:26 -0400 (EDT) Received: from mail pickup service by mail8.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 16:55:53 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 13:29:46 -0400 Received: from ruebert.ieee.org (ruebert.ieee.org [140.98.193.10]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AHTktH013512 for ; Mon, 10 Jun 2002 13:29:46 -0400 (EDT) Received: from ece.cmu.edu (gemini3.ieee.org [140.98.193.25]) by ruebert.ieee.org (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5AHQ0q25195; Mon, 10 Jun 2002 13:26:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AH6Zw28594 for ips-outgoing; Mon, 10 Jun 2002 13:06:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mercury.corp.iready.com ([65.115.68.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AH6Xw28590 for ; Mon, 10 Jun 2002 13:06:33 -0400 (EDT) Received: by mercury.corp.iready.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 10:06:22 -0700 Message-ID: <034670D62D19D31180990090277A37B702437BC0@mercury.corp.iready.com> From: Michael Smith To: Michael Smith , ips@ece.cmu.edu Subject: iSCSI: AHS use Date: Mon, 10 Jun 2002 10:06:16 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C210A1.220E3250" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C210A1.220E3250 Content-Type: text/plain; charset="iso-8859-1" I have some questions on the current AHS descriptions in 12-97. I just tripped over this, so I think maybe others might too. 1. In 12-97, p.130 we have the definition of AHS as Multiple Additional Header Segments (plural); switching between "AHS (singular), AHS (plural), AHS header segments made me look closer: [quote] The BHS is a fixed-length 48-byte header segment. It MAY be followed by Additional Header Segments (AHS), a Header-Digest, a Data Segment, and/or a Data-Digest. [end quote] 2. However, in the PDU format diagram on p. 131 of 12-97 it is not clear that we have the option of zero, one or more Additional Header Segments. After I re-read things a few times, and apologies if I have this wrong, I think that the use of multiple Additional Header Segments is along these lines: (a) Use one and only one Additional Header Segment for an extended CDB (SPC calls this a variable-length CDB). This extended CDB (or variable-length CDB) Additional Header Segment must immediately follow the BHS. (A suggested exact use definition of this type of Additional Header Segment coming up.) (b) Use one and only one Additional Header Segment for an Bidirectional Expected Read-Data Length. This Bidirectional Expected Read-Data Length Additional Header Segment must immediately follow the BHS. (c) Use of more than one Additional Header Segment is left up to the user. How many Additional Header Segments were we expecting to be able to be used? Would this maximum length of Additional Header Segments be limited only by the TotalAHSLength (8-bit field measuring length in four-byte words or ((2**8) - 1) * 4 bytes or roughly 1 kbyte)? Can we follow an extended CDB Additional Header Segment or a Bidirectional Expected Read-Data Length Additional Header Segment by one or more user-defined Additional Header Segment? Did I get this anywhere close to correct? 3. In one of Bob Russell's emails we have the following, which does seem to make the use of multiple Additional Header Segments a little clearer to me: [quote http://www.pdl.cmu.edu/mailinglists/ips/mail/msg03784.html] [view in fixed-width font on wide window] +------------------------+ | required BHS | > fixed length of 48 bytes +------------------------+ | optional AHS 1 |\ | - - - - - - - - - - - | \ | optional AHS 2 | \ | - - - - - - - - - - - | > total length in AHS_length field in BHS | . . . . | / | - - - - - - - - - - - | / | optional AHS n |/ +------------------------+ | optional header digest | -- covers preceding (48 + AHS_length) bytes +------------------------+ | |\ | optional data | > total length in DATA_length field in BHS | |/ +------------------------+ | optional data digest | -- covers preceding (DATA_length) bytes +------------------------+ [end view in fixed-width font on wide window] [end quote http://www.pdl.cmu.edu/mailinglists/ips/mail/msg03784.html] Is it possible to add something like this picture to the format diagram on p.131. I wouldn't ask if I hadn't tripped myself up on this already. 4. On p. 139 of 12-97 we have the following: [quote] 9.3.5 CDB - SCSI Command Descriptor Block There are 16 bytes in the CDB field to accommodate the commonly used CDBs. Whenever the CDB is larger than 16 bytes, an Extended CDB AHS MUST be used to contain the CDB spillover. [end quote] I tripped again on the term "spillover". Could we perhaps change 9.3.5 to the following (thanks to Rob Elliott, see http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10620.html): There are 16 bytes in the CDB field to accommodate bytes 0-15 of the commonly used CDBs. An Extended CDB AHS MUST be used to contain bytes 16-259 of a variable-length CDB [SPC]. 5. There is no description of ExtendedCDB...+ in 9.2.2.3 Extended CDB AHS I guess we would be repeating 9.3.5 if we defined ExtendedCDB as "bytes 16-259 of a variable-length CDB", but perhaps that is not a bad thing? Aloha Mike Smith CTO, iReady ------_=_NextPart_001_01C210A1.220E3250 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable iSCSI: AHS use

I have some questions on the current AHS descriptions = in 12-97. I just tripped over this, so I think maybe others might = too.

 
1. In 12-97, p.130 we have the definition of AHS as = Multiple Additional Header Segments (plural); switching between = "AHS (singular), AHS (plural), AHS header segments made me look = closer:

 
[quote]
The BHS is a fixed-length 48-byte header segment. It = MAY be followed by Additional Header Segments (AHS), a Header-Digest, a = Data Segment, and/or a Data-Digest.

[end quote]

2. However, in the PDU format diagram on p. 131 of = 12-97 it is not clear that we have the option of zero, one or more = Additional Header Segments. After I re-read things a few times, and = apologies if I have this wrong, I think that the use of multiple = Additional Header Segments is along these lines:

(a) Use one and only one Additional Header Segment = for an extended CDB (SPC calls this a variable-length CDB). This = extended CDB (or variable-length CDB) Additional Header Segment must = immediately follow the BHS. (A suggested exact use definition of this = type of Additional Header Segment coming up.)

(b) Use one and only one Additional Header Segment = for an Bidirectional Expected Read-Data Length. This Bidirectional = Expected Read-Data Length Additional Header Segment must immediately = follow the BHS.

(c) Use of more than one Additional Header Segment is = left up to the user.

How many Additional Header Segments were we expecting = to be able to be used? Would this maximum length of Additional Header = Segments be limited only by the TotalAHSLength (8-bit field measuring = length in four-byte words or ((2**8) - 1) * 4 bytes or roughly 1 = kbyte)? Can we follow an extended CDB Additional Header Segment or a = Bidirectional Expected Read-Data Length Additional Header Segment by = one or more user-defined Additional Header Segment?

Did I get this anywhere close to correct?

3. In one of Bob Russell's emails we have the = following, which does seem to make the use of multiple Additional = Header Segments a little clearer to me:

 
[quote http://www.pdl.cmu.edu/mailinglists/ips/mail/msg03784.= html]
 
[view in fixed-width font on wide window]
     = +------------------------+
     |     = required BHS       | > fixed length of = 48 bytes
     = +------------------------+
     |     = optional AHS 1     |\
     | - - - - - - - - - - = -  | \
     |     = optional AHS 2     |  \
     | - - - - - - - - - - = -  |   > total length in AHS_length field in = BHS
     = |        . . . = .         |  /
     | - - - - - - - - - - = -  | /
     |     = optional AHS n     |/
     = +------------------------+
     | optional header digest | = -- covers preceding (48 + AHS_length) bytes
     = +------------------------+
     = |            = ;            = |\
     |     = optional data      | > total length in = DATA_length field in BHS
     = |            = ;            = |/
     = +------------------------+
     |  optional data = digest  | -- covers preceding (DATA_length) bytes
     = +------------------------+

[end view in fixed-width font on wide window]
 
[end quote http://www.pdl.cmu.edu/mailinglists/ips/mail/msg03784.= html]

Is it possible to add something like this picture to = the format diagram on p.131. I wouldn't ask if I hadn't tripped myself = up on this already.

 
4. On p. 139 of 12-97 we have the following:
 
[quote]
 
9.3.5 CDB - SCSI Command Descriptor Block
There are 16 bytes in the CDB field to accommodate = the commonly used CDBs. Whenever the CDB is larger than 16 bytes, an = Extended CDB AHS MUST be used to contain the CDB spillover.

 
[end quote]

I tripped again on the term "spillover". = Could we perhaps change 9.3.5 to the following (thanks to Rob Elliott, = see = http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10620.html):

There are 16 bytes in the CDB field to accommodate = bytes 0-15 of the commonly used CDBs. An Extended CDB AHS MUST be used = to contain bytes 16-259 of a variable-length CDB [SPC].

5. There is no description of ExtendedCDB...+ in = 9.2.2.3 Extended CDB AHS

I guess we would be repeating 9.3.5 if we defined = ExtendedCDB as "bytes 16-259 of a variable-length CDB", but = perhaps that is not a bad thing?

Aloha
 
Mike Smith
CTO, iReady

------_=_NextPart_001_01C210A1.220E3250-- From owner-ips@ece.cmu.edu Thu Jun 13 18:48:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03052 for ; Thu, 13 Jun 2002 18:48:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DMWwZ27158 for ips-outgoing; Thu, 13 Jun 2002 18:32:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DMWuw27152; Thu, 13 Jun 2002 18:32:56 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g5DMYPu32366; Thu, 13 Jun 2002 18:34:25 -0400 Message-ID: <3D091D93.E9621217@splentec.com> Date: Thu, 13 Jun 2002 18:32:51 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Dave Nagle CC: ips@ece.cmu.edu Subject: Re: multiple e-mail messages References: <200206132116.RAA04987@opus.pdl.cmu.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Dave Nagle wrote: > > Everyone, > > I've asked the computer facilities people to check into the > multiple e-mail message problem. Hoping they can fix it > w/in a few hours. > > dave............ While you're at it, fix also the problem of dropped and never delivered messages (to individuals, not IPS). I've gotten (or NOT-gotten) quite a few of those. -- Luben From owner-ips@ece.cmu.edu Thu Jun 13 18:53:17 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03156 for ; Thu, 13 Jun 2002 18:53:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DMUmR26968 for ips-outgoing; Thu, 13 Jun 2002 18:30:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DMUkw26964 for ; Thu, 13 Jun 2002 18:30:46 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g5DMWDu32354; Thu, 13 Jun 2002 18:32:13 -0400 Message-ID: <3D091D0F.F66E4697@splentec.com> Date: Thu, 13 Jun 2002 18:30:39 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Bill Studenmund CC: iSCSI Subject: Re: iSCSI: 12-97 Bit Rule References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bill Studenmund wrote: > > > Yes, actually, I do. 1) An independent reader of the document agreed with > the author as to the meaning of the bit ordering. This fact is important > as authors (as I have found with most of the technical documents I have > written) have an intimate association with the document, and as such may > not see things as an independent reader would. 2) I wasn't repeating > Julian, I was expressing my opinion. The fact we agree indicates that > we agree. :-) So, this is all contrary to the fact that you mentioned that it is indeed confusing in a previous letter on this thread. As I said: we'll just wait to see for the comments from the industruy and the implementers. Especially the Linux community, which has defied all ``consensus'', ``ideology'', and what-not, and has chosen for the ``makes sense'' attitude. (Badly quoted from Linus.) > > Anyway, if you had paid attention you'd have noticed > > that the algorithm I sent DOESN'T DEPEND on the > > bit numbering (7:0 or 0:7) of the draft. _This_ > > was the more important subject (and my point)... > > Then why distract everyone by talking about bit sequence? So that it doesn't matter if YOU count bits 0 to 7 or 7 to 0 in a byte. So that anyone can implement it anyway. -- Luben From owner-ips@ece.cmu.edu Thu Jun 13 19:12:11 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03475 for ; Thu, 13 Jun 2002 19:12:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DMvuW28310 for ips-outgoing; Thu, 13 Jun 2002 18:57:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DMvsw28302 for ; Thu, 13 Jun 2002 18:57:54 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g5DMxJu32478; Thu, 13 Jun 2002 18:59:19 -0400 Message-ID: <3D09236A.67EBBFB3@splentec.com> Date: Thu, 13 Jun 2002 18:57:46 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: pat_thaler@agilent.com CC: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: Re: iSCSI: 12-97 Bit Rule References: <1BEBA5E8600DD4119A50009027AF54A00C5E46C5@axcs04.cos.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit pat_thaler@agilent.com wrote: > > The meaning of bit numbers 0 through 7 is clear and explicit in this > document. Both the information in 1.3 and the diagrams Chapter 9 make it > clear that iSCSI normally uses bit 0 as the most significant bit of a byte. > This is also the general IETF convention. Uuuuh, I know all this Pat, why do you waste bandwidth? BTW, this is NOT what you were saying in your other emails. > I know that some of us find the alternate numbering more logical, but we are > bound by IETF conventions. We, in general are bound by many things, e.g. gravity. This is why I tried to put forward an explanation of the computation steps which are not bound by the conventions used, but set forth their own ordering, and numbering, so as much as you can take it out of context and it would still work! > The draft is now consistant and unambiguous. Are you sure Pat? This is a big matso ball out there to make a statement like this and tomorrow post a message saying that something somewhere is ``unclear''. Pat, you should stick with your story, and not change it on a daily basis, like yesterday saying that ``bit rule is this and that'', and ``the CRC is this and that'', and today saying that ``everything is fine''. Less politics, more constructive algorithms. (you can quote me on this) -- Luben From owner-ips@ece.cmu.edu Thu Jun 13 19:13:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03508 for ; Thu, 13 Jun 2002 19:13:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DMwK428334 for ips-outgoing; Thu, 13 Jun 2002 18:58:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DMwIw28330 for ; Thu, 13 Jun 2002 18:58:18 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 9D017B8F1; Thu, 13 Jun 2002 16:58:17 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 7057414E; Thu, 13 Jun 2002 16:58:17 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 13 Jun 2002 16:58:16 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Jun 2002 16:58:16 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E46CE@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: luben@splentec.com, Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: 12-97 Bit Rule Date: Thu, 13 Jun 2002 16:58:15 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Luben, TCP/IP Illustrated numbers bits with bit 0 as the most significant. My books on Sonet number bits in a byte from 1 to 8. I guess you could argue these are not books on computer architecture, but the point is that not everyone numbers bits the same. If you will read 1.3.1 through 1.3.3, they do explicitly state the significance of bits in iSCSI words, half-words and bytes. Julian's new description is accurate and clear. Item 8 in your description is unclear and confusing because the bits do not "follow" each other in the order you state (and any viewing of bits in a message as a serial stream is entirely hypothetical). Regards, Pat -----Original Message----- From: Luben Tuikov [mailto:luben@splentec.com] Sent: Thursday, June 13, 2002 12:20 PM To: Julian Satran Cc: iSCSI Subject: Re: iSCSI: 12-97 Bit Rule Julian Satran wrote: > > Luben, > > The draft has figure that are an integral part of it. > In every one of those bit 7 is the least significant. > I don't know what your NORMALLY means. Julian, any book you open on computer architecture, assumes that bit 7 is more significant than bit 6, simply because 2^7 > 2^6. Stipulating that bit 7 is less significant than bit 6, needs explicitly to be said so, NOT inferred from ``figures in the text''. Nevertheless, as you may have already noticed, the algorithm which I sent you, is _independent_ of iSCSI's implication that bit 7 is less significant than bit 6. So, anywhich way you order the bits in the bytes for the rest of the draft, the algoritm would produce the same results, simply because it explicitly mentions ordering in step 1 (and 2). -- Luben From owner-ips@ece.cmu.edu Thu Jun 13 19:14:08 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03539 for ; Thu, 13 Jun 2002 19:14:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DMimS27770 for ips-outgoing; Thu, 13 Jun 2002 18:44:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DMilw27766 for ; Thu, 13 Jun 2002 18:44:47 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 7C5DEBA03; Thu, 13 Jun 2002 16:44:46 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1.cos.agilent.com (Postfix) with SMTP id C180A290; Thu, 13 Jun 2002 16:44:45 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 13 Jun 2002 16:44:44 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Jun 2002 16:44:44 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E46C5@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: luben@splentec.com, Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: 12-97 Bit Rule Date: Thu, 13 Jun 2002 16:44:43 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Luben, The meaning of bit numbers 0 through 7 is clear and explicit in this document. Both the information in 1.3 and the diagrams Chapter 9 make it clear that iSCSI normally uses bit 0 as the most significant bit of a byte. This is also the general IETF convention. I know that some of us find the alternate numbering more logical, but we are bound by IETF conventions. The draft is now consistant and unambiguous. Pat -----Original Message----- From: Luben Tuikov [mailto:luben@splentec.com] Sent: Thursday, June 13, 2002 11:15 AM To: Julian Satran Cc: iSCSI Subject: Re: iSCSI: 12-97 Bit Rule Julian Satran wrote: > > I took out completely the bit rule. > I reformulated the CRC text as: > > The CRC MUST be calculated by a method that produces the same results as the following process: > > - The PDU bits are considered as the coefficients of a polyno-mial M(x) of degree n-1; bit 7 of > the lowest numbered byte is considered the most significant bit (x^n-1), followed by bit 6 of the > lowest numbered byte and through bit 0 of the high-est numbered byte (x^0). This description, taken by itself, as you quote it here, mentions bit 7 of a byte. Normally, bit 7 of a byte is the Most Significant bit (MSb). But somewhere you MUST mention that bit 7 is, contrary to all intuition, the LSb, NOT, as many of us would assume, the MSb. (I.e. the _bit_ ordering as per the PDU template doesn't imply bit significance, or does it?) I.e. you need to mention that the bytes are mirrored. Here it is, again: 1) The bytes of the message form a bit stream, ordered Most Significant Byte (MSB), Most Significant bit (MSb) in memory, i.e. Big endian on bytes, Big endian on bits. Call this bit stream P. 2) The bytes of P are mirrored, thus forming byte 0, LSb first to MSb, then byte 1, LSb first to MSb, etc, (Big endian on Bytes, Little endian on bits), this forms the bit sequence A = {a_0, a_1, ..., a_(n-1)}. 3) The first 32 bits of A are complemented (a_0 to a_31). 4) The bits of A are considered coefficients of M(x), where M(x) = a_0 x^(n-1) + ... + a_(n-1) x^0. 5) The polynomial M(x) is multiplied by x^32, then divided by G(x), where G(x) is the polynomial representation of 0x11edc6f41. This produces a remainder R(x) of degree <= 31. 6) The coefficients of R(x) are considered a 32 bit sequence, R(x) = r_31 x^31 + ... + r_0 x^0. 7) R(x) is complemented and mirrored, the result is CRC(x). 8) The message sent is P and appended at the end are the bit coefficients of CRC(x), with x^31 bit coefficient first, then x^30, etc. 9) A receiver of a "good" message sent as per step (8), will get the value 0x1c2d19ed as R(x) (steps (1) to (6)). Note that CRC(x) is a polynomial and independent of the machine's representation. For clarity, I've omitted the fact that x^0 = 1. So, steps 1 to 6 form ``R(x) = compute_crc(P)'', and steps 7 to 8 form ``Send_This = inject_crc(P, R(x))''. I.e. ``Magic_Value = compute_crc(inject_crc(P, compute_crc(P)))'' Thus, one sends ``inject_crc(P, compute_crc(P))'', and the receiver does ``Magic_Value =?= compute_crc(message_received)'', which is step 9. -- Luben From owner-ips@ece.cmu.edu Thu Jun 13 19:14:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03565 for ; Thu, 13 Jun 2002 19:14:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DMast27351 for ips-outgoing; Thu, 13 Jun 2002 18:36:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DMaqw27345; Thu, 13 Jun 2002 18:36:52 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id BF6719F78; Thu, 13 Jun 2002 16:36:47 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id A12DF2AC; Thu, 13 Jun 2002 16:36:47 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 13 Jun 2002 16:36:47 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Jun 2002 16:36:47 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E46C0@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI: 12-97 Bit Rule Date: Thu, 13 Jun 2002 16:36:45 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-5220fd22-b42c-4f69-a687-01880250f6a7" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-5220fd22-b42c-4f69-a687-01880250f6a7 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2132A.CC30CE60" ------_=_NextPart_001_01C2132A.CC30CE60 Content-Type: text/plain; charset="iso-8859-1" Thank you Julian, I am very happy with this text. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, June 13, 2002 7:20 AM To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: 12-97 Bit Rule Importance: High I took out completely the bit rule. I reformulated the CRC text as: The CRC MUST be calculated by a method that produces the same results as the following process: - The PDU bits are considered as the coefficients of a polyno-mial M(x) of degree n-1; bit 7 of the lowest numbered byte is considered the most significant bit (x^n-1), followed by bit 6 of the lowest numbered byte and through bit 0 of the high-est numbered byte (x^0). - The most significant 32 bits are complemented. - The polynomial is multiplied by x^32 then divided by G(x). The generator polynomial produces a remainder R(x) of degree <= 31. - The coefficients of R(x) are considered a 32 bit sequence. - The bit sequence is complemented and the result is the CRC. - the CRC bits are mapped into the digest word - the x^31 coef-ficient in bit 7 of the lowest numbered byte of the digest continuing to through the byte up to the x^24 coefficient in bit 0 of the lowest numbered byte, continuing with the x^23 coefficient in bit 7 of next byte through x^0 in bit 0 of the highest numbered byte. - Computing the CRC over any segment (data or header) extended to include the CRC built using the generator 0x11edc6f41 will get always the value 0x1c2d19ed as its final CRC. This value is given here in its polynomial form - i.e. not mapped as the digest word I hope you will find it less confusing Julo pat_thaler@agilent.com 06/12/2002 08:41 PM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: iSCSI: 12-97 Bit Rule Julian, The bit rule added to 12-97 (1.3.4 page 31) is inconsistant with the clauses above it: Word Rule, Half-Word Rule and Byte Rule. It says "when the sequence of bits has a positional significance (e.g., a modulo 2 polynomial) then bit 7 of the lowest numbered byte is considered the most significant bit (2**n), followed by ...." When bits represent a number, they have positional significance so that sentence applies. However, the other rules apply the opposite significance to the bits within each byte. Also, note that bits represent polynomials at other times than the CRC such as for the purpose of authentication or encryption algorithms and those algorithms do not necessarily use the bit significance of the Bit Rule. The bit rule only applies to bit significance for CRC calculation. Bit Rule should be CRC Bit Rule and the associated text should make it clear that it only applies to the CRC calculation. Since it only applies there, it would be kinder to the reader to put the text in 11.1 rather than making the reader of 11.1 look nearly 200 pages back in the spec. Regards, Pat ------_=_NextPart_001_01C2132A.CC30CE60 Content-Type: text/html; charset="iso-8859-1"
Thank you Julian, I am very happy with this text.
 
Regards,
Pat
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, June 13, 2002 7:20 AM
To: pat_thaler@agilent.com
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iSCSI: 12-97 Bit Rule
Importance: High


I took out completely the bit rule.
I reformulated the CRC text as:

The CRC MUST be calculated by a method that produces the same results as the following process:

 - The PDU bits are considered as the coefficients of a polyno-mial M(x) of degree n-1; bit 7 of the lowest numbered byte is considered the most significant bit (x^n-1), followed by bit 6 of the lowest numbered byte and through bit 0 of the high-est numbered byte (x^0).

- The most significant 32 bits are complemented.

- The polynomial is multiplied by x^32 then divided by G(x). The generator polynomial produces a remainder R(x) of degree <= 31.

- The coefficients of R(x) are considered a 32 bit sequence.

- The bit sequence is complemented and the result is the CRC.

- the CRC bits are mapped into the digest word - the x^31 coef-ficient in bit 7 of the lowest numbered byte of the digest continuing to through the byte up to the x^24 coefficient in bit 0 of the lowest numbered byte, continuing with the x^23 coefficient in bit 7 of next byte through x^0 in bit 0 of the highest numbered byte.

- Computing the CRC over any segment (data or header) extended to include the CRC built using the generator 0x11edc6f41 will get always the value 0x1c2d19ed as its final CRC. This value is given here in its polynomial form - i.e. not mapped as the digest word

I hope you will find it less confusing

Julo



pat_thaler@agilent.com

06/12/2002 08:41 PM
Please respond to pat_thaler

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
        Subject:        iSCSI: 12-97 Bit Rule

       


Julian,
 
The bit rule added to 12-97 (1.3.4 page 31) is inconsistant with the clauses above it: Word Rule,  Half-Word Rule and Byte Rule.
 
It says "when the sequence of bits has a positional significance (e.g., a modulo 2 polynomial) then bit 7 of the lowest numbered byte is considered the most significant bit (2**n), followed by ...."
 
When bits represent a number, they have positional significance so that sentence applies. However, the other rules apply the opposite significance to the bits within each byte.
 
Also, note that bits represent polynomials at other times than the CRC such as for the purpose of authentication or encryption algorithms and those algorithms do not necessarily use the bit significance of the Bit Rule. The bit rule only applies to bit significance for CRC calculation.
 
Bit Rule should be CRC Bit Rule and the associated text should make it clear that it only applies to the CRC calculation. Since it only applies there, it would be kinder to the reader to put the text in 11.1 rather than making the reader of 11.1 look nearly 200 pages back in the spec.
 
Regards,
Pat

------_=_NextPart_001_01C2132A.CC30CE60-- ------=_NextPartTM-000-5220fd22-b42c-4f69-a687-01880250f6a7-- From owner-ips@ece.cmu.edu Thu Jun 13 19:28:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04008 for ; Thu, 13 Jun 2002 19:28:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DN6Km28727 for ips-outgoing; Thu, 13 Jun 2002 19:06:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DN6Iw28721 for ; Thu, 13 Jun 2002 19:06:18 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id D43BC30706; Thu, 13 Jun 2002 19:06:17 -0400 (EDT) Date: Thu, 13 Jun 2002 16:04:06 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Luben Tuikov Cc: iSCSI Subject: Re: iSCSI: 12-97 Bit Rule In-Reply-To: <3D091D0F.F66E4697@splentec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 13 Jun 2002, Luben Tuikov wrote: > Bill Studenmund wrote: > > > > > > Yes, actually, I do. 1) An independent reader of the document agreed with > > the author as to the meaning of the bit ordering. This fact is important > > as authors (as I have found with most of the technical documents I have > > written) have an intimate association with the document, and as such may > > not see things as an independent reader would. 2) I wasn't repeating > > Julian, I was expressing my opinion. The fact we agree indicates that > > we agree. :-) > > So, this is all contrary to the fact that you mentioned > that it is indeed confusing in a previous letter on this thread. No, it's not contrary to that statement. The IETF does something, as part of its standards, that I find counter- intuitive, and at first glance is confusing. It numbers bits in bytes in a manner I would not choose. However, the IETF uses this bit numbering scheme in ALL of its documents. It is consistent in its bit numbering. Thus if I read an IETF document, I prepare my mind for IETF bit numbering. Note that the IETF is not the only group to use this bit numbering. As I understand it the Mainframe folks use this bit numbering. Also, the documentation I have on PowerPC chips all uses this bit numbering, so it's not something the IETF made up. > As I said: we'll just wait to see for the comments > from the industruy and the implementers. Especially > the Linux community, which has defied all > ``consensus'', ``ideology'', and what-not, > and has chosen for the ``makes sense'' attitude. > (Badly quoted from Linus.) Well, two thoughts come to mind: 1) For me, no explanation of how to perform this CRC calculation will make sense if it dives into the space of abstract bit streams and such. My mind works much better with code snippets. 2) I expect the Linux community will start by looking at the implementations out there. The UNH implementation has CRC32C code in it. That code, AFAICT, is correct. > > > Anyway, if you had paid attention you'd have noticed > > > that the algorithm I sent DOESN'T DEPEND on the > > > bit numbering (7:0 or 0:7) of the draft. _This_ > > > was the more important subject (and my point)... > > > > Then why distract everyone by talking about bit sequence? > > So that it doesn't matter if YOU count bits 0 to 7 or 7 to 0 > in a byte. So that anyone can implement it anyway. I'm sorry, that came out wrong. If your main point was that your proposed text is independent of bit numbering, then the way you were discussing Julian's use of the bit numbering which is consistent with the rest of the document didn't help. At least not for me. Take care, Bill From owner-ips@ece.cmu.edu Thu Jun 13 19:31:27 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04134 for ; Thu, 13 Jun 2002 19:31:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DNNqs29583 for ips-outgoing; Thu, 13 Jun 2002 19:23:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DNNnw29573 for ; Thu, 13 Jun 2002 19:23:49 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g5DNP9u32597; Thu, 13 Jun 2002 19:25:09 -0400 Message-ID: <3D092977.475273F6@splentec.com> Date: Thu, 13 Jun 2002 19:23:35 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Bill Studenmund CC: iSCSI Subject: Re: iSCSI: 12-97 Bit Rule References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bill Studenmund wrote: > > However, the IETF uses this bit numbering scheme in ALL of its documents. > It is consistent in its bit numbering. Thus if I read an IETF document, I > prepare my mind for IETF bit numbering. Wow! > Note that the IETF is not the only group to use this bit numbering. As I > understand it the Mainframe folks use this bit numbering. Also, the > documentation I have on PowerPC chips all uses this bit numbering, so it's > not something the IETF made up. Wow -- so you've just discovered that it is just a convention -- good for you. > Well, two thoughts come to mind: > > 1) For me, no explanation of how to perform this CRC calculation will make > sense if it dives into the space of abstract bit streams and such. My mind > works much better with code snippets. Aaaah, here is the key! And my mind works better when I see more abstract ideas, just because the implementation/bit order/byte order doesn't matter. > 2) I expect the Linux community will start by looking at the > implementations out there. The UNH implementation has CRC32C code in it. > That code, AFAICT, is correct. You forget that there are incrediby smart ppl there, that will most likely NOT look, since they've done it before, long ago, in a galaxy far, far away... but I digress. > I'm sorry, that came out wrong. If your main point was that your proposed > text is independent of bit numbering, then the way you were discussing > Julian's use of the bit numbering which is consistent with the rest of the > document didn't help. At least not for me. Well, what can I say? (red star for Bill, black dot for Luben) -- Luben From owner-ips@ece.cmu.edu Thu Jun 13 19:31:55 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04170 for ; Thu, 13 Jun 2002 19:31:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DNFbS29191 for ips-outgoing; Thu, 13 Jun 2002 19:15:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DNFZw29186 for ; Thu, 13 Jun 2002 19:15:35 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 0477B1276; Thu, 13 Jun 2002 17:15:35 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id B6D12E2; Thu, 13 Jun 2002 17:15:34 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 13 Jun 2002 17:15:33 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Jun 2002 17:15:32 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E46D3@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: luben@splentec.com, pat_thaler@agilent.com Cc: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI: 12-97 Bit Rule Date: Thu, 13 Jun 2002 17:15:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Luben, You seem intent on taking an injured and combative tone which makes it difficult to have a reasoned discussion with you. Yesterday, there was content that was inconsistent on bit numbering and the CRC process and I pointed out the problems with it. Today's changes from Julian resolved those inconsistencies to my satisfaction. The new text clearly says how to process the bits. Therefore my message today is different from my message yesterday. If the situation changes then my assessment of it can change. I did make a leap of faith in my response that reformulated text from Julian's message will be in the next draft. With those changes the new draft will be clear and consistent on the topic of bit numbering and the subject of CRC. (Obviously I didn't mean that the draft is clear and consistent on all points - just that the inconsistencies that we are dealing with in this string have been resolved. I'm sorry I was not clear enough.) Sincerely, Pat -----Original Message----- From: Luben Tuikov [mailto:luben@splentec.com] Sent: Thursday, June 13, 2002 3:58 PM To: pat_thaler@agilent.com Cc: Julian_Satran@il.ibm.com; ips@ece.cmu.edu Subject: Re: iSCSI: 12-97 Bit Rule pat_thaler@agilent.com wrote: > > The meaning of bit numbers 0 through 7 is clear and explicit in this > document. Both the information in 1.3 and the diagrams Chapter 9 make it > clear that iSCSI normally uses bit 0 as the most significant bit of a byte. > This is also the general IETF convention. Uuuuh, I know all this Pat, why do you waste bandwidth? BTW, this is NOT what you were saying in your other emails. > I know that some of us find the alternate numbering more logical, but we are > bound by IETF conventions. We, in general are bound by many things, e.g. gravity. This is why I tried to put forward an explanation of the computation steps which are not bound by the conventions used, but set forth their own ordering, and numbering, so as much as you can take it out of context and it would still work! > The draft is now consistant and unambiguous. Are you sure Pat? This is a big matso ball out there to make a statement like this and tomorrow post a message saying that something somewhere is ``unclear''. Pat, you should stick with your story, and not change it on a daily basis, like yesterday saying that ``bit rule is this and that'', and ``the CRC is this and that'', and today saying that ``everything is fine''. Less politics, more constructive algorithms. (you can quote me on this) -- Luben From owner-ips@ece.cmu.edu Thu Jun 13 19:32:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04187 for ; Thu, 13 Jun 2002 19:32:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DNDn529114 for ips-outgoing; Thu, 13 Jun 2002 19:13:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DNDfw29101 for ; Thu, 13 Jun 2002 19:13:46 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g5DNEwu32541; Thu, 13 Jun 2002 19:14:58 -0400 Message-ID: <3D092714.F546F835@splentec.com> Date: Thu, 13 Jun 2002 19:13:24 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: pat_thaler@agilent.com CC: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: Re: iSCSI: 12-97 Bit Rule References: <1BEBA5E8600DD4119A50009027AF54A00C5E46CE@axcs04.cos.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit pat_thaler@agilent.com wrote: > > TCP/IP Illustrated numbers bits with bit 0 as the > most significant. My books on Sonet number bits > in a byte from 1 to 8. I guess you could argue > these are not books on computer architecture, but > the point is that not everyone numbers bits the > same. Uuuh, here we go again... Yes, I can argue that those are NOT books on computer architecure. Let me get home I'll send you the titles/authors/ISBN of a few books on Computer Architecture which use the NATURAL bit ordering: 2^(x+1) > 2^x, x >= 0, so it only _makes_sense_ to say that bit x+1 is more significant than bit x. Take the number 791, is the 2rd digit more significant than the 1nd? Well: 791 = 7*10^2 + 9*10^1 + 1*10^0. > If you will read 1.3.1 through 1.3.3, they do > explicitly state the significance of bits in > iSCSI words, half-words and bytes. Yep, and you were complaining that it was 200 pages away from 11.1 where the CRC digest was --- or was that in a private email? Trying to score points? > Julian's new description is accurate and clear. Are you sure? Are you really sure? > Item 8 in your description is unclear and confusing > because the bits do not "follow" each other in the > order you state (and any viewing of bits in a message > as a serial stream is entirely hypothetical). Here is 8: 8) The message sent is P and appended at the end are the bit coefficients of CRC(x), with x^31 bit coefficient first, then x^30, etc. That is after you send P, send CRC(x) as indicated. What doesn't follow what? Of course it is hypothetical... Pat, let me ask you this: Is Mathematics hypothetical? -- Luben From owner-ips@ece.cmu.edu Thu Jun 13 19:44:25 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04612 for ; Thu, 13 Jun 2002 19:44:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DNJFw29352 for ips-outgoing; Thu, 13 Jun 2002 19:19:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DNJDw29347; Thu, 13 Jun 2002 19:19:13 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id A921C1073; Thu, 13 Jun 2002 17:19:12 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 7BEDA10B; Thu, 13 Jun 2002 17:19:12 -0600 (MDT) Received: from 130.29.152.143 by axcsbh1.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 13 Jun 2002 17:19:12 -0600 Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Jun 2002 17:19:12 -0600 Message-ID: <01A7DAF31F93D511AEE300D0B706ED9201BF4984@axcs13.cos.agilent.com> From: "CAVANNA,VICENTE V (A-Roseville,ex1)" To: "'Bill Studenmund'" , Julian Satran Cc: "THALER,PAT (A-Roseville,ex1)" , ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI: 12-97 Bit Rule Date: Thu, 13 Jun 2002 17:19:09 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I believe Bill is correct. The receiver, unlike the transmitter, should not complement the remainder if he expects to get 0x1c2d19ed. I am afraid I may be reponsible for this mistake during an email exchange I and others had with Julian recently. Julian and those others must have trusted me a little too much. Sorry Julian and others. Vince |-----Original Message----- |From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] |Sent: Thursday, June 13, 2002 2:36 PM |To: Julian Satran |Cc: pat_thaler@agilent.com; ips@ece.cmu.edu; owner-ips@ece.cmu.edu |Subject: Re: iSCSI: 12-97 Bit Rule | | |On Thu, 13 Jun 2002, Julian Satran wrote: | |One minor question. | |> I took out completely the bit rule. |> I reformulated the CRC text as: |> |> The CRC MUST be calculated by a method that produces the |same results as |> the following process: |> |> - The PDU bits are considered as the coefficients of a |polyno-mial M(x) of |> degree n-1; bit 7 of the lowest numbered byte is considered the most |> significant bit (x^n-1), followed by bit 6 of the lowest |numbered byte and |> through bit 0 of the high-est numbered byte (x^0). |> |> - The most significant 32 bits are complemented. |> |> - The polynomial is multiplied by x^32 then divided by G(x). |The generator |> polynomial produces a remainder R(x) of degree <= 31. |> |> - The coefficients of R(x) are considered a 32 bit sequence. |> |> - The bit sequence is complemented and the result is the CRC. | |Call the above step 5. | |> - the CRC bits are mapped into the digest word - the x^31 |coef-ficient in |> bit 7 of the lowest numbered byte of the digest continuing |to through the |> byte up to the x^24 coefficient in bit 0 of the lowest numbered byte, |> continuing with the x^23 coefficient in bit 7 of next byte |through x^0 in |> bit 0 of the highest numbered byte. |> |> - Computing the CRC over any segment (data or header) |extended to include |> the CRC built using the generator 0x11edc6f41 will get |always the value |> 0x1c2d19ed as its final CRC. This value is given here in its |polynomial |> form - i.e. not mapped as the digest word | |About the use of "final CRC" with respect to 0x1c2d19ed. Step |5 says the |"CRC" is after the complementation, but my experiments indicate that |0x1c2d19ed is the uncomplimented result, and that the |complimented result |would be 0xe3d2e612. Thus 0xe3d2e612 would be the "CRC." | |> I hope you will find it less confusing | |I'm not sure what to do. The thoughts which come to my mind |take up space. |The simplest would be to mention what coefficents one uses in |well-known |crc packages. A more complex one would be to include source |code, as the |sctp crc draft did. | |Take care, | |Bill | From owner-ips@ece.cmu.edu Thu Jun 13 19:50:29 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04807 for ; Thu, 13 Jun 2002 19:50:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DNadj00142 for ips-outgoing; Thu, 13 Jun 2002 19:36:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DNabw00138 for ; Thu, 13 Jun 2002 19:36:37 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 580A630706; Thu, 13 Jun 2002 19:36:37 -0400 (EDT) Date: Thu, 13 Jun 2002 16:34:26 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Luben Tuikov Cc: iSCSI Subject: Re: iSCSI: 12-97 Bit Rule In-Reply-To: <3D092977.475273F6@splentec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 13 Jun 2002, Luben Tuikov wrote: Luben, what in the world are you hoping to achieve by this dialog? I fail to see how the note you just sent (partially quoted below), complete with hostile sarcasm, will achieve any changing to the CRC text. Are you wanting to change the spec, or are you wanting to be sarcastic? Take care, Bill > Bill Studenmund wrote: > > > > However, the IETF uses this bit numbering scheme in ALL of its documents. > > It is consistent in its bit numbering. Thus if I read an IETF document, I > > prepare my mind for IETF bit numbering. > > Wow! > > > Note that the IETF is not the only group to use this bit numbering. As I > > understand it the Mainframe folks use this bit numbering. Also, the > > documentation I have on PowerPC chips all uses this bit numbering, so it's > > not something the IETF made up. > > Wow -- so you've just discovered that it is just a convention -- > good for you. > [snip] From owner-ips@ece.cmu.edu Thu Jun 13 19:54:41 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04909 for ; Thu, 13 Jun 2002 19:54:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DNg4a00420 for ips-outgoing; Thu, 13 Jun 2002 19:42:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DNg3w00416 for ; Thu, 13 Jun 2002 19:42:03 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g5DNhKu32681; Thu, 13 Jun 2002 19:43:20 -0400 Message-ID: <3D092DBA.56FC05AA@splentec.com> Date: Thu, 13 Jun 2002 19:41:46 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: pat_thaler@agilent.com CC: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: Re: iSCSI: 12-97 Bit Rule References: <1BEBA5E8600DD4119A50009027AF54A00C5E46D3@axcs04.cos.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit pat_thaler@agilent.com wrote: > > You seem intent on taking an injured and combative tone which makes it difficult to have a reasoned discussion with you. > Well, I'm just trying to sift out 0-content emails from more constructive criticism emails. And believe me, ``I agree with so and so.... blah... blah'' repeated 1e9 times in an email is NOT, I repeat NOT constructive criticism, especially in a science bound mailing list. A reasoned discussion with me goes as follows: 1+1 = 2, ok, 1+2 = 1+(1+1) = 3, etc., i.e. highly constructve, rather than, essay like. But this is _my_ problem. In other words, I expect a message of the sort: ``you (I) said a+b = c, but a+b = c+1'' i.e. constructive and straight to the point. This is so much more helpful than the general essays with content ``Y:I agree with X''. I'm reading other mailing lists and I cannot find anywhere ``I agree with X''! It is as if ppl avoid it to preserve their own identity!!! -- Luben From owner-ips@ece.cmu.edu Thu Jun 13 20:12:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05301 for ; Thu, 13 Jun 2002 20:12:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DNcRn00252 for ips-outgoing; Thu, 13 Jun 2002 19:38:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DNcPw00248 for ; Thu, 13 Jun 2002 19:38:25 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 4BB84BC99; Thu, 13 Jun 2002 17:38:21 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 25FEB107; Thu, 13 Jun 2002 17:38:21 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 13 Jun 2002 17:38:20 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Jun 2002 17:38:20 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E46DA@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: luben@splentec.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: 12-97 Bit Rule Date: Thu, 13 Jun 2002 17:38:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Luben, If I ruled the world, I would number the least significant bit 0. I agree that that is a more logical numbering. My second choice would be for the whole world to use the same numbering even if it was different from that. However, neither you nor I rule the world and IETF has chosen to number the most significant bit 0 and the choices made by other organizations vary all over the map and we get to flop and flip bits to match them to the environment. A convention that is used throughout the document (like the significance of bits within a field) belongs at the front. That convention also gets reinforced when one looks at other parts of the document like chapter 9. That is why it is satisfactory for 1.3.1 through 1.3.3 to be at the front. A detail that only applies one place like the different ordering of the bits in the CRC calculation should be in the place where it is used. That is why it wasn't good to have 11.1 reference 1.3.4 for how to order the bits in the CRC calculation. This is just good editorial practice for building a usable document. On the particular text: 8) The message sent is P and appended at the end are the bit coefficients of CRC(x), with x^31 bit coefficient first, then x^30, etc. the problem is that the x^31 bit doesn't go first when it is in the frame. Also, bits can go through their entire existence without being sent in serial order so nothing is first. Say which bit of the CRC goes into which bit of the digest field and you are done. Sincerely, Pat -----Original Message----- From: Luben Tuikov [mailto:luben@splentec.com] Sent: Thursday, June 13, 2002 4:13 PM To: pat_thaler@agilent.com Cc: Julian_Satran@il.ibm.com; ips@ece.cmu.edu Subject: Re: iSCSI: 12-97 Bit Rule pat_thaler@agilent.com wrote: > > TCP/IP Illustrated numbers bits with bit 0 as the > most significant. My books on Sonet number bits > in a byte from 1 to 8. I guess you could argue > these are not books on computer architecture, but > the point is that not everyone numbers bits the > same. Uuuh, here we go again... Yes, I can argue that those are NOT books on computer architecure. Let me get home I'll send you the titles/authors/ISBN of a few books on Computer Architecture which use the NATURAL bit ordering: 2^(x+1) > 2^x, x >= 0, so it only _makes_sense_ to say that bit x+1 is more significant than bit x. Take the number 791, is the 2rd digit more significant than the 1nd? Well: 791 = 7*10^2 + 9*10^1 + 1*10^0. > If you will read 1.3.1 through 1.3.3, they do > explicitly state the significance of bits in > iSCSI words, half-words and bytes. Yep, and you were complaining that it was 200 pages away from 11.1 where the CRC digest was --- or was that in a private email? Trying to score points? > Julian's new description is accurate and clear. Are you sure? Are you really sure? > Item 8 in your description is unclear and confusing > because the bits do not "follow" each other in the > order you state (and any viewing of bits in a message > as a serial stream is entirely hypothetical). Here is 8: 8) The message sent is P and appended at the end are the bit coefficients of CRC(x), with x^31 bit coefficient first, then x^30, etc. That is after you send P, send CRC(x) as indicated. What doesn't follow what? Of course it is hypothetical... Pat, let me ask you this: Is Mathematics hypothetical? -- Luben From owner-ips@ece.cmu.edu Thu Jun 13 20:15:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05374 for ; Thu, 13 Jun 2002 20:15:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DNrF600994 for ips-outgoing; Thu, 13 Jun 2002 19:53:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DNrDw00990 for ; Thu, 13 Jun 2002 19:53:13 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g5DNsWu32746; Thu, 13 Jun 2002 19:54:32 -0400 Message-ID: <3D09305A.D2499E0E@splentec.com> Date: Thu, 13 Jun 2002 19:52:58 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Bill Studenmund CC: iSCSI Subject: Re: iSCSI: 12-97 Bit Rule References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bill Studenmund wrote: > > On Thu, 13 Jun 2002, Luben Tuikov wrote: > > Luben, what in the world are you hoping to achieve by this dialog? I fail > to see how the note you just sent (partially quoted below), complete with > hostile sarcasm, will achieve any changing to the CRC text. 1. Trying to extract more constructive emails from ppl, especially when they refer to emails sent by me. There is no point in you sending your praise of organization X and person Y to me. Just send me something of the sort: ``Luben, a+b = c+1, contrary to what you claim.'' and I'll be so happy. 2. I'm not trying to change the CRC text. Just trying to make it clearer. If you have a problem with abstract ideas, just say so, and that will be the end of it, rather than going around for a few emails. As I mentioned, I'm reading other mailing lists and ppl the DO NOT use ``I agree with X'' so as to preserve their own identity! They agree with rule, idea, notion, equation, postulate, etc. Preserve your identity! I've never seen ``I agree with X'' used so much (at all) elsewhere (Mailing lists). Let me hear YOUR opinion and YOUR ideas, but posting just to say that you praise organization X and person Y, is hardly of any help and is not constructive. -- Luben From owner-ips@ece.cmu.edu Thu Jun 13 20:16:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05391 for ; Thu, 13 Jun 2002 20:16:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DNkvl00646 for ips-outgoing; Thu, 13 Jun 2002 19:46:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DNkuw00640; Thu, 13 Jun 2002 19:46:56 -0400 (EDT) Received: from mail pickup service by mail8.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 19:41:10 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 12 Jun 2002 09:09:51 -0400 Received: from ruebert.ieee.org (ruebert.ieee.org [140.98.193.10]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5CD9pbC002953 for ; Wed, 12 Jun 2002 09:09:51 -0400 (EDT) Received: from ece.cmu.edu (gemini2.ieee.org [140.98.193.20]) by ruebert.ieee.org (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5CD9gq13316; Wed, 12 Jun 2002 09:09:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5CD4qa26730 for ips-outgoing; Wed, 12 Jun 2002 09:04:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5CD4ow26724; Wed, 12 Jun 2002 09:04:50 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5CD4d4L005198; Wed, 12 Jun 2002 15:04:39 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5CD4ax46910; Wed, 12 Jun 2002 15:04:36 +0200 To: Dennis Young Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iscsi: unsolicited data question X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 12 Jun 2002 16:04:34 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 12/06/2002 16:04:38, Serialize complete at 12/06/2002 16:04:38 Content-Type: multipart/alternative; boundary="=_alternative 0047A947C2256BD6_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0047A947C2256BD6_= Content-Type: text/plain; charset="us-ascii" yes - julo Dennis Young Sent by: owner-ips@ece.cmu.edu 06/12/2002 06:20 AM Please respond to Dennis Young To: ips@ece.cmu.edu cc: Subject: iscsi: unsolicited data question I have a question which has been asked before, but I couldn't find a direct answer in the archive. The table on page 200 of draft 12 doesn't directly answer this question either. The first paragraph on page 36 of draft 12 says "Targets operate in either solicitied (R2T) data mode or unsolicited (non R2T) data mode." tells me that a target, at all times during a data sequence transfer, can be one or the other, but not both (non R2T for the initial data out, R2T for the remaining data). Is this correct? Thanks, Dennis ---snip from an old email dated 3/30/2001--- " Hi Julian Sorry if I'm covering old ground... Is it possible to use unsolicited data for the first burst and then request any remaining data using R2T? For example, if the target has a previously allocated buffer available (length defined by FirstBurstSize) for unsolicited data, then once the initiator has sent unsolicited data up to and including this amount then the remaining data (if any) can be requested using R2T once the target has the buffer space available. ...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail: matthewb@bri.hp.com " --=_alternative 0047A947C2256BD6_= Content-Type: text/html; charset="us-ascii"
yes - julo


Dennis Young <dyoung@rhapsodynetworks.com>
Sent by: owner-ips@ece.cmu.edu

06/12/2002 06:20 AM
Please respond to Dennis Young

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iscsi: unsolicited data question

       


I have a question which has been asked before, but I couldn't find a direct
answer in the archive.  The table on page 200 of draft 12 doesn't directly
answer this question either.

The first paragraph on page 36 of draft 12 says "Targets operate in either
solicitied (R2T) data mode or unsolicited (non R2T) data mode."
tells me that a target, at all times during a data sequence transfer, can be

one or the other, but not both (non R2T for the initial data out, R2T for
the
remaining data).  Is this correct?

Thanks,
Dennis

---snip from an old email dated 3/30/2001---

" Hi Julian
Sorry if I'm covering old ground... Is it possible to use unsolicited data
for the first burst and then request any remaining data using R2T? For
example, if the target has a previously allocated buffer available (length
defined by FirstBurstSize) for unsolicited data, then once the initiator has
sent unsolicited data up to and including this amount then the remaining
data (if any) can be requested using R2T once the target has the buffer
space available.
...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail:
matthewb@bri.hp.com "

--=_alternative 0047A947C2256BD6_=-- From owner-ips@ece.cmu.edu Thu Jun 13 20:18:23 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05483 for ; Thu, 13 Jun 2002 20:18:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DNmbJ00748 for ips-outgoing; Thu, 13 Jun 2002 19:48:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DNmaw00744 for ; Thu, 13 Jun 2002 19:48:36 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 5422D30706; Thu, 13 Jun 2002 19:48:32 -0400 (EDT) Date: Thu, 13 Jun 2002 16:46:21 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: "CAVANNA,VICENTE V (A-Roseville,ex1)" Cc: Julian Satran , "THALER,PAT (A-Roseville,ex1)" , Subject: The slippery eel of CRC, RE: iSCSI: 12-97 Bit Rule In-Reply-To: <01A7DAF31F93D511AEE300D0B706ED9201BF4984@axcs13.cos.agilent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 13 Jun 2002, CAVANNA,VICENTE V (A-Roseville,ex1) wrote: > I believe Bill is correct. The receiver, unlike the transmitter, > should not complement the remainder if he expects to get 0x1c2d19ed. > > I am afraid I may be reponsible for this mistake during an email > exchange I and others had with Julian recently. Julian and those > others must have trusted me a little too much. Sorry Julian and > others. It seems like we're changing the text to be clearer for some folks, and unfortunately making it more confusing for others. It's like trying to catch an eel, as soon as we get a second hand on it, it pops out of the first. In addition to fixing the above, to be perfectly clear, perhaps we should mention that when calculating the CRC over a correctly recevied message + CRC, were the receiver to append the result of this calculation to the received message + CRC, it would always append the octed stream "c7 4b 67 48". This example is meant in the spirit of section B.4 where we have clear octets to compare against. Actually this bit should probably go in section B4 at the end. Take care, Bill From owner-ips@ece.cmu.edu Thu Jun 13 20:19:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05515 for ; Thu, 13 Jun 2002 20:19:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5DNxgD01290 for ips-outgoing; Thu, 13 Jun 2002 19:59:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5DNxew01285 for ; Thu, 13 Jun 2002 19:59:40 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 5A56C71D7; Thu, 13 Jun 2002 17:59:39 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 2880414E; Thu, 13 Jun 2002 17:59:39 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 13 Jun 2002 17:59:39 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Jun 2002 17:59:39 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E46E4@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: luben@splentec.com, pat_thaler@agilent.com Cc: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI: 12-97 Bit Rule Date: Thu, 13 Jun 2002 17:59:37 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Luben, This is a consensus group that holds debate and obtains consensus over the reflector. Therefore, the "I agree with X" messages are important to determine when we are closing in on consensus. Our chairs and editor need to know whether people agree with a proposal. I also find that people who write at greater length on why they agree often bring in new points that clarify the discussion. Pat -----Original Message----- From: Luben Tuikov [mailto:luben@splentec.com] Sent: Thursday, June 13, 2002 4:42 PM To: pat_thaler@agilent.com Cc: Julian_Satran@il.ibm.com; ips@ece.cmu.edu Subject: Re: iSCSI: 12-97 Bit Rule This is so much more helpful than the general essays with content ``Y:I agree with X''. From owner-ips@ece.cmu.edu Thu Jun 13 20:19:10 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05530 for ; Thu, 13 Jun 2002 20:19:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5E08Q401686 for ips-outgoing; Thu, 13 Jun 2002 20:08:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5E08Pw01681 for ; Thu, 13 Jun 2002 20:08:25 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g5E09eu00390; Thu, 13 Jun 2002 20:09:40 -0400 Message-ID: <3D0933E6.8A689921@splentec.com> Date: Thu, 13 Jun 2002 20:08:06 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: pat_thaler@agilent.com CC: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: Re: iSCSI: 12-97 Bit Rule References: <1BEBA5E8600DD4119A50009027AF54A00C5E46E4@axcs04.cos.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit pat_thaler@agilent.com wrote: > > Luben, > > This is a consensus group that holds debate and obtains consensus over the reflector. Therefore, the "I agree with X" messages are important to determine when we are closing in on consensus. Our chairs and editor need to know whether people agree with a proposal. > Then, you should probably use "I agree with consensus `a+b = c+1'". Preserve your identity. > I also find that people who write at greater length on why they agree often bring in new points that clarify the discussion. > Bzzt. Wrong! Pat, it only LOOKS like this, but it is not necessarily the case. People who understand see it, and ppl who don't get impressed. Read this: 1+1 = 2. How much clearer can this be. -- Luben From owner-ips@ece.cmu.edu Thu Jun 13 20:36:56 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06027 for ; Thu, 13 Jun 2002 20:36:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5E00h701346 for ips-outgoing; Thu, 13 Jun 2002 20:00:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5E00fw01338 for ; Thu, 13 Jun 2002 20:00:41 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g5E023u00352; Thu, 13 Jun 2002 20:02:03 -0400 Message-ID: <3D09321E.ABBD1D4B@splentec.com> Date: Thu, 13 Jun 2002 20:00:30 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: pat_thaler@agilent.com CC: ips@ece.cmu.edu Subject: Re: iSCSI: 12-97 Bit Rule References: <1BEBA5E8600DD4119A50009027AF54A00C5E46DA@axcs04.cos.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit pat_thaler@agilent.com wrote: > [cheerfully deleted 0-content reply] > On the particular text: > 8) The message sent is P and appended at the end are the > bit coefficients of CRC(x), with x^31 bit coefficient > first, then x^30, etc. > the problem is that the x^31 bit doesn't go first when it is in the frame. > Also, bits can go through their entire existence without being sent in > serial order so nothing is first. Say which bit of the CRC goes into which > bit of the digest field and you are done. Bzzt. Wrong. As you said, this is all hypothetical. Just as Julian said: ``hypothetical bit stream''. How did you get ``frame'' involved? You're mixing high-level, and low-level implementation. Once you have that bit stream ready and built, as outlined above by me, _THEN_ you pass it to the upper layers which will take care of sending and reordering, and what not. AND IF an implementation can ``see'' that it can optimize things just because their bit/byte order is such an such, then so be it, BUT the explanation should be formal enough and NOT refer to any particular implementation. -- Luben From owner-ips@ece.cmu.edu Thu Jun 13 20:36:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06040 for ; Thu, 13 Jun 2002 20:36:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5E0JdB02163 for ips-outgoing; Thu, 13 Jun 2002 20:19:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5E0Jbw02158; Thu, 13 Jun 2002 20:19:38 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 2C2831199; Thu, 13 Jun 2002 18:19:37 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with SMTP id DFFDE10B; Thu, 13 Jun 2002 18:19:36 -0600 (MDT) Received: from 130.29.152.143 by axcsbh1.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 13 Jun 2002 18:19:36 -0600 Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Jun 2002 18:19:36 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E46E9@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Bill Studenmund , Julian Satran Cc: "THALER,PAT (A-Roseville,ex1)" , ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI: 12-97 Bit Rule Date: Thu, 13 Jun 2002 18:19:35 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Bill, One could say: - Computing the CRC over any segment (data or header) extended to include the CRC built using the generator 0x11edc6f41 will get always the value 0x1c2d19ed as the result before complementing. This value is given here in its polynomial form - i.e. not mapped as the digest word. or - Computing the CRC over any segment (data or header) extended to include the CRC built using the generator 0x11edc6f41 will get always the value 0xe3d23612 as its final CRC. This value is given here in its polynomial form - i.e. not mapped as the digest word. or - Performing the formation of the plynomial M(x) over any segment (data or header) extended to include the digest, complementing the most significant 32 bits, multiplying by x^32 then dividing by G(x) will always produce the remainder polynomial 0x1c2d19ed. This value is in its polynomial form - not complemented and not mapped into the digest word. or - Computing the CRC over any segment (data or header) extended to include the CRC built using the generator 0x11edc6f41 will get always produce R(x) = 0x1c2d19ed. This value is in its polynomial form - not complemented and not mapped into the digest word. I like the last one best because it uses the term that relates the result to where it will appear in the process above. Pat -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Thursday, June 13, 2002 2:36 PM To: Julian Satran Cc: pat_thaler@agilent.com; ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: 12-97 Bit Rule On Thu, 13 Jun 2002, Julian Satran wrote: One minor question. > I took out completely the bit rule. > I reformulated the CRC text as: > > The CRC MUST be calculated by a method that produces the same results as > the following process: > > - The PDU bits are considered as the coefficients of a polyno-mial M(x) of > degree n-1; bit 7 of the lowest numbered byte is considered the most > significant bit (x^n-1), followed by bit 6 of the lowest numbered byte and > through bit 0 of the high-est numbered byte (x^0). > > - The most significant 32 bits are complemented. > > - The polynomial is multiplied by x^32 then divided by G(x). The generator > polynomial produces a remainder R(x) of degree <= 31. > > - The coefficients of R(x) are considered a 32 bit sequence. > > - The bit sequence is complemented and the result is the CRC. Call the above step 5. > - the CRC bits are mapped into the digest word - the x^31 coef-ficient in > bit 7 of the lowest numbered byte of the digest continuing to through the > byte up to the x^24 coefficient in bit 0 of the lowest numbered byte, > continuing with the x^23 coefficient in bit 7 of next byte through x^0 in > bit 0 of the highest numbered byte. > > - Computing the CRC over any segment (data or header) extended to include > the CRC built using the generator 0x11edc6f41 will get always the value > 0x1c2d19ed as its final CRC. This value is given here in its polynomial > form - i.e. not mapped as the digest word About the use of "final CRC" with respect to 0x1c2d19ed. Step 5 says the "CRC" is after the complementation, but my experiments indicate that 0x1c2d19ed is the uncomplimented result, and that the complimented result would be 0xe3d2e612. Thus 0xe3d2e612 would be the "CRC." > I hope you will find it less confusing I'm not sure what to do. The thoughts which come to my mind take up space. The simplest would be to mention what coefficents one uses in well-known crc packages. A more complex one would be to include source code, as the sctp crc draft did. Take care, Bill From owner-ips@ece.cmu.edu Thu Jun 13 21:37:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07270 for ; Thu, 13 Jun 2002 21:37:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5E0hM603064 for ips-outgoing; Thu, 13 Jun 2002 20:43:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5E0hKw03059 for ; Thu, 13 Jun 2002 20:43:20 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g5E0idu00700; Thu, 13 Jun 2002 20:44:39 -0400 Message-ID: <3D093C19.680C5890@splentec.com> Date: Thu, 13 Jun 2002 20:43:05 -0400 From: Luben Tuikov Reply-To: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "CAVANNA,VICENTE V (A-Roseville,ex1)" CC: "'Bill Studenmund'" , Julian Satran , "THALER,PAT (A-Roseville,ex1)" , ips@ece.cmu.edu Subject: Re: iSCSI: 12-97 Bit Rule References: <01A7DAF31F93D511AEE300D0B706ED9201BF4984@axcs13.cos.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit "CAVANNA,VICENTE V (A-Roseville,ex1)" wrote: > > I believe Bill is correct. The receiver, unlike the transmitter, should not complement the remainder if he expects to get 0x1c2d19ed. > I am afraid I may be reponsible for this mistake during an email exchange I and others had with Julian recently. Julian and those others must have trusted me a little too much. Sorry Julian and others. Vince, you had it right. The text was mentioning that it was the CRC that was the magic constant, and since the CRC is complemented in the course of computation, one more was needed to get ``back'' to the remainder. Yes, Bill, your empirical conclusion is correct. The magic constant _is_ the pure remainder in polynomial form (0x1c2d19ed). The CRC is the complemented (and byte mirrored) remainder. That is: you have 2 algoritms, one to compute the pure remainder, and another to complement it (and maybe byte-mirror) and inject it at the end of the message to be sent. The sender does both algorithms (compute and inject), and the receiver does just the first (compute) and compares the result with the magic value. This has already been mentioned in a more formal (and maybe confusing :-)) manner in an email from me at the beginning of this thread (take a look at it, the one with bit-sequences). -- Luben From owner-ips@ece.cmu.edu Thu Jun 13 21:57:11 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07952 for ; Thu, 13 Jun 2002 21:57:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5E1NJ805095 for ips-outgoing; Thu, 13 Jun 2002 21:23:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5E1NGw05089; Thu, 13 Jun 2002 21:23:16 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 0A90D30706; Thu, 13 Jun 2002 21:23:15 -0400 (EDT) Date: Thu, 13 Jun 2002 18:21:04 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: "THALER,PAT (A-Roseville,ex1)" Cc: Julian Satran , , Subject: RE: iSCSI: 12-97 Bit Rule In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00C5E46E9@axcs04.cos.agilent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 13 Jun 2002, THALER,PAT (A-Roseville,ex1) wrote: > Bill, > > One could say: > - Computing the CRC over any segment (data or header) extended to include > the CRC built using the generator 0x11edc6f41 will get always the value > 0x1c2d19ed as the result before complementing. This value is given here in its polynomial form - i.e. not mapped as the digest word. > > or > - Computing the CRC over any segment (data or header) extended to include > the CRC built using the generator 0x11edc6f41 will get always the value > 0xe3d23612 as its final CRC. This value is given here in its polynomial > form - i.e. not mapped as the digest word. > > or > - Performing the formation of the plynomial M(x) over any segment (data or header) extended to include the digest, complementing the most significant 32 bits, multiplying by x^32 then dividing by G(x) will always produce the remainder polynomial 0x1c2d19ed. This value is in its polynomial form - not complemented and not mapped into the digest word. > > or > - Computing the CRC over any segment (data or header) extended to include > the CRC built using the generator 0x11edc6f41 will get always produce > R(x) = 0x1c2d19ed. This value is in its polynomial form - not complemented and not mapped into the digest word. > > I like the last one best because it uses the term that relates the result to where it will appear in the process above. Sounds good. That's what we used to have, but with R(x) now specific. Take care, Bill From owner-ips@ece.cmu.edu Thu Jun 13 22:04:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08108 for ; Thu, 13 Jun 2002 22:04:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5E1kiK06016 for ips-outgoing; Thu, 13 Jun 2002 21:46:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5E1kgw06008 for ; Thu, 13 Jun 2002 21:46:42 -0400 (EDT) Received: from mail pickup service by mail8.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 21:43:30 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Jun 2002 17:47:28 -0400 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5BLlTbC002781 for ; Tue, 11 Jun 2002 17:47:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BKqQ603958 for ips-outgoing; Tue, 11 Jun 2002 16:52:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from astutenetworks.com (2.astutenetworks.com [216.142.74.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BKqNw03951 for ; Tue, 11 Jun 2002 16:52:23 -0400 (EDT) Received: from amirdesktop (dhcp62 [172.21.2.62]) by astutenetworks.com (8.11.6/8.11.2) with SMTP id g5BKpA909685; Tue, 11 Jun 2002 13:51:10 -0700 From: "Amir Shalit" To: "Mallikarjun C." , "Eddy Quicksall" , "Julian Satran" Cc: Subject: RE: iSCSI: changing MaxPDUDataLength Date: Tue, 11 Jun 2002 13:51:08 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <002001c2117f$24527e20$edd52b0f@rose.hp.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mallikarjun, The initiator can wait for all outstanding sequences to get acknowledged prior to negotiating MaxPDUDataLength change. That will work well for long-running commands and simplify target management. Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Mallikarjun C. Sent: Tuesday, June 11, 2002 12:35 PM To: Eddy Quicksall; Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iSCSI: changing MaxPDUDataLength Eddy, I am not clear on why you think the target code becomes messy on a PDU size change. The last para in section 4.4 states the following - "Parameters negotiated by a text exchange negotiation sequence become effective only after the negotiation sequence is completed." Since the target gets to complete a text negotiation with a Text Response PDU, it can time the applicability of a changed MaxRecvDataSegmentLength. Requiring that an initiator must idle the connection before changing this parameter, IMHO, is counter-productive when there's a dynamic PMTU degradation in the presence of long-running commands (writes in particular). Once the initiator starts the renegotiation, target would ideally want to quickly renegotiate its receive size as well to receive ULPDU-contained segments. In short, seems to me that the draft is saying what you would like. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Eddy Quicksall" To: "Julian Satran" Cc: Sent: Tuesday, June 11, 2002 7:56 AM Subject: RE: iSCSI: changing MaxPDUDataLength > I think it should be a requirement because if it is not, all target code > will have to have the messy code. Or, we could say that if it is not idle > commands, then the target may reject it. > > Eddy > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Tuesday, June 11, 2002 9:11 AM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > That is a fair request - we may slip in a recommendation to that effect (in > chapter 11?) > > Julo > > > > Eddy Quicksall > > > 06/11/2002 04:28 AM > Please respond to Eddy Quicksall > > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > How about if we say that an initiator must not change the MaxPDUDataSize > unless it first idles the commands (at least the ones with the R bit) or if > ErrorRecoveryLevel==0? > > That would simplify target code greatly and would meet the design goals; and > since it should be rare to change it, it would be of little impact to idle > the commands for a split second. > > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Monday, June 10, 2002 8:06 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > I said only that when you change length you can ask for all PDUs after the > ack! (no need to keep a tall - the old offsets are good up to the hole). > > Julo > > > Eddy Quicksall > > > 06/11/2002 12:32 AM > Please respond to Eddy Quicksall > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > Julian, > > Another problem here is that the target has to calculate the offset from the > DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 > means starting DataSN=4, send all the data for that sequence. > > I think it would be a performance hit and waist of memory to keep a tally of > all PDU sizes just for an occasional SNACK. > > It's not that it can't be done ... it is more that it is messy and I think > there is a solution that will satisfy the design requirements but keep the > software simpler. > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Saturday, June 08, 2002 10:16 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > That is not completely accurate. > The only problem is when PDU size decreases and then SNACK must be for all > data. > Target can also keep a mapping of numbers/to offsets (the list should be > small and if it gets long ask for ack (A-bit). > > Julo > > Eddy Quicksall > Sent by: owner-ips@ece.cmu.edu > > > 06/08/2002 10:54 PM > Please respond to Eddy Quicksall > > > To: pat_thaler@agilent.com > cc: ips@ece.cmu.edu > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > Thanks, > > As a target, I won't be able to let it change until all of the outstanding > commands are finished (running with ErrorRecoveryLevel>=1). This is because > I must use the PDU size to compute the offset from a SNACK's > BegRun/RunLength. > > So, I plan to not give the text response for a MaxPDURecvDataLength in FFP > until I get back an ExpStatSN == next StatSN. > > This will cause a delay of unknown time before the PDU size can actually > change ... do you see any problem with this? > > Eddy > > -----Original Message----- > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > Sent: Friday, June 07, 2002 1:13 PM > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > Subject: RE: iSCSI: changing MaxPDUDataLength > > > Eddy, > > If one uses a message sync and steering that relys on the transport segments > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path > MTU changes one would want to change the PDU data length to fit the new path > MTU. > > Pat > > -----Original Message----- > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > Sent: Wednesday, June 05, 2002 12:24 PM > To: ips@ece.cmu.edu > Subject: iSCSI: changing MaxPDUDataLength > > > Does anybody know a case where it is necessary to support a new PDU data > length during full feature phase? > > Eddy > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > From owner-ips@ece.cmu.edu Thu Jun 13 22:49:12 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09402 for ; Thu, 13 Jun 2002 22:49:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5E1xxb06549 for ips-outgoing; Thu, 13 Jun 2002 21:59:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5E1xqw06543 for ; Thu, 13 Jun 2002 21:59:53 -0400 (EDT) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.10.2+Sun/8.10.2) with ESMTP id g5E1xkv23807; Thu, 13 Jun 2002 18:59:46 -0700 (PDT) Received: from aimexc07.corp.adaptec.com (aimexc07.corp.adaptec.com [162.62.62.47]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id SAA25178; Thu, 13 Jun 2002 18:59:46 -0700 (PDT) Received: by aimexc07.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Jun 2002 18:59:29 -0700 Message-ID: From: "Ranganathan, Deva" To: "'Julian Satran'" Cc: ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Date: Thu, 13 Jun 2002 18:59:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21347.1E0BF0E0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21347.1E0BF0E0 Content-Type: text/plain "tells me that a target, at all times during a data sequence transfer, can be one or the other, but not both (non R2T for the initial data out, R2T for the remaining data). Is this correct?" really? I thought thatit is permissible to have non-R2T for the initial data out and R2T for remaining. i.e for a 64K transfer, the first 32K can be the first burst size of data and the next 32K will be solicited by the target through R2T. Am I missing something? -Deva -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 6:05 AM To: Dennis Young Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iscsi: unsolicited data question yes - julo Dennis Young Sent by: owner-ips@ece.cmu.edu 06/12/2002 06:20 AM Please respond to Dennis Young To: ips@ece.cmu.edu cc: Subject: iscsi: unsolicited data question I have a question which has been asked before, but I couldn't find a direct answer in the archive. The table on page 200 of draft 12 doesn't directly answer this question either. The first paragraph on page 36 of draft 12 says "Targets operate in either solicitied (R2T) data mode or unsolicited (non R2T) data mode." tells me that a target, at all times during a data sequence transfer, can be one or the other, but not both (non R2T for the initial data out, R2T for the remaining data). Is this correct? Thanks, Dennis ---snip from an old email dated 3/30/2001--- " Hi Julian Sorry if I'm covering old ground... Is it possible to use unsolicited data for the first burst and then request any remaining data using R2T? For example, if the target has a previously allocated buffer available (length defined by FirstBurstSize) for unsolicited data, then once the initiator has sent unsolicited data up to and including this amount then the remaining data (if any) can be requested using R2T once the target has the buffer space available. ...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail: matthewb@bri.hp.com " ------_=_NextPart_001_01C21347.1E0BF0E0 Content-Type: text/html
"tells me that a target, at all times during a data sequence transfer, can be

one or the other, but not both (non R2T for the initial data out, R2T for
the
remaining data).  Is this correct?"
 
really? I thought thatit is permissible to have non-R2T for the initial data out and R2T for
remaining. i.e for a 64K transfer, the first 32K can be the first burst size of data and
the next 32K will be solicited by the target through R2T. Am I missing something?
 

-Deva
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 12, 2002 6:05 AM
To: Dennis Young
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iscsi: unsolicited data question


yes - julo


Dennis Young <dyoung@rhapsodynetworks.com>
Sent by: owner-ips@ece.cmu.edu

06/12/2002 06:20 AM
Please respond to Dennis Young

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iscsi: unsolicited data question

       


I have a question which has been asked before, but I couldn't find a direct
answer in the archive.  The table on page 200 of draft 12 doesn't directly
answer this question either.

The first paragraph on page 36 of draft 12 says "Targets operate in either
solicitied (R2T) data mode or unsolicited (non R2T) data mode."
tells me that a target, at all times during a data sequence transfer, can be

one or the other, but not both (non R2T for the initial data out, R2T for
the
remaining data).  Is this correct?

Thanks,
Dennis

---snip from an old email dated 3/30/2001---

" Hi Julian
Sorry if I'm covering old ground... Is it possible to use unsolicited data
for the first burst and then request any remaining data using R2T? For
example, if the target has a previously allocated buffer available (length
defined by FirstBurstSize) for unsolicited data, then once the initiator has
sent unsolicited data up to and including this amount then the remaining
data (if any) can be requested using R2T once the target has the buffer
space available.
...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail:
matthewb@bri.hp.com "




------_=_NextPart_001_01C21347.1E0BF0E0-- From owner-ips@ece.cmu.edu Thu Jun 13 23:35:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09945 for ; Thu, 13 Jun 2002 23:35:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5E2d8408213 for ips-outgoing; Thu, 13 Jun 2002 22:39:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5E2d5w08209 for ; Thu, 13 Jun 2002 22:39:05 -0400 (EDT) Received: from mail pickup service by mail8.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 22:33:56 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Jun 2002 16:35:41 -0400 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5BKZga2003167 for ; Tue, 11 Jun 2002 16:35:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BJpwg00077 for ips-outgoing; Tue, 11 Jun 2002 15:51:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BJpvw00073 for ; Tue, 11 Jun 2002 15:51:57 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 83F6630706; Tue, 11 Jun 2002 15:51:56 -0400 (EDT) Date: Tue, 11 Jun 2002 12:49:49 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Santosh Rao Cc: Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys In-Reply-To: <3D064959.660D58EC@cup.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 11 Jun 2002, Santosh Rao wrote: > I don't see why this thread is going forever. There are other scsi > transports that deal with these types of issues without having to define > scsi transport protocol keys to indicate vendor_id, product_id and > product_rev. You can do one of the following : > > a) Parse out the DNS name of the target device from the exchanged > TargetName key, if you're an initiator. Similarly, parse out the DNS > name of the initiator from the exchanged InitiatorName key, if you're a > target. Use the DNS name as an indication of which device you're > speaking to and add your device specific tweaks based on this. That we can do. But that means that the system adminsitrator or a "smart agent" has to correlate the info. And, if a device moves, it has to get involved again to reconfigure. It could be that this won't be a problem, but it could also be a hassle. > If the InitiatorName or TargetName is in EUI-64 format, you can obtain > the vendor_id information from the upper 3 bytes of the EUI-64 name. That only gets you one of the three keys. :-) The product and revisions are the ones that are more important if we are bug-compensating. :-) > b) Send INQUIRY to LUN 0 to determine the vendor_id, product_id and > product_revisison_level of the device. Use this data to perform any > device specific tweaks in your software/firmware. That assumes that the iscsi device is the same as the scsi device. In the case of an iscsi->FC or iscsi->Parallel SCSI gateway, that's not going to be the case. > c) Provide out-of-band static configuration mechanisms in your initiator > or target to assign a vendor specific identity to 1 or more initiators > or targets. This allows the target configuration personnel to configure > the device appropriately for the initiators it is speaking to. That, like the first option above, involves correlating a lot of info, and keeping it up to date. Sounds like turning a protocol mess into a management mess. > I don't see any need to be defining iscsi login keys to duplicate the > vendor_id, product_id information. Well, that's your opinion. Some of us feel that what you describe above is a hassle we'd rather spare our customers. Especially since happy customers spend more. :-) Take care, Bill From owner-ips@ece.cmu.edu Thu Jun 13 23:37:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09993 for ; Thu, 13 Jun 2002 23:37:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5E36nl09256 for ips-outgoing; Thu, 13 Jun 2002 23:06:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5E36lw09251 for ; Thu, 13 Jun 2002 23:06:47 -0400 (EDT) Received: from mail pickup service by mail8.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 23:00:05 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Jun 2002 12:45:57 -0400 Received: from engine.ieee.org (engine.ieee.org [140.98.193.23]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5BFDmod029981 for ; Tue, 11 Jun 2002 11:13:48 -0400 (EDT) Received: from ece.cmu.edu (gemini2.ieee.org [140.98.193.20]) by engine.ieee.org (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5BFCcB08156; Tue, 11 Jun 2002 11:12:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BEuSo11409 for ips-outgoing; Tue, 11 Jun 2002 10:56:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BEuPw11403 for ; Tue, 11 Jun 2002 10:56:26 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 10:56:25 -0400 Message-ID: From: Eddy Quicksall To: Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Date: Tue, 11 Jun 2002 10:56:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I think it should be a requirement because if it is not, all target code will have to have the messy code. Or, we could say that if it is not idle commands, then the target may reject it. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, June 11, 2002 9:11 AM To: Eddy Quicksall Cc: ips@ece.cmu.edu; pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength That is a fair request - we may slip in a recommendation to that effect (in chapter 11?) Julo Eddy Quicksall 06/11/2002 04:28 AM Please respond to Eddy Quicksall To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength How about if we say that an initiator must not change the MaxPDUDataSize unless it first idles the commands (at least the ones with the R bit) or if ErrorRecoveryLevel==0? That would simplify target code greatly and would meet the design goals; and since it should be rare to change it, it would be of little impact to idle the commands for a split second. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, June 10, 2002 8:06 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu; pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength I said only that when you change length you can ask for all PDUs after the ack! (no need to keep a tall - the old offsets are good up to the hole). Julo Eddy Quicksall 06/11/2002 12:32 AM Please respond to Eddy Quicksall To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength Julian, Another problem here is that the target has to calculate the offset from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 means starting DataSN=4, send all the data for that sequence. I think it would be a performance hit and waist of memory to keep a tally of all PDU sizes just for an occasional SNACK. It's not that it can't be done ... it is more that it is messy and I think there is a solution that will satisfy the design requirements but keep the software simpler. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, June 08, 2002 10:16 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength That is not completely accurate. The only problem is when PDU size decreases and then SNACK must be for all data. Target can also keep a mapping of numbers/to offsets (the list should be small and if it gets long ask for ack (A-bit). Julo Eddy Quicksall Sent by: owner-ips@ece.cmu.edu 06/08/2002 10:54 PM Please respond to Eddy Quicksall To: pat_thaler@agilent.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Thanks, As a target, I won't be able to let it change until all of the outstanding commands are finished (running with ErrorRecoveryLevel>=1). This is because I must use the PDU size to compute the offset from a SNACK's BegRun/RunLength. So, I plan to not give the text response for a MaxPDURecvDataLength in FFP until I get back an ExpStatSN == next StatSN. This will cause a delay of unknown time before the PDU size can actually change ... do you see any problem with this? Eddy -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Friday, June 07, 2002 1:13 PM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Eddy, If one uses a message sync and steering that relys on the transport segments carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path MTU changes one would want to change the PDU data length to fit the new path MTU. Pat -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Wednesday, June 05, 2002 12:24 PM To: ips@ece.cmu.edu Subject: iSCSI: changing MaxPDUDataLength Does anybody know a case where it is necessary to support a new PDU data length during full feature phase? Eddy mailto: Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Fri Jun 14 03:00:55 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21667 for ; Fri, 14 Jun 2002 03:00:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5E6dOj17536 for ips-outgoing; Fri, 14 Jun 2002 02:39:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5E6dMw17531 for ; Fri, 14 Jun 2002 02:39:23 -0400 (EDT) Received: from mail pickup service by mail8.nc.rr.com with Microsoft SMTPSVC; Fri, 14 Jun 2002 02:37:08 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 15:30:12 -0400 Received: from ruebert.ieee.org (ruebert.ieee.org [140.98.193.10]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AJUCtH027715 for ; Mon, 10 Jun 2002 15:30:13 -0400 (EDT) Received: from ece.cmu.edu (gemini2.ieee.org [140.98.193.20]) by ruebert.ieee.org (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5AJToq14257; Mon, 10 Jun 2002 15:29:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AJ7wd05951 for ips-outgoing; Mon, 10 Jun 2002 15:07:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AJ7uw05946 for ; Mon, 10 Jun 2002 15:07:56 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 1B06A30706; Mon, 10 Jun 2002 15:07:56 -0400 (EDT) Date: Mon, 10 Jun 2002 12:05:48 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Ken Sandars Cc: Julian Satran , "Robert D. Russell" , Subject: Re: MaxRecvPDULength question In-Reply-To: <200206101550.QAA11665@best.eurologic.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Mon, 10 Jun 2002, Ken Sandars wrote: > Hi Julo & Bob, > > I support Bob on this change to the completely unambiguous > > "MaxRecvDataSegmentLength" I'll add another vote for it. :-) Take care, Bill From owner-ips@ece.cmu.edu Fri Jun 14 03:02:11 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21748 for ; Fri, 14 Jun 2002 03:02:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5E6YtL17353 for ips-outgoing; Fri, 14 Jun 2002 02:34:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5E6Ysw17349 for ; Fri, 14 Jun 2002 02:34:54 -0400 (EDT) Received: from mail pickup service by mail8.nc.rr.com with Microsoft SMTPSVC; Fri, 14 Jun 2002 02:33:19 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 16:54:13 -0400 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AKs4Ia025862 for ; Mon, 10 Jun 2002 16:54:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AKRfM10776 for ips-outgoing; Mon, 10 Jun 2002 16:27:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AKRdw10772 for ; Mon, 10 Jun 2002 16:27:39 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id BF913A4A; Mon, 10 Jun 2002 14:27:34 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 978B228F; Mon, 10 Jun 2002 14:27:34 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 10 Jun 2002 14:27:33 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 14:27:32 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C5E3E7B@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: luben@splentec.com, wrstuden@wasabisystems.com Cc: rsnively@Brocade.COM, ksandars@eurologic.com, ips@ece.cmu.edu Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys Date: Mon, 10 Jun 2002 14:27:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Luben, An IETF standard is suppose to produce interoperability. Therefore, when there is a MAY in the standard, it should be because each side can choose either option and they will interoperate independent of which they choose. For example: "iSCSI targets and initiators MUST support at least one TCP connection and MAY support several connections in a session." A device that supports only one connection per session will interoperate (over one connection) to a device that supports multiple connections. Pat -----Original Message----- From: Luben Tuikov [mailto:luben@splentec.com] Sent: Friday, June 07, 2002 4:18 PM To: Bill Studenmund Cc: Robert Snively; 'Ken Sandars'; Ips Reflector (E-mail) Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys Bill Studenmund wrote: > > > That comment reflects a very nice ideal. My concern is that I'm not sure > we're there. What about Luben's comments that there are existing > interoperability problems among compliant systems? AS I understand him, > compliant *iSCSI* systems. ?? I haven't checked for those lately, (especially in the login procedure), but any time you see ``MAY'' or ``may'' in the draft and a target and initiator arrive at different outcomes _just_ by taking one or the other route, you have ``compliant-non-interoperability'' (as you coined the term). > My technical writing skills aren't up > to the task to do anything different, and I expect someone will make some > $$ off of an intro book. There are books that talk about iSCSI now. I bet that just one month after iSCSI becomes a standard, you'll see 10 books on iSCSI, 5 for Unix/Linux (2 of them with CDs + implementations) and 5 for Windoze. I can think of at least one Linux Guru who's known to write books like that (for a month's time) and who might be considering this. > But the problem (as a number of recent threads have shown :-) is that > people who are looking at the spec for the first time don't necessarily > come to understand the spec the same way that the longer-term WG members > do. The longer-term members see the written spec as a clear reflection of > their idea of the spec, so they don't see the problems. They've been to > plug-fests, and so they have a lot of commonality in their mental ideas of > what the spec is. When a choice comes up, they naturally choose the same > way as the other longer-term members, and they don't always see that > they've made a choice. This basically is the old conundrum: How does one express one's ideas in the most unambiguous way? We don't know of a better way than formalism (i.e. mathematics). This is the reason I've been asking to be more formal in the draft. And I'm not just whining, as I've made it clear that I can volunteer time. This is why 4.1 and 1. exist in their current form. This is also why I've been trying to get the CRC algorithm in 11.1 become more formal, which would make it more clear and straightforward to implement. And this is why I'd like to see someone draw the decision graphs for the login/text stage/negotiations for the T and I -- then any problems will be evident. And this is why Robert of UNH started the variables' dependency charts. > So what do we do? The rest of us (certainly me) cannot do anything. I can just wait. (I can only correct spelling mistakes and missed periods, and such, like this one ) It would be interesing to see the development of iSCSI and the reaction of the rest of the industry and (closer to my heart) the Linux community once iSCSI becomes a standard. -- Luben From owner-ips@ece.cmu.edu Fri Jun 14 03:02:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21761 for ; Fri, 14 Jun 2002 03:02:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5E6Fhw16630 for ips-outgoing; Fri, 14 Jun 2002 02:15:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mercury.corp.iready.com ([65.115.68.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5E6Ffw16625 for ; Fri, 14 Jun 2002 02:15:41 -0400 (EDT) Received: by mercury.corp.iready.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Jun 2002 23:15:35 -0700 Message-ID: <034670D62D19D31180990090277A37B701FCA1D6@mercury.corp.iready.com> From: Arul Ponnusamy To: "'Ranganathan, Deva'" , "'Julian Satran'" Cc: ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Date: Thu, 13 Jun 2002 23:15:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2136A.DF93ED30" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2136A.DF93ED30 Content-Type: text/plain; charset="iso-8859-1" 1) I have the same doubt as Deva. i.e Solicited mode and unsolicited mode differ only with respect to the first outgoing data burst. Unsolicited mode: R2T is not needed only for the first outgoing data burst. The subsequent data MUST be solicited. Solicited mode: all data outs (including the first data out) MUST be solicited. Is this correct? 2) As per section 9.8 and 11.10, for WRITE operations without explicit Initial R2T, the InitialR2T MUST have negotiated to NO. But as per 11.12 says that if InitialR2T=yes and ImmediateData=yes, then Immediate unsolicited data only allowed. It looks like ambigous. Or Do I miss any other part of the spec which explains this? Arul -----Original Message----- From: Ranganathan, Deva [mailto:Deva_Ranganathan@adaptec.com] Sent: Thursday, June 13, 2002 6:59 PM To: 'Julian Satran' Cc: ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question "tells me that a target, at all times during a data sequence transfer, can be one or the other, but not both (non R2T for the initial data out, R2T for the remaining data). Is this correct?" really? I thought thatit is permissible to have non-R2T for the initial data out and R2T for remaining. i.e for a 64K transfer, the first 32K can be the first burst size of data and the next 32K will be solicited by the target through R2T. Am I missing something? -Deva -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 6:05 AM To: Dennis Young Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iscsi: unsolicited data question yes - julo Dennis Young Sent by: owner-ips@ece.cmu.edu 06/12/2002 06:20 AM Please respond to Dennis Young To: ips@ece.cmu.edu cc: Subject: iscsi: unsolicited data question I have a question which has been asked before, but I couldn't find a direct answer in the archive. The table on page 200 of draft 12 doesn't directly answer this question either. The first paragraph on page 36 of draft 12 says "Targets operate in either solicitied (R2T) data mode or unsolicited (non R2T) data mode." tells me that a target, at all times during a data sequence transfer, can be one or the other, but not both (non R2T for the initial data out, R2T for the remaining data). Is this correct? Thanks, Dennis ---snip from an old email dated 3/30/2001--- " Hi Julian Sorry if I'm covering old ground... Is it possible to use unsolicited data for the first burst and then request any remaining data using R2T? For example, if the target has a previously allocated buffer available (length defined by FirstBurstSize) for unsolicited data, then once the initiator has sent unsolicited data up to and including this amount then the remaining data (if any) can be requested using R2T once the target has the buffer space available. ...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail: matthewb@bri.hp.com " ------_=_NextPart_001_01C2136A.DF93ED30 Content-Type: text/html; charset="iso-8859-1"
1) I have the same doubt as Deva. i.e Solicited mode and unsolicited mode differ only with respect to the first outgoing data burst.
Unsolicited mode:
R2T is not needed only for the first outgoing data burst. The subsequent data MUST be solicited.
Solicited mode:
all data outs (including the first data out) MUST be solicited.
 
Is this correct?
 
2) As per section 9.8 and 11.10, for WRITE operations without explicit Initial R2T, the InitialR2T MUST have negotiated to NO. But as per 11.12 says that if InitialR2T=yes and ImmediateData=yes, then Immediate unsolicited data only allowed.
It looks like ambigous. Or Do I miss any other part of the spec which explains this?
 
 
Arul
 
 
 
-----Original Message-----
From: Ranganathan, Deva [mailto:Deva_Ranganathan@adaptec.com]
Sent: Thursday, June 13, 2002 6:59 PM
To: 'Julian Satran'
Cc: ips@ece.cmu.edu
Subject: RE: iscsi: unsolicited data question

"tells me that a target, at all times during a data sequence transfer, can be

one or the other, but not both (non R2T for the initial data out, R2T for
the
remaining data).  Is this correct?"
 
really? I thought thatit is permissible to have non-R2T for the initial data out and R2T for
remaining. i.e for a 64K transfer, the first 32K can be the first burst size of data and
the next 32K will be solicited by the target through R2T. Am I missing something?
 

-Deva
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 12, 2002 6:05 AM
To: Dennis Young
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iscsi: unsolicited data question


yes - julo


Dennis Young <dyoung@rhapsodynetworks.com>
Sent by: owner-ips@ece.cmu.edu

06/12/2002 06:20 AM
Please respond to Dennis Young

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iscsi: unsolicited data question

       


I have a question which has been asked before, but I couldn't find a direct
answer in the archive.  The table on page 200 of draft 12 doesn't directly
answer this question either.

The first paragraph on page 36 of draft 12 says "Targets operate in either
solicitied (R2T) data mode or unsolicited (non R2T) data mode."
tells me that a target, at all times during a data sequence transfer, can be

one or the other, but not both (non R2T for the initial data out, R2T for
the
remaining data).  Is this correct?

Thanks,
Dennis

---snip from an old email dated 3/30/2001---

" Hi Julian
Sorry if I'm covering old ground... Is it possible to use unsolicited data
for the first burst and then request any remaining data using R2T? For
example, if the target has a previously allocated buffer available (length
defined by FirstBurstSize) for unsolicited data, then once the initiator has
sent unsolicited data up to and including this amount then the remaining
data (if any) can be requested using R2T once the target has the buffer
space available.
...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail:
matthewb@bri.hp.com "




------_=_NextPart_001_01C2136A.DF93ED30-- From owner-ips@ece.cmu.edu Fri Jun 14 04:46:08 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23060 for ; Fri, 14 Jun 2002 04:46:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5E8SE721526 for ips-outgoing; Fri, 14 Jun 2002 04:28:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mercury.corp.iready.com ([65.115.68.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5E8SCw21521 for ; Fri, 14 Jun 2002 04:28:12 -0400 (EDT) Received: by mercury.corp.iready.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 01:12:00 -0700 Message-ID: <034670D62D19D31180990090277A37B701FCA1D7@mercury.corp.iready.com> From: Arul Ponnusamy To: "'Karthik Selvan'" , Arul Ponnusamy , "'Ranganathan, Deva'" , "'Julian Satran'" Cc: ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Date: Fri, 14 Jun 2002 01:11:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2137B.240A5FC0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2137B.240A5FC0 Content-Type: text/plain; charset="iso-8859-1" Draft Section 11.12 clearly says that "If ImmediateData is set to Yes and InitialR2t is to Yes(default), then only immediate data are accepted in the first burst." So it is not ambigous. (The word "immediate data" makes the difference) [Arul Ponnusamy] I think "immediate data" implies that it is unsolicited. Infact the table in the section 11.12 says explicitly "Immediate unsolicited data only". -----Original Message----- From: Karthik Selvan [mailto:kselvan@marantinetworks.com] Sent: Friday, June 14, 2002 12:46 AM To: 'Arul Ponnusamy'; 'Ranganathan, Deva'; 'Julian Satran' Cc: ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Hi, 1) I have the same doubt as Deva. i.e Solicited mode and unsolicited mode differ only with respect to the first outgoing data burst. Unsolicited mode: R2T is not needed only for the first outgoing data burst. The subsequent data MUST be solicited. Solicited mode: all data outs (including the first data out) MUST be solicited. Is this correct? Yes 2) As per section 9.8 and 11.10, for WRITE operations without explicit Initial R2T, the InitialR2T MUST have negotiated to NO. yes But as per 11.12 says that if InitialR2T=yes and ImmediateData=yes, then Immediate unsolicited data only allowed. Draft Section 11.2 clearly says that "If ImmediateData is set to Yes and InitialR2t is to Yes(default), then only immediate data are accepted in the first burst." So it is not ambigous. (The word "immediate data" makes the difference) Please refer previous postings in the mailing list. You can get detailed answers. Hope this helps karthik selvan -----Original Message----- From: Ranganathan, Deva [mailto:Deva_Ranganathan@adaptec.com] Sent: Thursday, June 13, 2002 6:59 PM To: 'Julian Satran' Cc: ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question "tells me that a target, at all times during a data sequence transfer, can be one or the other, but not both (non R2T for the initial data out, R2T for the remaining data). Is this correct?" really? I thought thatit is permissible to have non-R2T for the initial data out and R2T for remaining. i.e for a 64K transfer, the first 32K can be the first burst size of data and the next 32K will be solicited by the target through R2T. Am I missing something? -Deva -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 6:05 AM To: Dennis Young Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iscsi: unsolicited data question yes - julo Dennis Young Sent by: owner-ips@ece.cmu.edu 06/12/2002 06:20 AM Please respond to Dennis Young To: ips@ece.cmu.edu cc: Subject: iscsi: unsolicited data question I have a question which has been asked before, but I couldn't find a direct answer in the archive. The table on page 200 of draft 12 doesn't directly answer this question either. The first paragraph on page 36 of draft 12 says "Targets operate in either solicitied (R2T) data mode or unsolicited (non R2T) data mode." tells me that a target, at all times during a data sequence transfer, can be one or the other, but not both (non R2T for the initial data out, R2T for the remaining data). Is this correct? Thanks, Dennis ---snip from an old email dated 3/30/2001--- " Hi Julian Sorry if I'm covering old ground... Is it possible to use unsolicited data for the first burst and then request any remaining data using R2T? For example, if the target has a previously allocated buffer available (length defined by FirstBurstSize) for unsolicited data, then once the initiator has sent unsolicited data up to and including this amount then the remaining data (if any) can be requested using R2T once the target has the buffer space available. ...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail: matthewb@bri.hp.com " ------_=_NextPart_001_01C2137B.240A5FC0 Content-Type: text/html; charset="iso-8859-1" Message
<karthik> Draft Section 11.12 clearly says that 
"If ImmediateData is set to Yes and InitialR2t is to Yes(default), then only immediate data are accepted in the first burst."
 
 So it is not  ambigous.  (The word "immediate data" makes the difference) 
 
[Arul Ponnusamy] I think "immediate data" implies that it is unsolicited.  Infact the table in the section 11.12 says explicitly "Immediate unsolicited data only".

 
 -----Original Message-----
From: Karthik Selvan [mailto:kselvan@marantinetworks.com]
Sent: Friday, June 14, 2002 12:46 AM
To: 'Arul Ponnusamy'; 'Ranganathan, Deva'; 'Julian Satran'
Cc: ips@ece.cmu.edu
Subject: RE: iscsi: unsolicited data question

 
 
Hi,
        1) I have the same doubt as Deva. i.e Solicited mode and unsolicited mode differ only with respect to the first outgoing data burst.
Unsolicited mode:
R2T is not needed only for the first outgoing data burst. The subsequent data MUST be solicited.
Solicited mode:
all data outs (including the first data out) MUST be solicited.
 
Is this correct? 
 
<karthik>Yes 
 
2) As per section 9.8 and 11.10, for WRITE operations without explicit Initial R2T, the InitialR2T MUST have negotiated to NO.  
 
  <karthik> yes
 
 But as per 11.12 says that if InitialR2T=yes and ImmediateData=yes, then Immediate unsolicited data only allowed.  
 
<karthik> Draft Section 11.2 clearly says that 
"If ImmediateData is set to Yes and InitialR2t is to Yes(default), then only immediate data are accepted in the first burst."
 
 So it is not  ambigous.  (The word "immediate data" makes the difference) 
Please refer previous postings in the mailing list. You can get detailed answers.
 
Hope this helps
karthik selvan
 
 
-----Original Message-----
From: Ranganathan, Deva [mailto:Deva_Ranganathan@adaptec.com]
Sent: Thursday, June 13, 2002 6:59 PM
To: 'Julian Satran'
Cc: ips@ece.cmu.edu
Subject: RE: iscsi: unsolicited data question

"tells me that a target, at all times during a data sequence transfer, can be

one or the other, but not both (non R2T for the initial data out, R2T for
the
remaining data).  Is this correct?"
 
really? I thought thatit is permissible to have non-R2T for the initial data out and R2T for
remaining. i.e for a 64K transfer, the first 32K can be the first burst size of data and
the next 32K will be solicited by the target through R2T. Am I missing something?
 

-Deva
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 12, 2002 6:05 AM
To: Dennis Young
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iscsi: unsolicited data question


yes - julo


Dennis Young <dyoung@rhapsodynetworks.com>
Sent by: owner-ips@ece.cmu.edu

06/12/2002 06:20 AM
Please respond to Dennis Young

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iscsi: unsolicited data question

       


I have a question which has been asked before, but I couldn't find a direct
answer in the archive.  The table on page 200 of draft 12 doesn't directly
answer this question either.

The first paragraph on page 36 of draft 12 says "Targets operate in either
solicitied (R2T) data mode or unsolicited (non R2T) data mode."
tells me that a target, at all times during a data sequence transfer, can be

one or the other, but not both (non R2T for the initial data out, R2T for
the
remaining data).  Is this correct?

Thanks,
Dennis

---snip from an old email dated 3/30/2001---

" Hi Julian
Sorry if I'm covering old ground... Is it possible to use unsolicited data
for the first burst and then request any remaining data using R2T? For
example, if the target has a previously allocated buffer available (length
defined by FirstBurstSize) for unsolicited data, then once the initiator has
sent unsolicited data up to and including this amount then the remaining
data (if any) can be requested using R2T once the target has the buffer
space available.
...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail:
matthewb@bri.hp.com "




------_=_NextPart_001_01C2137B.240A5FC0-- From owner-ips@ece.cmu.edu Fri Jun 14 04:47:29 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23083 for ; Fri, 14 Jun 2002 04:47:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5E7mYt20023 for ips-outgoing; Fri, 14 Jun 2002 03:48:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from marantinetworks.com ([66.147.154.67]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5E7mWw20016 for ; Fri, 14 Jun 2002 03:48:32 -0400 (EDT) Received: from kselvan (Sonic.marantinetworks.com [66.147.154.66]) by marantinetworks.com (8.11.2/8.11.2) with ESMTP id g5E7oCh18246; Fri, 14 Jun 2002 00:50:13 -0700 From: "Karthik Selvan" To: "'Arul Ponnusamy'" , "'Ranganathan, Deva'" , "'Julian Satran'" Cc: Subject: RE: iscsi: unsolicited data question Date: Fri, 14 Jun 2002 00:45:42 -0700 Message-ID: <01c901c21377$7c5a16b0$8601a8c0@maranti.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01CA_01C2133C.CFFB3EB0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <034670D62D19D31180990090277A37B701FCA1D6@mercury.corp.iready.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_01CA_01C2133C.CFFB3EB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, 1) I have the same doubt as Deva. i.e Solicited mode and unsolicited mode differ only with respect to the first outgoing data burst. Unsolicited mode: R2T is not needed only for the first outgoing data burst. The subsequent data MUST be solicited. Solicited mode: all data outs (including the first data out) MUST be solicited. Is this correct? Yes 2) As per section 9.8 and 11.10, for WRITE operations without explicit Initial R2T, the InitialR2T MUST have negotiated to NO. yes But as per 11.12 says that if InitialR2T=yes and ImmediateData=yes, then Immediate unsolicited data only allowed. Draft Section 11.2 clearly says that "If ImmediateData is set to Yes and InitialR2t is to Yes(default), then only immediate data are accepted in the first burst." So it is not ambigous. (The word "immediate data" makes the difference) Please refer previous postings in the mailing list. You can get detailed answers. Hope this helps karthik selvan -----Original Message----- From: Ranganathan, Deva [mailto:Deva_Ranganathan@adaptec.com] Sent: Thursday, June 13, 2002 6:59 PM To: 'Julian Satran' Cc: ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question "tells me that a target, at all times during a data sequence transfer, can be one or the other, but not both (non R2T for the initial data out, R2T for the remaining data). Is this correct?" really? I thought thatit is permissible to have non-R2T for the initial data out and R2T for remaining. i.e for a 64K transfer, the first 32K can be the first burst size of data and the next 32K will be solicited by the target through R2T. Am I missing something? -Deva -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 6:05 AM To: Dennis Young Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iscsi: unsolicited data question yes - julo Dennis Young Sent by: owner-ips@ece.cmu.edu 06/12/2002 06:20 AM Please respond to Dennis Young To: ips@ece.cmu.edu cc: Subject: iscsi: unsolicited data question I have a question which has been asked before, but I couldn't find a direct answer in the archive. The table on page 200 of draft 12 doesn't directly answer this question either. The first paragraph on page 36 of draft 12 says "Targets operate in either solicitied (R2T) data mode or unsolicited (non R2T) data mode." tells me that a target, at all times during a data sequence transfer, can be one or the other, but not both (non R2T for the initial data out, R2T for the remaining data). Is this correct? Thanks, Dennis ---snip from an old email dated 3/30/2001--- " Hi Julian Sorry if I'm covering old ground... Is it possible to use unsolicited data for the first burst and then request any remaining data using R2T? For example, if the target has a previously allocated buffer available (length defined by FirstBurstSize) for unsolicited data, then once the initiator has sent unsolicited data up to and including this amount then the remaining data (if any) can be requested using R2T once the target has the buffer space available. ...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail: matthewb@bri.hp.com " ------=_NextPart_000_01CA_01C2133C.CFFB3EB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
 
Hi,
       =  1) I=20 have the same doubt as Deva. i.e = Solicited=20 mode and unsolicited mode differ only with respect to the first outgoing = data=20 burst.
Unsolicited mode:
R2T=20 is not needed only for the first outgoing data burst. The subsequent = data MUST=20 be solicited.
Solicited mode:
all=20 data outs (including the first data out) MUST be solicited.=20
 
Is this correct? 
 
<karthik>Yes <= /FONT>
 
2) As per section 9.8 and = 11.10, for=20 WRITE operations without explicit Initial R2T, = the InitialR2T MUST=20 have negotiated to NO.  
 
  = <karthik>=20 yes
 
 But as per = 11.12 says that=20 if InitialR2T=3Dyes and ImmediateData=3Dyes, then Immediate = unsolicited=20 data only allowed.  
 
<karthik> Draft = Section 11.2=20 clearly says that 
"If ImmediateData is set to = Yes and=20 InitialR2t is to Yes(default), then only immediate data are accepted = in the=20 first burst."
 
 So = it is=20 not  ambigous.  (The word=20 "immediate data" makes the difference) 
Please refer previous postings in the = mailing list.=20 You can get detailed answers.
 
Hope=20 this helps
karthik selvan
 
 
-----Original Message-----
From: Ranganathan, = Deva=20 [mailto:Deva_Ranganathan@adaptec.com]
Sent: Thursday, June = 13,=20 2002 6:59 PM
To: 'Julian Satran'
Cc:=20 ips@ece.cmu.edu
Subject: RE: iscsi: unsolicited data=20 question

"tells me that a target, at all = times during=20 a data sequence transfer, can be

one or the other, but not = both (non=20 R2T for the initial data out, R2T for
the
remaining data). =  Is=20 this correct?"
 
really? I thought thatit is = permissible to=20 have non-R2T for the initial data out and R2T=20 for
remaining. i.e for a 64K transfer, the = first 32K=20 can be the first burst size of data=20 and
the=20 next 32K will be solicited by the target through R2T. Am I missing=20 something?
 

-Deva
 
-----Original Message-----
From: Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June = 12, 2002=20 6:05 AM
To: Dennis Young
Cc: ips@ece.cmu.edu;=20 owner-ips@ece.cmu.edu
Subject: Re: iscsi: unsolicited = data=20 question


yes -=20 julo


Dennis Young=20 <dyoung@rhapsodynetworks.com>
Sent by: = owner-ips@ece.cmu.edu=20

06/12/2002 06:20 = AM
Please respond to Dennis = Young=20

       =20
    =    =20 To:        ips@ece.cmu.edu =
        cc: =    =20    
   =20     Subject:        iscsi: = unsolicited=20 data question

   =20    


I have a question which has been = asked before,=20 but I couldn't find a direct
answer in the archive.  The = table on=20 page 200 of draft 12 doesn't directly
answer this question=20 either.

The first paragraph on page 36 of draft 12 says = "Targets=20 operate in either
solicitied (R2T) data mode or unsolicited = (non R2T)=20 data mode."
tells me that a target, at all times during a data = sequence=20 transfer, can be

one or the other, but not both (non R2T = for the=20 initial data out, R2T for
the
remaining data).  Is this = correct?

Thanks,
Dennis

---snip from an old email = dated=20 3/30/2001---

" Hi Julian
Sorry if I'm covering old = ground... Is=20 it possible to use unsolicited data
for the first burst and = then=20 request any remaining data using R2T? For
example, if the = target has a=20 previously allocated buffer available (length
defined by=20 FirstBurstSize) for unsolicited data, then once the initiator = has
sent=20 unsolicited data up to and including this amount then the=20 remaining
data (if any) can be requested using R2T once the = target has=20 the buffer
space available.
...Matthew Burbridge Hewlett = Packard,=20 Bristol Telnet: 312 7010 E-mail:
matthewb@bri.hp.com=20 = "




------=_NextPart_000_01CA_01C2133C.CFFB3EB0-- From owner-ips@ece.cmu.edu Fri Jun 14 04:47:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23098 for ; Fri, 14 Jun 2002 04:47:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5E8P5c21411 for ips-outgoing; Fri, 14 Jun 2002 04:25:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from marantinetworks.com ([66.147.154.67]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5E8P3w21406 for ; Fri, 14 Jun 2002 04:25:03 -0400 (EDT) Received: from kselvan (Sonic.marantinetworks.com [66.147.154.66]) by marantinetworks.com (8.11.2/8.11.2) with ESMTP id g5E8Qth19062; Fri, 14 Jun 2002 01:26:55 -0700 From: "Karthik Selvan" To: "'Arul Ponnusamy'" , "'Ranganathan, Deva'" , "'Julian Satran'" Cc: Subject: RE: iscsi: unsolicited data question Date: Fri, 14 Jun 2002 01:22:25 -0700 Message-ID: <01d501c2137c$9d46f1e0$8601a8c0@maranti.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01D6_01C21341.F0E819E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <034670D62D19D31180990090277A37B701FCA1D7@mercury.corp.iready.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_01D6_01C21341.F0E819E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, 1) In draft 12.98, Page no : 215, line 14 says "If ImmediateData is set to Yes and InitialR2t is to Yes(default), then only immediate data are accepted in the first burst." 2) Page 216 table uses "Immediate unsolicited data only". 3) whenever there is a difference between text and the table in std. documents, we have to follow the text. 4) Julo may solve this in next draft or he may clarify more in the mailing list. Hope this helps karthik selvan -----Original Message----- From: Arul Ponnusamy [mailto:aponnusamy@corp.iready.com] Sent: Friday, June 14, 2002 1:12 AM To: 'Karthik Selvan'; Arul Ponnusamy; 'Ranganathan, Deva'; 'Julian Satran' Cc: ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Draft Section 11.12 clearly says that "If ImmediateData is set to Yes and InitialR2t is to Yes(default), then only immediate data are accepted in the first burst." So it is not ambigous. (The word "immediate data" makes the difference) [Arul Ponnusamy] I think "immediate data" implies that it is unsolicited. Infact the table in the section 11.12 says explicitly "Immediate unsolicited data only". -----Original Message----- From: Karthik Selvan [mailto:kselvan@marantinetworks.com] Sent: Friday, June 14, 2002 12:46 AM To: 'Arul Ponnusamy'; 'Ranganathan, Deva'; 'Julian Satran' Cc: ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Hi, 1) I have the same doubt as Deva. i.e Solicited mode and unsolicited mode differ only with respect to the first outgoing data burst. Unsolicited mode: R2T is not needed only for the first outgoing data burst. The subsequent data MUST be solicited. Solicited mode: all data outs (including the first data out) MUST be solicited. Is this correct? Yes 2) As per section 9.8 and 11.10, for WRITE operations without explicit Initial R2T, the InitialR2T MUST have negotiated to NO. yes But as per 11.12 says that if InitialR2T=yes and ImmediateData=yes, then Immediate unsolicited data only allowed. Draft Section 11.2 clearly says that "If ImmediateData is set to Yes and InitialR2t is to Yes(default), then only immediate data are accepted in the first burst." So it is not ambigous. (The word "immediate data" makes the difference) Please refer previous postings in the mailing list. You can get detailed answers. Hope this helps karthik selvan -----Original Message----- From: Ranganathan, Deva [mailto:Deva_Ranganathan@adaptec.com] Sent: Thursday, June 13, 2002 6:59 PM To: 'Julian Satran' Cc: ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question "tells me that a target, at all times during a data sequence transfer, can be one or the other, but not both (non R2T for the initial data out, R2T for the remaining data). Is this correct?" really? I thought thatit is permissible to have non-R2T for the initial data out and R2T for remaining. i.e for a 64K transfer, the first 32K can be the first burst size of data and the next 32K will be solicited by the target through R2T. Am I missing something? -Deva -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 6:05 AM To: Dennis Young Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iscsi: unsolicited data question yes - julo Dennis Young Sent by: owner-ips@ece.cmu.edu 06/12/2002 06:20 AM Please respond to Dennis Young To: ips@ece.cmu.edu cc: Subject: iscsi: unsolicited data question I have a question which has been asked before, but I couldn't find a direct answer in the archive. The table on page 200 of draft 12 doesn't directly answer this question either. The first paragraph on page 36 of draft 12 says "Targets operate in either solicitied (R2T) data mode or unsolicited (non R2T) data mode." tells me that a target, at all times during a data sequence transfer, can be one or the other, but not both (non R2T for the initial data out, R2T for the remaining data). Is this correct? Thanks, Dennis ---snip from an old email dated 3/30/2001--- " Hi Julian Sorry if I'm covering old ground... Is it possible to use unsolicited data for the first burst and then request any remaining data using R2T? For example, if the target has a previously allocated buffer available (length defined by FirstBurstSize) for unsolicited data, then once the initiator has sent unsolicited data up to and including this amount then the remaining data (if any) can be requested using R2T once the target has the buffer space available. ...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail: matthewb@bri.hp.com " ------=_NextPart_000_01D6_01C21341.F0E819E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
Hi,
 
1) In=20 draft 12.98, Page no : 215, line 14 says
"If ImmediateData is set to Yes and = InitialR2t is to=20 Yes(default), then only immediate data are accepted in the first=20 burst."
 
2) Page 216 = table uses=20 "Immediate unsolicited data only".
 
3)  = whenever=20  there is a difference between text and the table in std. = documents, we=20 have to follow the text.
 
4)  = Julo may solve=20 this in next draft or he may clarify more in the mailing=20 list.
 
Hope this=20 helps
karthik=20 selvan
 
-----Original Message-----
From: Arul = Ponnusamy=20 [mailto:aponnusamy@corp.iready.com]
Sent: Friday, June 14, = 2002=20 1:12 AM
To: 'Karthik Selvan'; Arul Ponnusamy; 'Ranganathan, = Deva';=20 'Julian Satran'
Cc: ips@ece.cmu.edu
Subject: RE: = iscsi:=20 unsolicited data question

<karthik> Draft = Section 11.12 clearly says=20 that 
"If ImmediateData is set to = Yes and=20 InitialR2t is to Yes(default), then only immediate data are accepted = in the=20 first burst."
 
 So = it is=20 not  ambigous.  (The word=20 "immediate data" makes the=20 difference) 
 
[Arul Ponnusamy] I think "immediate data" implies that it is = unsolicited.  Infact the table in the section 11.12 says = explicitly=20 "Immediate unsolicited data=20 only".

 
 -----Original = Message-----
From: Karthik=20 Selvan [mailto:kselvan@marantinetworks.com]
Sent: Friday, = June 14,=20 2002 12:46 AM
To: 'Arul Ponnusamy'; 'Ranganathan, Deva'; = 'Julian=20 Satran'
Cc: ips@ece.cmu.edu
Subject: RE: iscsi:=20 unsolicited data question

 
 
Hi,
      =20  1) I have the same doubt as Deva. i.e Solicited mode and unsolicited mode = differ only=20 with respect to the first outgoing data burst.=20
Unsolicited mode:
R2T is not needed only for the first = outgoing=20 data burst. The subsequent data MUST be = solicited.
Solicited mode:
all data outs (including the first data = out) MUST=20 be solicited.
 
Is this correct? 
 
<karthik>Yes <= /FONT>
 
2) As per section 9.8 and=20 11.10, for WRITE operations without explicit Initial R2T,=20 the InitialR2T MUST have negotiated to NO.  
 
  = <karthik> yes
 
 But=20 as per 11.12 says that if InitialR2T=3Dyes and = ImmediateData=3Dyes,=20 then Immediate unsolicited data only allowed.  
 
<karthik>=20 Draft Section 11.2 clearly says=20 that 
"If=20 ImmediateData is set to Yes and InitialR2t is to Yes(default), = then only=20 immediate data are accepted in the first=20 burst."
 
 So=20 it is not  ambigous.  (The word "immediate data" makes = the=20 difference) 
Please refer previous postings in the = mailing=20 list. You can get detailed answers.
 
Hope this helps
karthik selvan
 
 
-----Original Message-----
From: Ranganathan, = Deva=20 [mailto:Deva_Ranganathan@adaptec.com]
Sent: Thursday, = June 13,=20 2002 6:59 PM
To: 'Julian Satran'
Cc:=20 ips@ece.cmu.edu
Subject: RE: iscsi: unsolicited data=20 question

"tells me that a target, at = all times=20 during a data sequence transfer, can be

one or the other, = but not=20 both (non R2T for the initial data out, R2T = for
the
remaining=20 data).  Is this correct?"
 
really? I thought thatit is = permissible to=20 have non-R2T for the initial data out and R2T=20 for
remaining. i.e for a 64K transfer, = the first=20 32K can be the first burst size of data=20 and
the next 32K will be solicited by the = target=20 through R2T. Am I missing=20 something?
 

-Deva
 
-----Original Message-----
From: Julian = Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, = June 12,=20 2002 6:05 AM
To: Dennis Young
Cc: = ips@ece.cmu.edu;=20 owner-ips@ece.cmu.edu
Subject: Re: iscsi: = unsolicited data=20 question


yes -=20 julo


Dennis Young=20 <dyoung@rhapsodynetworks.com>
Sent by: = owner-ips@ece.cmu.edu=20

06/12/2002 06:20 = AM=20
Please respond to = Dennis=20 Young

      =  =20
  =    =20   To:       =  ips@ece.cmu.edu=20
    =     cc:=20        
        Subject:   =    =20  iscsi: unsolicited data question =

     =20  


I have a question which has been = asked=20 before, but I couldn't find a direct
answer in the = archive.=20  The table on page 200 of draft 12 doesn't = directly
answer=20 this question either.

The first paragraph on page 36 of = draft=20 12 says "Targets operate in either
solicitied (R2T) data = mode or=20 unsolicited (non R2T) data mode."
tells me that a target, = at all=20 times during a data sequence transfer, can be

one or = the other,=20 but not both (non R2T for the initial data out, R2T=20 for
the
remaining data).  Is this=20 correct?

Thanks,
Dennis

---snip from an old = email=20 dated 3/30/2001---

" Hi Julian
Sorry if I'm = covering old=20 ground... Is it possible to use unsolicited data
for the = first=20 burst and then request any remaining data using R2T? = For
example,=20 if the target has a previously allocated buffer available=20 (length
defined by FirstBurstSize) for unsolicited data, = then once=20 the initiator has
sent unsolicited data up to and including = this=20 amount then the remaining
data (if any) can be requested = using R2T=20 once the target has the buffer
space available. =
...Matthew=20 Burbridge Hewlett Packard, Bristol Telnet: 312 7010=20 E-mail:
matthewb@bri.hp.com=20 = "




------=_NextPart_000_01D6_01C21341.F0E819E0-- From owner-ips@ece.cmu.edu Fri Jun 14 04:47:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23084 for ; Fri, 14 Jun 2002 04:47:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5E8DOp20969 for ips-outgoing; Fri, 14 Jun 2002 04:13:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from marantinetworks.com ([66.147.154.67]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5E8DLw20964 for ; Fri, 14 Jun 2002 04:13:21 -0400 (EDT) Received: from kselvan (Sonic.marantinetworks.com [66.147.154.66]) by marantinetworks.com (8.11.2/8.11.2) with ESMTP id g5E8FUh18817; Fri, 14 Jun 2002 01:15:30 -0700 From: "Karthik Selvan" To: "'Ranganathan, Deva'" , "'Julian Satran'" Cc: Subject: RE: iscsi: unsolicited data question Date: Fri, 14 Jun 2002 01:10:59 -0700 Message-ID: <01ce01c2137b$04c9bbb0$8601a8c0@maranti.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01CF_01C21340.586AE3B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_01CF_01C21340.586AE3B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi really? I thought thatit is permissible to have non-R2T for the initial data out and R2T for remaining. i.e for a 64K transfer, the first 32K can be the first burst size of data and the next 32K will be solicited by the target through R2T. Am I missing something? when we are doing first 32k, we are operating in unsolicited mode. For next 32k we are operating in solicited mode. So we are not operating at both the mode at the same time. For first 32k unsolicited mode we have to make sure that InitialR2T=no and 32k = min(FirstBurstSize,Expected DataTransferLength) Hope this helps karthik selvan -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 6:05 AM To: Dennis Young Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iscsi: unsolicited data question yes - julo Dennis Young Sent by: owner-ips@ece.cmu.edu 06/12/2002 06:20 AM Please respond to Dennis Young To: ips@ece.cmu.edu cc: Subject: iscsi: unsolicited data question I have a question which has been asked before, but I couldn't find a direct answer in the archive. The table on page 200 of draft 12 doesn't directly answer this question either. The first paragraph on page 36 of draft 12 says "Targets operate in either solicitied (R2T) data mode or unsolicited (non R2T) data mode." tells me that a target, at all times during a data sequence transfer, can be one or the other, but not both (non R2T for the initial data out, R2T for the remaining data). Is this correct? Thanks, Dennis ---snip from an old email dated 3/30/2001--- " Hi Julian Sorry if I'm covering old ground... Is it possible to use unsolicited data for the first burst and then request any remaining data using R2T? For example, if the target has a previously allocated buffer available (length defined by FirstBurstSize) for unsolicited data, then once the initiator has sent unsolicited data up to and including this amount then the remaining data (if any) can be requested using R2T once the target has the buffer space available. ...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail: matthewb@bri.hp.com " ------=_NextPart_000_01CF_01C21340.586AE3B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
Hi
 
 
really?=20 I thought thatit is permissible to have non-R2T for the initial = data out=20 and R2T for
remaining. i.e for a 64K transfer, the = first 32K can=20 be the first burst size of data = and
the next=20 32K will be solicited by the target through R2T. Am I missing=20 something?
 
 <karthik>=20 when we are doing first 32k, we are operating in unsolicited mode. For = next=20 32k we are operating in solicited=20 mode.
So we are not = operating at both=20 the mode at the same time. For first 32k unsolicited mode we have to = make sure=20 that InitialR2T=3Dno and 32k =3D min(FirstBurstSize,Expected=20 DataTransferLength) 
 
Hope this=20 helps
karthik=20 selvan 

-----Original Message-----
From: Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June = 12, 2002=20 6:05 AM
To: Dennis Young
Cc: ips@ece.cmu.edu;=20 owner-ips@ece.cmu.edu
Subject: Re: iscsi: unsolicited data = question


yes -=20 julo


Dennis Young=20 <dyoung@rhapsodynetworks.com>
Sent by: = owner-ips@ece.cmu.edu=20

06/12/2002 06:20 AM =
Please respond to Dennis = Young

       =20
    =    =20 To:        ips@ece.cmu.edu =
        cc: =    =20    
   =20     Subject:        iscsi: = unsolicited=20 data question

   =20    


I have a question which has been asked = before, but=20 I couldn't find a direct
answer in the archive.  The table = on page=20 200 of draft 12 doesn't directly
answer this question = either.

The=20 first paragraph on page 36 of draft 12 says "Targets operate in = either=20
solicitied (R2T) data mode or unsolicited (non R2T) data = mode."
tells=20 me that a target, at all times during a data sequence transfer, can=20 be

one or the other, but not both (non R2T for the initial = data out,=20 R2T for
the
remaining data).  Is this=20 correct?

Thanks,
Dennis

---snip from an old email = dated=20 3/30/2001---

" Hi Julian
Sorry if I'm covering old = ground... Is=20 it possible to use unsolicited data
for the first burst and then = request=20 any remaining data using R2T? For
example, if the target has a = previously=20 allocated buffer available (length
defined by FirstBurstSize) for = unsolicited data, then once the initiator has
sent unsolicited = data up to=20 and including this amount then the remaining
data (if any) can be = requested using R2T once the target has the buffer
space = available.=20
...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010=20 E-mail:
matthewb@bri.hp.com=20 "




------=_NextPart_000_01CF_01C21340.586AE3B0-- From owner-ips@ece.cmu.edu Fri Jun 14 05:40:39 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23548 for ; Fri, 14 Jun 2002 05:40:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5E8xWe22635 for ips-outgoing; Fri, 14 Jun 2002 04:59:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from marantinetworks.com ([66.147.154.67]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5E8xUw22631 for ; Fri, 14 Jun 2002 04:59:30 -0400 (EDT) Received: from kselvan (Sonic.marantinetworks.com [66.147.154.66]) by marantinetworks.com (8.11.2/8.11.2) with ESMTP id g5E91Lh19864; Fri, 14 Jun 2002 02:01:21 -0700 From: "Karthik Selvan" To: "'BURBRIDGE,MATTHEW \(HP-UnitedKingdom,ex2\)'" , "'Arul Ponnusamy'" , "'Ranganathan, Deva'" , "'Julian Satran'" Cc: Subject: RE: iscsi: unsolicited data question Date: Fri, 14 Jun 2002 01:56:50 -0700 Message-ID: <01e201c21381$6c659220$8601a8c0@maranti.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <0B9A57FF1D57D411B47500D0B73E5CC104FF1FE3@dickens.bri.hp.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, 1) Your table looks great. Thanks Karthik selvan Hi all, There are two forms of unsolicited data: "Immediate Data" and "Unsolicited Data Out PDUs". The text in section 11.12 is correct and is backed up by the table. However, the table may be improved my changing it thus: +----------+-------------+------------------+--------------+ |InitialR2T|ImmediateData|Accept Unsolicited| Accept | | | | Data Out PDUs |Immediate Data| +----------+-------------+------------------+--------------+ | No | No | Yes | No | +----------+-------------+------------------+--------------+ | No | Yes | Yes | Yes | +----------+-------------+------------------+--------------+ | Yes | No | No | No | +----------+-------------+------------------+--------------+ | Yes | Yes | No | Yes | +----------+-------------+------------------+--------------+ Cheers Matthew Burbridge -----Original Message----- From: Karthik Selvan [mailto:kselvan@marantinetworks.com] Sent: Friday, June 14, 2002 9:22 AM To: 'Arul Ponnusamy'; 'Ranganathan, Deva'; 'Julian Satran' Cc: ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Hi, 1) In draft 12.98, Page no : 215, line 14 says "If ImmediateData is set to Yes and InitialR2t is to Yes(default), then only immediate data are accepted in the first burst." 2) Page 216 table uses "Immediate unsolicited data only". 3) whenever there is a difference between text and the table in std. documents, we have to follow the text. 4) Julo may solve this in next draft or he may clarify more in the mailing list. Hope this helps karthik selvan -----Original Message----- From: Arul Ponnusamy [mailto:aponnusamy@corp.iready.com] Sent: Friday, June 14, 2002 1:12 AM To: 'Karthik Selvan'; Arul Ponnusamy; 'Ranganathan, Deva'; 'Julian Satran' Cc: ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Draft Section 11.12 clearly says that "If ImmediateData is set to Yes and InitialR2t is to Yes(default), then only immediate data are accepted in the first burst." So it is not ambigous. (The word "immediate data" makes the difference) [Arul Ponnusamy] I think "immediate data" implies that it is unsolicited. Infact the table in the section 11.12 says explicitly "Immediate unsolicited data only". -----Original Message----- From: Karthik Selvan [mailto:kselvan@marantinetworks.com] Sent: Friday, June 14, 2002 12:46 AM To: 'Arul Ponnusamy'; 'Ranganathan, Deva'; 'Julian Satran' Cc: ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Hi, 1) I have the same doubt as Deva. i.e Solicited mode and unsolicited mode differ only with respect to the first outgoing data burst. Unsolicited mode: R2T is not needed only for the first outgoing data burst. The subsequent data MUST be solicited. Solicited mode: all data outs (including the first data out) MUST be solicited. Is this correct? Yes 2) As per section 9.8 and 11.10, for WRITE operations without explicit Initial R2T, the InitialR2T MUST have negotiated to NO. yes But as per 11.12 says that if InitialR2T=yes and ImmediateData=yes, then Immediate unsolicited data only allowed. Draft Section 11.2 clearly says that "If ImmediateData is set to Yes and InitialR2t is to Yes(default), then only immediate data are accepted in the first burst." So it is not ambigous. (The word "immediate data" makes the difference) Please refer previous postings in the mailing list. You can get detailed answers. Hope this helps karthik selvan -----Original Message----- From: Ranganathan, Deva [mailto:Deva_Ranganathan@adaptec.com] Sent: Thursday, June 13, 2002 6:59 PM To: 'Julian Satran' Cc: ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question "tells me that a target, at all times during a data sequence transfer, can be one or the other, but not both (non R2T for the initial data out, R2T for the remaining data). Is this correct?" really? I thought thatit is permissible to have non-R2T for the initial data out and R2T for remaining. i.e for a 64K transfer, the first 32K can be the first burst size of data and the next 32K will be solicited by the target through R2T. Am I missing something? -Deva -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 6:05 AM To: Dennis Young Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iscsi: unsolicited data question yes - julo Dennis Young Sent by: owner-ips@ece.cmu.edu 06/12/2002 06:20 AM Please respond to Dennis Young To: ips@ece.cmu.edu cc: Subject: iscsi: unsolicited data question I have a question which has been asked before, but I couldn't find a direct answer in the archive. The table on page 200 of draft 12 doesn't directly answer this question either. The first paragraph on page 36 of draft 12 says "Targets operate in either solicitied (R2T) data mode or unsolicited (non R2T) data mode." tells me that a target, at all times during a data sequence transfer, can be one or the other, but not both (non R2T for the initial data out, R2T for the remaining data). Is this correct? Thanks, Dennis ---snip from an old email dated 3/30/2001--- " Hi Julian Sorry if I'm covering old ground... Is it possible to use unsolicited data for the first burst and then request any remaining data using R2T? For example, if the target has a previously allocated buffer available (length defined by FirstBurstSize) for unsolicited data, then once the initiator has sent unsolicited data up to and including this amount then the remaining data (if any) can be requested using R2T once the target has the buffer space available. ...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail: matthewb@bri.hp.com " From owner-ips@ece.cmu.edu Fri Jun 14 05:46:17 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23599 for ; Fri, 14 Jun 2002 05:46:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5E8rTZ22408 for ips-outgoing; Fri, 14 Jun 2002 04:53:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5E8rRw22403 for ; Fri, 14 Jun 2002 04:53:27 -0400 (EDT) Received: from fowey.BR.ITC.HP.COM (fowey.br.itc.hp.com [15.145.8.186]) by bramg1.net.external.hp.com (Postfix) with SMTP id 73C8EAD; Fri, 14 Jun 2002 10:53:26 +0200 (METDST) Received: from 15.145.8.186 by fowey.BR.ITC.HP.COM (InterScan E-Mail VirusWall NT); Fri, 14 Jun 2002 09:53:26 +0100 (GMT Daylight Time) Received: by fowey.br.itc.hp.com with Internet Mail Service (5.5.2655.55) id ; Fri, 14 Jun 2002 09:53:26 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC104FF1FE3@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'Karthik Selvan'" , "'Arul Ponnusamy'" , "'Ranganathan, Deva'" , "'Julian Satran'" Cc: ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Date: Fri, 14 Jun 2002 09:53:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi all, There are two forms of unsolicited data: "Immediate Data" and "Unsolicited Data Out PDUs". The text in section 11.12 is correct and is backed up by the table. However, the table may be improved my changing it thus: +----------+-------------+------------------+--------------+ |InitialR2T|ImmediateData|Accept Unsolicited| Accept | | | | Data Out PDUs |Immediate Data| +----------+-------------+------------------+--------------+ | No | No | Yes | No | +----------+-------------+------------------+--------------+ | No | Yes | Yes | Yes | +----------+-------------+------------------+--------------+ | Yes | No | No | No | +----------+-------------+------------------+--------------+ | Yes | Yes | No | Yes | +----------+-------------+------------------+--------------+ Cheers Matthew Burbridge -----Original Message----- From: Karthik Selvan [mailto:kselvan@marantinetworks.com] Sent: Friday, June 14, 2002 9:22 AM To: 'Arul Ponnusamy'; 'Ranganathan, Deva'; 'Julian Satran' Cc: ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Hi, 1) In draft 12.98, Page no : 215, line 14 says "If ImmediateData is set to Yes and InitialR2t is to Yes(default), then only immediate data are accepted in the first burst." 2) Page 216 table uses "Immediate unsolicited data only". 3) whenever there is a difference between text and the table in std. documents, we have to follow the text. 4) Julo may solve this in next draft or he may clarify more in the mailing list. Hope this helps karthik selvan -----Original Message----- From: Arul Ponnusamy [mailto:aponnusamy@corp.iready.com] Sent: Friday, June 14, 2002 1:12 AM To: 'Karthik Selvan'; Arul Ponnusamy; 'Ranganathan, Deva'; 'Julian Satran' Cc: ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Draft Section 11.12 clearly says that "If ImmediateData is set to Yes and InitialR2t is to Yes(default), then only immediate data are accepted in the first burst." So it is not ambigous. (The word "immediate data" makes the difference) [Arul Ponnusamy] I think "immediate data" implies that it is unsolicited. Infact the table in the section 11.12 says explicitly "Immediate unsolicited data only". -----Original Message----- From: Karthik Selvan [mailto:kselvan@marantinetworks.com] Sent: Friday, June 14, 2002 12:46 AM To: 'Arul Ponnusamy'; 'Ranganathan, Deva'; 'Julian Satran' Cc: ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Hi, 1) I have the same doubt as Deva. i.e Solicited mode and unsolicited mode differ only with respect to the first outgoing data burst. Unsolicited mode: R2T is not needed only for the first outgoing data burst. The subsequent data MUST be solicited. Solicited mode: all data outs (including the first data out) MUST be solicited. Is this correct? Yes 2) As per section 9.8 and 11.10, for WRITE operations without explicit Initial R2T, the InitialR2T MUST have negotiated to NO. yes But as per 11.12 says that if InitialR2T=yes and ImmediateData=yes, then Immediate unsolicited data only allowed. Draft Section 11.2 clearly says that "If ImmediateData is set to Yes and InitialR2t is to Yes(default), then only immediate data are accepted in the first burst." So it is not ambigous. (The word "immediate data" makes the difference) Please refer previous postings in the mailing list. You can get detailed answers. Hope this helps karthik selvan -----Original Message----- From: Ranganathan, Deva [mailto:Deva_Ranganathan@adaptec.com] Sent: Thursday, June 13, 2002 6:59 PM To: 'Julian Satran' Cc: ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question "tells me that a target, at all times during a data sequence transfer, can be one or the other, but not both (non R2T for the initial data out, R2T for the remaining data). Is this correct?" really? I thought thatit is permissible to have non-R2T for the initial data out and R2T for remaining. i.e for a 64K transfer, the first 32K can be the first burst size of data and the next 32K will be solicited by the target through R2T. Am I missing something? -Deva -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 6:05 AM To: Dennis Young Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iscsi: unsolicited data question yes - julo Dennis Young Sent by: owner-ips@ece.cmu.edu 06/12/2002 06:20 AM Please respond to Dennis Young To: ips@ece.cmu.edu cc: Subject: iscsi: unsolicited data question I have a question which has been asked before, but I couldn't find a direct answer in the archive. The table on page 200 of draft 12 doesn't directly answer this question either. The first paragraph on page 36 of draft 12 says "Targets operate in either solicitied (R2T) data mode or unsolicited (non R2T) data mode." tells me that a target, at all times during a data sequence transfer, can be one or the other, but not both (non R2T for the initial data out, R2T for the remaining data). Is this correct? Thanks, Dennis ---snip from an old email dated 3/30/2001--- " Hi Julian Sorry if I'm covering old ground... Is it possible to use unsolicited data for the first burst and then request any remaining data using R2T? For example, if the target has a previously allocated buffer available (length defined by FirstBurstSize) for unsolicited data, then once the initiator has sent unsolicited data up to and including this amount then the remaining data (if any) can be requested using R2T once the target has the buffer space available. ...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail: matthewb@bri.hp.com " From owner-ips@ece.cmu.edu Fri Jun 14 06:31:08 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23972 for ; Fri, 14 Jun 2002 06:31:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5E9g4S05473 for ips-outgoing; Fri, 14 Jun 2002 05:42:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hclnpd.hclt.co.in ([202.54.64.7]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5E9g2w05467 for ; Fri, 14 Jun 2002 05:42:02 -0400 (EDT) Received: from mailnpd.hclt-ntl.co.in ([192.168.19.36]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MR124A02; Fri, 14 Jun 2002 15:11:09 +0530 Received: from priya-pc.hclt-ntl.co.in (priya-pc.hclt-ntl.co.in [192.168.19.88]) by mailnpd.hclt-ntl.co.in (8.11.0/8.11.0) with SMTP id g5E9YFL30789; Fri, 14 Jun 2002 15:04:15 +0530 Content-Type: text/plain; charset="iso-8859-1" From: Priya Viswambharan To: Arul Ponnusamy , "'Karthik Selvan'" , Arul Ponnusamy , "'Ranganathan, Deva'" , "'Julian Satran'" Subject: Re: iscsi: unsolicited data question Date: Fri, 14 Jun 2002 15:08:43 +0530 X-Mailer: KMail [version 1.2] Cc: ips@ece.cmu.edu References: <034670D62D19D31180990090277A37B701FCA1D7@mercury.corp.iready.com> In-Reply-To: <034670D62D19D31180990090277A37B701FCA1D7@mercury.corp.iready.com> MIME-Version: 1.0 Message-Id: <02061415084312.01202@priya-pc.hclt-ntl.co.in> Content-Transfer-Encoding: 8bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi Arul, Unsolicited data can be sent as immediate data or through DATA OUT PDUs or both depending on the negotiation done. "Immediate unsolicited data only" means that if there is unsolicited data to be sent, it can be sent only as immediate data - DATA OUT PDUs or combination of immediate data and DATA Out for unsolicited data is disallowed in this case. Thanks Priya > > [Arul Ponnusamy] I think "immediate data" implies that it > is unsolicited. Infact the table in the section 11.12 > says explicitly "Immediate unsolicited data only". > > > -----Original Message----- > From: Karthik Selvan [mailto:kselvan@marantinetworks.com] > Sent: Friday, June 14, 2002 12:46 AM > To: 'Arul Ponnusamy'; 'Ranganathan, Deva'; 'Julian > Satran' Cc: ips@ece.cmu.edu > Subject: RE: iscsi: unsolicited data question > > > > > > Hi, > 1) I have the same doubt as Deva. i.e Solicited > mode and unsolicited mode differ only with respect to the > first outgoing data burst. > > Unsolicited mode: > R2T is not needed only for the first outgoing data burst. > The subsequent data MUST be solicited. > Solicited mode: > all data outs (including the first data out) MUST be > solicited. > > Is this correct? > > Yes > > 2) As per section 9.8 and 11.10, for WRITE operations > without explicit Initial R2T, the InitialR2T MUST have > negotiated to NO. > > yes > > But as per 11.12 says that if InitialR2T=yes and > ImmediateData=yes, then Immediate unsolicited data only > allowed. > > Draft Section 11.2 clearly says that > "If ImmediateData is set to Yes and InitialR2t is to > Yes(default), then only immediate data are accepted in > the first burst." > > So it is not ambigous. (The word "immediate data" > makes the difference) Please refer previous postings in > the mailing list. You can get detailed answers. > > Hope this helps > karthik selvan > > > > -----Original Message----- > From: Ranganathan, Deva > [mailto:Deva_Ranganathan@adaptec.com] Sent: Thursday, > June 13, 2002 6:59 PM > To: 'Julian Satran' > Cc: ips@ece.cmu.edu > Subject: RE: iscsi: unsolicited data question > > > "tells me that a target, at all times during a data > sequence transfer, can be > > one or the other, but not both (non R2T for the initial > data out, R2T for the > remaining data). Is this correct?" > > really? I thought thatit is permissible to have non-R2T > for the initial data out and R2T for > remaining. i.e for a 64K transfer, the first 32K can be > the first burst size of data and > the next 32K will be solicited by the target through R2T. > Am I missing something? > > > -Deva > > > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Wednesday, June 12, 2002 6:05 AM > To: Dennis Young > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu > Subject: Re: iscsi: unsolicited data question > > > > yes - julo > > > > Dennis Young > Sent by: owner-ips@ece.cmu.edu > > > 06/12/2002 06:20 AM > Please respond to Dennis Young > > > > To: ips@ece.cmu.edu > cc: > Subject: iscsi: unsolicited data question > > > > > I have a question which has been asked before, but I > couldn't find a direct answer in the archive. The table > on page 200 of draft 12 doesn't directly answer this > question either. > > The first paragraph on page 36 of draft 12 says "Targets > operate in either solicitied (R2T) data mode or > unsolicited (non R2T) data mode." tells me that a target, > at all times during a data sequence transfer, can be > > one or the other, but not both (non R2T for the initial > data out, R2T for the > remaining data). Is this correct? > > Thanks, > Dennis > > ---snip from an old email dated 3/30/2001--- > > " Hi Julian > Sorry if I'm covering old ground... Is it possible to use > unsolicited data for the first burst and then request any > remaining data using R2T? For example, if the target has > a previously allocated buffer available (length defined > by FirstBurstSize) for unsolicited data, then once the > initiator has sent unsolicited data up to and including > this amount then the remaining data (if any) can be > requested using R2T once the target has the buffer space > available. > ...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 > 7010 E-mail: matthewb@bri.hp.com " ---------------------------------------- Content-Type: text/html; charset="iso-8859-1"; name="Attachment: 1" Content-Transfer-Encoding: 7bit Content-Description: ---------------------------------------- From owner-ips@ece.cmu.edu Fri Jun 14 07:55:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25644 for ; Fri, 14 Jun 2002 07:55:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5EBEio08749 for ips-outgoing; Fri, 14 Jun 2002 07:14:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hclnpd.hclt.co.in ([202.54.64.7]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5EBEgw08745 for ; Fri, 14 Jun 2002 07:14:42 -0400 (EDT) Received: from mailnpd.hclt-ntl.co.in ([192.168.19.36]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MR124BVR; Fri, 14 Jun 2002 16:43:50 +0530 Received: from nramamurpc (nramamur-pc.hclt-ntl.co.in [192.168.19.98]) by mailnpd.hclt-ntl.co.in (8.11.0/8.11.0) with SMTP id g5EB70L01719 for ; Fri, 14 Jun 2002 16:37:00 +0530 Message-ID: <007f01c21394$db603c80$6213a8c0@hcltech.com> From: "Nandakumar Ramamurthy" To: Subject: iSCSI: FirstBurstSize and unsolicited data Date: Fri, 14 Jun 2002 16:45:56 +0530 Organization: HCL Technologies Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi All, Consider the case where InitialR2T=yes and ImmediateData=yes. All other values are the defaults. The expected data transfer length for a SCSI write operation is a value exceeding FirstBurstSize (64KB). In the above case, the initiator will send immediate unsolicited data (MaxRecvPDULength=8192 bytes). After that it has to wait for an R2T from the target. In this scenario, FirstBurstSize of data will not be sent to the target as unsolicited data-out's cannot be sent here. My understanding is that the remaining data can be sent only through solicited Data-out PDUs, and this is the expected way according to the draft. What does the following statement(in Section 9.4.6.2 Sense Data) mean in this context ? The target reports the "Not enough unsolicited data" condition only if it does not support output (write) operations in which the total data length is greater than FirstBurstSize, but the initiator sent less than FirstBurstSize amount of unsolicited data, and out-of-order R2Ts cannot be used. If this is specific to the SCSI layer at the target, what is the dependency on FirstBurstSize? Please clarify. Thanks, Nandakumar Member Technical Staff HCL Technologies, Chennai, INDIA. http://san.hcltech.com From owner-ips@ece.cmu.edu Fri Jun 14 09:46:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29323 for ; Fri, 14 Jun 2002 09:46:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5EDc2o15160 for ips-outgoing; Fri, 14 Jun 2002 09:38:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5EDc0w15156 for ; Fri, 14 Jun 2002 09:38:00 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 09:37:59 -0400 Message-ID: From: Sanjay Goyal To: "'Nandakumar Ramamurthy'" , ips@ece.cmu.edu Subject: RE: iSCSI: FirstBurstSize and unsolicited data Date: Fri, 14 Jun 2002 09:37:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk The specifications says If you send any non-immediate unsolicited data-out PDUs, the total unsolicited amount of data should be FirstBurstSize amount of data. Regards Sanjay Goyal -----Original Message----- From: Nandakumar Ramamurthy [mailto:nramamur@npd.hcltech.com] Sent: Friday, June 14, 2002 7:16 AM To: ips@ece.cmu.edu Subject: iSCSI: FirstBurstSize and unsolicited data Hi All, Consider the case where InitialR2T=yes and ImmediateData=yes. All other values are the defaults. The expected data transfer length for a SCSI write operation is a value exceeding FirstBurstSize (64KB). In the above case, the initiator will send immediate unsolicited data (MaxRecvPDULength=8192 bytes). After that it has to wait for an R2T from the target. In this scenario, FirstBurstSize of data will not be sent to the target as unsolicited data-out's cannot be sent here. My understanding is that the remaining data can be sent only through solicited Data-out PDUs, and this is the expected way according to the draft. What does the following statement(in Section 9.4.6.2 Sense Data) mean in this context ? The target reports the "Not enough unsolicited data" condition only if it does not support output (write) operations in which the total data length is greater than FirstBurstSize, but the initiator sent less than FirstBurstSize amount of unsolicited data, and out-of-order R2Ts cannot be used. If this is specific to the SCSI layer at the target, what is the dependency on FirstBurstSize? Please clarify. Thanks, Nandakumar Member Technical Staff HCL Technologies, Chennai, INDIA. http://san.hcltech.com From owner-ips@ece.cmu.edu Fri Jun 14 09:50:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29454 for ; Fri, 14 Jun 2002 09:50:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5EDNRu14386 for ips-outgoing; Fri, 14 Jun 2002 09:23:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5EDNOw14381 for ; Fri, 14 Jun 2002 09:23:24 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5EDN7vh013194; Fri, 14 Jun 2002 15:23:07 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5EDN6L23706; Fri, 14 Jun 2002 15:23:06 +0200 To: "Karthik Selvan" Cc: "'Arul Ponnusamy'" , "'Ranganathan, Deva'" , ips@ece.cmu.edu, "'BURBRIDGE,MATTHEW \(HP-UnitedKingdom,ex2\)'" , owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iscsi: unsolicited data question X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 14 Jun 2002 16:23:04 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 14/06/2002 16:23:07, Serialize complete at 14/06/2002 16:23:07 Content-Type: multipart/alternative; boundary="=_alternative 0048E4E4C2256BD8_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0048E4E4C2256BD8_= Content-Type: text/plain; charset="us-ascii" OK Julo "Karthik Selvan" Sent by: owner-ips@ece.cmu.edu 06/14/2002 11:56 AM Please respond to "Karthik Selvan" To: "'BURBRIDGE,MATTHEW \(HP-UnitedKingdom,ex2\)'" , "'Arul Ponnusamy'" , "'Ranganathan, Deva'" , Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: iscsi: unsolicited data question Hi, 1) Your table looks great. Thanks Karthik selvan Hi all, There are two forms of unsolicited data: "Immediate Data" and "Unsolicited Data Out PDUs". The text in section 11.12 is correct and is backed up by the table. However, the table may be improved my changing it thus: +----------+-------------+------------------+--------------+ |InitialR2T|ImmediateData|Accept Unsolicited| Accept | | | | Data Out PDUs |Immediate Data| +----------+-------------+------------------+--------------+ | No | No | Yes | No | +----------+-------------+------------------+--------------+ | No | Yes | Yes | Yes | +----------+-------------+------------------+--------------+ | Yes | No | No | No | +----------+-------------+------------------+--------------+ | Yes | Yes | No | Yes | +----------+-------------+------------------+--------------+ Cheers Matthew Burbridge -----Original Message----- From: Karthik Selvan [mailto:kselvan@marantinetworks.com] Sent: Friday, June 14, 2002 9:22 AM To: 'Arul Ponnusamy'; 'Ranganathan, Deva'; 'Julian Satran' Cc: ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Hi, 1) In draft 12.98, Page no : 215, line 14 says "If ImmediateData is set to Yes and InitialR2t is to Yes(default), then only immediate data are accepted in the first burst." 2) Page 216 table uses "Immediate unsolicited data only". 3) whenever there is a difference between text and the table in std. documents, we have to follow the text. 4) Julo may solve this in next draft or he may clarify more in the mailing list. Hope this helps karthik selvan -----Original Message----- From: Arul Ponnusamy [mailto:aponnusamy@corp.iready.com] Sent: Friday, June 14, 2002 1:12 AM To: 'Karthik Selvan'; Arul Ponnusamy; 'Ranganathan, Deva'; 'Julian Satran' Cc: ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Draft Section 11.12 clearly says that "If ImmediateData is set to Yes and InitialR2t is to Yes(default), then only immediate data are accepted in the first burst." So it is not ambigous. (The word "immediate data" makes the difference) [Arul Ponnusamy] I think "immediate data" implies that it is unsolicited. Infact the table in the section 11.12 says explicitly "Immediate unsolicited data only". -----Original Message----- From: Karthik Selvan [mailto:kselvan@marantinetworks.com] Sent: Friday, June 14, 2002 12:46 AM To: 'Arul Ponnusamy'; 'Ranganathan, Deva'; 'Julian Satran' Cc: ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question Hi, 1) I have the same doubt as Deva. i.e Solicited mode and unsolicited mode differ only with respect to the first outgoing data burst. Unsolicited mode: R2T is not needed only for the first outgoing data burst. The subsequent data MUST be solicited. Solicited mode: all data outs (including the first data out) MUST be solicited. Is this correct? Yes 2) As per section 9.8 and 11.10, for WRITE operations without explicit Initial R2T, the InitialR2T MUST have negotiated to NO. yes But as per 11.12 says that if InitialR2T=yes and ImmediateData=yes, then Immediate unsolicited data only allowed. Draft Section 11.2 clearly says that "If ImmediateData is set to Yes and InitialR2t is to Yes(default), then only immediate data are accepted in the first burst." So it is not ambigous. (The word "immediate data" makes the difference) Please refer previous postings in the mailing list. You can get detailed answers. Hope this helps karthik selvan -----Original Message----- From: Ranganathan, Deva [mailto:Deva_Ranganathan@adaptec.com] Sent: Thursday, June 13, 2002 6:59 PM To: 'Julian Satran' Cc: ips@ece.cmu.edu Subject: RE: iscsi: unsolicited data question "tells me that a target, at all times during a data sequence transfer, can be one or the other, but not both (non R2T for the initial data out, R2T for the remaining data). Is this correct?" really? I thought thatit is permissible to have non-R2T for the initial data out and R2T for remaining. i.e for a 64K transfer, the first 32K can be the first burst size of data and the next 32K will be solicited by the target through R2T. Am I missing something? -Deva -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 12, 2002 6:05 AM To: Dennis Young Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iscsi: unsolicited data question yes - julo Dennis Young Sent by: owner-ips@ece.cmu.edu 06/12/2002 06:20 AM Please respond to Dennis Young To: ips@ece.cmu.edu cc: Subject: iscsi: unsolicited data question I have a question which has been asked before, but I couldn't find a direct answer in the archive. The table on page 200 of draft 12 doesn't directly answer this question either. The first paragraph on page 36 of draft 12 says "Targets operate in either solicitied (R2T) data mode or unsolicited (non R2T) data mode." tells me that a target, at all times during a data sequence transfer, can be one or the other, but not both (non R2T for the initial data out, R2T for the remaining data). Is this correct? Thanks, Dennis ---snip from an old email dated 3/30/2001--- " Hi Julian Sorry if I'm covering old ground... Is it possible to use unsolicited data for the first burst and then request any remaining data using R2T? For example, if the target has a previously allocated buffer available (length defined by FirstBurstSize) for unsolicited data, then once the initiator has sent unsolicited data up to and including this amount then the remaining data (if any) can be requested using R2T once the target has the buffer space available. ...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail: matthewb@bri.hp.com " --=_alternative 0048E4E4C2256BD8_= Content-Type: text/html; charset="us-ascii"
OK Julo


"Karthik Selvan" <kselvan@marantinetworks.com>
Sent by: owner-ips@ece.cmu.edu

06/14/2002 11:56 AM
Please respond to "Karthik Selvan"

       
        To:        "'BURBRIDGE,MATTHEW \(HP-UnitedKingdom,ex2\)'" <matthew_burbridge@hp.com>, "'Arul Ponnusamy'" <aponnusamy@corp.iready.com>, "'Ranganathan, Deva'" <Deva_Ranganathan@adaptec.com>, Julian Satran/Haifa/IBM@IBMIL
        cc:        <ips@ece.cmu.edu>
        Subject:        RE: iscsi: unsolicited data question

       



Hi,

1) Your table looks great.

Thanks
Karthik selvan

Hi all,

There are two forms of unsolicited data: "Immediate Data" and
"Unsolicited Data Out PDUs".

The text in section 11.12 is correct and is backed up by the table.

However, the table may be improved my changing it thus:
+----------+-------------+------------------+--------------+
|InitialR2T|ImmediateData|Accept Unsolicited|   Accept     |
|          |             |   Data Out PDUs  |Immediate Data|
+----------+-------------+------------------+--------------+
| No       | No          | Yes              | No           |
+----------+-------------+------------------+--------------+
| No       | Yes         | Yes              | Yes          |
+----------+-------------+------------------+--------------+
| Yes      | No          | No               | No           |
+----------+-------------+------------------+--------------+
| Yes      | Yes         | No               | Yes          |
+----------+-------------+------------------+--------------+

Cheers

Matthew Burbridge


-----Original Message-----
From: Karthik Selvan [mailto:kselvan@marantinetworks.com]
Sent: Friday, June 14, 2002 9:22 AM
To: 'Arul Ponnusamy'; 'Ranganathan, Deva'; 'Julian Satran'
Cc: ips@ece.cmu.edu
Subject: RE: iscsi: unsolicited data question



Hi,

1) In draft 12.98, Page no : 215, line 14 says
"If ImmediateData is set to Yes and InitialR2t is to Yes(default), then
only immediate data are accepted in the first burst."

2) Page 216 table uses "Immediate unsolicited data only".

3)  whenever  there is a difference between text and the table in std.
documents, we have to follow the text.

4)  Julo may solve this in next draft or he may clarify more in the
mailing list.

Hope this helps
karthik selvan

-----Original Message-----
From: Arul Ponnusamy [mailto:aponnusamy@corp.iready.com]
Sent: Friday, June 14, 2002 1:12 AM
To: 'Karthik Selvan'; Arul Ponnusamy; 'Ranganathan, Deva'; 'Julian
Satran'
Cc: ips@ece.cmu.edu
Subject: RE: iscsi: unsolicited data question


<karthik> Draft Section 11.12 clearly says that
"If ImmediateData is set to Yes and InitialR2t is to Yes(default), then
only immediate data are accepted in the first burst."

So it is not  ambigous.  (The word "immediate data" makes the
difference)

[Arul Ponnusamy] I think "immediate data" implies that it is
unsolicited. Infact the table in the section 11.12 says explicitly
"Immediate unsolicited data only".


-----Original Message-----
From: Karthik Selvan [mailto:kselvan@marantinetworks.com]
Sent: Friday, June 14, 2002 12:46 AM
To: 'Arul Ponnusamy'; 'Ranganathan, Deva'; 'Julian Satran'
Cc: ips@ece.cmu.edu
Subject: RE: iscsi: unsolicited data question




Hi,
       1) I have the same doubt as Deva. i.e Solicited mode and
unsolicited mode differ only with respect to the first outgoing data
burst. Unsolicited mode: R2T is not needed only for the first outgoing
data burst. The subsequent data MUST be solicited. Solicited mode: all
data outs (including the first data out) MUST be solicited.

Is this correct?

<karthik>Yes

2) As per section 9.8 and 11.10, for WRITE operations without explicit
Initial R2T, the InitialR2T MUST have negotiated to NO.

 <karthik> yes

But as per 11.12 says that if InitialR2T=yes and ImmediateData=yes,
then Immediate unsolicited data only allowed.

<karthik> Draft Section 11.2 clearly says that
"If ImmediateData is set to Yes and InitialR2t is to Yes(default), then
only immediate data are accepted in the first burst."

So it is not  ambigous.  (The word "immediate data" makes the
difference) Please refer previous postings in the mailing list. You can
get detailed answers.

Hope this helps
karthik selvan


-----Original Message-----
From: Ranganathan, Deva [mailto:Deva_Ranganathan@adaptec.com]
Sent: Thursday, June 13, 2002 6:59 PM
To: 'Julian Satran'
Cc: ips@ece.cmu.edu
Subject: RE: iscsi: unsolicited data question


"tells me that a target, at all times during a data sequence transfer,
can be

one or the other, but not both (non R2T for the initial data out, R2T
for the remaining data).  Is this correct?"

really? I thought thatit is permissible to have non-R2T for the initial
data out and R2T for remaining. i.e for a 64K transfer, the first 32K
can be the first burst size of data and the next 32K will be solicited
by the target through R2T. Am I missing something?


-Deva



-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 12, 2002 6:05 AM
To: Dennis Young
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iscsi: unsolicited data question



yes - julo


Dennis Young <dyoung@rhapsodynetworks.com>
Sent by: owner-ips@ece.cmu.edu
06/12/2002 06:20 AM
Please respond to Dennis Young
     
       To:        ips@ece.cmu.edu
       cc:        
       Subject:        iscsi: unsolicited data question

     


I have a question which has been asked before, but I couldn't find a
direct answer in the archive.  The table on page 200 of draft 12 doesn't
directly answer this question either.

The first paragraph on page 36 of draft 12 says "Targets operate in
either solicitied (R2T) data mode or unsolicited (non R2T) data mode."
tells me that a target, at all times during a data sequence transfer,
can be

one or the other, but not both (non R2T for the initial data out, R2T
for the remaining data).  Is this correct?

Thanks,
Dennis

---snip from an old email dated 3/30/2001---

" Hi Julian
Sorry if I'm covering old ground... Is it possible to use unsolicited
data for the first burst and then request any remaining data using R2T?
For example, if the target has a previously allocated buffer available
(length defined by FirstBurstSize) for unsolicited data, then once the
initiator has sent unsolicited data up to and including this amount then
the remaining data (if any) can be requested using R2T once the target
has the buffer space available. ...Matthew Burbridge Hewlett Packard,
Bristol Telnet: 312 7010 E-mail: matthewb@bri.hp.com "



--=_alternative 0048E4E4C2256BD8_=-- From owner-ips@ece.cmu.edu Fri Jun 14 09:52:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29558 for ; Fri, 14 Jun 2002 09:51:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5ED2hv13328 for ips-outgoing; Fri, 14 Jun 2002 09:02:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5ED2ew13321 for ; Fri, 14 Jun 2002 09:02:40 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5ED2U5u052088; Fri, 14 Jun 2002 15:02:30 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5ED2SN31390; Fri, 14 Jun 2002 15:02:29 +0200 To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu, luben@splentec.com, owner-ips@ece.cmu.edu Importance: High MIME-Version: 1.0 Subject: RE: iSCSI: 12-97 Bit Rule X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 14 Jun 2002 16:02:26 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 14/06/2002 16:02:29, Serialize complete at 14/06/2002 16:02:29 Content-Type: multipart/alternative; boundary="=_alternative 0046FC7AC2256BD8_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0046FC7AC2256BD8_= Content-Type: text/plain; charset="us-ascii" Excellent - we are now spending time in the Never-Endian space :-) (coined by a good friend) - I am deleting the whole thread on my mailer. If you think I should pay attention to something please change the subject line. I know ( an changed already) the remainder word. Thanks Julo pat_thaler@agilent.com Sent by: owner-ips@ece.cmu.edu 06/14/2002 02:38 AM Please respond to pat_thaler To: luben@splentec.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: 12-97 Bit Rule Luben, If I ruled the world, I would number the least significant bit 0. I agree that that is a more logical numbering. My second choice would be for the whole world to use the same numbering even if it was different from that. However, neither you nor I rule the world and IETF has chosen to number the most significant bit 0 and the choices made by other organizations vary all over the map and we get to flop and flip bits to match them to the environment. A convention that is used throughout the document (like the significance of bits within a field) belongs at the front. That convention also gets reinforced when one looks at other parts of the document like chapter 9. That is why it is satisfactory for 1.3.1 through 1.3.3 to be at the front. A detail that only applies one place like the different ordering of the bits in the CRC calculation should be in the place where it is used. That is why it wasn't good to have 11.1 reference 1.3.4 for how to order the bits in the CRC calculation. This is just good editorial practice for building a usable document. On the particular text: 8) The message sent is P and appended at the end are the bit coefficients of CRC(x), with x^31 bit coefficient first, then x^30, etc. the problem is that the x^31 bit doesn't go first when it is in the frame. Also, bits can go through their entire existence without being sent in serial order so nothing is first. Say which bit of the CRC goes into which bit of the digest field and you are done. Sincerely, Pat -----Original Message----- From: Luben Tuikov [mailto:luben@splentec.com] Sent: Thursday, June 13, 2002 4:13 PM To: pat_thaler@agilent.com Cc: Julian_Satran@il.ibm.com; ips@ece.cmu.edu Subject: Re: iSCSI: 12-97 Bit Rule pat_thaler@agilent.com wrote: > > TCP/IP Illustrated numbers bits with bit 0 as the > most significant. My books on Sonet number bits > in a byte from 1 to 8. I guess you could argue > these are not books on computer architecture, but > the point is that not everyone numbers bits the > same. Uuuh, here we go again... Yes, I can argue that those are NOT books on computer architecure. Let me get home I'll send you the titles/authors/ISBN of a few books on Computer Architecture which use the NATURAL bit ordering: 2^(x+1) > 2^x, x >= 0, so it only _makes_sense_ to say that bit x+1 is more significant than bit x. Take the number 791, is the 2rd digit more significant than the 1nd? Well: 791 = 7*10^2 + 9*10^1 + 1*10^0. > If you will read 1.3.1 through 1.3.3, they do > explicitly state the significance of bits in > iSCSI words, half-words and bytes. Yep, and you were complaining that it was 200 pages away from 11.1 where the CRC digest was --- or was that in a private email? Trying to score points? > Julian's new description is accurate and clear. Are you sure? Are you really sure? > Item 8 in your description is unclear and confusing > because the bits do not "follow" each other in the > order you state (and any viewing of bits in a message > as a serial stream is entirely hypothetical). Here is 8: 8) The message sent is P and appended at the end are the bit coefficients of CRC(x), with x^31 bit coefficient first, then x^30, etc. That is after you send P, send CRC(x) as indicated. What doesn't follow what? Of course it is hypothetical... Pat, let me ask you this: Is Mathematics hypothetical? -- Luben --=_alternative 0046FC7AC2256BD8_= Content-Type: text/html; charset="us-ascii"
Excellent - we are now spending time in the Never-Endian space :-) (coined by a good friend) - I am deleting the whole thread on my mailer.
If you think I should pay attention to something please change the subject line.  I know ( an changed already) the remainder word. Thanks

Julo


pat_thaler@agilent.com
Sent by: owner-ips@ece.cmu.edu

06/14/2002 02:38 AM
Please respond to pat_thaler

       
        To:        luben@splentec.com
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: 12-97 Bit Rule

       


Luben,

If I ruled the world, I would number the least significant bit 0. I agree
that that is a more logical numbering. My second choice would be for the
whole world to use the same numbering even if it was different from that.
However, neither you nor I rule the world and IETF has chosen to number the
most significant bit 0 and the choices made by other organizations vary all
over the map and we get to flop and flip bits to match them to the
environment.

A convention that is used throughout the document (like the significance of
bits within a field) belongs at the front. That convention also gets
reinforced when one looks at other parts of the document like chapter 9.
That is why it is satisfactory for 1.3.1 through 1.3.3 to be at the front. A
detail that only applies one place like the different ordering of the bits
in the CRC calculation should be in the place where it is used. That is why
it wasn't good to have 11.1 reference 1.3.4 for how to order the bits in the
CRC calculation. This is just good editorial practice for building a usable
document.

On the particular text:
8) The message sent is P and appended at the end are the
  bit coefficients of CRC(x), with x^31 bit coefficient
  first, then x^30, etc.
the problem is that the x^31 bit doesn't go first when it is in the frame.
Also, bits can go through their entire existence without being sent in
serial order so nothing is first. Say which bit of the CRC goes into which
bit of the digest field and you are done.

Sincerely,
Pat

-----Original Message-----
From: Luben Tuikov [mailto:luben@splentec.com]
Sent: Thursday, June 13, 2002 4:13 PM
To: pat_thaler@agilent.com
Cc: Julian_Satran@il.ibm.com; ips@ece.cmu.edu
Subject: Re: iSCSI: 12-97 Bit Rule


pat_thaler@agilent.com wrote:
>
> TCP/IP Illustrated numbers bits with bit 0 as the
> most significant. My books on Sonet number bits
> in a byte from 1 to 8. I guess you could argue
> these are not books on computer architecture, but
> the point is that not everyone numbers bits the
> same.

Uuuh, here we go again...

Yes, I can argue that those are NOT books
on computer architecure. Let me get home
I'll send you the titles/authors/ISBN
of a few books on Computer Architecture
which use the NATURAL bit ordering:

2^(x+1) > 2^x, x >= 0,
so it only _makes_sense_ to say that
bit x+1 is more significant than bit x.

Take the number 791, is the 2rd digit
more significant than the 1nd?
Well: 791 = 7*10^2 + 9*10^1 + 1*10^0.

> If you will read 1.3.1 through 1.3.3, they do
> explicitly state the significance of bits in
> iSCSI words, half-words and bytes.

Yep, and you were complaining that it was
200 pages away from 11.1 where the CRC
digest was --- or was that in a private
email? Trying to score points?

> Julian's new description is accurate and clear.

Are you sure? Are you really sure?

> Item 8 in your description is unclear and confusing
> because the bits do not "follow" each other in the
> order you state (and any viewing of bits in a message
> as a serial stream is entirely hypothetical).

Here is 8:

8) The message sent is P and appended at the end are the
  bit coefficients of CRC(x), with x^31 bit coefficient
  first, then x^30, etc.

That is after you send P, send CRC(x) as indicated.
What doesn't follow what?

Of course it is hypothetical...

Pat, let me ask you this: Is Mathematics hypothetical?

--
Luben

--=_alternative 0046FC7AC2256BD8_=-- From owner-ips@ece.cmu.edu Fri Jun 14 09:52:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29578 for ; Fri, 14 Jun 2002 09:52:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5ED8NZ13620 for ips-outgoing; Fri, 14 Jun 2002 09:08:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5ED5Kw13425 for ; Fri, 14 Jun 2002 09:05:20 -0400 (EDT) Received: from mail pickup service by mail6.nc.rr.com with Microsoft SMTPSVC; Fri, 14 Jun 2002 03:51:56 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 23:25:05 -0400 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5B3P5Ia017195 for ; Mon, 10 Jun 2002 23:25:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5B2oZl28608 for ips-outgoing; Mon, 10 Jun 2002 22:50:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5B2o5w28577 for ; Mon, 10 Jun 2002 22:50:05 -0400 (EDT) Received: from phys-hanwk16-2.ebay.sun.com ([129.149.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA18895; Mon, 10 Jun 2002 19:49:59 -0700 (PDT) Received: from Sun.COM (vpn-129-147-152-110.Central.Sun.COM [129.147.152.110]) by phys-hanwk16-2.ebay.sun.com (8.10.2+Sun/8.10.2/ENSMAIL,v2.1p1) with ESMTP id g5B2nuB14917; Mon, 10 Jun 2002 19:49:56 -0700 (PDT) Message-ID: <3D05658A.6040707@Sun.COM> Date: Mon, 10 Jun 2002 21:50:50 -0500 From: David Robinson User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Bill Studenmund CC: Paul Koning , pat_thaler@agilent.com, ksandars@eurologic.com, bmastors@allocity.com, ips@ece.cmu.edu Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bill Studenmund wrote: > On Mon, 10 Jun 2002, Paul Koning wrote: >>Excerpt of message (sent 10 June 2002) by Bill Studenmund: >> >>>I expect iSCSI 2 (or 1.1) will be on the order of a year or more out from >>>iSCSI. What does everyone else think? >>> >>If the spec is as good as it should be, that's a fine time frame. But >>if significant interop issues are found soon after RFC, then 1.1 will >>have to happen a whole lot sooner. >> > > What happens if we're somewhere inbetween? Or what if we find an issue > where 80% of the implementations all chose the same way? > > I'm trying to scope out the shades of gray we might run into. As a reminder about the IETF standards process, RFC2026. The IPS working group is driving towards "Proposed Standard" which by definition: "Implementors should treat Proposed Standards as immature specifications." The next step is "Draft Standard" where there is expectation that changes will be made between Proposed and Draft. "A Draft Standard is normally considered to be a final specification..." To move from Proposed to Draft is where two independant implementations are required and where the "80%" implementation problems are caught and fixed. The RFC we are driving towards is just the first step in a long path, there will be plenty of opportunities to fix "bugs" that are found we real implementations are built. Thus vendor specific keys are not needed, what we have today is not going to be the "Internet Standard." -David From owner-ips@ece.cmu.edu Fri Jun 14 10:28:49 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00803 for ; Fri, 14 Jun 2002 10:28:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5EDlTq15709 for ips-outgoing; Fri, 14 Jun 2002 09:47:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5EDlRw15704 for ; Fri, 14 Jun 2002 09:47:27 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 09:47:26 -0400 Message-ID: From: Eddy Quicksall To: ips@ece.cmu.edu Subject: iSCSI: A bit and followed by separate Status PDU Date: Fri, 14 Jun 2002 09:47:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk 9.7.2 says: On receiving a Data-In PDU with the A bit set to 1, if there are no holes in the read data until that Data-In PDU, the initiator MUST issue a SNACK of type DataACK except when it is able to acknowledge the status for the task immediately via ExpStatSN on other outbound PDUs if the status for the task is also received; in this latter case (acknowledgement through ExpStatSN) sending a SNACK of type DataACK in response to the A bit is not mandatory but if it is done it must not be sent after the status acknowledgement through ExpStatSN. Regarding the "if the status for the task is also received" ... is that referring to the S bit and A bit within the same PDU or is there some other case I'm missing? Eddy mailto:Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Fri Jun 14 10:48:53 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01754 for ; Fri, 14 Jun 2002 10:48:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5EEOlp17635 for ips-outgoing; Fri, 14 Jun 2002 10:24:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5EEOfw17623; Fri, 14 Jun 2002 10:24:41 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5EEOVin017988; Fri, 14 Jun 2002 16:24:31 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5EEOVL137986; Fri, 14 Jun 2002 16:24:31 +0200 To: Sanjay Goyal Cc: ips@ece.cmu.edu, "'Nandakumar Ramamurthy'" , owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: FirstBurstSize and unsolicited data X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 14 Jun 2002 17:24:28 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 14/06/2002 17:24:32, Serialize complete at 14/06/2002 17:24:32 Content-Type: multipart/alternative; boundary="=_alternative 004F06D7C2256BD8_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004F06D7C2256BD8_= Content-Type: text/plain; charset="us-ascii" ... or all the data - if it is less than the FirstBurstSize. Julo Sanjay Goyal Sent by: owner-ips@ece.cmu.edu 06/14/2002 04:37 PM Please respond to Sanjay Goyal To: "'Nandakumar Ramamurthy'" , ips@ece.cmu.edu cc: Subject: RE: iSCSI: FirstBurstSize and unsolicited data The specifications says If you send any non-immediate unsolicited data-out PDUs, the total unsolicited amount of data should be FirstBurstSize amount of data. Regards Sanjay Goyal -----Original Message----- From: Nandakumar Ramamurthy [mailto:nramamur@npd.hcltech.com] Sent: Friday, June 14, 2002 7:16 AM To: ips@ece.cmu.edu Subject: iSCSI: FirstBurstSize and unsolicited data Hi All, Consider the case where InitialR2T=yes and ImmediateData=yes. All other values are the defaults. The expected data transfer length for a SCSI write operation is a value exceeding FirstBurstSize (64KB). In the above case, the initiator will send immediate unsolicited data (MaxRecvPDULength=8192 bytes). After that it has to wait for an R2T from the target. In this scenario, FirstBurstSize of data will not be sent to the target as unsolicited data-out's cannot be sent here. My understanding is that the remaining data can be sent only through solicited Data-out PDUs, and this is the expected way according to the draft. What does the following statement(in Section 9.4.6.2 Sense Data) mean in this context ? The target reports the "Not enough unsolicited data" condition only if it does not support output (write) operations in which the total data length is greater than FirstBurstSize, but the initiator sent less than FirstBurstSize amount of unsolicited data, and out-of-order R2Ts cannot be used. If this is specific to the SCSI layer at the target, what is the dependency on FirstBurstSize? Please clarify. Thanks, Nandakumar Member Technical Staff HCL Technologies, Chennai, INDIA. http://san.hcltech.com --=_alternative 004F06D7C2256BD8_= Content-Type: text/html; charset="us-ascii"
... or all the data - if it is less than the FirstBurstSize. Julo


Sanjay Goyal <sanjay_goyal@ivivity.com>
Sent by: owner-ips@ece.cmu.edu

06/14/2002 04:37 PM
Please respond to Sanjay Goyal

       
        To:        "'Nandakumar Ramamurthy'" <nramamur@npd.hcltech.com>, ips@ece.cmu.edu
        cc:        
        Subject:        RE: iSCSI: FirstBurstSize and unsolicited data

       


The specifications says
If you send any non-immediate unsolicited data-out PDUs, the total
unsolicited amount of data should be FirstBurstSize amount of data.


Regards
Sanjay Goyal


-----Original Message-----
From: Nandakumar Ramamurthy [mailto:nramamur@npd.hcltech.com]
Sent: Friday, June 14, 2002 7:16 AM
To: ips@ece.cmu.edu
Subject: iSCSI: FirstBurstSize and unsolicited data


Hi All,

Consider the case where InitialR2T=yes and ImmediateData=yes.
All other values are the defaults.

The expected data transfer length for a SCSI write
operation is a value exceeding FirstBurstSize (64KB).

In the above case, the initiator will send immediate
unsolicited data (MaxRecvPDULength=8192 bytes).
After that it has to wait for an R2T from the target.

In this scenario, FirstBurstSize of data will not be sent
to the target as unsolicited data-out's cannot be sent here.

My understanding is that the remaining data can be
sent only through solicited Data-out PDUs,
and this is the expected way according to the draft.

What does the following statement(in Section 9.4.6.2 Sense Data) mean in
this context ?

<quote>

The target reports the "Not enough unsolicited data" condition only
if it does not support output (write) operations in which the total

data length is greater than FirstBurstSize, but the initiator sent

less than FirstBurstSize amount of unsolicited data, and out-of-order

R2Ts cannot be used.

</quote>

If this is specific to the SCSI layer at the target,
what is the dependency on FirstBurstSize?

Please clarify.

Thanks,
Nandakumar
Member Technical Staff
HCL Technologies, Chennai, INDIA.
http://san.hcltech.com

--=_alternative 004F06D7C2256BD8_=-- From owner-ips@ece.cmu.edu Fri Jun 14 10:48:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01777 for ; Fri, 14 Jun 2002 10:48:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5EEOuY17641 for ips-outgoing; Fri, 14 Jun 2002 10:24:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5EEOfw17624; Fri, 14 Jun 2002 10:24:41 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5EEOV5u088950; Fri, 14 Jun 2002 16:24:31 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5EEOUL64162; Fri, 14 Jun 2002 16:24:30 +0200 To: Eddy Quicksall Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: A bit and followed by separate Status PDU X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 14 Jun 2002 17:24:28 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 14/06/2002 17:24:30, Serialize complete at 14/06/2002 17:24:30 Content-Type: multipart/alternative; boundary="=_alternative 004ECFCBC2256BD8_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004ECFCBC2256BD8_= Content-Type: text/plain; charset="us-ascii" It refers to both the S bit or a separate response. If the initiator processes a Response before it issues the SNACK it can act the same way as when status is embedded. Target frees resources if ExpStatSN passes over the status - Julo Eddy Quicksall Sent by: owner-ips@ece.cmu.edu 06/14/2002 04:47 PM Please respond to Eddy Quicksall To: ips@ece.cmu.edu cc: Subject: iSCSI: A bit and followed by separate Status PDU 9.7.2 says: On receiving a Data-In PDU with the A bit set to 1, if there are no holes in the read data until that Data-In PDU, the initiator MUST issue a SNACK of type DataACK except when it is able to acknowledge the status for the task immediately via ExpStatSN on other outbound PDUs if the status for the task is also received; in this latter case (acknowledgement through ExpStatSN) sending a SNACK of type DataACK in response to the A bit is not mandatory but if it is done it must not be sent after the status acknowledgement through ExpStatSN. Regarding the "if the status for the task is also received" ... is that referring to the S bit and A bit within the same PDU or is there some other case I'm missing? Eddy mailto:Eddy_Quicksall@iVivity.com --=_alternative 004ECFCBC2256BD8_= Content-Type: text/html; charset="us-ascii"
It refers to both the S bit or a separate response. If the initiator processes a Response before it issues the SNACK it can act the same way as when status is embedded. Target frees resources if ExpStatSN passes over the status - Julo


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

06/14/2002 04:47 PM
Please respond to Eddy Quicksall

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI: A bit and followed by separate Status PDU

       


9.7.2 says:

On receiving a Data-In PDU with the A bit set to 1, if there are no
holes in the read data until that Data-In PDU, the initiator MUST
issue a SNACK of type DataACK except when it is able to acknowledge
the status for the task immediately via ExpStatSN on other outbound
PDUs if the status for the task is also received; in this latter case
(acknowledgement through ExpStatSN) sending a SNACK of type DataACK
in response to the A bit is not mandatory but if it is done it must
not be sent after the status acknowledgement through ExpStatSN.

Regarding the "if the status for the task is also received" ... is that
referring to the S bit and A bit within the same PDU or is there some other
case I'm missing?

Eddy
<mailto:Eddy_Quicksall@iVivity.com> mailto:Eddy_Quicksall@iVivity.com



--=_alternative 004ECFCBC2256BD8_=-- From owner-ips@ece.cmu.edu Fri Jun 14 11:35:14 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03726 for ; Fri, 14 Jun 2002 11:35:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5EEfOw18543 for ips-outgoing; Fri, 14 Jun 2002 10:41:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5EEfMw18539 for ; Fri, 14 Jun 2002 10:41:22 -0400 (EDT) Received: from mail pickup service by mail6.nc.rr.com with Microsoft SMTPSVC; Fri, 14 Jun 2002 10:34:29 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Jun 2002 21:20:43 -0400 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5C0Z2bC001374 for ; Tue, 11 Jun 2002 20:35:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BNvHf13225 for ips-outgoing; Tue, 11 Jun 2002 19:57:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BNvFw13216 for ; Tue, 11 Jun 2002 19:57:15 -0400 (EDT) Received: from london ([192.168.1.19]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id QAA16002; Tue, 11 Jun 2002 16:55:32 -0700 (PDT) From: "Rod Harrison" To: "Julian Satran" , "Mallikarjun C." Cc: Subject: RE: iSCSI: changing MaxPDUDataLength Date: Tue, 11 Jun 2002 18:57:36 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I'm torn, I don't want to make this sort of change late on but I think it would be a good thing in the long term. How about adding the additional async message code and saying upon receipt the initiator MAY start a negotiation sequence or logout and re-login the connection immediately without having to wait for the negotiated timeouts? - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Tuesday, June 11, 2002 4:28 PM To: Mallikarjun C. Cc: ips@ece.cmu.edu; Julian Satran; owner-ips@ece.cmu.edu Subject: Re: iSCSI: changing MaxPDUDataLength Importance: High Mallikarjun, The question was general and not specific to MaxRecv.... Although we say that negotiation is symmetric we don't have any mechanism through which a target can say it wants to start negotiation something (sort of similar but not as strong as a the "request logout" - "request to negotiate" that will require the initiator to issue a text request and kick-off a negotiation. Julo "Mallikarjun C." To: , Julian Satran/Haifa/IBM@IBMIL Sent by: cc: owner-ips@ece.cmu Subject: Re: iSCSI: changing MaxPDUDataLength .edu 06/11/2002 10:50 PM Please respond to "Mallikarjun C." > I also realized that we don't have "negotiation prompt" from the target. > I am not sure that we need one. I am not sure about it either. My preference is not to add this. It appears to me that a target does have the option of dropping the connection today if it can't work with non-ULPDU-contained segments for too long. I suspect that the target would do the same if (we introduced the "negotiation prompt" and) the initiator doesn't/couldn't honor the "negotiation prompt". Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Julian Satran" To: Sent: Tuesday, June 11, 2002 8:34 AM Subject: RE: iSCSI: changing MaxPDUDataLength > I suggest the following text in 11.13 > > A change of MaxRecvDataSegmentLength by an initiator or target > becomes effective after all commands preceding the negotiation > end-ing request have been processed by the target and their status > is acknowledged. > > I also realized that we don't have "negotiation prompt" from the target. > I am not sure that we need one. > If some of you think we need we may want one additional code in the Asynch > Message. > Please comment TODAY. > > Julo > ----- Forwarded by Julian Satran/Haifa/IBM on 06/11/2002 06:29 PM ----- > > Julian Satran > To: Eddy Quicksall > 06/11/2002 04:04 cc: ips@ece.cmu.edu, pat_thaler@agilent.com > PM From: Julian Satran/Haifa/IBM@IBMIL > Subject: RE: iSCSI: changing MaxPDUDataLength(Document link: Julian Satran - Mail) > > > > > > > > > > That is a fair request - we may slip in a recommendation to that effect (in > chapter 11?) > > Julo > > > > Eddy Quicksall > vivity.com> cc: ips@ece.cmu.edu, pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > 06/11/2002 04:28 > AM > Please respond to > Eddy Quicksall > > > > > > How about if we say that an initiator must not change the MaxPDUDataSize > unless it first idles the commands (at least the ones with the R bit) or if > ErrorRecoveryLevel==0? > > That would simplify target code greatly and would meet the design goals; > and since it should be rare to change it, it would be of little impact to > idle the commands for a split second. > > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Monday, June 10, 2002 8:06 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > I said only that when you change length you can ask for all PDUs > after the ack! (no need to keep a tall - the old offsets are good up > to the hole). > > Julo > > > Eddy Quicksall > To: Julian > Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu, > 06/11/2002 12:32 AM pat_thaler@agilent.com > Please respond to Eddy Quicksall Subject: RE: iSCSI: > changing MaxPDUDataLength > > > > > > > > Julian, > > Another problem here is that the target has to calculate the offset > from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and > RunLngth=0 means starting DataSN=4, send all the data for that > sequence. > > I think it would be a performance hit and waist of memory to keep a > tally of all PDU sizes just for an occasional SNACK. > > It's not that it can't be done ... it is more that it is messy and I > think there is a solution that will satisfy the design requirements > but keep the software simpler. > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Saturday, June 08, 2002 10:16 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > That is not completely accurate. > The only problem is when PDU size decreases and then SNACK must be > for all data. > Target can also keep a mapping of numbers/to offsets (the list should > be small and if it gets long ask for ack (A-bit). > > Julo > > Eddy Quicksall > To: > Sent by: owner-ips@ece.cmu.edu pat_thaler@agilent.com > cc: ips@ece.cmu.edu > Subject: RE: iSCSI: > 06/08/2002 10:54 PM changing MaxPDUDataLength > Please respond to Eddy Quicksall > > > > > > > > Thanks, > > As a target, I won't be able to let it change until all of the > outstanding > commands are finished (running with ErrorRecoveryLevel>=1). This is > because > I must use the PDU size to compute the offset from a SNACK's > BegRun/RunLength. > > So, I plan to not give the text response for a MaxPDURecvDataLength > in FFP > until I get back an ExpStatSN == next StatSN. > > This will cause a delay of unknown time before the PDU size can > actually > change ... do you see any problem with this? > > Eddy > > -----Original Message----- > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > Sent: Friday, June 07, 2002 1:13 PM > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > Subject: RE: iSCSI: changing MaxPDUDataLength > > > Eddy, > > If one uses a message sync and steering that relys on the transport > segments > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the > path > MTU changes one would want to change the PDU data length to fit the > new path > MTU. > > Pat > > -----Original Message----- > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > Sent: Wednesday, June 05, 2002 12:24 PM > To: ips@ece.cmu.edu > Subject: iSCSI: changing MaxPDUDataLength > > > Does anybody know a case where it is necessary to support a new PDU > data > length during full feature phase? > > Eddy > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > > > From owner-ips@ece.cmu.edu Fri Jun 14 12:53:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06174 for ; Fri, 14 Jun 2002 12:53:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5EGBn623604 for ips-outgoing; Fri, 14 Jun 2002 12:11:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5EGBlw23598 for ; Fri, 14 Jun 2002 12:11:47 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id D2DCEF9; Fri, 14 Jun 2002 10:11:46 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 53B131D93; Fri, 14 Jun 2002 10:11:46 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 14 Jun 2002 10:11:45 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 10:11:45 -0600 Message-ID: <01A7DAF31F93D511AEE300D0B706ED9201BF4986@axcs13.cos.agilent.com> From: vince_cavanna@agilent.com To: luben@splentec.com, vince_cavanna@agilent.com Cc: wrstuden@wasabisystems.com, Julian_Satran@il.ibm.com, pat_thaler@agilent.com, ips@ece.cmu.edu Subject: RE: iSCSI: 12-97 Bit Rule Date: Fri, 14 Jun 2002 10:11:43 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Luben, When Bill pointed out that the text of the spec required the receiver to complement the remainder in order to obtain the magic number 0x1c2d19ed I re-read the text and came to the same interpretation as Bill. With that interpretation I do believe there is a problem in the text. I had previously read the text and not seen a problem. The reason I thought it was my fault is that in recent private correspondence between you, Pat and Julian I noticed that Pat had it correct in one of her memos and I corrected her (erroneously) and nobody objected and Julian changed the text and I, for one, felt comfortable with it. I know that you also had it right (from my perspective) in your description but what we are commenting on is what is in the text. As Bill pointed out, the text defines, in its description of the CRC proceesing at the transmitter, that the "CRC computation" includes bit complementing. Later, in the description of the receiver computation at the receiver, the text refers to "CRC computation" once more. The reader has no clue that "CRC computation" at the receiver should not include the complement operation if he is to obtain the value 0x1c2d19ed. Thus I agree that hte text is misleading. We need to make it explicit that the receiver follows a different algorithm (no complementing) and expects 0x1c2d19ed or that it implements the same algorithm and expects 0xe3d2e612. Vince |-----Original Message----- |From: Luben Tuikov [mailto:luben@splentec.com] |Sent: Thursday, June 13, 2002 5:43 PM |To: CAVANNA,VICENTE V (A-Roseville,ex1) |Cc: 'Bill Studenmund'; Julian Satran; THALER,PAT (A-Roseville,ex1); |ips@ece.cmu.edu |Subject: Re: iSCSI: 12-97 Bit Rule | | |"CAVANNA,VICENTE V (A-Roseville,ex1)" wrote: |> |> I believe Bill is correct. The receiver, unlike the |transmitter, should not complement the remainder if he expects |to get 0x1c2d19ed. |> I am afraid I may be reponsible for this mistake during an |email exchange I and others had with Julian recently. Julian |and those others must have trusted me a little too much. Sorry |Julian and others. | |Vince, you had it right. The text was mentioning that it was |the CRC that |was the magic constant, and since the CRC is complemented in |the course of |computation, one more was needed to get ``back'' to the remainder. | |Yes, Bill, your empirical conclusion is correct. | |The magic constant _is_ the pure remainder in polynomial |form (0x1c2d19ed). | |The CRC is the complemented (and byte mirrored) remainder. | |That is: you have 2 algoritms, one to compute the pure |remainder, and another to complement it (and maybe byte-mirror) |and inject it at the end of the message to be sent. | |The sender does both algorithms (compute and inject), |and the receiver does just the first (compute) and compares |the result with the magic value. | |This has already been mentioned in a more formal (and |maybe confusing :-)) manner in an email from me at the |beginning of this thread (take a look at it, the one |with bit-sequences). | |-- |Luben | From owner-ips@ece.cmu.edu Fri Jun 14 12:57:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06258 for ; Fri, 14 Jun 2002 12:57:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5EG7gx23375 for ips-outgoing; Fri, 14 Jun 2002 12:07:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5EG7Yw23362; Fri, 14 Jun 2002 12:07:34 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 029B71613; Fri, 14 Jun 2002 10:07:33 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 32A52290; Fri, 14 Jun 2002 10:07:32 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 14 Jun 2002 10:07:32 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 10:07:32 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C89106D@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com, pat_thaler@agilent.com Cc: ips@ece.cmu.edu, luben@splentec.com, owner-ips@ece.cmu.edu Subject: RE: iSCSI: 12-97 Bit Rule Date: Fri, 14 Jun 2002 10:07:30 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-e05cba53-e1b6-462c-9e00-04717b819bdb" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-e05cba53-e1b6-462c-9e00-04717b819bdb Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C213BD.96248E40" ------_=_NextPart_001_01C213BD.96248E40 Content-Type: text/plain; charset="iso-8859-1" All, I am also done with this thread. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, June 14, 2002 6:02 AM To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu; luben@splentec.com; owner-ips@ece.cmu.edu Subject: RE: iSCSI: 12-97 Bit Rule Importance: High Excellent - we are now spending time in the Never-Endian space :-) (coined by a good friend) - I am deleting the whole thread on my mailer. If you think I should pay attention to something please change the subject line. I know ( an changed already) the remainder word. Thanks Julo pat_thaler@agilent.com Sent by: owner-ips@ece.cmu.edu 06/14/2002 02:38 AM Please respond to pat_thaler To: luben@splentec.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: 12-97 Bit Rule Luben, If I ruled the world, I would number the least significant bit 0. I agree that that is a more logical numbering. My second choice would be for the whole world to use the same numbering even if it was different from that. However, neither you nor I rule the world and IETF has chosen to number the most significant bit 0 and the choices made by other organizations vary all over the map and we get to flop and flip bits to match them to the environment. A convention that is used throughout the document (like the significance of bits within a field) belongs at the front. That convention also gets reinforced when one looks at other parts of the document like chapter 9. That is why it is satisfactory for 1.3.1 through 1.3.3 to be at the front. A detail that only applies one place like the different ordering of the bits in the CRC calculation should be in the place where it is used. That is why it wasn't good to have 11.1 reference 1.3.4 for how to order the bits in the CRC calculation. This is just good editorial practice for building a usable document. On the particular text: 8) The message sent is P and appended at the end are the bit coefficients of CRC(x), with x^31 bit coefficient first, then x^30, etc. the problem is that the x^31 bit doesn't go first when it is in the frame. Also, bits can go through their entire existence without being sent in serial order so nothing is first. Say which bit of the CRC goes into which bit of the digest field and you are done. Sincerely, Pat -----Original Message----- From: Luben Tuikov [mailto:luben@splentec.com] Sent: Thursday, June 13, 2002 4:13 PM To: pat_thaler@agilent.com Cc: Julian_Satran@il.ibm.com; ips@ece.cmu.edu Subject: Re: iSCSI: 12-97 Bit Rule pat_thaler@agilent.com wrote: > > TCP/IP Illustrated numbers bits with bit 0 as the > most significant. My books on Sonet number bits > in a byte from 1 to 8. I guess you could argue > these are not books on computer architecture, but > the point is that not everyone numbers bits the > same. Uuuh, here we go again... Yes, I can argue that those are NOT books on computer architecure. Let me get home I'll send you the titles/authors/ISBN of a few books on Computer Architecture which use the NATURAL bit ordering: 2^(x+1) > 2^x, x >= 0, so it only _makes_sense_ to say that bit x+1 is more significant than bit x. Take the number 791, is the 2rd digit more significant than the 1nd? Well: 791 = 7*10^2 + 9*10^1 + 1*10^0. > If you will read 1.3.1 through 1.3.3, they do > explicitly state the significance of bits in > iSCSI words, half-words and bytes. Yep, and you were complaining that it was 200 pages away from 11.1 where the CRC digest was --- or was that in a private email? Trying to score points? > Julian's new description is accurate and clear. Are you sure? Are you really sure? > Item 8 in your description is unclear and confusing > because the bits do not "follow" each other in the > order you state (and any viewing of bits in a message > as a serial stream is entirely hypothetical). Here is 8: 8) The message sent is P and appended at the end are the bit coefficients of CRC(x), with x^31 bit coefficient first, then x^30, etc. That is after you send P, send CRC(x) as indicated. What doesn't follow what? Of course it is hypothetical... Pat, let me ask you this: Is Mathematics hypothetical? -- Luben ------_=_NextPart_001_01C213BD.96248E40 Content-Type: text/html; charset="iso-8859-1"
All,
 
I am also done with this thread.
 
Regards,
Pat
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, June 14, 2002 6:02 AM
To: pat_thaler@agilent.com
Cc: ips@ece.cmu.edu; luben@splentec.com; owner-ips@ece.cmu.edu
Subject: RE: iSCSI: 12-97 Bit Rule
Importance: High


Excellent - we are now spending time in the Never-Endian space :-) (coined by a good friend) - I am deleting the whole thread on my mailer.
If you think I should pay attention to something please change the subject line.  I know ( an changed already) the remainder word. Thanks

Julo


pat_thaler@agilent.com
Sent by: owner-ips@ece.cmu.edu

06/14/2002 02:38 AM
Please respond to pat_thaler

       
        To:        luben@splentec.com
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: 12-97 Bit Rule

       


Luben,

If I ruled the world, I would number the least significant bit 0. I agree
that that is a more logical numbering. My second choice would be for the
whole world to use the same numbering even if it was different from that.
However, neither you nor I rule the world and IETF has chosen to number the
most significant bit 0 and the choices made by other organizations vary all
over the map and we get to flop and flip bits to match them to the
environment.

A convention that is used throughout the document (like the significance of
bits within a field) belongs at the front. That convention also gets
reinforced when one looks at other parts of the document like chapter 9.
That is why it is satisfactory for 1.3.1 through 1.3.3 to be at the front. A
detail that only applies one place like the different ordering of the bits
in the CRC calculation should be in the place where it is used. That is why
it wasn't good to have 11.1 reference 1.3.4 for how to order the bits in the
CRC calculation. This is just good editorial practice for building a usable
document.

On the particular text:
8) The message sent is P and appended at the end are the
  bit coefficients of CRC(x), with x^31 bit coefficient
  first, then x^30, etc.
the problem is that the x^31 bit doesn't go first when it is in the frame.
Also, bits can go through their entire existence without being sent in
serial order so nothing is first. Say which bit of the CRC goes into which
bit of the digest field and you are done.

Sincerely,
Pat

-----Original Message-----
From: Luben Tuikov [mailto:luben@splentec.com]
Sent: Thursday, June 13, 2002 4:13 PM
To: pat_thaler@agilent.com
Cc: Julian_Satran@il.ibm.com; ips@ece.cmu.edu
Subject: Re: iSCSI: 12-97 Bit Rule


pat_thaler@agilent.com wrote:
>
> TCP/IP Illustrated numbers bits with bit 0 as the
> most significant. My books on Sonet number bits
> in a byte from 1 to 8. I guess you could argue
> these are not books on computer architecture, but
> the point is that not everyone numbers bits the
> same.

Uuuh, here we go again...

Yes, I can argue that those are NOT books
on computer architecure. Let me get home
I'll send you the titles/authors/ISBN
of a few books on Computer Architecture
which use the NATURAL bit ordering:

2^(x+1) > 2^x, x >= 0,
so it only _makes_sense_ to say that
bit x+1 is more significant than bit x.

Take the number 791, is the 2rd digit
more significant than the 1nd?
Well: 791 = 7*10^2 + 9*10^1 + 1*10^0.

> If you will read 1.3.1 through 1.3.3, they do
> explicitly state the significance of bits in
> iSCSI words, half-words and bytes.

Yep, and you were complaining that it was
200 pages away from 11.1 where the CRC
digest was --- or was that in a private
email? Trying to score points?

> Julian's new description is accurate and clear.

Are you sure? Are you really sure?

> Item 8 in your description is unclear and confusing
> because the bits do not "follow" each other in the
> order you state (and any viewing of bits in a message
> as a serial stream is entirely hypothetical).

Here is 8:

8) The message sent is P and appended at the end are the
  bit coefficients of CRC(x), with x^31 bit coefficient
  first, then x^30, etc.

That is after you send P, send CRC(x) as indicated.
What doesn't follow what?

Of course it is hypothetical...

Pat, let me ask you this: Is Mathematics hypothetical?

--
Luben


------_=_NextPart_001_01C213BD.96248E40-- ------=_NextPartTM-000-e05cba53-e1b6-462c-9e00-04717b819bdb-- From owner-ips@ece.cmu.edu Fri Jun 14 13:19:26 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07017 for ; Fri, 14 Jun 2002 13:19:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5EGkNZ25610 for ips-outgoing; Fri, 14 Jun 2002 12:46:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5EGkMw25605 for ; Fri, 14 Jun 2002 12:46:22 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 2A08186BA; Fri, 14 Jun 2002 10:46:19 -0600 (MDT) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id CC6252C6; Fri, 14 Jun 2002 10:46:16 -0600 (MDT) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 14 Jun 2002 10:46:16 -0600 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 10:46:16 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C8910A6@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: "Fischer, Michael" , "'Eddy Quicksall'" , Santosh Rao , IPS Reflector Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ? Date: Fri, 14 Jun 2002 10:46:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Michael, It doesn't matter that FirstBurstSize was negotiated but is now not used. It doesn't hurt anything for it to be sitting around with a value in it. Also, the initiator declaring that it is ready to go to Full phase does not mean that the target has to go to full feature phase. The target can still continue to negotiate and, if the target does continue (by sending T=0), the initiator can change back to T=0 in its Login Request. What would happen is: I->T FirstBurstSize=512; T=0; NSG=CSG; T->I FirstBurstSize=512; T=0; NSG=CSG; I->T InitialR2T=no, ImmediateData=no; T=1; NSG=FULL T->I InitialR2T=yes, ImmediateData=no; ; T=1; NSG=FULL or if the target still has other keys it wants to send in further PDUs or the target also originates a key this line would be T->I InitialR2T=yes, ImmediateData=no; ; T=0; NSG=FULL In this latter case, the initiator might respond with T=1 if it is still ready to go to full feature phase or it might respond with T=0 if to continue the negotiation in response to the new keys it received. When the Initiator originates keys while setting T=1; it is allowing the target to respond and is willing to go to the next phase regardless of the response. Regards, Pat -----Original Message----- From: Fischer, Michael [mailto:Michael_Fischer@adaptec.com] Sent: Wednesday, February 06, 2002 11:39 AM To: 'Eddy Quicksall'; Santosh Rao; IPS Reflector Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ? What if the sequence is as follows: I->T FirstBurstSize=512; T=0; NSG=CSG; T->I FirstBurstSize=512; T=0; NSG=CSG; I->T InitialR2T=no, ImmediateData=no; T=1; NSG=FULL If the target does not support InitialR2T=no.. Does login now fail? There does not seem to be a way for the target to say that it requires R2T. Why did the Initiator send FirstBurstSize if it was setting InitialR2T to no? There is no negotiation with an AND function. Michael Fischer -----Original Message----- From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] Sent: Wednesday, February 06, 2002 9:47 AM To: Santosh Rao; IPS Reflector Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ? That is how I am interpreting it. BTW: How about this one ... I->T FirstBurstSize=512, InitialR2T=no, ImmediateData=no If the target does not support InitialR2T=no, how should it respond to FirstBurstSize? Should the target do this (for draft >= 9)? T->I FirstBurstSize=irrelevant, InitialR2T=yes, ImmediateData=no Eddy -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Tuesday, February 05, 2002 2:56 PM To: IPS Reflector Subject: ips : Is FirstBurstSize valid when InitialR2T=yes ? Hello, Can someone clarify if the login key FirstBurstSize is valid when : InitialR2T=yes and ImmediateData=yes ? i.e. if immediate data is enabled and un-solicited data is disabled during login negotiation, is the value of FirstBurstSize received in the login response to be interpreted ? My current understanding is that FirstBurstSize is inclusive of the immediate data portion, and so, if immediate data is enabled, but un-solicited data is disabled, then, FirstBurstSize *must* be valid and must be <= DataPDULength. (after rev 09, it would be <= (MaxRecvPDULength - the header components size)). For example, a target implementation may offer a FirstBurstSize < DataPDULength, in which case, the immediate data size is the MIN(DataPDULength, FirstBurstSize, bytes_to_send). Can someone clarify if this is a correct interpretation or set me right on this ? Thanks, Santosh -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## From owner-ips@ece.cmu.edu Fri Jun 14 13:25:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07225 for ; Fri, 14 Jun 2002 13:25:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5EHApI27172 for ips-outgoing; Fri, 14 Jun 2002 13:10:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5EHAnw27167 for ; Fri, 14 Jun 2002 13:10:49 -0400 (EDT) Received: from mail pickup service by mail6.nc.rr.com with Microsoft SMTPSVC; Fri, 14 Jun 2002 10:43:30 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Jun 2002 00:04:28 -0400 Received: from engine.ieee.org (engine.ieee.org [140.98.193.23]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5B2EcIa021525 for ; Mon, 10 Jun 2002 22:14:38 -0400 (EDT) Received: from ece.cmu.edu (gemini3.ieee.org [140.98.193.25]) by engine.ieee.org (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5B2E5B03728; Mon, 10 Jun 2002 22:14:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AMLYX17077 for ips-outgoing; Mon, 10 Jun 2002 18:21:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AMLWw17073 for ; Mon, 10 Jun 2002 18:21:33 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 4B76030706; Mon, 10 Jun 2002 18:21:32 -0400 (EDT) Date: Mon, 10 Jun 2002 15:19:25 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: "THALER"@ece.cmu.edu Cc: Ken Sandars , , , Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00C5E3E67@axcs04.cos.agilent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Mon, 10 Jun 2002, THALER,PAT (A-Roseville,ex1) wrote: > Ken, > > The incentive is that, in my experience, when products interoperate > out of the chute (because the spec is clear) the market grows quickly. > When interoperability is a nightmare built in by testing and tweaks, > then markets grow slowly. > > Ambiguities need to be fixed. A number that have been raised recently > have been fixed. If there are ones you feel haven't been addressed, I > would like to see them fixed. That is what we should do rather than > planning on building in work arounds. I agree that if folks know of ambiguities, we should fix them. PLEASE bring them up. NOW. :-) I also agree that we shouldn't ship a spec with what we know to be holes in it. In fact, that's why my EMails have been quite, shall we say, vigorous. _I_ want iSCSI to be the best spec it can. The question to me, though, is two-fold. 1) as my other note indicates, I think these keys have value on their own (I don't plan on using them for bug adaptability, just info). 2) (and this is the bigger question) What do we do about bugs we find *after* we get to RFC stage? Yes, we fix them in the next version. But how quickly are we going to get that version out? Are we going to crank RFCs out as fast as Julian can make I-D drafts now? I doubt it. If we were, then I think saying, "Update to the next version," is a reasonable approach. I expect iSCSI 2 (or 1.1) will be on the order of a year or more out from iSCSI. What does everyone else think? What do we do in the mean time? And shouldn't we think about that now? Take care, Bill From owner-ips@ece.cmu.edu Fri Jun 14 13:28:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07299 for ; Fri, 14 Jun 2002 13:28:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5EGqll26053 for ips-outgoing; Fri, 14 Jun 2002 12:52:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5EGqkw26048 for ; Fri, 14 Jun 2002 12:52:46 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 79B92BBBA for ; Fri, 14 Jun 2002 10:52:45 -0600 (MDT) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 413E82AC for ; Fri, 14 Jun 2002 10:52:45 -0600 (MDT) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 14 Jun 2002 10:52:45 -0600 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 10:52:45 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C8910BA@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Santosh Rao , IPS Reflector Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ? Date: Fri, 14 Jun 2002 10:52:42 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, I don't see any requirement for FirstBurstSize <= MaxRecvPDUDataSize even when InitialR2T=yes and ImmediateData=yes. When only Immediate unsolicited data can be sent, the amount of that data is limited to the lesser of FirstBurstSize and MaxRecvPDUDataSize. FirstBurstSize is negotiated session wide and MaxRecvPDUDataSize is connection per direction so it would be entirely reasonable to have FirstBurstSize large (or smaller) than MaxRecvPDUDataSize on some connections. Regards, Pat -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Tuesday, February 05, 2002 11:56 AM To: IPS Reflector Subject: ips : Is FirstBurstSize valid when InitialR2T=yes ? Hello, Can someone clarify if the login key FirstBurstSize is valid when : InitialR2T=yes and ImmediateData=yes ? i.e. if immediate data is enabled and un-solicited data is disabled during login negotiation, is the value of FirstBurstSize received in the login response to be interpreted ? My current understanding is that FirstBurstSize is inclusive of the immediate data portion, and so, if immediate data is enabled, but un-solicited data is disabled, then, FirstBurstSize *must* be valid and must be <= DataPDULength. (after rev 09, it would be <= (MaxRecvPDULength - the header components size)). For example, a target implementation may offer a FirstBurstSize < DataPDULength, in which case, the immediate data size is the MIN(DataPDULength, FirstBurstSize, bytes_to_send). Can someone clarify if this is a correct interpretation or set me right on this ? Thanks, Santosh -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## From owner-ips@ece.cmu.edu Fri Jun 14 14:11:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08596 for ; Fri, 14 Jun 2002 14:11:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5EHiX029262 for ips-outgoing; Fri, 14 Jun 2002 13:44:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5EHiVw29257 for ; Fri, 14 Jun 2002 13:44:31 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 09735153C; Fri, 14 Jun 2002 11:44:31 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 9E27C1EE; Fri, 14 Jun 2002 11:44:30 -0600 (MDT) Received: from 130.29.152.143 by axcsbh1.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 14 Jun 2002 11:44:30 -0600 Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 11:44:30 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C8910E1@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: "Martin, Nick" , Eddy Quicksall Cc: Santosh Rao , IPS Reflector Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ? Date: Fri, 14 Jun 2002 11:44:29 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, "Reject" is not an acceptable response in this situation. "Reject" for a numerical negotiation indicates that there was a problem with the value offered - it was out of the specified bounds. See 4.2 "The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are reserved and must only be used as described here." and 4.2.2: "An offer of a value not admissible (e.g., not within the specified bounds) MAY be answered with the constant "Reject" or the responder MAY select an admissible value." (The other uses of Reject are specific to list and range negotiations.) The offered value was within the specified bounds so it should not be rejected. Regards, Pat -----Original Message----- From: Martin, Nick [mailto:Nick.Martin@compaq.com] Sent: Thursday, February 07, 2002 5:38 PM To: Eddy Quicksall Cc: Santosh Rao; IPS Reflector Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ? I think the value Irrelevant should be used sparingly. In this case, the values 512, Irrelevant, and Reject will have the same effect on subsequent packets on the wire unless and until ImmediateData or InitialR2T are negotiated again. At that time the current value of FirstBurstSize again becomes useful. There is some rule about least surprise which I can not quote at the moment, but given that these three possible return values produce the same result, I would send the 512 since that will be least surprising to the initiator. Remember that Irrelevant does not mean forgotten. There is still a current value in effect, even if the target chooses not to re-negotiate it at this time. I would not choose to refuse to accept the new value for FirstBurstSize. However if I wanted to so choose, I think I would use Reject. If the target does not support unsolicited nor immediate data and will never use the value FirstBurstSize, it could still keep a current value for the field. In doing so it will be less likely to force an initiator down a seldom trodden path. Thanks, Nick From owner-ips@ece.cmu.edu Fri Jun 14 14:12:49 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08650 for ; Fri, 14 Jun 2002 14:12:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5EHOHv27983 for ips-outgoing; Fri, 14 Jun 2002 13:24:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5EHOEw27968 for ; Fri, 14 Jun 2002 13:24:14 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id CDE7030706; Fri, 14 Jun 2002 13:24:13 -0400 (EDT) Date: Fri, 14 Jun 2002 10:22:00 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Nandakumar Ramamurthy Cc: Subject: Re: iSCSI: FirstBurstSize and unsolicited data In-Reply-To: <007f01c21394$db603c80$6213a8c0@hcltech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Fri, 14 Jun 2002, Nandakumar Ramamurthy wrote: > Hi All, > > Consider the case where InitialR2T=yes and ImmediateData=yes. > All other values are the defaults. > > The expected data transfer length for a SCSI write > operation is a value exceeding FirstBurstSize (64KB). > > In the above case, the initiator will send immediate > unsolicited data (MaxRecvPDULength=8192 bytes). > After that it has to wait for an R2T from the target. That is correct. > In this scenario, FirstBurstSize of data will not be sent > to the target as unsolicited data-out's cannot be sent here. > > My understanding is that the remaining data can be > sent only through solicited Data-out PDUs, > and this is the expected way according to the draft. > > What does the following statement(in Section 9.4.6.2 Sense Data) mean in > this context ? > > > > The target reports the "Not enough unsolicited data" condition only > if it does not support output (write) operations in which the total > data length is greater than FirstBurstSize, but the initiator sent > less than FirstBurstSize amount of unsolicited data, and out-of-order > R2Ts cannot be used. > > I think what that's getting at is if you do a write command and send unsolicited data-out PDUs, you've promised to send FirstBurstSize worth of data. If you don't, to continue the operation, the target needs to send an R2T for the missing data. But that would be an out-of-order R2T since by sending unsolicited data, you are acting as if you received an R2T for FirstBurstSize data; this error R2T would be going backwards. Take care, Bill From owner-ips@ece.cmu.edu Fri Jun 14 14:13:08 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08663 for ; Fri, 14 Jun 2002 14:13:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5EHTf228352 for ips-outgoing; Fri, 14 Jun 2002 13:29:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5EHTdw28344 for ; Fri, 14 Jun 2002 13:29:39 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 5E3B4BFD4; Fri, 14 Jun 2002 11:29:38 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 347E71E6; Fri, 14 Jun 2002 11:29:38 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 14 Jun 2002 11:29:35 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 11:29:35 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C8910D5@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Nick.Martin@compaq.com, santoshr@cup.hp.com, ips@ece.cmu.edu Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ? Date: Fri, 14 Jun 2002 11:29:34 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Nick, It is currently (12-98) MacRecvDataSegmentLength rather than MaxRecvPDULength. Pat -----Original Message----- From: Martin, Nick [mailto:Nick.Martin@compaq.com] Sent: Wednesday, February 06, 2002 2:06 PM To: Santosh Rao; IPS Reflector Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ? Santosh, One clarification is that MaxRecvPDULength (formerly DataPDULength), FirstBurstSize, and MaxBurstSize limit the size of the data segment or payload portion of the PDU. The header and digests are not counted within these lengths. (Also note that these are now in bytes now all 512 byte chunks.) Their ranges are 512 to (2**24)-1. The upper bound corresponding to the max value which can be expressed in the 24-bit field DataSegmentLength. If the value is 1024, it means 1024 bytes of data, not 1024 minus 48-byte header, minus up to two 4-byte digests. Compute your own overhead before negotiating the value. One may want to make sure all iSCSI PDUs fit within MTU. If the MTU, the overhead of the protocols below iSCSI, and the overhead of iSCSI are known, the number of iSCSI data bytes that will fit in a MTU size packet can be computed and negotiated. It does not need to be a power of 2 nor a multiple of 512. A multiple of 4 is expected. As has been pointed out some values may become unused or meaningless due to the setting of other values. The responder may reply with key=irrelevant. However I see no harm in accepting a numeric value, although it may not be used. The intention of the initiator may be to replace the default value in case part or all of the negotiation for no-unsolicited data is rejected. It is not invalid to have FirstBurstSize less than MaxRecvPDULength and ImmediateData=yes and InitialR2T=no. In this case InitialR2T=no cause no different behavior from InitialR2T=yes, since the FirstBurstSize will always be satisfied with immediate data. I do not think it would be appropriate to reply InitialR2T=Irrelevant. I think key=Irrelevant should be used when the responder is required to reply, but can not construct a reply that makes sense. This could be due to something else making the key meaningless. Examples might be a prior FMarker=no making RFMarkInt=Irrelevant, or a prior AuthMethod=SRP causing CHAP_A=Irrelevant. Key=Reject may fit such cases as well or better, if the other end should already know the prior result. Thanks, Nick > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Tuesday, February 05, 2002 1:56 PM > To: IPS Reflector > Subject: ips : Is FirstBurstSize valid when InitialR2T=yes ? > > > Hello, > > Can someone clarify if the login key FirstBurstSize is valid when : > InitialR2T=yes and ImmediateData=yes ? > > i.e. if immediate data is enabled and un-solicited data is disabled > during login negotiation, is the value of FirstBurstSize > received in the > login response to be interpreted ? > > My current understanding is that FirstBurstSize is inclusive of the > immediate data portion, and so, if immediate data is enabled, but > un-solicited data is disabled, then, FirstBurstSize *must* be > valid and > must be <= DataPDULength. (after rev 09, it would be <= > (MaxRecvPDULength - the header components size)). > > For example, a target implementation may offer a FirstBurstSize < > DataPDULength, in which case, the immediate data size is the > MIN(DataPDULength, FirstBurstSize, bytes_to_send). > > Can someone clarify if this is a correct interpretation or > set me right > on this ? > > Thanks, > Santosh > > > -- > ################################## > Santosh Rao > Software Design Engineer, > HP-UX iSCSI Driver Team, > Hewlett Packard, Cupertino. > email : santoshr@cup.hp.com > Phone : 408-447-3751 > ################################## > From owner-ips@ece.cmu.edu Fri Jun 14 14:13:14 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08709 for ; Fri, 14 Jun 2002 14:13:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5EHNgZ27939 for ips-outgoing; Fri, 14 Jun 2002 13:23:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5EHNfw27935 for ; Fri, 14 Jun 2002 13:23:41 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id EB22DBA35; Fri, 14 Jun 2002 11:23:40 -0600 (MDT) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id AB5F9EE; Fri, 14 Jun 2002 11:23:40 -0600 (MDT) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 14 Jun 2002 11:23:40 -0600 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 11:23:40 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C8910D1@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Santosh Rao , Eddy Quicksall Cc: IPS Reflector Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ? Date: Fri, 14 Jun 2002 11:23:39 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, I strongly disagree. There is no reason that FirstBurstSize should be 0 or any other particular value if InitalR2T = yes and ImmediateData=No. It won't be used in that case so it is fine for it to remain at the default of 64k or any other allowed value. The only requirment is that the target should respond with a valid value (one that is less than the offerred value and less than MaxBurstSize) because simple-minded login code on the Initiator may check that the value follows the rules even though other keys make the value unused. The target could also respond with Irrelevant. Pat -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Wednesday, February 06, 2002 1:33 PM To: Eddy Quicksall Cc: IPS Reflector Subject: Re: ips : Is FirstBurstSize valid when InitialR2T=yes ? I think this needs changing then. There's no reason the following should'nt be allowed : I -> T : InitialR2T=no ImmediateData=yes FirstBurstSize=65536 T -> I : InitialR2T=yes ImmediateData=no FirstBurstSize=0 Julian : Can we change the allowed valid range for FirstBurstSize from : FirstBurstSize= to : FirstBurstSize= - Santosh Eddy Quicksall wrote: > > Draft 10 says: > > FirstBurstSize= > > So that means you can't send a 0, doesn't it? > > Eddy > > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Wednesday, February 06, 2002 3:01 PM > To: Fischer, Michael > Cc: 'Eddy Quicksall'; IPS Reflector > Subject: Re: ips : Is FirstBurstSize valid when InitialR2T=yes ? > > IMO, the FirstBurstSize key value negotiated during login is a don't > care if *BOTH* immediate data and un-solicited data have been disabled. > > However, if the target knows up-front that it does not support either > immediate or un-solcited and it receives the key FirstBurstSize during > login negotiation, it should return a 0 value as the result of the > negotiation for FirstBurstSize. > > (Note that the special semantics of 0 implying no limit is no longer > true for FirstBurstSize and hence, the target can just return 0 iff both > immediata data and un-solicited data are disabled in login negotiation.) > > - Santosh > > "Fischer, Michael" wrote: > > > > What if the sequence is as follows: > > > > I->T FirstBurstSize=512; T=0; NSG=CSG; > > T->I FirstBurstSize=512; T=0; NSG=CSG; > > I->T InitialR2T=no, ImmediateData=no; T=1; NSG=FULL > > > > If the target does not support InitialR2T=no.. Does login now fail? > There > > does not seem to be a way for the target to say that it requires R2T. Why > > did the Initiator send FirstBurstSize if it was setting InitialR2T to no? > > There is no negotiation with an AND function. > > > > Michael Fischer > > > > -----Original Message----- > > From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] > > Sent: Wednesday, February 06, 2002 9:47 AM > > To: Santosh Rao; IPS Reflector > > Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ? > > > > That is how I am interpreting it. > > > > BTW: How about this one ... > > > > I->T FirstBurstSize=512, InitialR2T=no, ImmediateData=no > > > > If the target does not support InitialR2T=no, how should it respond to > > FirstBurstSize? > > > > Should the target do this (for draft >= 9)? > > > > T->I FirstBurstSize=irrelevant, InitialR2T=yes, ImmediateData=no > > > > Eddy > > > > -----Original Message----- > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > Sent: Tuesday, February 05, 2002 2:56 PM > > To: IPS Reflector > > Subject: ips : Is FirstBurstSize valid when InitialR2T=yes ? > > > > Hello, > > > > Can someone clarify if the login key FirstBurstSize is valid when : > > InitialR2T=yes and ImmediateData=yes ? > > > > i.e. if immediate data is enabled and un-solicited data is disabled > > during login negotiation, is the value of FirstBurstSize received in the > > login response to be interpreted ? > > > > My current understanding is that FirstBurstSize is inclusive of the > > immediate data portion, and so, if immediate data is enabled, but > > un-solicited data is disabled, then, FirstBurstSize *must* be valid and > > must be <= DataPDULength. (after rev 09, it would be <= > > (MaxRecvPDULength - the header components size)). > > > > For example, a target implementation may offer a FirstBurstSize < > > DataPDULength, in which case, the immediate data size is the > > MIN(DataPDULength, FirstBurstSize, bytes_to_send). > > > > Can someone clarify if this is a correct interpretation or set me right > > on this ? > > > > Thanks, > > Santosh -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## From owner-ips@ece.cmu.edu Fri Jun 14 14:14:23 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08804 for ; Fri, 14 Jun 2002 14:14:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5EHlPn29439 for ips-outgoing; Fri, 14 Jun 2002 13:47:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5EHlNw29434 for ; Fri, 14 Jun 2002 13:47:23 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5EHia5u071840; Fri, 14 Jun 2002 19:44:37 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5EHiZL130032; Fri, 14 Jun 2002 19:44:35 +0200 To: "THALER,PAT (A-Roseville,ex1)" Cc: Eddy Quicksall , IPS Reflector , owner-ips@ece.cmu.edu, Santosh Rao Importance: High MIME-Version: 1.0 Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ? X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Fri, 14 Jun 2002 20:41:33 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 14/06/2002 20:44:35, Serialize complete at 14/06/2002 20:44:35 Content-Type: multipart/alternative; boundary="=_alternative 00613065C2256BD8_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00613065C2256BD8_= Content-Type: text/plain; charset="us-ascii" Pat, You are fighting a very old war! The mail you are answering is dated February 2002! Julo "THALER,PAT (A-Roseville,ex1)" Sent by: owner-ips@ece.cmu.edu 06/14/2002 08:23 PM Please respond to "THALER,PAT (A-Roseville,ex1)" To: Santosh Rao , Eddy Quicksall cc: IPS Reflector Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ? Santosh, I strongly disagree. There is no reason that FirstBurstSize should be 0 or any other particular value if InitalR2T = yes and ImmediateData=No. It won't be used in that case so it is fine for it to remain at the default of 64k or any other allowed value. The only requirment is that the target should respond with a valid value (one that is less than the offerred value and less than MaxBurstSize) because simple-minded login code on the Initiator may check that the value follows the rules even though other keys make the value unused. The target could also respond with Irrelevant. Pat -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Wednesday, February 06, 2002 1:33 PM To: Eddy Quicksall Cc: IPS Reflector Subject: Re: ips : Is FirstBurstSize valid when InitialR2T=yes ? I think this needs changing then. There's no reason the following should'nt be allowed : I -> T : InitialR2T=no ImmediateData=yes FirstBurstSize=65536 T -> I : InitialR2T=yes ImmediateData=no FirstBurstSize=0 Julian : Can we change the allowed valid range for FirstBurstSize from : FirstBurstSize= to : FirstBurstSize= - Santosh Eddy Quicksall wrote: > > Draft 10 says: > > FirstBurstSize= > > So that means you can't send a 0, doesn't it? > > Eddy > > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Wednesday, February 06, 2002 3:01 PM > To: Fischer, Michael > Cc: 'Eddy Quicksall'; IPS Reflector > Subject: Re: ips : Is FirstBurstSize valid when InitialR2T=yes ? > > IMO, the FirstBurstSize key value negotiated during login is a don't > care if *BOTH* immediate data and un-solicited data have been disabled. > > However, if the target knows up-front that it does not support either > immediate or un-solcited and it receives the key FirstBurstSize during > login negotiation, it should return a 0 value as the result of the > negotiation for FirstBurstSize. > > (Note that the special semantics of 0 implying no limit is no longer > true for FirstBurstSize and hence, the target can just return 0 iff both > immediata data and un-solicited data are disabled in login negotiation.) > > - Santosh > > "Fischer, Michael" wrote: > > > > What if the sequence is as follows: > > > > I->T FirstBurstSize=512; T=0; NSG=CSG; > > T->I FirstBurstSize=512; T=0; NSG=CSG; > > I->T InitialR2T=no, ImmediateData=no; T=1; NSG=FULL > > > > If the target does not support InitialR2T=no.. Does login now fail? > There > > does not seem to be a way for the target to say that it requires R2T. Why > > did the Initiator send FirstBurstSize if it was setting InitialR2T to no? > > There is no negotiation with an AND function. > > > > Michael Fischer > > > > -----Original Message----- > > From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] > > Sent: Wednesday, February 06, 2002 9:47 AM > > To: Santosh Rao; IPS Reflector > > Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ? > > > > That is how I am interpreting it. > > > > BTW: How about this one ... > > > > I->T FirstBurstSize=512, InitialR2T=no, ImmediateData=no > > > > If the target does not support InitialR2T=no, how should it respond to > > FirstBurstSize? > > > > Should the target do this (for draft >= 9)? > > > > T->I FirstBurstSize=irrelevant, InitialR2T=yes, ImmediateData=no > > > > Eddy > > > > -----Original Message----- > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > Sent: Tuesday, February 05, 2002 2:56 PM > > To: IPS Reflector > > Subject: ips : Is FirstBurstSize valid when InitialR2T=yes ? > > > > Hello, > > > > Can someone clarify if the login key FirstBurstSize is valid when : > > InitialR2T=yes and ImmediateData=yes ? > > > > i.e. if immediate data is enabled and un-solicited data is disabled > > during login negotiation, is the value of FirstBurstSize received in the > > login response to be interpreted ? > > > > My current understanding is that FirstBurstSize is inclusive of the > > immediate data portion, and so, if immediate data is enabled, but > > un-solicited data is disabled, then, FirstBurstSize *must* be valid and > > must be <= DataPDULength. (after rev 09, it would be <= > > (MaxRecvPDULength - the header components size)). > > > > For example, a target implementation may offer a FirstBurstSize < > > DataPDULength, in which case, the immediate data size is the > > MIN(DataPDULength, FirstBurstSize, bytes_to_send). > > > > Can someone clarify if this is a correct interpretation or set me right > > on this ? > > > > Thanks, > > Santosh -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## --=_alternative 00613065C2256BD8_= Content-Type: text/html; charset="us-ascii"
Pat,

You are fighting a very old war!
The mail you are answering is dated February 2002!

Julo


"THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>
Sent by: owner-ips@ece.cmu.edu

06/14/2002 08:23 PM
Please respond to "THALER,PAT (A-Roseville,ex1)"

       
        To:        Santosh Rao <santoshr@cup.hp.com>, Eddy Quicksall <Eddy_Quicksall@ivivity.com>
        cc:        IPS Reflector <ips@ece.cmu.edu>
        Subject:        RE: ips : Is FirstBurstSize valid when InitialR2T=yes ?

       


Santosh,

I strongly disagree. There is no reason that FirstBurstSize should be 0 or any other particular value if InitalR2T = yes and ImmediateData=No. It won't be used in that case so it is fine for it to remain at the default of 64k or any other allowed value. The only requirment is that the target should respond with a valid value (one that is less than the offerred value and less than MaxBurstSize) because simple-minded login code on the Initiator may check that the value follows the rules even though other keys make the value unused. The target could also respond with Irrelevant.

Pat

-----Original Message-----
From: Santosh Rao [mailto:santoshr@cup.hp.com]
Sent: Wednesday, February 06, 2002 1:33 PM
To: Eddy Quicksall
Cc: IPS Reflector
Subject: Re: ips : Is FirstBurstSize valid when InitialR2T=yes ?



I think this needs changing then. There's no reason the following
should'nt be allowed :

I -> T :
                InitialR2T=no
                ImmediateData=yes
                FirstBurstSize=65536

T -> I :
                InitialR2T=yes
                ImmediateData=no
                FirstBurstSize=0

Julian :
Can we change the allowed valid range for FirstBurstSize from :

FirstBurstSize=<number-512-to-(2**24-1)>

to :

FirstBurstSize=<number-0-to-(2**24-1)>


- Santosh


Eddy Quicksall wrote:
>
> Draft 10 says:
>
> FirstBurstSize=<number-512-to-(2**24-1)>
>
> So that means you can't send a 0, doesn't it?
>
> Eddy
>
> -----Original Message-----
> From: Santosh Rao [mailto:santoshr@cup.hp.com]
> Sent: Wednesday, February 06, 2002 3:01 PM
> To: Fischer, Michael
> Cc: 'Eddy Quicksall'; IPS Reflector
> Subject: Re: ips : Is FirstBurstSize valid when InitialR2T=yes ?
>
> IMO, the FirstBurstSize key value negotiated during login is a don't
> care if *BOTH* immediate data and un-solicited data have been disabled.
>
> However, if the target knows up-front that it does not support either
> immediate or un-solcited and it receives the key FirstBurstSize during
> login negotiation, it should return a 0 value as the result of the
> negotiation for FirstBurstSize.
>
> (Note that the special semantics of 0 implying no limit is no longer
> true for FirstBurstSize and hence, the target can just return 0 iff both
> immediata data and un-solicited data are disabled in login negotiation.)
>
> - Santosh
>
> "Fischer, Michael" wrote:
> >
> > What if the sequence is as follows:
> >
> > I->T    FirstBurstSize=512; T=0; NSG=CSG;
> > T->I    FirstBurstSize=512; T=0; NSG=CSG;
> > I->T    InitialR2T=no, ImmediateData=no; T=1; NSG=FULL
> >
> > If the target does not support InitialR2T=no..  Does login now fail?
> There
> > does not seem to be a way for the target to say that it requires R2T.  Why
> > did the Initiator send FirstBurstSize if it was setting InitialR2T to no?
> > There is no negotiation with an AND function.
> >
> > Michael Fischer
> >
> > -----Original Message-----
> > From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com]
> > Sent: Wednesday, February 06, 2002 9:47 AM
> > To: Santosh Rao; IPS Reflector
> > Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ?
> >
> > That is how I am interpreting it.
> >
> > BTW: How about this one ...
> >
> > I->T FirstBurstSize=512, InitialR2T=no, ImmediateData=no
> >
> > If the target does not support InitialR2T=no, how should it respond to
> > FirstBurstSize?
> >
> > Should the target do this (for draft >= 9)?
> >
> > T->I FirstBurstSize=irrelevant, InitialR2T=yes, ImmediateData=no
> >
> > Eddy
> >
> > -----Original Message-----
> > From: Santosh Rao [mailto:santoshr@cup.hp.com]
> > Sent: Tuesday, February 05, 2002 2:56 PM
> > To: IPS Reflector
> > Subject: ips : Is FirstBurstSize valid when InitialR2T=yes ?
> >
> > Hello,
> >
> > Can someone clarify if the login key FirstBurstSize is valid when :
> > InitialR2T=yes  and ImmediateData=yes ?
> >
> > i.e. if immediate data is enabled and un-solicited data is disabled
> > during login negotiation, is the value of FirstBurstSize received in the
> > login response to be interpreted ?
> >
> > My current understanding is that FirstBurstSize is inclusive of the
> > immediate data portion, and so, if immediate data is enabled, but
> > un-solicited data is disabled, then, FirstBurstSize *must* be valid and
> > must be <= DataPDULength. (after rev 09, it would be <=
> > (MaxRecvPDULength - the header components size)).
> >
> > For example, a target implementation may offer a FirstBurstSize <
> > DataPDULength, in which case, the immediate data size is the
> > MIN(DataPDULength, FirstBurstSize, bytes_to_send).
> >
> > Can someone clarify if this is a correct interpretation or set me right
> > on this ?
> >
> > Thanks,
> > Santosh


--
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
##################################

--=_alternative 00613065C2256BD8_=-- From owner-ips@ece.cmu.edu Fri Jun 14 14:14:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08854 for ; Fri, 14 Jun 2002 14:14:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5EHKng27755 for ips-outgoing; Fri, 14 Jun 2002 13:20:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5EHKkw27750 for ; Fri, 14 Jun 2002 13:20:46 -0400 (EDT) Received: from mail pickup service by mail6.nc.rr.com with Microsoft SMTPSVC; Fri, 14 Jun 2002 10:44:06 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Jun 2002 21:25:49 -0400 Received: from ruebert.ieee.org (ruebert.ieee.org [140.98.193.10]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5C1PmbC013802 for ; Tue, 11 Jun 2002 21:25:48 -0400 (EDT) Received: from ece.cmu.edu (gemini3.ieee.org [140.98.193.25]) by ruebert.ieee.org (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5C1PXq12911; Tue, 11 Jun 2002 21:25:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5C0uN515899 for ips-outgoing; Tue, 11 Jun 2002 20:56:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5C0uLw15895 for ; Tue, 11 Jun 2002 20:56:21 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel10.hp.com (Postfix) with ESMTP id 9167DC0040E; Tue, 11 Jun 2002 17:56:15 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id RAA06663; Tue, 11 Jun 2002 17:55:39 -0700 (PDT) Message-ID: <011101c211ab$9d3dfb80$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Eddy Quicksall" , "Julian Satran" Cc: References: Subject: Re: iSCSI: changing MaxPDUDataLength Date: Tue, 11 Jun 2002 17:53:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Can you suggest how this would be handled otherwise? I earlier said I will not get into implementation details, I will however provide a generic answer. Given that the changed PDU size is not specific to one command, I see the history of "past max PDU size(s)" as a connection attribute. All you need on a per-task basis is really the value of one DataSN *where* it had changed. We could further debate how to deal with multiple number of PDU size changes during the life of an I/O - but I'm reluctant to be involved in that debate because a) it's most unlikely, and b) there's no hard requirement that the target must always satisfy SNACKs under extreme conditions, and finally c) it's too implementation-specific to be discussed on the ips reflector. Finally, I'd like to remind you that mandating "no text negotiation till quiesced" has harmful effects on targets dealing with long writes and wanting ULPDU- containment - whose case you may be arguing. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Eddy Quicksall" To: "Mallikarjun C." ; "Julian Satran" Cc: Sent: Tuesday, June 11, 2002 4:45 PM Subject: RE: iSCSI: changing MaxPDUDataLength > Consider the following (using Julian's suggestion): > > -> cmd 1 > -> req to change to length 2 > -> cmd 2 > > <- stat 1 > <- data 2, PDU 0, Length 1 > > -> cmd 3, ack 1 so change the length > > <- data 2, PDU 1, Length 2 > > -> SNACK data 2, PDU 1 > > So we have to calculate the offset for Data 2, PDU 1 using old length and > send data after that offset using new length. That means keeping track of > PDU lengths which I would like to avoid. > > Or, the target would have to force idling of commands before it gives the > response to the change. > > Can you suggest how this would be handled otherwise? > > Eddy > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Tuesday, June 11, 2002 6:57 PM > To: Eddy Quicksall; Julian Satran > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: changing MaxPDUDataLength > > > Eddy, > > I am not sure if you're agreeing with me or not... but let me add some > comments. > > I don't expect the change in PDU size to happen frequently - no change > in what I earlier said. > > You are making an assumption that a target must record the PDU size for > every > PDU if SNACKs are to be satisfied across changed MaxRecvDataSegmentLength. > > As Julian earlier said, you don't have to. I will not go into > implementation details, but > I believe just the value of the DataSN from which the new size is effective > should > be all that's needed. Besides, the spec guarantees that only RunLength=0 is > used > on any SNACK after the change. > > You are also implying that targets can declare their changed > MaxRecvDataSegmentLength > anytime just for writes. There are two problems with this - a) reads and > writes may both > be active in the typical case on an iSCSI connection, and b) a target can > declare its changed > value only if an initiator is allowed to start the Text Request (and I > thought you were suggesting > that we explicitly disallow that). > > Hope that clears it up. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > > ----- Original Message ----- > From: "Eddy Quicksall" > To: "Mallikarjun C." ; "Julian Satran" > > Cc: > Sent: Tuesday, June 11, 2002 3:18 PM > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > You are correct and that is exactly how I have had to code it. With fast > > path and slow path code split between processors, it becomes even worse. > > > > When I read your comments on why the PDU size could change (from way back > in > > March I think), I got did not get the impression that it would happen very > > often and that in fact it may only happen when you are maintaining > > allegiance to another connection. > > > > If it is something that is not going to happen very often, then it would > be > > so much easier to have the initiator idle the commands first (all it > really > > needs to do is idle the READ commands). If it is going to change so often > > that idling would be degrading, I suspect that just doing the negotiation > > that often would itself be degrading. > > > > And, be aware that the target will probably idle the R commands. > Otherwise, > > it will have to track PDU sizes and that would be really > > "counter-productive" (especially when there should be no SNACKs on a good > > connection anyway). > > > > I don't see any problem with the target negotiating its size at any time. > > And the initiator would not have to idle the WRITE or no-data commands. > > > > Eddy > > > > -----Original Message----- > > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > > Sent: Tuesday, June 11, 2002 3:35 PM > > To: Eddy Quicksall; Julian Satran > > Cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: changing MaxPDUDataLength > > > > > > Eddy, > > > > I am not clear on why you think the target code becomes messy on > > a PDU size change. The last para in section 4.4 states the following - > > > > "Parameters negotiated by a text exchange negotiation sequence become > > effective only after the negotiation sequence is completed." > > > > Since the target gets to complete a text negotiation with a Text Response > > PDU, it can time the applicability of a changed MaxRecvDataSegmentLength. > > > > Requiring that an initiator must idle the connection before changing this > > parameter, IMHO, is counter-productive when there's a dynamic PMTU > > degradation in the presence of long-running commands (writes in > particular). > > Once the initiator starts the renegotiation, target would ideally want to > > quickly > > renegotiate its receive size as well to receive ULPDU-contained segments. > > > > In short, seems to me that the draft is saying what you would like. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > > cbm@rose.hp.com > > > > > > ----- Original Message ----- > > From: "Eddy Quicksall" > > To: "Julian Satran" > > Cc: > > Sent: Tuesday, June 11, 2002 7:56 AM > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > I think it should be a requirement because if it is not, all target code > > > will have to have the messy code. Or, we could say that if it is not > idle > > > commands, then the target may reject it. > > > > > > Eddy > > > > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Tuesday, June 11, 2002 9:11 AM > > > To: Eddy Quicksall > > > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > That is a fair request - we may slip in a recommendation to that effect > > (in > > > chapter 11?) > > > > > > Julo > > > > > > > > > > > > Eddy Quicksall > > > > > > > > > 06/11/2002 04:28 AM > > > Please respond to Eddy Quicksall > > > > > > > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > > > > How about if we say that an initiator must not change the MaxPDUDataSize > > > unless it first idles the commands (at least the ones with the R bit) or > > if > > > ErrorRecoveryLevel==0? > > > > > > That would simplify target code greatly and would meet the design goals; > > and > > > since it should be rare to change it, it would be of little impact to > idle > > > the commands for a split second. > > > > > > > > > Eddy > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Monday, June 10, 2002 8:06 PM > > > To: Eddy Quicksall > > > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > I said only that when you change length you can ask for all PDUs after > the > > > ack! (no need to keep a tall - the old offsets are good up to the hole). > > > > > > > Julo > > > > > > > > > Eddy Quicksall > > > > > > > > > 06/11/2002 12:32 AM > > > Please respond to Eddy Quicksall > > > > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > > > > > > > Julian, > > > > > > Another problem here is that the target has to calculate the offset from > > the > > > DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 > > > means starting DataSN=4, send all the data for that sequence. > > > > > > I think it would be a performance hit and waist of memory to keep a > tally > > of > > > all PDU sizes just for an occasional SNACK. > > > > > > It's not that it can't be done ... it is more that it is messy and I > think > > > there is a solution that will satisfy the design requirements but keep > the > > > software simpler. > > > > > > Eddy > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Saturday, June 08, 2002 10:16 PM > > > To: Eddy Quicksall > > > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > That is not completely accurate. > > > The only problem is when PDU size decreases and then SNACK must be for > all > > > data. > > > Target can also keep a mapping of numbers/to offsets (the list should be > > > small and if it gets long ask for ack (A-bit). > > > > > > Julo > > > > > > Eddy Quicksall > > > Sent by: owner-ips@ece.cmu.edu > > > > > > > > > 06/08/2002 10:54 PM > > > Please respond to Eddy Quicksall > > > > > > > > > To: pat_thaler@agilent.com > > > cc: ips@ece.cmu.edu > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > As a target, I won't be able to let it change until all of the > outstanding > > > commands are finished (running with ErrorRecoveryLevel>=1). This is > > because > > > I must use the PDU size to compute the offset from a SNACK's > > > BegRun/RunLength. > > > > > > So, I plan to not give the text response for a MaxPDURecvDataLength in > FFP > > > until I get back an ExpStatSN == next StatSN. > > > > > > This will cause a delay of unknown time before the PDU size can actually > > > change ... do you see any problem with this? > > > > > > Eddy > > > > > > -----Original Message----- > > > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > > > Sent: Friday, June 07, 2002 1:13 PM > > > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > Eddy, > > > > > > If one uses a message sync and steering that relys on the transport > > segments > > > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the > path > > > MTU changes one would want to change the PDU data length to fit the new > > path > > > MTU. > > > > > > Pat > > > > > > -----Original Message----- > > > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > > > Sent: Wednesday, June 05, 2002 12:24 PM > > > To: ips@ece.cmu.edu > > > Subject: iSCSI: changing MaxPDUDataLength > > > > > > > > > Does anybody know a case where it is necessary to support a new PDU data > > > length during full feature phase? > > > > > > Eddy > > > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Fri Jun 14 14:14:55 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08868 for ; Fri, 14 Jun 2002 14:14:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5EHWqo28561 for ips-outgoing; Fri, 14 Jun 2002 13:32:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5EHWpw28557 for ; Fri, 14 Jun 2002 13:32:51 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 2B9BC12A0; Fri, 14 Jun 2002 11:32:50 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 02CBE2D5; Fri, 14 Jun 2002 11:32:50 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 14 Jun 2002 11:32:48 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 11:32:47 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C8910D9@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Eddy_Quicksall@ivivity.com, Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ? Date: Fri, 14 Jun 2002 11:32:44 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy, It would be valid to give Irrelevant as an answer, but there is no need for "should" or "SHOULD". It is equally valid for it to respond with a valid number even though the number will not be used. Pat -----Original Message----- From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] Sent: Thursday, February 07, 2002 3:56 AM To: Julian Satran; ips@ece.cmu.edu Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ? Given that the target can't do immediate or unsolicited, should it give "Irrelevant" as the answer? I.e.: T->I FirstBurstSize=Irrelevant, InitialR2T=yes, ImmediateData=no Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, February 06, 2002 11:39 PM To: ips@ece.cmu.edu Subject: Re: ips : Is FirstBurstSize valid when InitialR2T=yes ? Why should we? The way it is the parameters can be checked without relation one to another. The is no logical flaw in having FirstBurstSize <> 0 and no use for it. Julo Santosh Rao hp.com> cc: IPS Reflector Sent by: Subject: Re: ips : Is FirstBurstSize valid when owner-ips@ece. InitialR2T=yes ? cmu.edu 06-02-02 23:32 I think this needs changing then. There's no reason the following should'nt be allowed : I -> T : InitialR2T=no ImmediateData=yes FirstBurstSize=65536 T -> I : InitialR2T=yes ImmediateData=no FirstBurstSize=0 Julian : Can we change the allowed valid range for FirstBurstSize from : FirstBurstSize= to : FirstBurstSize= - Santosh Eddy Quicksall wrote: > > Draft 10 says: > > FirstBurstSize= > > So that means you can't send a 0, doesn't it? > > Eddy > > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Wednesday, February 06, 2002 3:01 PM > To: Fischer, Michael > Cc: 'Eddy Quicksall'; IPS Reflector > Subject: Re: ips : Is FirstBurstSize valid when InitialR2T=yes ? > > IMO, the FirstBurstSize key value negotiated during login is a don't > care if *BOTH* immediate data and un-solicited data have been disabled. > > However, if the target knows up-front that it does not support either > immediate or un-solcited and it receives the key FirstBurstSize during > login negotiation, it should return a 0 value as the result of the > negotiation for FirstBurstSize. > > (Note that the special semantics of 0 implying no limit is no longer > true for FirstBurstSize and hence, the target can just return 0 iff both > immediata data and un-solicited data are disabled in login negotiation.) > > - Santosh > > "Fischer, Michael" wrote: > > > > What if the sequence is as follows: > > > > I->T FirstBurstSize=512; T=0; NSG=CSG; > > T->I FirstBurstSize=512; T=0; NSG=CSG; > > I->T InitialR2T=no, ImmediateData=no; T=1; NSG=FULL > > > > If the target does not support InitialR2T=no.. Does login now fail? > There > > does not seem to be a way for the target to say that it requires R2T. Why > > did the Initiator send FirstBurstSize if it was setting InitialR2T to no? > > There is no negotiation with an AND function. > > > > Michael Fischer > > > > -----Original Message----- > > From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] > > Sent: Wednesday, February 06, 2002 9:47 AM > > To: Santosh Rao; IPS Reflector > > Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ? > > > > That is how I am interpreting it. > > > > BTW: How about this one ... > > > > I->T FirstBurstSize=512, InitialR2T=no, ImmediateData=no > > > > If the target does not support InitialR2T=no, how should it respond to > > FirstBurstSize? > > > > Should the target do this (for draft >= 9)? > > > > T->I FirstBurstSize=irrelevant, InitialR2T=yes, ImmediateData=no > > > > Eddy > > > > -----Original Message----- > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > Sent: Tuesday, February 05, 2002 2:56 PM > > To: IPS Reflector > > Subject: ips : Is FirstBurstSize valid when InitialR2T=yes ? > > > > Hello, > > > > Can someone clarify if the login key FirstBurstSize is valid when : > > InitialR2T=yes and ImmediateData=yes ? > > > > i.e. if immediate data is enabled and un-solicited data is disabled > > during login negotiation, is the value of FirstBurstSize received in the > > login response to be interpreted ? > > > > My current understanding is that FirstBurstSize is inclusive of the > > immediate data portion, and so, if immediate data is enabled, but > > un-solicited data is disabled, then, FirstBurstSize *must* be valid and > > must be <= DataPDULength. (after rev 09, it would be <= > > (MaxRecvPDULength - the header components size)). > > > > For example, a target implementation may offer a FirstBurstSize < > > DataPDULength, in which case, the immediate data size is the > > MIN(DataPDULength, FirstBurstSize, bytes_to_send). > > > > Can someone clarify if this is a correct interpretation or set me right > > on this ? > > > > Thanks, > > Santosh -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## From owner-ips@ece.cmu.edu Fri Jun 14 15:10:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11407 for ; Fri, 14 Jun 2002 15:10:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5EIR3101905 for ips-outgoing; Fri, 14 Jun 2002 14:27:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5EIQxw01893 for ; Fri, 14 Jun 2002 14:26:59 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5EIQqvh020656; Fri, 14 Jun 2002 20:26:52 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5EIQqL144896; Fri, 14 Jun 2002 20:26:52 +0200 To: internet-drafts@ietf.org Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSI version 13 draft X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 14 Jun 2002 21:26:50 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 14/06/2002 21:26:51, Serialize complete at 14/06/2002 21:26:51 Content-Type: multipart/alternative; boundary="=_alternative 0064A2A8C2256BD8_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0064A2A8C2256BD8_= Content-Type: text/plain; charset="us-ascii" On behalf of the team of authors and as part of the IETF-IPS working group I submit a draft for immediate publication. The text and pdf versions can be found at: http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-13.txt http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-13.pdf This version completely replaces: draft-ietf-ips-iscsi-12.txt and pdf Julian Satran - IBM Research Laboratory at Haifa --=_alternative 0064A2A8C2256BD8_= Content-Type: text/html; charset="us-ascii"





On behalf of the team of authors and as part of the IETF-IPS working group
I submit a draft for immediate publication.

The text and pdf versions can be found at:

http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-13.txt

http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-13.pdf


This version completely replaces:

draft-ietf-ips-iscsi-12.txt and pdf



Julian Satran - IBM Research Laboratory at Haifa

























--=_alternative 0064A2A8C2256BD8_=-- From owner-ips@ece.cmu.edu Fri Jun 14 16:25:54 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14280 for ; Fri, 14 Jun 2002 16:25:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5EJVwZ05734 for ips-outgoing; Fri, 14 Jun 2002 15:31:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5EJVtw05729 for ; Fri, 14 Jun 2002 15:31:56 -0400 (EDT) Received: from mail pickup service by mail6.nc.rr.com with Microsoft SMTPSVC; Fri, 14 Jun 2002 10:46:59 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Jun 2002 22:52:03 -0400 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5C1uaa2014572 for ; Tue, 11 Jun 2002 21:56:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5C0uN515899 for ips-outgoing; Tue, 11 Jun 2002 20:56:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5C0uLw15895 for ; Tue, 11 Jun 2002 20:56:21 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel10.hp.com (Postfix) with ESMTP id 9167DC0040E; Tue, 11 Jun 2002 17:56:15 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id RAA06663; Tue, 11 Jun 2002 17:55:39 -0700 (PDT) Message-ID: <011101c211ab$9d3dfb80$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Eddy Quicksall" , "Julian Satran" Cc: References: Subject: Re: iSCSI: changing MaxPDUDataLength Date: Tue, 11 Jun 2002 17:53:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Can you suggest how this would be handled otherwise? I earlier said I will not get into implementation details, I will however provide a generic answer. Given that the changed PDU size is not specific to one command, I see the history of "past max PDU size(s)" as a connection attribute. All you need on a per-task basis is really the value of one DataSN *where* it had changed. We could further debate how to deal with multiple number of PDU size changes during the life of an I/O - but I'm reluctant to be involved in that debate because a) it's most unlikely, and b) there's no hard requirement that the target must always satisfy SNACKs under extreme conditions, and finally c) it's too implementation-specific to be discussed on the ips reflector. Finally, I'd like to remind you that mandating "no text negotiation till quiesced" has harmful effects on targets dealing with long writes and wanting ULPDU- containment - whose case you may be arguing. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Eddy Quicksall" To: "Mallikarjun C." ; "Julian Satran" Cc: Sent: Tuesday, June 11, 2002 4:45 PM Subject: RE: iSCSI: changing MaxPDUDataLength > Consider the following (using Julian's suggestion): > > -> cmd 1 > -> req to change to length 2 > -> cmd 2 > > <- stat 1 > <- data 2, PDU 0, Length 1 > > -> cmd 3, ack 1 so change the length > > <- data 2, PDU 1, Length 2 > > -> SNACK data 2, PDU 1 > > So we have to calculate the offset for Data 2, PDU 1 using old length and > send data after that offset using new length. That means keeping track of > PDU lengths which I would like to avoid. > > Or, the target would have to force idling of commands before it gives the > response to the change. > > Can you suggest how this would be handled otherwise? > > Eddy > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Tuesday, June 11, 2002 6:57 PM > To: Eddy Quicksall; Julian Satran > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: changing MaxPDUDataLength > > > Eddy, > > I am not sure if you're agreeing with me or not... but let me add some > comments. > > I don't expect the change in PDU size to happen frequently - no change > in what I earlier said. > > You are making an assumption that a target must record the PDU size for > every > PDU if SNACKs are to be satisfied across changed MaxRecvDataSegmentLength. > > As Julian earlier said, you don't have to. I will not go into > implementation details, but > I believe just the value of the DataSN from which the new size is effective > should > be all that's needed. Besides, the spec guarantees that only RunLength=0 is > used > on any SNACK after the change. > > You are also implying that targets can declare their changed > MaxRecvDataSegmentLength > anytime just for writes. There are two problems with this - a) reads and > writes may both > be active in the typical case on an iSCSI connection, and b) a target can > declare its changed > value only if an initiator is allowed to start the Text Request (and I > thought you were suggesting > that we explicitly disallow that). > > Hope that clears it up. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > > ----- Original Message ----- > From: "Eddy Quicksall" > To: "Mallikarjun C." ; "Julian Satran" > > Cc: > Sent: Tuesday, June 11, 2002 3:18 PM > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > You are correct and that is exactly how I have had to code it. With fast > > path and slow path code split between processors, it becomes even worse. > > > > When I read your comments on why the PDU size could change (from way back > in > > March I think), I got did not get the impression that it would happen very > > often and that in fact it may only happen when you are maintaining > > allegiance to another connection. > > > > If it is something that is not going to happen very often, then it would > be > > so much easier to have the initiator idle the commands first (all it > really > > needs to do is idle the READ commands). If it is going to change so often > > that idling would be degrading, I suspect that just doing the negotiation > > that often would itself be degrading. > > > > And, be aware that the target will probably idle the R commands. > Otherwise, > > it will have to track PDU sizes and that would be really > > "counter-productive" (especially when there should be no SNACKs on a good > > connection anyway). > > > > I don't see any problem with the target negotiating its size at any time. > > And the initiator would not have to idle the WRITE or no-data commands. > > > > Eddy > > > > -----Original Message----- > > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > > Sent: Tuesday, June 11, 2002 3:35 PM > > To: Eddy Quicksall; Julian Satran > > Cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: changing MaxPDUDataLength > > > > > > Eddy, > > > > I am not clear on why you think the target code becomes messy on > > a PDU size change. The last para in section 4.4 states the following - > > > > "Parameters negotiated by a text exchange negotiation sequence become > > effective only after the negotiation sequence is completed." > > > > Since the target gets to complete a text negotiation with a Text Response > > PDU, it can time the applicability of a changed MaxRecvDataSegmentLength. > > > > Requiring that an initiator must idle the connection before changing this > > parameter, IMHO, is counter-productive when there's a dynamic PMTU > > degradation in the presence of long-running commands (writes in > particular). > > Once the initiator starts the renegotiation, target would ideally want to > > quickly > > renegotiate its receive size as well to receive ULPDU-contained segments. > > > > In short, seems to me that the draft is saying what you would like. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > > cbm@rose.hp.com > > > > > > ----- Original Message ----- > > From: "Eddy Quicksall" > > To: "Julian Satran" > > Cc: > > Sent: Tuesday, June 11, 2002 7:56 AM > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > I think it should be a requirement because if it is not, all target code > > > will have to have the messy code. Or, we could say that if it is not > idle > > > commands, then the target may reject it. > > > > > > Eddy > > > > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Tuesday, June 11, 2002 9:11 AM > > > To: Eddy Quicksall > > > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > That is a fair request - we may slip in a recommendation to that effect > > (in > > > chapter 11?) > > > > > > Julo > > > > > > > > > > > > Eddy Quicksall > > > > > > > > > 06/11/2002 04:28 AM > > > Please respond to Eddy Quicksall > > > > > > > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > > > > How about if we say that an initiator must not change the MaxPDUDataSize > > > unless it first idles the commands (at least the ones with the R bit) or > > if > > > ErrorRecoveryLevel==0? > > > > > > That would simplify target code greatly and would meet the design goals; > > and > > > since it should be rare to change it, it would be of little impact to > idle > > > the commands for a split second. > > > > > > > > > Eddy > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Monday, June 10, 2002 8:06 PM > > > To: Eddy Quicksall > > > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > I said only that when you change length you can ask for all PDUs after > the > > > ack! (no need to keep a tall - the old offsets are good up to the hole). > > > > > > > Julo > > > > > > > > > Eddy Quicksall > > > > > > > > > 06/11/2002 12:32 AM > > > Please respond to Eddy Quicksall > > > > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > > > > > > > Julian, > > > > > > Another problem here is that the target has to calculate the offset from > > the > > > DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 > > > means starting DataSN=4, send all the data for that sequence. > > > > > > I think it would be a performance hit and waist of memory to keep a > tally > > of > > > all PDU sizes just for an occasional SNACK. > > > > > > It's not that it can't be done ... it is more that it is messy and I > think > > > there is a solution that will satisfy the design requirements but keep > the > > > software simpler. > > > > > > Eddy > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Saturday, June 08, 2002 10:16 PM > > > To: Eddy Quicksall > > > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > That is not completely accurate. > > > The only problem is when PDU size decreases and then SNACK must be for > all > > > data. > > > Target can also keep a mapping of numbers/to offsets (the list should be > > > small and if it gets long ask for ack (A-bit). > > > > > > Julo > > > > > > Eddy Quicksall > > > Sent by: owner-ips@ece.cmu.edu > > > > > > > > > 06/08/2002 10:54 PM > > > Please respond to Eddy Quicksall > > > > > > > > > To: pat_thaler@agilent.com > > > cc: ips@ece.cmu.edu > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > As a target, I won't be able to let it change until all of the > outstanding > > > commands are finished (running with ErrorRecoveryLevel>=1). This is > > because > > > I must use the PDU size to compute the offset from a SNACK's > > > BegRun/RunLength. > > > > > > So, I plan to not give the text response for a MaxPDURecvDataLength in > FFP > > > until I get back an ExpStatSN == next StatSN. > > > > > > This will cause a delay of unknown time before the PDU size can actually > > > change ... do you see any problem with this? > > > > > > Eddy > > > > > > -----Original Message----- > > > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > > > Sent: Friday, June 07, 2002 1:13 PM > > > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > Eddy, > > > > > > If one uses a message sync and steering that relys on the transport > > segments > > > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the > path > > > MTU changes one would want to change the PDU data length to fit the new > > path > > > MTU. > > > > > > Pat > > > > > > -----Original Message----- > > > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > > > Sent: Wednesday, June 05, 2002 12:24 PM > > > To: ips@ece.cmu.edu > > > Subject: iSCSI: changing MaxPDUDataLength > > > > > > > > > Does anybody know a case where it is necessary to support a new PDU data > > > length during full feature phase? > > > > > > Eddy > > > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Fri Jun 14 16:40:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14634 for ; Fri, 14 Jun 2002 16:40:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5EKEjX08206 for ips-outgoing; Fri, 14 Jun 2002 16:14:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5EKEhw08201 for ; Fri, 14 Jun 2002 16:14:43 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 513D030706; Fri, 14 Jun 2002 16:14:43 -0400 (EDT) Date: Fri, 14 Jun 2002 13:12:30 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Subject: Reject PDUs and the F bit Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk I haev a question about the following text in section 9.17.1 of 12-97 (which I don't think's changed): In all the cases in which a pre-instantiated SCSI task is terminated because of the reject, the target MUST issue a proper SCSI command response with CHECK CONDITION as described in Section 9.4.3 Response. In those cases in which a status for the SCSI task was already sent before the reject no additional status is required. If the error is detected while data from the initiator is still expected (the com- mand PDU did not contain all the data and the target has not received a Data-out PDU with the Final bit 1), the target MUST wait until it receives the Data-out PDU with the F bit set to 1 before sending the Response PDU. I'm confused on two points: 1) When do we need to send a Reject PDU if we're also sending a SCSI Response that indicates error status? i.e. why send two PDUs? Is it to provide both iSCSI and SCSI status? 2) I have a question about the, "If the error is detected while data from the initiator is still expected ..." part. Say the command was an iSCSI write, and I have three outstanding R2Ts. Part way through I realize that I want to error away the task (for whatever reason). Am I correct in reading the above text as saying I have to wait for all of my outstanding R2Ts to close (send the F bit), or do I only have to wait for one to close? Take care, Bill From owner-ips@ece.cmu.edu Fri Jun 14 17:11:51 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15390 for ; Fri, 14 Jun 2002 17:11:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5EKjnQ09861 for ips-outgoing; Fri, 14 Jun 2002 16:45:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5EKjlw09856 for ; Fri, 14 Jun 2002 16:45:47 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 16:45:46 -0400 Message-ID: From: Eddy Quicksall To: ips@ece.cmu.edu Subject: Getting old messages Date: Fri, 14 Jun 2002 16:45:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I'm getting old and repeated messages. Is anyone else experiencing that problem? Eddy mailto:Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Fri Jun 14 17:12:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15388 for ; Fri, 14 Jun 2002 17:11:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5EKh0K09736 for ips-outgoing; Fri, 14 Jun 2002 16:43:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5EKgww09732 for ; Fri, 14 Jun 2002 16:42:58 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 16:42:57 -0400 Message-ID: From: Eddy Quicksall To: Bill Studenmund , Nandakumar Ramamurthy Cc: ips@ece.cmu.edu Subject: RE: iSCSI: FirstBurstSize and unsolicited data Date: Fri, 14 Jun 2002 16:42:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk The initiator should probably reduce FirstBurstSize to 8k. Although the spec does not seem to mandate this. Eddy -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Friday, June 14, 2002 1:22 PM To: Nandakumar Ramamurthy Cc: ips@ece.cmu.edu Subject: Re: iSCSI: FirstBurstSize and unsolicited data On Fri, 14 Jun 2002, Nandakumar Ramamurthy wrote: > Hi All, > > Consider the case where InitialR2T=yes and ImmediateData=yes. > All other values are the defaults. > > The expected data transfer length for a SCSI write > operation is a value exceeding FirstBurstSize (64KB). > > In the above case, the initiator will send immediate > unsolicited data (MaxRecvPDULength=8192 bytes). > After that it has to wait for an R2T from the target. That is correct. > In this scenario, FirstBurstSize of data will not be sent > to the target as unsolicited data-out's cannot be sent here. > > My understanding is that the remaining data can be > sent only through solicited Data-out PDUs, > and this is the expected way according to the draft. > > What does the following statement(in Section 9.4.6.2 Sense Data) mean in > this context ? > > > > The target reports the "Not enough unsolicited data" condition only > if it does not support output (write) operations in which the total > data length is greater than FirstBurstSize, but the initiator sent > less than FirstBurstSize amount of unsolicited data, and out-of-order > R2Ts cannot be used. > > I think what that's getting at is if you do a write command and send unsolicited data-out PDUs, you've promised to send FirstBurstSize worth of data. If you don't, to continue the operation, the target needs to send an R2T for the missing data. But that would be an out-of-order R2T since by sending unsolicited data, you are acting as if you received an R2T for FirstBurstSize data; this error R2T would be going backwards. Take care, Bill From owner-ips@ece.cmu.edu Fri Jun 14 17:25:15 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15813 for ; Fri, 14 Jun 2002 17:25:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5ELFMb11734 for ips-outgoing; Fri, 14 Jun 2002 17:15:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5ELFLw11730 for ; Fri, 14 Jun 2002 17:15:21 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 621F215CE for ; Fri, 14 Jun 2002 15:15:20 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 3A9B12DC for ; Fri, 14 Jun 2002 15:15:20 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 14 Jun 2002 15:15:20 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 15:15:20 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C891179@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: ips@ece.cmu.edu Subject: RE: iSCSI: FirstBurstSize and unsolicited data Date: Fri, 14 Jun 2002 15:15:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk RE: > > The target reports the "Not enough unsolicited data" condition only > if it does not support output (write) operations in which the total > data length is greater than FirstBurstSize, but the initiator sent > less than FirstBurstSize amount of unsolicited data, and out-of-order > R2Ts cannot be used. > > This text does seem strange. Why does it say "only if it does not support output (write) operations in which" the initiator sent less data than the standard requires? Why would the target support that given that the initiator is required to send FirstBurstSize of unsolicited data if it sends non-immediate data PDUs (and total data length is greater than FirstBurstSize). Even out-of-order R2Ts are enabled, the target shouldn't be required to send an R2T for data that should have been sent unsolicited. This will complicate implementations. The text also doesn't deal with cases where the Initiator sent only Immediate data. Also it doesn't deal with cases where the transfer is less than First Burst size and the initiator sent non-immediate unsolicited data with a length less than the required amount. I think the text should be "The target reports the "Not enough unsolicited data" condition if the Initiator sent non-Immediate unsolicited data with a totla unsolicited data length less than the smaller of FirstBurstSize and Expected Data Transfer Length." It also isn't clear why this error has an iSCSI condition code while other similar errors do not. In particular, it is just as possible that an Initiator sends less data in response to an explicit R2T. When it sends less unsolicited data than it should, it is violating an implicit R2T. Why is violation of an implicit R2T different from violation of an explicit R2T? And why is sending less data than expected flagged with a Sense Data error but sending more data than expected is not? Regards, Pat From owner-ips@ece.cmu.edu Fri Jun 14 17:30:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15938 for ; Fri, 14 Jun 2002 17:30:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5EKoEs10077 for ips-outgoing; Fri, 14 Jun 2002 16:50:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtp1.electric.net (smtp1.electric.net [216.129.90.14]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5EKoCw10070 for ; Fri, 14 Jun 2002 16:50:12 -0400 (EDT) Received: from hm1.electric.net ([216.129.90.33]) by smtp1.electric.net with smtp (Exim 4.04) id 17Iy1L-000FhJ-01 for ips@ece.cmu.edu; Fri, 14 Jun 2002 13:50:11 -0700 Received: from osmtp1.electric.net ([216.129.90.28]) by hm1.electric.net (NAVGW 2.5.2.9) with SMTP id M2002061413501015801 for ; Fri, 14 Jun 2002 13:50:10 -0700 Received: from [206.175.229.19] (helo=EGRodriguez) by osmtp1.electric.net with esmtp (Exim 3.22 #1) id 17Iy1K-000IH1-04 for ips@ece.cmu.edu; Fri, 14 Jun 2002 13:50:10 -0700 From: "Elizabeth G. Rodriguez" To: Subject: IPS-ALL Reminder: Last call comments on iFCP and FCIP due by Monday Date: Fri, 14 Jun 2002 15:47:40 -0600 Message-ID: <00d601c213ed$1c3a39b0$23e9c0d8@EGRodriguez> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D7_01C213BA.D19FC9B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00D7_01C213BA.D19FC9B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Just a reminder that last call comments are due by Monday at 5pm for the FCIP and iFCP drafts. Thanks, Elizabeth Rodriguez ------=_NextPart_000_00D7_01C213BA.D19FC9B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just a reminder that last call comments are due by = Monday at 5pm for the FCIP and iFCP drafts.

 

Thanks,

 

Elizabeth Rodriguez

------=_NextPart_000_00D7_01C213BA.D19FC9B0-- From owner-ips@ece.cmu.edu Fri Jun 14 17:31:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16001 for ; Fri, 14 Jun 2002 17:31:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5EL03M10639 for ips-outgoing; Fri, 14 Jun 2002 17:00:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5EL01w10634 for ; Fri, 14 Jun 2002 17:00:01 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 6366B30706; Fri, 14 Jun 2002 17:00:01 -0400 (EDT) Date: Fri, 14 Jun 2002 13:57:48 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Eddy Quicksall Cc: Nandakumar Ramamurthy , Subject: RE: iSCSI: FirstBurstSize and unsolicited data In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Fri, 14 Jun 2002, Eddy Quicksall wrote: > The initiator should probably reduce FirstBurstSize to 8k. > > Although the spec does not seem to mandate this. Why? I don't see how that helps us (forcing it to be 8k, or MaxRecvPDUDataSize), because immediate data are bounded by both FirstBurstSize and MaxRecvPDUDataSize. i.e. we will always have to check both. So putting a requirement that FirstBurstSize not be over 8k (or MaxRecvPDUDataSize) doesn't mean we can skip checking immediate data size against both FirstBurstSize and MaxRecvPDUDataSize, but it means we would need to add code to login to check this bounding. How does this help us? Take care, Bill From owner-ips@ece.cmu.edu Fri Jun 14 18:18:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17693 for ; Fri, 14 Jun 2002 18:18:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5ELr0G13575 for ips-outgoing; Fri, 14 Jun 2002 17:53:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5ELqww13571 for ; Fri, 14 Jun 2002 17:52:58 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 1ABF530706; Fri, 14 Jun 2002 17:52:58 -0400 (EDT) Date: Fri, 14 Jun 2002 14:50:45 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Eddy Quicksall Cc: Nandakumar Ramamurthy , Subject: RE: iSCSI: FirstBurstSize and unsolicited data In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Fri, 14 Jun 2002, Eddy Quicksall wrote: > > I didn't say to put a requirement on it ... I just said maybe the initiator > should have done that. What good is a FirstBurstSize of 64k if you can't > send it? Ahhh.. To answer the question, nothing, other than the fact it's out of the way. :-) Take care, Bill From owner-ips@ece.cmu.edu Fri Jun 14 18:18:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17726 for ; Fri, 14 Jun 2002 18:18:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5ELs4k13657 for ips-outgoing; Fri, 14 Jun 2002 17:54:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f25.pav2.hotmail.com [64.4.37.25]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5ELK3w11962 for ; Fri, 14 Jun 2002 17:20:04 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 14 Jun 2002 14:19:58 -0700 Received: from 129.219.25.77 by pv2fd.pav2.hotmail.msn.com with HTTP; Fri, 14 Jun 2002 21:19:57 GMT X-Originating-IP: [129.219.25.77] From: "shesha bhushan" To: ips@ece.cmu.edu Subject: SCSI-Target ID in ISCSI Date: Fri, 14 Jun 2002 21:19:57 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 14 Jun 2002 21:19:58.0053 (UTC) FILETIME=[3C586950:01C213E9] Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi All, I have a disk array. Each disk in that array has a saperate ID. The devices are internally conncted using SCSI. If I have iSCSI HBA on the array, (with a router attached to it). The router will have an IP address. Say IP Address + target ID indentifies uniquily a disk. How is the SCSI-Target ID(NOT the LUN#) is transmitted from the iSCSI-Initiator to the iSCSI-Target. Thanks in advance for any of your comments Shesha _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. From owner-ips@ece.cmu.edu Fri Jun 14 18:19:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17744 for ; Fri, 14 Jun 2002 18:19:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5ELdee12903 for ips-outgoing; Fri, 14 Jun 2002 17:39:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5ELdbw12894 for ; Fri, 14 Jun 2002 17:39:37 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 17:39:36 -0400 Message-ID: From: Eddy Quicksall To: Bill Studenmund Cc: Nandakumar Ramamurthy , ips@ece.cmu.edu Subject: RE: iSCSI: FirstBurstSize and unsolicited data Date: Fri, 14 Jun 2002 17:39:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I didn't say to put a requirement on it ... I just said maybe the initiator should have done that. What good is a FirstBurstSize of 64k if you can't send it? Maybe I'm missing something. Eddy -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Friday, June 14, 2002 4:58 PM To: Eddy Quicksall Cc: Nandakumar Ramamurthy; ips@ece.cmu.edu Subject: RE: iSCSI: FirstBurstSize and unsolicited data On Fri, 14 Jun 2002, Eddy Quicksall wrote: > The initiator should probably reduce FirstBurstSize to 8k. > > Although the spec does not seem to mandate this. Why? I don't see how that helps us (forcing it to be 8k, or MaxRecvPDUDataSize), because immediate data are bounded by both FirstBurstSize and MaxRecvPDUDataSize. i.e. we will always have to check both. So putting a requirement that FirstBurstSize not be over 8k (or MaxRecvPDUDataSize) doesn't mean we can skip checking immediate data size against both FirstBurstSize and MaxRecvPDUDataSize, but it means we would need to add code to login to check this bounding. How does this help us? Take care, Bill From owner-ips@ece.cmu.edu Fri Jun 14 18:19:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17770 for ; Fri, 14 Jun 2002 18:19:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5ELqIw13532 for ips-outgoing; Fri, 14 Jun 2002 17:52:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar1ab.compuserve.com (siaar1ab.compuserve.com [149.174.40.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5EKiWw09809 for ; Fri, 14 Jun 2002 16:44:32 -0400 (EDT) Received: (from mailgate@localhost) by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id QAA17274 for ips@ece.cmu.edu; Fri, 14 Jun 2002 16:44:26 -0400 (EDT) Received: from EGRodriguez (dal-tgn-tvo-vty19.as.wcom.net [206.175.229.19]) by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id QAA17249 for ; Fri, 14 Jun 2002 16:44:24 -0400 (EDT) From: "Elizabeth Rodriguez" To: Subject: Reminder: Last call comments on iFCP and FCIP due by Monday Date: Fri, 14 Jun 2002 15:41:54 -0600 Message-ID: <00cc01c213ec$4e4883e0$23e9c0d8@EGRodriguez> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CD_01C213BA.03AE13E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00CD_01C213BA.03AE13E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Just a reminder that last call comments are due by Monday at 5pm for the FCIP and iFCP drafts. Thanks, Elizabeth Rodriguez ------=_NextPart_000_00CD_01C213BA.03AE13E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just a reminder that last call comments are due by = Monday at 5pm for the FCIP and iFCP drafts.

 

Thanks,

 

Elizabeth Rodriguez    &nbs= p; 

------=_NextPart_000_00CD_01C213BA.03AE13E0-- From owner-ips@ece.cmu.edu Fri Jun 14 18:20:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17784 for ; Fri, 14 Jun 2002 18:19:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5ELpaY13470 for ips-outgoing; Fri, 14 Jun 2002 17:51:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5ELpYw13465 for ; Fri, 14 Jun 2002 17:51:35 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 1389C16F5; Fri, 14 Jun 2002 15:51:34 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 91DFB107; Fri, 14 Jun 2002 15:51:33 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 14 Jun 2002 15:51:30 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 15:51:30 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C89118C@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: iSCSI: use of Text/Login with no data segment Date: Fri, 14 Jun 2002 15:51:28 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, 4.2 (page 72) of iSCSI-13 says: A target or initiator SHOULD NOT use a Text/Login Response or Text/ Login Request with no data segment (DataSegmentLength 0) unless responding to a Text/Login Request respective Text/Login Response with the C bit set to 1. "SHOULD NOT" is too strong here as there are times when one must send a Text/Login Response or Request with no data segment if one is to complete the login. For example, a Target might send a Login response with the T=0 and C=0. If the initiator doesn't have an keys it wants to send, then the initiator will have to send a Login Request with no data segment if the login is to complete. Also, wrt grammar, "respective" is not a conjunction so the normal way to use it would be "... A or B ... C or D, respectively, ...." At least that is the usage that I have seen and what the dictionary at hand supports. If one wants to retain the idea of not sending empty PDUs when you do have something to say, one could put in: A target or initiator SHOULD NOT use a Text/Login Response or Text/ Login Request with no data segment (DataSegmentLength 0) unless responding to a Text/Login Request or Text/Login Response, respectively, with the T bit set to 0 while the node has no keys to send or with the C bit set to 1. Pat From owner-ips@ece.cmu.edu Fri Jun 14 18:24:36 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17992 for ; Fri, 14 Jun 2002 18:24:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5EM9Ql14369 for ips-outgoing; Fri, 14 Jun 2002 18:09:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5EM9Pw14365 for ; Fri, 14 Jun 2002 18:09:25 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 73F6215BC; Fri, 14 Jun 2002 16:09:24 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 5171A3D1; Fri, 14 Jun 2002 16:09:24 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 14 Jun 2002 16:09:24 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 16:09:24 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C891193@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: eddy_quicksall@ivivity.com, wrstuden@wasabisystems.com, nramamur@npd.hcltech.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: FirstBurstSize and unsolicited data Date: Fri, 14 Jun 2002 16:09:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk While there is no need to reduce FirstBurstSize to MaxRecvDataSegmentLength (current name for MaxRecvPDULength below), 11.15 says: "FirstBurstSize MUST NOT exceed MaxBurstSize." and it doesn't moderate that with a statement such as "unless InitialR2T=yes" so it would probably be wise to reduce FirstBurstSize if needed to satisfy that condition in case your partner checks the relative values of the parameters even when FirstBurstSize isn't important. Regards, Pat -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Friday, June 14, 2002 1:43 PM To: Bill Studenmund; Nandakumar Ramamurthy Cc: ips@ece.cmu.edu Subject: RE: iSCSI: FirstBurstSize and unsolicited data The initiator should probably reduce FirstBurstSize to 8k. Although the spec does not seem to mandate this. Eddy -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Friday, June 14, 2002 1:22 PM To: Nandakumar Ramamurthy Cc: ips@ece.cmu.edu Subject: Re: iSCSI: FirstBurstSize and unsolicited data On Fri, 14 Jun 2002, Nandakumar Ramamurthy wrote: > Hi All, > > Consider the case where InitialR2T=yes and ImmediateData=yes. > All other values are the defaults. > > The expected data transfer length for a SCSI write > operation is a value exceeding FirstBurstSize (64KB). > > In the above case, the initiator will send immediate > unsolicited data (MaxRecvPDULength=8192 bytes). > After that it has to wait for an R2T from the target. That is correct. > In this scenario, FirstBurstSize of data will not be sent > to the target as unsolicited data-out's cannot be sent here. > > My understanding is that the remaining data can be > sent only through solicited Data-out PDUs, > and this is the expected way according to the draft. > > What does the following statement(in Section 9.4.6.2 Sense Data) mean in > this context ? > > > > The target reports the "Not enough unsolicited data" condition only > if it does not support output (write) operations in which the total > data length is greater than FirstBurstSize, but the initiator sent > less than FirstBurstSize amount of unsolicited data, and out-of-order > R2Ts cannot be used. > > I think what that's getting at is if you do a write command and send unsolicited data-out PDUs, you've promised to send FirstBurstSize worth of data. If you don't, to continue the operation, the target needs to send an R2T for the missing data. But that would be an out-of-order R2T since by sending unsolicited data, you are acting as if you received an R2T for FirstBurstSize data; this error R2T would be going backwards. Take care, Bill From owner-ips@ece.cmu.edu Fri Jun 14 19:02:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18859 for ; Fri, 14 Jun 2002 19:02:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5EMnrX16335 for ips-outgoing; Fri, 14 Jun 2002 18:49:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5EMnqw16328 for ; Fri, 14 Jun 2002 18:49:52 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 18:49:46 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564BF7A@CORPMX14> From: Black_David@emc.com To: fred@cisco.com Cc: ips@ece.cmu.edu Subject: RE: Getting old messages Date: Fri, 14 Jun 2002 18:48:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Nope, Road Runner appears to have a problem with email servers in NC sitting on messages for 24-48 hours and then sending them back to the list - I've just gotten off the phone with RR's NOC who assures me that their abuse team is in motion to deal with this ... stay tuned. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Friday, June 14, 2002 6:45 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu > Subject: Re: Getting old messages > > > At 04:45 PM 6/14/2002 -0400, Eddy Quicksall wrote: > >I'm getting old and repeated messages. Is anyone else > experiencing that > >problem? > > let me guess - they have two attachments, and if you open the > attachments > you get infected with the klez worm? > From owner-ips@ece.cmu.edu Fri Jun 14 19:02:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18877 for ; Fri, 14 Jun 2002 19:02:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5EMKmQ14915 for ips-outgoing; Fri, 14 Jun 2002 18:20:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5EMKlw14911 for ; Fri, 14 Jun 2002 18:20:47 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 18:19:09 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564BF74@CORPMX14> From: Black_David@emc.com To: bhushan_vadulas@hotmail.com, ips@ece.cmu.edu Subject: RE: SCSI-Target ID in ISCSI Date: Fri, 14 Jun 2002 18:19:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk The value of the iSCSI TargetName key names the iSCSI Target; your disk array implementation is responsible for keeping an internal mapping of how its internal SCSI Target IDs correspond to the externally visible iSCSI TargetNames. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: shesha bhushan [mailto:bhushan_vadulas@hotmail.com] > Sent: Friday, June 14, 2002 5:20 PM > To: ips@ece.cmu.edu > Subject: SCSI-Target ID in ISCSI > > > Hi All, > I have a disk array. Each disk in that array has a saperate ID. The > devices are internally conncted using SCSI. If I have iSCSI > HBA on the > array, (with a router attached to it). The router will have > an IP address. > Say IP Address + target ID indentifies uniquily a disk. > > How is the SCSI-Target ID(NOT the LUN#) is transmitted from the > iSCSI-Initiator to the iSCSI-Target. > > Thanks in advance for any of your comments > Shesha > > _________________________________________________________________ > Get your FREE download of MSN Explorer at > http://explorer.msn.com/intl.asp. > From owner-ips@ece.cmu.edu Fri Jun 14 19:03:06 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18890 for ; Fri, 14 Jun 2002 19:03:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5EMKRp14893 for ips-outgoing; Fri, 14 Jun 2002 18:20:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5EMKPw14885 for ; Fri, 14 Jun 2002 18:20:25 -0400 (EDT) Received: from xparelay1.corp.hp.com (xparelay1.corp.hp.com [15.58.136.173]) by palrel10.hp.com (Postfix) with ESMTP id EAEDAC003AB; Fri, 14 Jun 2002 15:20:19 -0700 (PDT) Received: from xpabh3.corp.hp.com (xpabh3.corp.hp.com [15.58.136.223]) by xparelay1.corp.hp.com (Postfix) with ESMTP id EA900E000A7; Fri, 14 Jun 2002 15:20:19 -0700 (PDT) Received: by xpabh3.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 15:20:19 -0700 Message-ID: <499DC368E25AD411B3F100902740AD6508E9A476@xrose03.rose.hp.com> From: "ERICKSON,SHAWN (HP-Roseville,ex1)" To: "'shesha bhushan'" , ips@ece.cmu.edu Subject: RE: SCSI-Target ID in ISCSI Date: Fri, 14 Jun 2002 15:20:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Not sure I follow... it this array wanting to act as a JBOD or some type of RAID device? In other words are clients expecting to connect to your array at its IP address and talk to a logical unit identified by a LUN, with the LU being synthesized by hardware in the array out of one or more of the internal SCSI disks? Or are they expecting to talk with the individual SCSI disks in the "array" over iSCSI? -Shawn ------------------------------------------------------- Shawn Carl Erickson (805) 883-4319 [Telnet] Hewlett Packard Company OV NSSO Joint Venture Storage Resource Management R&D Lab (Santa Barbara) ------------------------------------------------------- ------------------------------------------------------- > -----Original Message----- > From: shesha bhushan [mailto:bhushan_vadulas@hotmail.com] > Sent: Friday, June 14, 2002 2:20 PM > To: ips@ece.cmu.edu > Subject: SCSI-Target ID in ISCSI > > > Hi All, > I have a disk array. Each disk in that array has a saperate ID. The > devices are internally conncted using SCSI. If I have iSCSI > HBA on the > array, (with a router attached to it). The router will have > an IP address. > Say IP Address + target ID indentifies uniquily a disk. > > How is the SCSI-Target ID(NOT the LUN#) is transmitted from the > iSCSI-Initiator to the iSCSI-Target. > > Thanks in advance for any of your comments > Shesha > > _________________________________________________________________ > Get your FREE download of MSN Explorer at > http://explorer.msn.com/intl.asp. > From owner-ips@ece.cmu.edu Fri Jun 14 19:03:12 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18903 for ; Fri, 14 Jun 2002 19:03:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5EMirU16103 for ips-outgoing; Fri, 14 Jun 2002 18:44:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5EMipw16094 for ; Fri, 14 Jun 2002 18:44:51 -0400 (EDT) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5EMijPJ015811; Fri, 14 Jun 2002 15:44:45 -0700 (PDT) Message-Id: <5.1.1.6.2.20020614154359.026ebca8@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 14 Jun 2002 15:44:42 -0700 To: Eddy Quicksall From: Fred Baker Subject: Re: Getting old messages Cc: ips@ece.cmu.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ips@ece.cmu.edu Precedence: bulk At 04:45 PM 6/14/2002 -0400, Eddy Quicksall wrote: >I'm getting old and repeated messages. Is anyone else experiencing that >problem? let me guess - they have two attachments, and if you open the attachments you get infected with the klez worm? From owner-ips@ece.cmu.edu Fri Jun 14 20:05:44 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19609 for ; Fri, 14 Jun 2002 20:05:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5ENd0m18380 for ips-outgoing; Fri, 14 Jun 2002 19:39:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5ENcww18376 for ; Fri, 14 Jun 2002 19:38:58 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id CDAD116B7; Fri, 14 Jun 2002 17:38:57 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id C6D1EEE; Fri, 14 Jun 2002 17:38:56 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 14 Jun 2002 17:38:56 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 17:38:56 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C8911C6@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: mkrikis@yahoo.com, pat_thaler@agilent.com, Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI: use of Text/Login with no data segment Date: Fri, 14 Jun 2002 17:38:55 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Martins, Your alternate wording looks fine to me. Pat -----Original Message----- From: Martins Krikis [mailto:mkrikis@yahoo.com] Sent: Friday, June 14, 2002 4:32 PM To: pat_thaler@agilent.com; Julian_Satran@il.ibm.com; ips@ece.cmu.edu Subject: Re: iSCSI: use of Text/Login with no data segment --- pat_thaler@agilent.com wrote: > If one wants to retain the idea of not sending empty > PDUs when you do have > something to say, one could put in: > A target or initiator SHOULD NOT use a Text/Login > Response or Text/ > Login Request with no data segment > (DataSegmentLength 0) unless > responding to a Text/Login Request or Text/Login > Response, respectively, > with the T bit set to 0 while the node has no keys > to send or with the C bit > set to 1. I don't see a problem with an implementation that deliberately sends an empty PDU to let the other side "speak" first. Doing this back-and-forth would not be a great situation, but IMHO it suffices to simply discourage such behavior, without resorting to "SHOULD NOT"-s. So, how about this instead? A target or initiator is discouraged from sending Text/Login Response or Text/Login Request with no data segment (DataSegmentLength 0) unless responding to a Text/Login Request or Text/Login Response, respectively, with the C bit set to 1, or the F/T bit set to 0 while having no keys to send. Or, let's just skip such restrictions/discouragements entirely. Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Fri Jun 14 20:07:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19625 for ; Fri, 14 Jun 2002 20:07:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5ENof818855 for ips-outgoing; Fri, 14 Jun 2002 19:50:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5ENoew18851 for ; Fri, 14 Jun 2002 19:50:40 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 558B615CE; Fri, 14 Jun 2002 17:50:39 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 2F4612F1; Fri, 14 Jun 2002 17:50:39 -0600 (MDT) Received: from 130.29.152.143 by axcsbh1.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 14 Jun 2002 17:50:39 -0600 Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 17:50:38 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C8911CA@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Julian Satran Cc: ips@ece.cmu.edu Subject: iSCSI: length and size Date: Fri, 14 Jun 2002 17:50:37 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, iSCSI-13 uses "length" quite a bit more than 100 times. Many of those times are in regard to the length of data, headers, and PDUs e.g. The basic header segment has a fixed length of 48 bytes. Expected Data Transfer Length Each PDU contains the payload length and the data offset.... It also uses size about 40 times with the same meaning as length. Most of these are the terms MaxBurstSize and FirstBurstSize and text associated with those terms. It would be better (less likely to confuse readers and better for those of us who look for information using search tools) to choose one of those terms and always use it when talking about length/size. I don't care which is chosen. Pat From owner-ips@ece.cmu.edu Fri Jun 14 20:08:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19638 for ; Fri, 14 Jun 2002 20:08:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5ENg7D18523 for ips-outgoing; Fri, 14 Jun 2002 19:42:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5ENg5w18518 for ; Fri, 14 Jun 2002 19:42:05 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel9.hp.com (Postfix) with ESMTP id 1DF1A8052F1; Fri, 14 Jun 2002 19:42:00 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id QAA10590; Fri, 14 Jun 2002 16:43:48 -0700 (PDT) Message-ID: <00de01c213fd$12ce2a70$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Bill Studenmund" , References: Subject: Re: Reject PDUs and the F bit Date: Fri, 14 Jun 2002 16:41:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bill, On your 1, the answer is yes. It is designed to allow a generic PDU reject handling code on both sides, which may or may not escalate to the task termination. If it did, it would be handled uniformly as any other SCSI Response. On your 2, the answer is yes, the target is expected to wait for all outstanding R2Ts to be responded to (section 6.5 specifies it clearly). Sorry, I agree that it isn't as clear as it can be here. Julian, I suggest replacing the last sentence of the quoted text with the below. If the error is detected while data from the initiator is still expected (the com- mand PDU did not contain all the data and/or the target has not received a Data-Out PDU with the F bit set to 1 in response to each outstanding R2T), the target MUST wait until it receives the last expected Data-out PDU with the F bit set to 1 before sending the Response PDU. Thanks! -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Bill Studenmund" To: Sent: Friday, June 14, 2002 1:12 PM Subject: Reject PDUs and the F bit > I haev a question about the following text in section 9.17.1 of 12-97 > (which I don't think's changed): > > In all the cases in which a pre-instantiated SCSI task is terminated > because of the reject, the target MUST issue a proper SCSI command > response with CHECK CONDITION as described in Section 9.4.3 Response. > In those cases in which a status for the SCSI task was already sent > before the reject no additional status is required. If the error is > detected while data from the initiator is still expected (the com- > mand PDU did not contain all the data and the target has not received > a Data-out PDU with the Final bit 1), the target MUST wait until it > receives the Data-out PDU with the F bit set to 1 before sending the > Response PDU. > > I'm confused on two points: > > 1) When do we need to send a Reject PDU if we're also sending a SCSI > Response that indicates error status? i.e. why send two PDUs? Is it to > provide both iSCSI and SCSI status? > > 2) I have a question about the, "If the error is detected while data from > the initiator is still expected ..." part. Say the command was an iSCSI > write, and I have three outstanding R2Ts. Part way through I realize that > I want to error away the task (for whatever reason). Am I correct in > reading the above text as saying I have to wait for all of my outstanding > R2Ts to close (send the F bit), or do I only have to wait for one to > close? > > Take care, > > Bill > > From owner-ips@ece.cmu.edu Fri Jun 14 20:09:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19657 for ; Fri, 14 Jun 2002 20:08:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5ENmQw18791 for ips-outgoing; Fri, 14 Jun 2002 19:48:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtp3.electric.net (smtp3.electric.net [216.129.90.16]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5ENmOw18787 for ; Fri, 14 Jun 2002 19:48:24 -0400 (EDT) Received: from hm1.electric.net ([216.129.90.33]) by smtp3.electric.net with smtp (Exim 4.04) id 17J0nn-000577-01 for ips@ece.cmu.edu; Fri, 14 Jun 2002 16:48:23 -0700 Received: from osmtp3.electric.net ([216.129.90.30]) by hm1.electric.net (NAVGW 2.5.2.9) with SMTP id M2002061416482231954 for ; Fri, 14 Jun 2002 16:48:22 -0700 Received: from [206.175.238.29] (helo=EGRodriguez) by osmtp3.electric.net with esmtp (Exim 3.22 #1) id 17J0nk-0002HW-04 for ips@ece.cmu.edu; Fri, 14 Jun 2002 16:48:21 -0700 From: "Elizabeth G. Rodriguez" To: Subject: IPS-ALL: Last call on IPS Security Draft Date: Fri, 14 Jun 2002 18:45:50 -0600 Message-ID: <010201c21405$ffd86940$23e9c0d8@EGRodriguez> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0103_01C213D3.B53DF940" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0103_01C213D3.B53DF940 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, The IPS security draft is now ready for last call. This draft is normative to all three core IPS protocols - iSCSI, iFCP, and FCIP. Details: Document: Securing Block Storage Protocols over IP URL: http://www.ietf.org/internet-drafts/draft-ietf-ips-security-13.txt Last call period: 2 Weeks Submit comments no later than: Monday, July 1, 2002, 8am EST Comments editorial in nature may be sent directly to the editor, Bernard Aboba [aboba@internaut.com], with a copy to the co-chairs.[ElizabethRodriguez@ieee.org, black_david@emc.com] Technical issues need to be discussed directly on the mailing list reflector. Editor: Bernard Aboba [aboba@internaut.com] Elizabeth Rodriguez & David Black, IPS WG co-chairs ------=_NextPart_000_0103_01C213D3.B53DF940 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

The IPS security draft is now ready for last = call.

This draft is normative to all three core IPS = protocols – iSCSI, iFCP, and FCIP.

 

Details:

 

Document: =
Securing Block Storage Protocols over IP

 

URL: http://www.ietf.org/internet-drafts/draft-ietf-ips-security-13.txt=

 

Last call period: 2 Weeks

Submit comments no later than: Monday, July 1, 2002, 8am EST

 

Comments editorial in nature may be sent directly to = the editor, Bernard Aboba [aboba@internaut.com], = with a copy to the co-chairs.[ElizabethRodriguez@ieee.org, black_david@emc.com]

Technical issues need to be discussed directly on the mailing list reflector.

 

Editor:  Bernard = Aboba [aboba@internaut.com]

 

Elizabeth Rodriguez & David = Black,

IPS WG co-chairs

 

 

------=_NextPart_000_0103_01C213D3.B53DF940-- From owner-ips@ece.cmu.edu Fri Jun 14 20:09:35 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19674 for ; Fri, 14 Jun 2002 20:09:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5ENWBU18069 for ips-outgoing; Fri, 14 Jun 2002 19:32:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13703.mail.yahoo.com (web13703.mail.yahoo.com [216.136.175.136]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g5ENWAw18065 for ; Fri, 14 Jun 2002 19:32:10 -0400 (EDT) Message-ID: <20020614233209.50964.qmail@web13703.mail.yahoo.com> Received: from [192.55.52.4] by web13703.mail.yahoo.com via HTTP; Fri, 14 Jun 2002 16:32:09 PDT Date: Fri, 14 Jun 2002 16:32:09 -0700 (PDT) From: Martins Krikis Subject: Re: iSCSI: use of Text/Login with no data segment To: pat_thaler@agilent.com, Julian_Satran@il.ibm.com, ips@ece.cmu.edu In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00C89118C@axcs04.cos.agilent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- pat_thaler@agilent.com wrote: > If one wants to retain the idea of not sending empty > PDUs when you do have > something to say, one could put in: > A target or initiator SHOULD NOT use a Text/Login > Response or Text/ > Login Request with no data segment > (DataSegmentLength 0) unless > responding to a Text/Login Request or Text/Login > Response, respectively, > with the T bit set to 0 while the node has no keys > to send or with the C bit > set to 1. I don't see a problem with an implementation that deliberately sends an empty PDU to let the other side "speak" first. Doing this back-and-forth would not be a great situation, but IMHO it suffices to simply discourage such behavior, without resorting to "SHOULD NOT"-s. So, how about this instead? A target or initiator is discouraged from sending Text/Login Response or Text/Login Request with no data segment (DataSegmentLength 0) unless responding to a Text/Login Request or Text/Login Response, respectively, with the C bit set to 1, or the F/T bit set to 0 while having no keys to send. Or, let's just skip such restrictions/discouragements entirely. Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Fri Jun 14 20:28:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19949 for ; Fri, 14 Jun 2002 20:28:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5F06Vb19449 for ips-outgoing; Fri, 14 Jun 2002 20:06:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtp2.electricmail.net (smtp2.electric.net [216.129.90.15]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5F06Tw19445 for ; Fri, 14 Jun 2002 20:06:29 -0400 (EDT) Received: from [216.129.90.84] (helo=deckard.electric.net) by smtp2.electricmail.net with smtp (Exim 4.04) id 17J15I-000IBo-01 for ips@ece.cmu.edu; Fri, 14 Jun 2002 17:06:28 -0700 Received: from osmtp3.electric.net ([216.129.90.30]) by deckard.electric.net (NAVGW 2.5.2.9) with SMTP id M2002061417062715663 for ; Fri, 14 Jun 2002 17:06:27 -0700 Received: from [206.175.238.29] (helo=EGRodriguez) by osmtp3.electric.net with esmtp (Exim 3.22 #1) id 17J15G-0005YM-04 for ips@ece.cmu.edu; Fri, 14 Jun 2002 17:06:27 -0700 From: "Elizabeth G. Rodriguez" To: Subject: IPS-All: Last Call Updates/Yokohoma Date: Fri, 14 Jun 2002 19:03:56 -0600 Message-ID: <010f01c21408$874a42c0$23e9c0d8@EGRodriguez> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0110_01C213D6.3CAFD2C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0110_01C213D6.3CAFD2C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, I have just announced last call for the security draft. The FCIP and iFCP last calls are scheduled for completion this coming Monday. The iSCSI draft 13 has been submitted to the IETF, and last call will be announced a couple of days after the official announcement hits the reflector, which I expect will be sometime on Monday or Tuesday. Two other drafts - FC Mgmt MIB and SCSI MIB are also almost ready for last call. That process will likely start some time in July. Also as a reminder, Yokohoma deadlines for IETF draft submission are June 24 at 9am EST for -00 drafts and July 1 at 9am EST for all other drafts. As David announced earlier this week, a Draft agenda is available at http://www.ietf.org/meetings/agenda_54.txt and currently IPS is scheduled to meet Monday evening at 7:30 pm for 2.5 hours and Tuesday afternoon at 1pm for 1 hour. But, this is subject to change. The agenda will not be finalized until June 21. Let David or I know of any questions. Thanks, Elizabeth Rodriguez ------=_NextPart_000_0110_01C213D6.3CAFD2C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I have just announced last call for the security = draft.

The FCIP and iFCP last calls are scheduled for = completion this coming Monday.

The iSCSI draft 13 has been submitted to the IETF, = and last call will be announced a couple of days after the official announcement = hits the reflector, which I expect will be sometime on Monday or = Tuesday.

Two other drafts – FC Mgmt MIB and SCSI MIB are = also almost ready for last call.  That process will likely start some = time in July.

 

Also as a reminder, Yokohoma deadlines for IETF draft = submission are June 24 at 9am EST for -00 drafts and July 1 = at 9am EST for all other drafts.

 

As David announced earlier this week, a Draft agenda = is available at http://www.ietf.org/m= eetings/agenda_54.txt and currently IPS is scheduled to meet Monday evening at = 7:30 pm for 2.5 hours and Tuesday afternoon at 1pm for 1 = hour.  But, this is subject to change.  The agenda will not be finalized = until June 21.

 

Let David or I know of any = questions.

 

Thanks,

 

Elizabeth Rodriguez

------=_NextPart_000_0110_01C213D6.3CAFD2C0-- From owner-ips@ece.cmu.edu Fri Jun 14 21:15:35 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20587 for ; Fri, 14 Jun 2002 21:15:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5F0dMH20614 for ips-outgoing; Fri, 14 Jun 2002 20:39:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5F0dLw20610 for ; Fri, 14 Jun 2002 20:39:21 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 64CDD1726; Fri, 14 Jun 2002 18:39:20 -0600 (MDT) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 3D86A2AC; Fri, 14 Jun 2002 18:39:20 -0600 (MDT) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 14 Jun 2002 18:39:20 -0600 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 18:39:20 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C8911EC@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Julian Satran , ips@ece.cmu.edu Subject: iSCSI: advancing CmdSN after a command retry rule Date: Fri, 14 Jun 2002 18:39:17 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, I'm having a little trouble understanding this text near the end of 2.2.2.1: If an initiator issues a command retry for a command with CmdSN R on a connection when the session CmdSN register is Q, it MUST NOT advance the CmdSN past R + 2**31 -1 unless a different non-immediate command with CmdSN equal or greater than Q was issued on the same connection if the connection is still operational, and the reception of the command is acknowledged by the target (see Section 8.4 Command Retry and Cleaning Old Command Instances). The second non-immediate command when sent, MUST be sent in-order after the retried command on the same connection. What does "different" mean in a different non-immediate command with CmdSN equal or greater than Q"? Isn't any command with a new CmdSN because it has a new CmdSN? What is the purpose of "if the connection is still operational"? If a new command is issued on the connection it must still be operational. Perhaps it was intended to mean that if the connection was not operational then CmdSN can be advanced past the limit without this requirement being met. There doesn't seem to be any definition of when a connection is "operational". Does the connection leave the operational state when it leaves S5 or is it when it has returned to S1? Does "second non-immediate command" mean the command sent on this connection with CmdSN equal or greater than Q? Other commands with Q <= CmdSN < R + 2**31 - 1 may be sent on other connections, so the second command is the second command on this connection, right? It isn't clear what the last sentence was intended to do since any command sent before the retry would advance Q so inherently any command sent after the retry with a new CmdSN must be in-order after the retry. I suggest the following text plus clarification of the meaning of operational for a connection: "If an initiator issues a command retry for a command with CmdSN R on a connection when the session CmdSN register is Q, it MUST NOT advance the CmdSN past R + 2**31 -1 unless the connection is no longer operational or a non-immediate command with CmdSN equal or greater than Q was issued on the same connection and the reception of the command is acknowledged by the target (see Section 8.4 Command Retry and Cleaning Old Command Instances). Pat From owner-ips@ece.cmu.edu Fri Jun 14 22:23:15 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21821 for ; Fri, 14 Jun 2002 22:23:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5F1k9L22899 for ips-outgoing; Fri, 14 Jun 2002 21:46:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar2aa.compuserve.com (siaar2aa.compuserve.com [149.174.40.137]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5F1k6w22895 for ; Fri, 14 Jun 2002 21:46:06 -0400 (EDT) Received: (from mailgate@localhost) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id VAA18702 for ips@ece.cmu.edu; Fri, 14 Jun 2002 21:46:00 -0400 (EDT) Received: from compuserve.com (dal-tgn-tlv-vty1.as.wcom.net [216.192.236.1]) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id VAA18608 for ; Fri, 14 Jun 2002 21:45:57 -0400 (EDT) Message-ID: <3D0A9DDB.7761B1C5@compuserve.com> Date: Fri, 14 Jun 2002 20:52:27 -0500 From: Ralph Weber Reply-To: roweber@acm.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: IPS-ALL Reminder: Last call comments on iFCP and FCIP due by Monday References: <00d601c213ed$1c3a39b0$23e9c0d8@EGRodriguez> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit At this time, I am aware of only one Last Call comment on FCIP, the comment regarding a normative reference to the security draft. If I have missed something, please notify me via private e-mail. Thanks. .Ralph "Elizabeth G. Rodriguez" wrote: > Just a reminder that last call comments are due by Monday at5pm for the FCIP and iFCP drafts. > > Thanks, > > Elizabeth Rodriguez > From owner-ips@ece.cmu.edu Fri Jun 14 22:25:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21878 for ; Fri, 14 Jun 2002 22:25:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5F1sDr23166 for ips-outgoing; Fri, 14 Jun 2002 21:54:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5F1sCw23161 for ; Fri, 14 Jun 2002 21:54:12 -0400 (EDT) Received: from mail pickup service by mail6.nc.rr.com with Microsoft SMTPSVC; Fri, 14 Jun 2002 21:51:23 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 17:13:56 -0400 Received: from ruebert.ieee.org (ruebert.ieee.org [140.98.193.10]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5ALDutH025454 for ; Mon, 10 Jun 2002 17:13:56 -0400 (EDT) Received: from ece.cmu.edu (gemini2.ieee.org [140.98.193.20]) by ruebert.ieee.org (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5ALDQq23980; Mon, 10 Jun 2002 17:13:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AKwPC12581 for ips-outgoing; Mon, 10 Jun 2002 16:58:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AKwNw12577 for ; Mon, 10 Jun 2002 16:58:23 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 16:58:07 -0400 Message-ID: From: Eddy Quicksall To: "Robert D. Russell" , Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: MaxRecvPDULength question Date: Mon, 10 Jun 2002 16:58:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Below it says: "The DataSegmentLength in a Text *Request* MUST NOT exceed the iSCSI initiator's MaxRecvDataSegmentLength (a per connection and per direction negotiated parameter)." But it seems it should say "Response". Eddy -----Original Message----- From: Robert D. Russell [mailto:rdr@io.iol.unh.edu] Sent: Monday, June 10, 2002 3:43 AM To: Julian_Satran@il.ibm.com; ips@ece.cmu.edu Subject: Re: MaxRecvPDULength question Julian: It has been stated several times that at this late stage we should not be requesting changes that are just preferences. Nevertheless, due to apparent misunderstandings of its meaning, the key named MaxRecvPDULength in draft 12 is apparently going to have its name changed in draft 13. Fine. No problem. However, to remove all possibility of future misunderstandings, why don't we give it a name that says precisely what it is: MaxRecvDataSegmentLength That way, the first sentence in the third paragraph of section 9.7.1 would begin: "DataSegmentLength MUST not exceed MaxRecvDataSegmentLength for the direction it is sent ..." which seems to me to be the classic definition of a maximum. The issue of changing the name from MaxRecvPDULength started with an e-mail sent by Luben Tuikov on 21 May (who, by the way, did NOT want to change the name, just its meaning), and was followed by a short flurry of e-mails under the thread "MaxRecvPDULength question". Some of the names suggested on that thread were: MaxRecvDataLength (21 May by Paul Konig) MaxRecvDataSegmentSize (21 May by Pat Thaler) MaxRecvDataSegSize (21 May by Pat Thaler) MaxRecvPDUDataSize (22 May by Pat Thaler) and what got into the draft was this last suggestion by Pat. I don't believe there was a consensus for this choice (probably, as was stated by Pat several times, because most people don't really see the need for a renaming and didn't bother to participate in the thread). Therefore, I would ask you to reconsider the new name and ask for consensus on the new choice. I believe the name MaxRecvDataSegmentLength is so closely linked to the name DataSegmentLength that its meaning should be clear to even a first-time reader, especially given the statement in section 9.7.1 quoted above. Furthermore, there clearly is the concept of DataSegmentLength elsewhere in the standard -- every PDU has a DataSegmentLength field. I could find no concept of PDUDataSize (or even "data size") elsewhere in the current draft. Whether or not this renaming happens (again), I believe there should be the following rewordings to be more precise in order to avoid any ambiguities and/or future misinterpretations. The first sentence in section 9.10.5 should be changed to read: "The DataSegmentLength in a Text Request MUST NOT exceed the iSCSI target's MaxRecvDataSegmentLength (a per connection and per direction negotiated parameter)." and the first sentence in section 9.11.6 should be changed to read: "The DataSegmentLength in a Text Request MUST NOT exceed the iSCSI initiator's MaxRecvDataSegmentLength (a per connection and per direction negotiated parameter)." Finally, two sentences in section 11.13 should be changed to read: "The initiator or target declares the maximum DataSegmentLength in bytes it can receive in an iSCSI PDU." and "The transmitter (initiator or target) is required to send PDUs with a DataSegmentLength not exceeding MaxRecvDataSegmentLength of the receiver." Thank you for your consideration, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Fri Jun 14 22:25:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21891 for ; Fri, 14 Jun 2002 22:25:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5F217A23441 for ips-outgoing; Fri, 14 Jun 2002 22:01:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5F216w23437 for ; Fri, 14 Jun 2002 22:01:06 -0400 (EDT) Received: from mail pickup service by mail6.nc.rr.com with Microsoft SMTPSVC; Fri, 14 Jun 2002 21:59:02 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Jun 2002 20:08:47 -0400 Received: from ruebert.ieee.org (ruebert.ieee.org [140.98.193.10]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5C08ka2028800 for ; Tue, 11 Jun 2002 20:08:46 -0400 (EDT) Received: from ece.cmu.edu (gemini3.ieee.org [140.98.193.25]) by ruebert.ieee.org (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5C07nq20132; Tue, 11 Jun 2002 20:07:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BNjY512669 for ips-outgoing; Tue, 11 Jun 2002 19:45:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BNjWw12664 for ; Tue, 11 Jun 2002 19:45:32 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 19:45:32 -0400 Message-ID: From: Eddy Quicksall To: "Mallikarjun C." , Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Date: Tue, 11 Jun 2002 19:45:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Consider the following (using Julian's suggestion): -> cmd 1 -> req to change to length 2 -> cmd 2 <- stat 1 <- data 2, PDU 0, Length 1 -> cmd 3, ack 1 so change the length <- data 2, PDU 1, Length 2 -> SNACK data 2, PDU 1 So we have to calculate the offset for Data 2, PDU 1 using old length and send data after that offset using new length. That means keeping track of PDU lengths which I would like to avoid. Or, the target would have to force idling of commands before it gives the response to the change. Can you suggest how this would be handled otherwise? Eddy -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com] Sent: Tuesday, June 11, 2002 6:57 PM To: Eddy Quicksall; Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iSCSI: changing MaxPDUDataLength Eddy, I am not sure if you're agreeing with me or not... but let me add some comments. I don't expect the change in PDU size to happen frequently - no change in what I earlier said. You are making an assumption that a target must record the PDU size for every PDU if SNACKs are to be satisfied across changed MaxRecvDataSegmentLength. As Julian earlier said, you don't have to. I will not go into implementation details, but I believe just the value of the DataSN from which the new size is effective should be all that's needed. Besides, the spec guarantees that only RunLength=0 is used on any SNACK after the change. You are also implying that targets can declare their changed MaxRecvDataSegmentLength anytime just for writes. There are two problems with this - a) reads and writes may both be active in the typical case on an iSCSI connection, and b) a target can declare its changed value only if an initiator is allowed to start the Text Request (and I thought you were suggesting that we explicitly disallow that). Hope that clears it up. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Eddy Quicksall" To: "Mallikarjun C." ; "Julian Satran" Cc: Sent: Tuesday, June 11, 2002 3:18 PM Subject: RE: iSCSI: changing MaxPDUDataLength > You are correct and that is exactly how I have had to code it. With fast > path and slow path code split between processors, it becomes even worse. > > When I read your comments on why the PDU size could change (from way back in > March I think), I got did not get the impression that it would happen very > often and that in fact it may only happen when you are maintaining > allegiance to another connection. > > If it is something that is not going to happen very often, then it would be > so much easier to have the initiator idle the commands first (all it really > needs to do is idle the READ commands). If it is going to change so often > that idling would be degrading, I suspect that just doing the negotiation > that often would itself be degrading. > > And, be aware that the target will probably idle the R commands. Otherwise, > it will have to track PDU sizes and that would be really > "counter-productive" (especially when there should be no SNACKs on a good > connection anyway). > > I don't see any problem with the target negotiating its size at any time. > And the initiator would not have to idle the WRITE or no-data commands. > > Eddy > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Tuesday, June 11, 2002 3:35 PM > To: Eddy Quicksall; Julian Satran > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: changing MaxPDUDataLength > > > Eddy, > > I am not clear on why you think the target code becomes messy on > a PDU size change. The last para in section 4.4 states the following - > > "Parameters negotiated by a text exchange negotiation sequence become > effective only after the negotiation sequence is completed." > > Since the target gets to complete a text negotiation with a Text Response > PDU, it can time the applicability of a changed MaxRecvDataSegmentLength. > > Requiring that an initiator must idle the connection before changing this > parameter, IMHO, is counter-productive when there's a dynamic PMTU > degradation in the presence of long-running commands (writes in particular). > Once the initiator starts the renegotiation, target would ideally want to > quickly > renegotiate its receive size as well to receive ULPDU-contained segments. > > In short, seems to me that the draft is saying what you would like. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > > ----- Original Message ----- > From: "Eddy Quicksall" > To: "Julian Satran" > Cc: > Sent: Tuesday, June 11, 2002 7:56 AM > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > I think it should be a requirement because if it is not, all target code > > will have to have the messy code. Or, we could say that if it is not idle > > commands, then the target may reject it. > > > > Eddy > > > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Tuesday, June 11, 2002 9:11 AM > > To: Eddy Quicksall > > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > That is a fair request - we may slip in a recommendation to that effect > (in > > chapter 11?) > > > > Julo > > > > > > > > Eddy Quicksall > > > > > > 06/11/2002 04:28 AM > > Please respond to Eddy Quicksall > > > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > How about if we say that an initiator must not change the MaxPDUDataSize > > unless it first idles the commands (at least the ones with the R bit) or > if > > ErrorRecoveryLevel==0? > > > > That would simplify target code greatly and would meet the design goals; > and > > since it should be rare to change it, it would be of little impact to idle > > the commands for a split second. > > > > > > Eddy > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Monday, June 10, 2002 8:06 PM > > To: Eddy Quicksall > > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > I said only that when you change length you can ask for all PDUs after the > > ack! (no need to keep a tall - the old offsets are good up to the hole). > > > > Julo > > > > > > Eddy Quicksall > > > > > > 06/11/2002 12:32 AM > > Please respond to Eddy Quicksall > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > Julian, > > > > Another problem here is that the target has to calculate the offset from > the > > DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 > > means starting DataSN=4, send all the data for that sequence. > > > > I think it would be a performance hit and waist of memory to keep a tally > of > > all PDU sizes just for an occasional SNACK. > > > > It's not that it can't be done ... it is more that it is messy and I think > > there is a solution that will satisfy the design requirements but keep the > > software simpler. > > > > Eddy > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Saturday, June 08, 2002 10:16 PM > > To: Eddy Quicksall > > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > That is not completely accurate. > > The only problem is when PDU size decreases and then SNACK must be for all > > data. > > Target can also keep a mapping of numbers/to offsets (the list should be > > small and if it gets long ask for ack (A-bit). > > > > Julo > > > > Eddy Quicksall > > Sent by: owner-ips@ece.cmu.edu > > > > > > 06/08/2002 10:54 PM > > Please respond to Eddy Quicksall > > > > > > To: pat_thaler@agilent.com > > cc: ips@ece.cmu.edu > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > > > Thanks, > > > > As a target, I won't be able to let it change until all of the outstanding > > commands are finished (running with ErrorRecoveryLevel>=1). This is > because > > I must use the PDU size to compute the offset from a SNACK's > > BegRun/RunLength. > > > > So, I plan to not give the text response for a MaxPDURecvDataLength in FFP > > until I get back an ExpStatSN == next StatSN. > > > > This will cause a delay of unknown time before the PDU size can actually > > change ... do you see any problem with this? > > > > Eddy > > > > -----Original Message----- > > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > > Sent: Friday, June 07, 2002 1:13 PM > > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > Eddy, > > > > If one uses a message sync and steering that relys on the transport > segments > > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path > > MTU changes one would want to change the PDU data length to fit the new > path > > MTU. > > > > Pat > > > > -----Original Message----- > > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > > Sent: Wednesday, June 05, 2002 12:24 PM > > To: ips@ece.cmu.edu > > Subject: iSCSI: changing MaxPDUDataLength > > > > > > Does anybody know a case where it is necessary to support a new PDU data > > length during full feature phase? > > > > Eddy > > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Fri Jun 14 22:26:11 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21911 for ; Fri, 14 Jun 2002 22:26:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5F1v6h23296 for ips-outgoing; Fri, 14 Jun 2002 21:57:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5F1v3w23285 for ; Fri, 14 Jun 2002 21:57:04 -0400 (EDT) Received: from mail pickup service by mail6.nc.rr.com with Microsoft SMTPSVC; Fri, 14 Jun 2002 21:53:57 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Jun 2002 20:06:49 -0400 Received: from ruebert.ieee.org (ruebert.ieee.org [140.98.193.10]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5C06na2021792 for ; Tue, 11 Jun 2002 20:06:49 -0400 (EDT) Received: from ece.cmu.edu (gemini3.ieee.org [140.98.193.25]) by ruebert.ieee.org (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5C06Sq19346; Tue, 11 Jun 2002 20:06:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BNvHf13225 for ips-outgoing; Tue, 11 Jun 2002 19:57:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BNvFw13216 for ; Tue, 11 Jun 2002 19:57:15 -0400 (EDT) Received: from london ([192.168.1.19]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id QAA16002; Tue, 11 Jun 2002 16:55:32 -0700 (PDT) From: "Rod Harrison" To: "Julian Satran" , "Mallikarjun C." Cc: Subject: RE: iSCSI: changing MaxPDUDataLength Date: Tue, 11 Jun 2002 18:57:36 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I'm torn, I don't want to make this sort of change late on but I think it would be a good thing in the long term. How about adding the additional async message code and saying upon receipt the initiator MAY start a negotiation sequence or logout and re-login the connection immediately without having to wait for the negotiated timeouts? - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Tuesday, June 11, 2002 4:28 PM To: Mallikarjun C. Cc: ips@ece.cmu.edu; Julian Satran; owner-ips@ece.cmu.edu Subject: Re: iSCSI: changing MaxPDUDataLength Importance: High Mallikarjun, The question was general and not specific to MaxRecv.... Although we say that negotiation is symmetric we don't have any mechanism through which a target can say it wants to start negotiation something (sort of similar but not as strong as a the "request logout" - "request to negotiate" that will require the initiator to issue a text request and kick-off a negotiation. Julo "Mallikarjun C." To: , Julian Satran/Haifa/IBM@IBMIL Sent by: cc: owner-ips@ece.cmu Subject: Re: iSCSI: changing MaxPDUDataLength .edu 06/11/2002 10:50 PM Please respond to "Mallikarjun C." > I also realized that we don't have "negotiation prompt" from the target. > I am not sure that we need one. I am not sure about it either. My preference is not to add this. It appears to me that a target does have the option of dropping the connection today if it can't work with non-ULPDU-contained segments for too long. I suspect that the target would do the same if (we introduced the "negotiation prompt" and) the initiator doesn't/couldn't honor the "negotiation prompt". Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Julian Satran" To: Sent: Tuesday, June 11, 2002 8:34 AM Subject: RE: iSCSI: changing MaxPDUDataLength > I suggest the following text in 11.13 > > A change of MaxRecvDataSegmentLength by an initiator or target > becomes effective after all commands preceding the negotiation > end-ing request have been processed by the target and their status > is acknowledged. > > I also realized that we don't have "negotiation prompt" from the target. > I am not sure that we need one. > If some of you think we need we may want one additional code in the Asynch > Message. > Please comment TODAY. > > Julo > ----- Forwarded by Julian Satran/Haifa/IBM on 06/11/2002 06:29 PM ----- > > Julian Satran > To: Eddy Quicksall > 06/11/2002 04:04 cc: ips@ece.cmu.edu, pat_thaler@agilent.com > PM From: Julian Satran/Haifa/IBM@IBMIL > Subject: RE: iSCSI: changing MaxPDUDataLength(Document link: Julian Satran - Mail) > > > > > > > > > > That is a fair request - we may slip in a recommendation to that effect (in > chapter 11?) > > Julo > > > > Eddy Quicksall > vivity.com> cc: ips@ece.cmu.edu, pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > 06/11/2002 04:28 > AM > Please respond to > Eddy Quicksall > > > > > > How about if we say that an initiator must not change the MaxPDUDataSize > unless it first idles the commands (at least the ones with the R bit) or if > ErrorRecoveryLevel==0? > > That would simplify target code greatly and would meet the design goals; > and since it should be rare to change it, it would be of little impact to > idle the commands for a split second. > > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Monday, June 10, 2002 8:06 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > I said only that when you change length you can ask for all PDUs > after the ack! (no need to keep a tall - the old offsets are good up > to the hole). > > Julo > > > Eddy Quicksall > To: Julian > Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu, > 06/11/2002 12:32 AM pat_thaler@agilent.com > Please respond to Eddy Quicksall Subject: RE: iSCSI: > changing MaxPDUDataLength > > > > > > > > Julian, > > Another problem here is that the target has to calculate the offset > from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and > RunLngth=0 means starting DataSN=4, send all the data for that > sequence. > > I think it would be a performance hit and waist of memory to keep a > tally of all PDU sizes just for an occasional SNACK. > > It's not that it can't be done ... it is more that it is messy and I > think there is a solution that will satisfy the design requirements > but keep the software simpler. > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Saturday, June 08, 2002 10:16 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > That is not completely accurate. > The only problem is when PDU size decreases and then SNACK must be > for all data. > Target can also keep a mapping of numbers/to offsets (the list should > be small and if it gets long ask for ack (A-bit). > > Julo > > Eddy Quicksall > To: > Sent by: owner-ips@ece.cmu.edu pat_thaler@agilent.com > cc: ips@ece.cmu.edu > Subject: RE: iSCSI: > 06/08/2002 10:54 PM changing MaxPDUDataLength > Please respond to Eddy Quicksall > > > > > > > > Thanks, > > As a target, I won't be able to let it change until all of the > outstanding > commands are finished (running with ErrorRecoveryLevel>=1). This is > because > I must use the PDU size to compute the offset from a SNACK's > BegRun/RunLength. > > So, I plan to not give the text response for a MaxPDURecvDataLength > in FFP > until I get back an ExpStatSN == next StatSN. > > This will cause a delay of unknown time before the PDU size can > actually > change ... do you see any problem with this? > > Eddy > > -----Original Message----- > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > Sent: Friday, June 07, 2002 1:13 PM > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > Subject: RE: iSCSI: changing MaxPDUDataLength > > > Eddy, > > If one uses a message sync and steering that relys on the transport > segments > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the > path > MTU changes one would want to change the PDU data length to fit the > new path > MTU. > > Pat > > -----Original Message----- > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > Sent: Wednesday, June 05, 2002 12:24 PM > To: ips@ece.cmu.edu > Subject: iSCSI: changing MaxPDUDataLength > > > Does anybody know a case where it is necessary to support a new PDU > data > length during full feature phase? > > Eddy > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > > > From owner-ips@ece.cmu.edu Fri Jun 14 23:26:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23314 for ; Fri, 14 Jun 2002 23:26:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5F30Q125565 for ips-outgoing; Fri, 14 Jun 2002 23:00:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5F30Ow25560 for ; Fri, 14 Jun 2002 23:00:24 -0400 (EDT) Received: from mail pickup service by mail6.nc.rr.com with Microsoft SMTPSVC; Fri, 14 Jun 2002 23:00:24 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 12:27:11 -0400 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AGRAIa009316 for ; Mon, 10 Jun 2002 12:27:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AFolN23839 for ips-outgoing; Mon, 10 Jun 2002 11:50:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from best.eurologic.com ([213.190.135.5]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AFoiw23835 for ; Mon, 10 Jun 2002 11:50:45 -0400 (EDT) Received: from there (wombat [192.168.7.41]) by best.eurologic.com (8.9.3+Sun/8.9.3) with SMTP id QAA11665; Mon, 10 Jun 2002 16:50:28 +0100 (BST) Message-Id: <200206101550.QAA11665@best.eurologic.com> Content-Type: text/plain; charset="iso-8859-1" From: Ken Sandars Organization: Eurologic Systems To: "Julian Satran" , "Robert D. Russell" Subject: Re: MaxRecvPDULength question Date: Mon, 10 Jun 2002 16:49:43 +0000 X-Mailer: KMail [version 1.3.1] Cc: ips@ece.cmu.edu References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi Julo & Bob, I support Bob on this change to the completely unambiguous "MaxRecvDataSegmentLength" Cheers, Ken -- Ken Sandars Eurologic Systems Ltd ksandars@eurologic.com On Monday 10 June 2002 1:51 pm, Julian Satran wrote: > Bob, > > I can do that too - and if we wait for consensus for a name - well that > will be forever. > So if at least one more person wants the change and nobody is against we > will have it as you wish if not then not. > > Julo > > > > > "Robert D. Russell" > 06/10/2002 10:42 AM > Please respond to "Robert D. Russell" > > > To: Julian Satran/Haifa/IBM@IBMIL, > cc: > Subject: Re: MaxRecvPDULength question > > > > > Julian: > > It has been stated several times that at this late stage we > should not be requesting changes that are just preferences. > > Nevertheless, due to apparent misunderstandings of its meaning, > the key named MaxRecvPDULength in draft 12 is apparently going > to have its name changed in draft 13. > > Fine. No problem. > > However, to remove all possibility of future misunderstandings, > why don't we give it a name that says precisely what it is: > > MaxRecvDataSegmentLength > > That way, the first sentence in the third paragraph of section > 9.7.1 would begin: > > "DataSegmentLength MUST not exceed MaxRecvDataSegmentLength > for the direction it is sent ..." > > which seems to me to be the classic definition of a maximum. > > The issue of changing the name from MaxRecvPDULength started with an > e-mail sent by Luben Tuikov on 21 May (who, by the way, did NOT want > to change the name, just its meaning), and was followed by a short > flurry of e-mails under the thread "MaxRecvPDULength question". > > Some of the names suggested on that thread were: > MaxRecvDataLength (21 May by Paul Konig) > MaxRecvDataSegmentSize (21 May by Pat Thaler) > MaxRecvDataSegSize (21 May by Pat Thaler) > MaxRecvPDUDataSize (22 May by Pat Thaler) > > and what got into the draft was this last suggestion by Pat. > > I don't believe there was a consensus for this choice (probably, as > was stated by Pat several times, because most people don't really see > the need for a renaming and didn't bother to participate in the thread). > Therefore, I would ask you to reconsider the new name and ask for > consensus on the new choice. > > I believe the name MaxRecvDataSegmentLength is so closely linked to the > name DataSegmentLength that its meaning should be clear to even a > first-time reader, especially given the statement in section 9.7.1 > quoted above. > > Furthermore, there clearly is the concept of DataSegmentLength elsewhere > in the standard -- every PDU has a DataSegmentLength field. > I could find no concept of PDUDataSize (or even "data size") elsewhere in > the current draft. > > > Whether or not this renaming happens (again), I believe there should be > the following rewordings to be more precise in order to avoid any > ambiguities and/or future misinterpretations. > > The first sentence in section 9.10.5 should be changed to read: > > "The DataSegmentLength in a Text Request MUST NOT exceed the > iSCSI target's MaxRecvDataSegmentLength (a per connection and per > direction negotiated parameter)." > > and the first sentence in section 9.11.6 should be changed to read: > > "The DataSegmentLength in a Text Request MUST NOT exceed the > iSCSI initiator's MaxRecvDataSegmentLength (a per connection and per > direction negotiated parameter)." > > Finally, two sentences in section 11.13 should be changed to read: > > "The initiator or target declares the maximum DataSegmentLength in > bytes it can receive in an iSCSI PDU." > > and > > "The transmitter (initiator or target) is required to send PDUs with a > DataSegmentLength not exceeding MaxRecvDataSegmentLength of the > receiver." > > > Thank you for your consideration, > > > Bob Russell > InterOperability Lab > University of New Hampshire > rdr@iol.unh.edu > 603-862-3774 From owner-ips@ece.cmu.edu Fri Jun 14 23:29:27 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23372 for ; Fri, 14 Jun 2002 23:29:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5F2qMP25239 for ips-outgoing; Fri, 14 Jun 2002 22:52:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5F2qKw25233; Fri, 14 Jun 2002 22:52:20 -0400 (EDT) Received: from mail pickup service by mail6.nc.rr.com with Microsoft SMTPSVC; Fri, 14 Jun 2002 22:50:40 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 12:24:03 -0400 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AGO2Ia026829 for ; Mon, 10 Jun 2002 12:24:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5AFoqN23849 for ips-outgoing; Mon, 10 Jun 2002 11:50:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5AFonw23843; Mon, 10 Jun 2002 11:50:50 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5AFog7n026246; Mon, 10 Jun 2002 17:50:42 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5AFogD66432; Mon, 10 Jun 2002 17:50:43 +0200 To: "BURBRIDGE"@ece.cmu.edu Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: CHAP-Slight Re-Phrase! X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Mon, 10 Jun 2002 18:50:39 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 10/06/2002 18:50:43, Serialize complete at 10/06/2002 18:50:43 Content-Type: multipart/alternative; boundary="=_alternative 00567C77C2256BD4_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00567C77C2256BD4_= Content-Type: text/plain; charset="us-ascii" thanks - julo "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" Sent by: owner-ips@ece.cmu.edu 06/10/2002 04:47 PM Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: ips@ece.cmu.edu cc: Subject: iSCSI: CHAP-Slight Re-Phrase! Julian et al, I may have misinterpreted section "7.2.1 CHAP Considerations" (Third Paragraph) but may I suggest replacing the word "of" with "by" as it makes more sense. Matthew "Moreover, in this case IKE authentication with group pre-shared keys SHOULD NOT be used unless it is not essential to protect group members against off-line dictionary attacks of other members." "Moreover, in this case IKE authentication with group pre-shared keys SHOULD NOT be used unless it is not essential to protect group members against off-line dictionary attacks BY other members." --=_alternative 00567C77C2256BD4_= Content-Type: text/html; charset="us-ascii"
thanks - julo


"BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>
Sent by: owner-ips@ece.cmu.edu

06/10/2002 04:47 PM
Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)"

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI: CHAP-Slight Re-Phrase!

       


Julian et al,

I may have misinterpreted section "7.2.1 CHAP Considerations" (Third
Paragraph) but may I suggest replacing the word "of" with "by" as it makes
more sense.

Matthew

"Moreover, in this case IKE authentication with group pre-shared
keys SHOULD NOT be used unless it is not essential to protect group
members against off-line dictionary attacks of other members."

"Moreover, in this case IKE authentication with group pre-shared
keys SHOULD NOT be used unless it is not essential to protect group
members against off-line dictionary attacks BY other members."

--=_alternative 00567C77C2256BD4_=-- From owner-ips@ece.cmu.edu Fri Jun 14 23:41:29 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23476 for ; Fri, 14 Jun 2002 23:41:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5F3TxD26702 for ips-outgoing; Fri, 14 Jun 2002 23:29:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5F3Tvw26698 for ; Fri, 14 Jun 2002 23:29:57 -0400 (EDT) Received: from mail pickup service by mail6.nc.rr.com with Microsoft SMTPSVC; Fri, 14 Jun 2002 23:28:53 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 23:01:10 -0400 Received: from ruebert.ieee.org (ruebert.ieee.org [140.98.193.10]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5B31AIa025532 for ; Mon, 10 Jun 2002 23:01:10 -0400 (EDT) Received: from ece.cmu.edu (gemini2.ieee.org [140.98.193.20]) by ruebert.ieee.org (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5B30hq25715; Mon, 10 Jun 2002 23:00:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5B2Wnw27874 for ips-outgoing; Mon, 10 Jun 2002 22:32:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar2aa.compuserve.com (siaar2aa.compuserve.com [149.174.40.137]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5B2Wkw27869 for ; Mon, 10 Jun 2002 22:32:46 -0400 (EDT) Received: (from mailgate@localhost) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id WAA22173 for ips@ece.cmu.edu; Mon, 10 Jun 2002 22:32:40 -0400 (EDT) Received: from compuserve.com (chi-tgn-gvp-vty9.as.wcom.net [216.192.150.9]) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id WAA22145 for ; Mon, 10 Jun 2002 22:32:30 -0400 (EDT) Message-ID: <3D0560C0.1120B499@compuserve.com> Date: Mon, 10 Jun 2002 21:30:24 -0500 From: Ralph Weber Reply-To: roweber@acm.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IPS Reflector Subject: FCIP does not reference draft-ietf-ips-security-??.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit It has come to my attention that FCIP does not reference draft-ietf-ips-security-??.txt as was agreed in Huntington Beach. As part of the WG Last Call resolution for FCIP, the following actions are proposed to remedy this oversight. 1) Add a normative reference to draft-ietf-ips-security-??.txt 2) Give the normative reference some wording in the body text by adding a new paragraph near the beginning of Section 10 (the Security section in FCIP). The proposed wording for the new paragraph is as follows: "The ips Security document [xx] contains an expanded discussion and additional rational for the security require- ments in this section. The ips Security document also may contain requirements beyond those present in this document. However, in the event that requirements in the ips Security document conflict with requirements stated in this document, the requirements in this document SHALL prevail." Comments on these changes are welcomed within the context of the FCIP WG Last Call process (i.e., when the WG Last Call closes the FCIP draft will be revised based on the results of the discussion initiated here). Thanks. .Ralph From owner-ips@ece.cmu.edu Sat Jun 15 00:31:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23983 for ; Sat, 15 Jun 2002 00:31:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5F3tuc27734 for ips-outgoing; Fri, 14 Jun 2002 23:55:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5F3tsw27729 for ; Fri, 14 Jun 2002 23:55:55 -0400 (EDT) Received: from mail pickup service by mail6.nc.rr.com with Microsoft SMTPSVC; Fri, 14 Jun 2002 23:55:18 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Jun 2002 19:22:42 -0400 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5BNMfa2019570 for ; Tue, 11 Jun 2002 19:22:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BMobx10193 for ips-outgoing; Tue, 11 Jun 2002 18:50:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BMoYw10182 for ; Tue, 11 Jun 2002 18:50:34 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5BMoRYj015576; Wed, 12 Jun 2002 00:50:27 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5BMoQp61766; Wed, 12 Jun 2002 00:50:26 +0200 Importance: High Subject: RE: iSCSI: changing MaxPDUDataLength To: Eddy Quicksall Cc: ips@ece.cmu.edu, Julian Satran X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Wed, 12 Jun 2002 00:17:16 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 12/06/2002 01:50:26 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I think that even the text I suggested is more than it is needed. Quiescing the connection is not practical - many large box builder will find this unacceptable and obviously an implementation can go away without it. As I pointed out for retries you need only the offset at the change point and anything that happens later require retransmission of everything from the known point. Julo Eddy Quicksall cc: Subject: RE: iSCSI: changing MaxPDUDataLength 06/11/2002 08:56 PM Please respond to Eddy Quicksall I see a case where the target could still end up sending PDU's of different lengths for a given command. It would be much safer if the initiator was required to idle the commands before sending the new MaxRecvDataSegmentLength. That way there is nothing for the target to do other than change the size. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, June 11, 2002 11:34 AM To: ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Importance: High I suggest the following text in 11.13 A change of MaxRecvDataSegmentLength by an initiator or target becomes effective after all commands preceding the negotiation end-ing request have been processed by the target and their status is acknowledged. I also realized that we don't have "negotiation prompt" from the target. I am not sure that we need one. If some of you think we need we may want one additional code in the Asynch Message. Please comment TODAY. Julo ----- Forwarded by Julian Satran/Haifa/IBM on 06/11/2002 06:29 PM ----- Julian Satran To: Eddy Quicksall 06/11/2002 04:04 cc: ips@ece.cmu.edu, pat_thaler@agilent.com PM From: Julian Satran/Haifa/IBM@IBMIL Subject: RE: iSCSI: changing MaxPDUDataLength(Document link: Julian Satran - Mail) That is a fair request - we may slip in a recommendation to that effect (in chapter 11?) Julo Eddy Quicksall cc: ips@ece.cmu.edu, pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength 06/11/2002 04:28 AM Please respond to Eddy Quicksall How about if we say that an initiator must not change the MaxPDUDataSize unless it first idles the commands (at least the ones with the R bit) or if ErrorRecoveryLevel==0? That would simplify target code greatly and would meet the design goals; and since it should be rare to change it, it would be of little impact to idle the commands for a split second. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, June 10, 2002 8:06 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu; pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength I said only that when you change length you can ask for all PDUs after the ack! (no need to keep a tall - the old offsets are good up to the hole). Julo Eddy Quicksall To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, 06/11/2002 12:32 AM pat_thaler@agilent.com Please respond to Eddy Quicksall Subject: RE: iSCSI: changing MaxPDUDataLength Julian, Another problem here is that the target has to calculate the offset from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 means starting DataSN=4, send all the data for that sequence. I think it would be a performance hit and waist of memory to keep a tally of all PDU sizes just for an occasional SNACK. It's not that it can't be done ... it is more that it is messy and I think there is a solution that will satisfy the design requirements but keep the software simpler. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, June 08, 2002 10:16 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength That is not completely accurate. The only problem is when PDU size decreases and then SNACK must be for all data. Target can also keep a mapping of numbers/to offsets (the list should be small and if it gets long ask for ack (A-bit). Julo Eddy Quicksall To: Sent by: owner-ips@ece.cmu.edu pat_thaler@agilent.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: 06/08/2002 10:54 PM changing MaxPDUDataLength Please respond to Eddy Quicksall Thanks, As a target, I won't be able to let it change until all of the outstanding commands are finished (running with ErrorRecoveryLevel>=1). This is because I must use the PDU size to compute the offset from a SNACK's BegRun/RunLength. So, I plan to not give the text response for a MaxPDURecvDataLength in FFP until I get back an ExpStatSN == next StatSN. This will cause a delay of unknown time before the PDU size can actually change ... do you see any problem with this? Eddy -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Friday, June 07, 2002 1:13 PM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Eddy, If one uses a message sync and steering that relys on the transport segments carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path MTU changes one would want to change the PDU data length to fit the new path MTU. Pat -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Wednesday, June 05, 2002 12:24 PM To: ips@ece.cmu.edu Subject: iSCSI: changing MaxPDUDataLength Does anybody know a case where it is necessary to support a new PDU data length during full feature phase? Eddy mailto: Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Sat Jun 15 00:32:54 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24009 for ; Sat, 15 Jun 2002 00:32:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5F3u1o27746 for ips-outgoing; Fri, 14 Jun 2002 23:56:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5F3txw27739 for ; Fri, 14 Jun 2002 23:55:59 -0400 (EDT) Received: from mail pickup service by mail6.nc.rr.com with Microsoft SMTPSVC; Fri, 14 Jun 2002 23:55:30 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Jun 2002 19:23:29 -0400 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5BNNNbC005347 for ; Tue, 11 Jun 2002 19:23:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BMI5s08723 for ips-outgoing; Tue, 11 Jun 2002 18:18:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BMI3w08718 for ; Tue, 11 Jun 2002 18:18:03 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 18:18:01 -0400 Message-ID: From: Eddy Quicksall To: "Mallikarjun C." , Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Date: Tue, 11 Jun 2002 18:18:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk You are correct and that is exactly how I have had to code it. With fast path and slow path code split between processors, it becomes even worse. When I read your comments on why the PDU size could change (from way back in March I think), I got did not get the impression that it would happen very often and that in fact it may only happen when you are maintaining allegiance to another connection. If it is something that is not going to happen very often, then it would be so much easier to have the initiator idle the commands first (all it really needs to do is idle the READ commands). If it is going to change so often that idling would be degrading, I suspect that just doing the negotiation that often would itself be degrading. And, be aware that the target will probably idle the R commands. Otherwise, it will have to track PDU sizes and that would be really "counter-productive" (especially when there should be no SNACKs on a good connection anyway). I don't see any problem with the target negotiating its size at any time. And the initiator would not have to idle the WRITE or no-data commands. Eddy -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com] Sent: Tuesday, June 11, 2002 3:35 PM To: Eddy Quicksall; Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iSCSI: changing MaxPDUDataLength Eddy, I am not clear on why you think the target code becomes messy on a PDU size change. The last para in section 4.4 states the following - "Parameters negotiated by a text exchange negotiation sequence become effective only after the negotiation sequence is completed." Since the target gets to complete a text negotiation with a Text Response PDU, it can time the applicability of a changed MaxRecvDataSegmentLength. Requiring that an initiator must idle the connection before changing this parameter, IMHO, is counter-productive when there's a dynamic PMTU degradation in the presence of long-running commands (writes in particular). Once the initiator starts the renegotiation, target would ideally want to quickly renegotiate its receive size as well to receive ULPDU-contained segments. In short, seems to me that the draft is saying what you would like. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Eddy Quicksall" To: "Julian Satran" Cc: Sent: Tuesday, June 11, 2002 7:56 AM Subject: RE: iSCSI: changing MaxPDUDataLength > I think it should be a requirement because if it is not, all target code > will have to have the messy code. Or, we could say that if it is not idle > commands, then the target may reject it. > > Eddy > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Tuesday, June 11, 2002 9:11 AM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > That is a fair request - we may slip in a recommendation to that effect (in > chapter 11?) > > Julo > > > > Eddy Quicksall > > > 06/11/2002 04:28 AM > Please respond to Eddy Quicksall > > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > How about if we say that an initiator must not change the MaxPDUDataSize > unless it first idles the commands (at least the ones with the R bit) or if > ErrorRecoveryLevel==0? > > That would simplify target code greatly and would meet the design goals; and > since it should be rare to change it, it would be of little impact to idle > the commands for a split second. > > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Monday, June 10, 2002 8:06 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > I said only that when you change length you can ask for all PDUs after the > ack! (no need to keep a tall - the old offsets are good up to the hole). > > Julo > > > Eddy Quicksall > > > 06/11/2002 12:32 AM > Please respond to Eddy Quicksall > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > Julian, > > Another problem here is that the target has to calculate the offset from the > DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 > means starting DataSN=4, send all the data for that sequence. > > I think it would be a performance hit and waist of memory to keep a tally of > all PDU sizes just for an occasional SNACK. > > It's not that it can't be done ... it is more that it is messy and I think > there is a solution that will satisfy the design requirements but keep the > software simpler. > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Saturday, June 08, 2002 10:16 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > That is not completely accurate. > The only problem is when PDU size decreases and then SNACK must be for all > data. > Target can also keep a mapping of numbers/to offsets (the list should be > small and if it gets long ask for ack (A-bit). > > Julo > > Eddy Quicksall > Sent by: owner-ips@ece.cmu.edu > > > 06/08/2002 10:54 PM > Please respond to Eddy Quicksall > > > To: pat_thaler@agilent.com > cc: ips@ece.cmu.edu > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > Thanks, > > As a target, I won't be able to let it change until all of the outstanding > commands are finished (running with ErrorRecoveryLevel>=1). This is because > I must use the PDU size to compute the offset from a SNACK's > BegRun/RunLength. > > So, I plan to not give the text response for a MaxPDURecvDataLength in FFP > until I get back an ExpStatSN == next StatSN. > > This will cause a delay of unknown time before the PDU size can actually > change ... do you see any problem with this? > > Eddy > > -----Original Message----- > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > Sent: Friday, June 07, 2002 1:13 PM > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > Subject: RE: iSCSI: changing MaxPDUDataLength > > > Eddy, > > If one uses a message sync and steering that relys on the transport segments > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path > MTU changes one would want to change the PDU data length to fit the new path > MTU. > > Pat > > -----Original Message----- > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > Sent: Wednesday, June 05, 2002 12:24 PM > To: ips@ece.cmu.edu > Subject: iSCSI: changing MaxPDUDataLength > > > Does anybody know a case where it is necessary to support a new PDU data > length during full feature phase? > > Eddy > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > From owner-ips@ece.cmu.edu Sat Jun 15 00:35:12 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24028 for ; Sat, 15 Jun 2002 00:35:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5F4JaW28737 for ips-outgoing; Sat, 15 Jun 2002 00:19:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5F4JYw28732 for ; Sat, 15 Jun 2002 00:19:34 -0400 (EDT) Received: from mail pickup service by mail6.nc.rr.com with Microsoft SMTPSVC; Sat, 15 Jun 2002 00:19:15 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Jun 2002 20:31:21 -0400 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5C0VJa2019188 for ; Tue, 11 Jun 2002 20:31:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BNjY512669 for ips-outgoing; Tue, 11 Jun 2002 19:45:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BNjWw12664 for ; Tue, 11 Jun 2002 19:45:32 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 19:45:32 -0400 Message-ID: From: Eddy Quicksall To: "Mallikarjun C." , Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Date: Tue, 11 Jun 2002 19:45:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Consider the following (using Julian's suggestion): -> cmd 1 -> req to change to length 2 -> cmd 2 <- stat 1 <- data 2, PDU 0, Length 1 -> cmd 3, ack 1 so change the length <- data 2, PDU 1, Length 2 -> SNACK data 2, PDU 1 So we have to calculate the offset for Data 2, PDU 1 using old length and send data after that offset using new length. That means keeping track of PDU lengths which I would like to avoid. Or, the target would have to force idling of commands before it gives the response to the change. Can you suggest how this would be handled otherwise? Eddy -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com] Sent: Tuesday, June 11, 2002 6:57 PM To: Eddy Quicksall; Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iSCSI: changing MaxPDUDataLength Eddy, I am not sure if you're agreeing with me or not... but let me add some comments. I don't expect the change in PDU size to happen frequently - no change in what I earlier said. You are making an assumption that a target must record the PDU size for every PDU if SNACKs are to be satisfied across changed MaxRecvDataSegmentLength. As Julian earlier said, you don't have to. I will not go into implementation details, but I believe just the value of the DataSN from which the new size is effective should be all that's needed. Besides, the spec guarantees that only RunLength=0 is used on any SNACK after the change. You are also implying that targets can declare their changed MaxRecvDataSegmentLength anytime just for writes. There are two problems with this - a) reads and writes may both be active in the typical case on an iSCSI connection, and b) a target can declare its changed value only if an initiator is allowed to start the Text Request (and I thought you were suggesting that we explicitly disallow that). Hope that clears it up. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Eddy Quicksall" To: "Mallikarjun C." ; "Julian Satran" Cc: Sent: Tuesday, June 11, 2002 3:18 PM Subject: RE: iSCSI: changing MaxPDUDataLength > You are correct and that is exactly how I have had to code it. With fast > path and slow path code split between processors, it becomes even worse. > > When I read your comments on why the PDU size could change (from way back in > March I think), I got did not get the impression that it would happen very > often and that in fact it may only happen when you are maintaining > allegiance to another connection. > > If it is something that is not going to happen very often, then it would be > so much easier to have the initiator idle the commands first (all it really > needs to do is idle the READ commands). If it is going to change so often > that idling would be degrading, I suspect that just doing the negotiation > that often would itself be degrading. > > And, be aware that the target will probably idle the R commands. Otherwise, > it will have to track PDU sizes and that would be really > "counter-productive" (especially when there should be no SNACKs on a good > connection anyway). > > I don't see any problem with the target negotiating its size at any time. > And the initiator would not have to idle the WRITE or no-data commands. > > Eddy > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Tuesday, June 11, 2002 3:35 PM > To: Eddy Quicksall; Julian Satran > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: changing MaxPDUDataLength > > > Eddy, > > I am not clear on why you think the target code becomes messy on > a PDU size change. The last para in section 4.4 states the following - > > "Parameters negotiated by a text exchange negotiation sequence become > effective only after the negotiation sequence is completed." > > Since the target gets to complete a text negotiation with a Text Response > PDU, it can time the applicability of a changed MaxRecvDataSegmentLength. > > Requiring that an initiator must idle the connection before changing this > parameter, IMHO, is counter-productive when there's a dynamic PMTU > degradation in the presence of long-running commands (writes in particular). > Once the initiator starts the renegotiation, target would ideally want to > quickly > renegotiate its receive size as well to receive ULPDU-contained segments. > > In short, seems to me that the draft is saying what you would like. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > > ----- Original Message ----- > From: "Eddy Quicksall" > To: "Julian Satran" > Cc: > Sent: Tuesday, June 11, 2002 7:56 AM > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > I think it should be a requirement because if it is not, all target code > > will have to have the messy code. Or, we could say that if it is not idle > > commands, then the target may reject it. > > > > Eddy > > > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Tuesday, June 11, 2002 9:11 AM > > To: Eddy Quicksall > > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > That is a fair request - we may slip in a recommendation to that effect > (in > > chapter 11?) > > > > Julo > > > > > > > > Eddy Quicksall > > > > > > 06/11/2002 04:28 AM > > Please respond to Eddy Quicksall > > > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > How about if we say that an initiator must not change the MaxPDUDataSize > > unless it first idles the commands (at least the ones with the R bit) or > if > > ErrorRecoveryLevel==0? > > > > That would simplify target code greatly and would meet the design goals; > and > > since it should be rare to change it, it would be of little impact to idle > > the commands for a split second. > > > > > > Eddy > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Monday, June 10, 2002 8:06 PM > > To: Eddy Quicksall > > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > I said only that when you change length you can ask for all PDUs after the > > ack! (no need to keep a tall - the old offsets are good up to the hole). > > > > Julo > > > > > > Eddy Quicksall > > > > > > 06/11/2002 12:32 AM > > Please respond to Eddy Quicksall > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu, pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > Julian, > > > > Another problem here is that the target has to calculate the offset from > the > > DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 > > means starting DataSN=4, send all the data for that sequence. > > > > I think it would be a performance hit and waist of memory to keep a tally > of > > all PDU sizes just for an occasional SNACK. > > > > It's not that it can't be done ... it is more that it is messy and I think > > there is a solution that will satisfy the design requirements but keep the > > software simpler. > > > > Eddy > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Saturday, June 08, 2002 10:16 PM > > To: Eddy Quicksall > > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > That is not completely accurate. > > The only problem is when PDU size decreases and then SNACK must be for all > > data. > > Target can also keep a mapping of numbers/to offsets (the list should be > > small and if it gets long ask for ack (A-bit). > > > > Julo > > > > Eddy Quicksall > > Sent by: owner-ips@ece.cmu.edu > > > > > > 06/08/2002 10:54 PM > > Please respond to Eddy Quicksall > > > > > > To: pat_thaler@agilent.com > > cc: ips@ece.cmu.edu > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > > > > > > > > > Thanks, > > > > As a target, I won't be able to let it change until all of the outstanding > > commands are finished (running with ErrorRecoveryLevel>=1). This is > because > > I must use the PDU size to compute the offset from a SNACK's > > BegRun/RunLength. > > > > So, I plan to not give the text response for a MaxPDURecvDataLength in FFP > > until I get back an ExpStatSN == next StatSN. > > > > This will cause a delay of unknown time before the PDU size can actually > > change ... do you see any problem with this? > > > > Eddy > > > > -----Original Message----- > > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > > Sent: Friday, June 07, 2002 1:13 PM > > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > Eddy, > > > > If one uses a message sync and steering that relys on the transport > segments > > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path > > MTU changes one would want to change the PDU data length to fit the new > path > > MTU. > > > > Pat > > > > -----Original Message----- > > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > > Sent: Wednesday, June 05, 2002 12:24 PM > > To: ips@ece.cmu.edu > > Subject: iSCSI: changing MaxPDUDataLength > > > > > > Does anybody know a case where it is necessary to support a new PDU data > > length during full feature phase? > > > > Eddy > > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Sat Jun 15 01:21:32 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24379 for ; Sat, 15 Jun 2002 01:21:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5F4iEY29617 for ips-outgoing; Sat, 15 Jun 2002 00:44:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5F4iDw29612 for ; Sat, 15 Jun 2002 00:44:13 -0400 (EDT) Received: from mail pickup service by mail6.nc.rr.com with Microsoft SMTPSVC; Sat, 15 Jun 2002 00:36:52 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Jun 2002 19:31:14 -0400 Received: from engine.ieee.org (engine.ieee.org [140.98.193.23]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5BN0Na2018826 for ; Tue, 11 Jun 2002 19:00:23 -0400 (EDT) Received: from ece.cmu.edu (gemini3.ieee.org [140.98.193.25]) by engine.ieee.org (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5BN06B07405; Tue, 11 Jun 2002 19:00:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BMobx10193 for ips-outgoing; Tue, 11 Jun 2002 18:50:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BMoYw10182 for ; Tue, 11 Jun 2002 18:50:34 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5BMoRYj015576; Wed, 12 Jun 2002 00:50:27 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5BMoQp61766; Wed, 12 Jun 2002 00:50:26 +0200 Importance: High Subject: RE: iSCSI: changing MaxPDUDataLength To: Eddy Quicksall Cc: ips@ece.cmu.edu, Julian Satran X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Wed, 12 Jun 2002 00:17:16 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 12/06/2002 01:50:26 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I think that even the text I suggested is more than it is needed. Quiescing the connection is not practical - many large box builder will find this unacceptable and obviously an implementation can go away without it. As I pointed out for retries you need only the offset at the change point and anything that happens later require retransmission of everything from the known point. Julo Eddy Quicksall cc: Subject: RE: iSCSI: changing MaxPDUDataLength 06/11/2002 08:56 PM Please respond to Eddy Quicksall I see a case where the target could still end up sending PDU's of different lengths for a given command. It would be much safer if the initiator was required to idle the commands before sending the new MaxRecvDataSegmentLength. That way there is nothing for the target to do other than change the size. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, June 11, 2002 11:34 AM To: ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Importance: High I suggest the following text in 11.13 A change of MaxRecvDataSegmentLength by an initiator or target becomes effective after all commands preceding the negotiation end-ing request have been processed by the target and their status is acknowledged. I also realized that we don't have "negotiation prompt" from the target. I am not sure that we need one. If some of you think we need we may want one additional code in the Asynch Message. Please comment TODAY. Julo ----- Forwarded by Julian Satran/Haifa/IBM on 06/11/2002 06:29 PM ----- Julian Satran To: Eddy Quicksall 06/11/2002 04:04 cc: ips@ece.cmu.edu, pat_thaler@agilent.com PM From: Julian Satran/Haifa/IBM@IBMIL Subject: RE: iSCSI: changing MaxPDUDataLength(Document link: Julian Satran - Mail) That is a fair request - we may slip in a recommendation to that effect (in chapter 11?) Julo Eddy Quicksall cc: ips@ece.cmu.edu, pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength 06/11/2002 04:28 AM Please respond to Eddy Quicksall How about if we say that an initiator must not change the MaxPDUDataSize unless it first idles the commands (at least the ones with the R bit) or if ErrorRecoveryLevel==0? That would simplify target code greatly and would meet the design goals; and since it should be rare to change it, it would be of little impact to idle the commands for a split second. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, June 10, 2002 8:06 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu; pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength I said only that when you change length you can ask for all PDUs after the ack! (no need to keep a tall - the old offsets are good up to the hole). Julo Eddy Quicksall To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, 06/11/2002 12:32 AM pat_thaler@agilent.com Please respond to Eddy Quicksall Subject: RE: iSCSI: changing MaxPDUDataLength Julian, Another problem here is that the target has to calculate the offset from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and RunLngth=0 means starting DataSN=4, send all the data for that sequence. I think it would be a performance hit and waist of memory to keep a tally of all PDU sizes just for an occasional SNACK. It's not that it can't be done ... it is more that it is messy and I think there is a solution that will satisfy the design requirements but keep the software simpler. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, June 08, 2002 10:16 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com Subject: RE: iSCSI: changing MaxPDUDataLength That is not completely accurate. The only problem is when PDU size decreases and then SNACK must be for all data. Target can also keep a mapping of numbers/to offsets (the list should be small and if it gets long ask for ack (A-bit). Julo Eddy Quicksall To: Sent by: owner-ips@ece.cmu.edu pat_thaler@agilent.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: 06/08/2002 10:54 PM changing MaxPDUDataLength Please respond to Eddy Quicksall Thanks, As a target, I won't be able to let it change until all of the outstanding commands are finished (running with ErrorRecoveryLevel>=1). This is because I must use the PDU size to compute the offset from a SNACK's BegRun/RunLength. So, I plan to not give the text response for a MaxPDURecvDataLength in FFP until I get back an ExpStatSN == next StatSN. This will cause a delay of unknown time before the PDU size can actually change ... do you see any problem with this? Eddy -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Friday, June 07, 2002 1:13 PM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Eddy, If one uses a message sync and steering that relys on the transport segments carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the path MTU changes one would want to change the PDU data length to fit the new path MTU. Pat -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Wednesday, June 05, 2002 12:24 PM To: ips@ece.cmu.edu Subject: iSCSI: changing MaxPDUDataLength Does anybody know a case where it is necessary to support a new PDU data length during full feature phase? Eddy mailto: Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Sat Jun 15 01:21:40 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24392 for ; Sat, 15 Jun 2002 01:21:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5F4ZuB29330 for ips-outgoing; Sat, 15 Jun 2002 00:35:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5F4Zsw29325 for ; Sat, 15 Jun 2002 00:35:54 -0400 (EDT) Received: from mail pickup service by mail6.nc.rr.com with Microsoft SMTPSVC; Sat, 15 Jun 2002 00:34:11 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Jun 2002 22:02:17 -0400 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5C21BbC007789 for ; Tue, 11 Jun 2002 22:01:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5C1B4916541 for ips-outgoing; Tue, 11 Jun 2002 21:11:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5C1B2w16536 for ; Tue, 11 Jun 2002 21:11:02 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel11.hp.com (Postfix) with ESMTP id C342B60044C; Tue, 11 Jun 2002 18:10:56 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id SAA10416; Tue, 11 Jun 2002 18:12:45 -0700 (PDT) Message-ID: <012001c211ae$00baa990$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Julian Satran" Cc: References: Subject: Re: iSCSI: changing MaxPDUDataLength Date: Tue, 11 Jun 2002 18:10:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, I knew that the question was general, but I couldn't find any other key whose redeclaration/renegotiation is important during the life of a connection - and the proposed didn't look very useful for this key. Consequently, I don't see a strong reason for the addition except for completeness. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Julian Satran" To: "Mallikarjun C." Cc: ; "Julian Satran" ; Sent: Tuesday, June 11, 2002 2:28 PM Subject: Re: iSCSI: changing MaxPDUDataLength > > Mallikarjun, > > The question was general and not specific to MaxRecv.... > Although we say that negotiation is symmetric we don't have any mechanism > through which a target can say it wants to start negotiation something > (sort of similar but not as strong as a the "request logout" - "request to > negotiate" that will require the initiator to issue a text request and > kick-off a negotiation. > > Julo > > > > "Mallikarjun C." > To: , Julian Satran/Haifa/IBM@IBMIL > Sent by: cc: > owner-ips@ece.cmu Subject: Re: iSCSI: changing MaxPDUDataLength > .edu > > > 06/11/2002 10:50 > PM > Please respond to > "Mallikarjun C." > > > > > > > I also realized that we don't have "negotiation prompt" from the target. > > I am not sure that we need one. > > I am not sure about it either. > > My preference is not to add this. It appears to me that a target does have > the option of dropping the connection today if it can't work with > non-ULPDU-contained > segments for too long. I suspect that the target would do the same if (we > introduced the "negotiation prompt" and) the initiator doesn't/couldn't > honor the > "negotiation prompt". > > Thanks. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > > ----- Original Message ----- > From: "Julian Satran" > To: > Sent: Tuesday, June 11, 2002 8:34 AM > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > I suggest the following text in 11.13 > > > > A change of MaxRecvDataSegmentLength by an initiator or target > > becomes effective after all commands preceding the negotiation > > end-ing request have been processed by the target and their status > > is acknowledged. > > > > I also realized that we don't have "negotiation prompt" from the target. > > I am not sure that we need one. > > If some of you think we need we may want one additional code in the > Asynch > > Message. > > Please comment TODAY. > > > > Julo > > ----- Forwarded by Julian Satran/Haifa/IBM on 06/11/2002 06:29 PM ----- > > > > Julian Satran > > To: Eddy Quicksall > > > 06/11/2002 04:04 cc: ips@ece.cmu.edu, > pat_thaler@agilent.com > > > PM From: Julian > Satran/Haifa/IBM@IBMIL > > Subject: RE: iSCSI: > changing MaxPDUDataLength(Document link: > Julian Satran - Mail) > > > > > > > > > > > > > > > > > > > > That is a fair request - we may slip in a recommendation to that effect > (in > > chapter 11?) > > > > Julo > > > > > > > > Eddy Quicksall > > Satran/Haifa/IBM@IBMIL > > vivity.com> cc: ips@ece.cmu.edu, > pat_thaler@agilent.com > > Subject: RE: iSCSI: > changing MaxPDUDataLength > > 06/11/2002 04:28 > > AM > > Please respond to > > Eddy Quicksall > > > > > > > > > > > > How about if we say that an initiator must not change the MaxPDUDataSize > > unless it first idles the commands (at least the ones with the R bit) or > if > > ErrorRecoveryLevel==0? > > > > That would simplify target code greatly and would meet the design goals; > > and since it should be rare to change it, it would be of little impact to > > idle the commands for a split second. > > > > > > Eddy > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Monday, June 10, 2002 8:06 PM > > To: Eddy Quicksall > > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > I said only that when you change length you can ask for all PDUs > > after the ack! (no need to keep a tall - the old offsets are good > up > > to the hole). > > > > Julo > > > > > > Eddy Quicksall > > To: Julian > > Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu, > > 06/11/2002 12:32 AM pat_thaler@agilent.com > > Please respond to Eddy Quicksall Subject: RE: iSCSI: > > changing MaxPDUDataLength > > > > > > > > > > > > > > > > Julian, > > > > Another problem here is that the target has to calculate the offset > > from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 > and > > RunLngth=0 means starting DataSN=4, send all the data for that > > sequence. > > > > I think it would be a performance hit and waist of memory to keep a > > tally of all PDU sizes just for an occasional SNACK. > > > > It's not that it can't be done ... it is more that it is messy and > I > > think there is a solution that will satisfy the design requirements > > but keep the software simpler. > > > > Eddy > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Saturday, June 08, 2002 10:16 PM > > To: Eddy Quicksall > > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > That is not completely accurate. > > The only problem is when PDU size decreases and then SNACK must be > > for all data. > > Target can also keep a mapping of numbers/to offsets (the list > should > > be small and if it gets long ask for ack (A-bit). > > > > Julo > > > > Eddy Quicksall > > To: > > Sent by: owner-ips@ece.cmu.edu pat_thaler@agilent.com > > cc: ips@ece.cmu.edu > > Subject: RE: iSCSI: > > 06/08/2002 10:54 PM changing MaxPDUDataLength > > Please respond to Eddy Quicksall > > > > > > > > > > > > > > > > Thanks, > > > > As a target, I won't be able to let it change until all of the > > outstanding > > commands are finished (running with ErrorRecoveryLevel>=1). This is > > because > > I must use the PDU size to compute the offset from a SNACK's > > BegRun/RunLength. > > > > So, I plan to not give the text response for a MaxPDURecvDataLength > > in FFP > > until I get back an ExpStatSN == next StatSN. > > > > This will cause a delay of unknown time before the PDU size can > > actually > > change ... do you see any problem with this? > > > > Eddy > > > > -----Original Message----- > > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > > Sent: Friday, June 07, 2002 1:13 PM > > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > > Subject: RE: iSCSI: changing MaxPDUDataLength > > > > > > Eddy, > > > > If one uses a message sync and steering that relys on the transport > > segments > > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if > the > > path > > MTU changes one would want to change the PDU data length to fit the > > new path > > MTU. > > > > Pat > > > > -----Original Message----- > > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > > Sent: Wednesday, June 05, 2002 12:24 PM > > To: ips@ece.cmu.edu > > Subject: iSCSI: changing MaxPDUDataLength > > > > > > Does anybody know a case where it is necessary to support a new PDU > > data > > length during full feature phase? > > > > Eddy > > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Sat Jun 15 01:24:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23984 for ; Sat, 15 Jun 2002 00:31:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5F3t0I27690 for ips-outgoing; Fri, 14 Jun 2002 23:55:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5F3sww27685; Fri, 14 Jun 2002 23:54:58 -0400 (EDT) Received: from mail pickup service by mail6.nc.rr.com with Microsoft SMTPSVC; Fri, 14 Jun 2002 23:54:37 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Jun 2002 19:22:20 -0400 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5BNMJbC001467 for ; Tue, 11 Jun 2002 19:22:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5BMocw10196 for ips-outgoing; Tue, 11 Jun 2002 18:50:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5BMoYw10181; Tue, 11 Jun 2002 18:50:34 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5BMoRYj060852; Wed, 12 Jun 2002 00:50:27 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5BMoQp125010; Wed, 12 Jun 2002 00:50:27 +0200 Importance: High Subject: Re: iSCSI: changing MaxPDUDataLength To: "Mallikarjun C." Cc: ips@ece.cmu.edu, "Julian Satran" , owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Wed, 12 Jun 2002 00:28:28 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 12/06/2002 01:50:27 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mallikarjun, The question was general and not specific to MaxRecv.... Although we say that negotiation is symmetric we don't have any mechanism through which a target can say it wants to start negotiation something (sort of similar but not as strong as a the "request logout" - "request to negotiate" that will require the initiator to issue a text request and kick-off a negotiation. Julo "Mallikarjun C." To: , Julian Satran/Haifa/IBM@IBMIL Sent by: cc: owner-ips@ece.cmu Subject: Re: iSCSI: changing MaxPDUDataLength .edu 06/11/2002 10:50 PM Please respond to "Mallikarjun C." > I also realized that we don't have "negotiation prompt" from the target. > I am not sure that we need one. I am not sure about it either. My preference is not to add this. It appears to me that a target does have the option of dropping the connection today if it can't work with non-ULPDU-contained segments for too long. I suspect that the target would do the same if (we introduced the "negotiation prompt" and) the initiator doesn't/couldn't honor the "negotiation prompt". Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Julian Satran" To: Sent: Tuesday, June 11, 2002 8:34 AM Subject: RE: iSCSI: changing MaxPDUDataLength > I suggest the following text in 11.13 > > A change of MaxRecvDataSegmentLength by an initiator or target > becomes effective after all commands preceding the negotiation > end-ing request have been processed by the target and their status > is acknowledged. > > I also realized that we don't have "negotiation prompt" from the target. > I am not sure that we need one. > If some of you think we need we may want one additional code in the Asynch > Message. > Please comment TODAY. > > Julo > ----- Forwarded by Julian Satran/Haifa/IBM on 06/11/2002 06:29 PM ----- > > Julian Satran > To: Eddy Quicksall > 06/11/2002 04:04 cc: ips@ece.cmu.edu, pat_thaler@agilent.com > PM From: Julian Satran/Haifa/IBM@IBMIL > Subject: RE: iSCSI: changing MaxPDUDataLength(Document link: Julian Satran - Mail) > > > > > > > > > > That is a fair request - we may slip in a recommendation to that effect (in > chapter 11?) > > Julo > > > > Eddy Quicksall > vivity.com> cc: ips@ece.cmu.edu, pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > 06/11/2002 04:28 > AM > Please respond to > Eddy Quicksall > > > > > > How about if we say that an initiator must not change the MaxPDUDataSize > unless it first idles the commands (at least the ones with the R bit) or if > ErrorRecoveryLevel==0? > > That would simplify target code greatly and would meet the design goals; > and since it should be rare to change it, it would be of little impact to > idle the commands for a split second. > > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Monday, June 10, 2002 8:06 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > I said only that when you change length you can ask for all PDUs > after the ack! (no need to keep a tall - the old offsets are good up > to the hole). > > Julo > > > Eddy Quicksall > To: Julian > Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu, > 06/11/2002 12:32 AM pat_thaler@agilent.com > Please respond to Eddy Quicksall Subject: RE: iSCSI: > changing MaxPDUDataLength > > > > > > > > Julian, > > Another problem here is that the target has to calculate the offset > from the DataSN #. And as BegRun can be any value. E.g., BegRun=4 and > RunLngth=0 means starting DataSN=4, send all the data for that > sequence. > > I think it would be a performance hit and waist of memory to keep a > tally of all PDU sizes just for an occasional SNACK. > > It's not that it can't be done ... it is more that it is messy and I > think there is a solution that will satisfy the design requirements > but keep the software simpler. > > Eddy > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Saturday, June 08, 2002 10:16 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com > Subject: RE: iSCSI: changing MaxPDUDataLength > > > That is not completely accurate. > The only problem is when PDU size decreases and then SNACK must be > for all data. > Target can also keep a mapping of numbers/to offsets (the list should > be small and if it gets long ask for ack (A-bit). > > Julo > > Eddy Quicksall > To: > Sent by: owner-ips@ece.cmu.edu pat_thaler@agilent.com > cc: ips@ece.cmu.edu > Subject: RE: iSCSI: > 06/08/2002 10:54 PM changing MaxPDUDataLength > Please respond to Eddy Quicksall > > > > > > > > Thanks, > > As a target, I won't be able to let it change until all of the > outstanding > commands are finished (running with ErrorRecoveryLevel>=1). This is > because > I must use the PDU size to compute the offset from a SNACK's > BegRun/RunLength. > > So, I plan to not give the text response for a MaxPDURecvDataLength > in FFP > until I get back an ExpStatSN == next StatSN. > > This will cause a delay of unknown time before the PDU size can > actually > change ... do you see any problem with this? > > Eddy > > -----Original Message----- > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > Sent: Friday, June 07, 2002 1:13 PM > To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu > Subject: RE: iSCSI: changing MaxPDUDataLength > > > Eddy, > > If one uses a message sync and steering that relys on the transport > segments > carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if the > path > MTU changes one would want to change the PDU data length to fit the > new path > MTU. > > Pat > > -----Original Message----- > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > Sent: Wednesday, June 05, 2002 12:24 PM > To: ips@ece.cmu.edu > Subject: iSCSI: changing MaxPDUDataLength > > > Does anybody know a case where it is necessary to support a new PDU > data > length during full feature phase? > > Eddy > mailto: Eddy_Quicksall@iVivity.com > > > > > > > > > > From owner-ips@ece.cmu.edu Sat Jun 15 09:10:53 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07399 for ; Sat, 15 Jun 2002 09:10:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5FCVco25565 for ips-outgoing; Sat, 15 Jun 2002 08:31:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5F3Y0w26859 for ; Fri, 14 Jun 2002 23:34:00 -0400 (EDT) Received: from mail pickup service by mail6.nc.rr.com with Microsoft SMTPSVC; Fri, 14 Jun 2002 23:31:47 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 23:02:46 -0400 Received: from ruebert.ieee.org (ruebert.ieee.org [140.98.193.10]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5B32kIa000661 for ; Mon, 10 Jun 2002 23:02:46 -0400 (EDT) Received: from ece.cmu.edu (gemini2.ieee.org [140.98.193.20]) by ruebert.ieee.org (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5B328q26461; Mon, 10 Jun 2002 23:02:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5B2oZl28608 for ips-outgoing; Mon, 10 Jun 2002 22:50:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5B2o5w28577 for ; Mon, 10 Jun 2002 22:50:05 -0400 (EDT) Received: from phys-hanwk16-2.ebay.sun.com ([129.149.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA18895; Mon, 10 Jun 2002 19:49:59 -0700 (PDT) Received: from Sun.COM (vpn-129-147-152-110.Central.Sun.COM [129.147.152.110]) by phys-hanwk16-2.ebay.sun.com (8.10.2+Sun/8.10.2/ENSMAIL,v2.1p1) with ESMTP id g5B2nuB14917; Mon, 10 Jun 2002 19:49:56 -0700 (PDT) Message-ID: <3D05658A.6040707@Sun.COM> Date: Mon, 10 Jun 2002 21:50:50 -0500 From: David Robinson User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Bill Studenmund CC: Paul Koning , pat_thaler@agilent.com, ksandars@eurologic.com, bmastors@allocity.com, ips@ece.cmu.edu Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bill Studenmund wrote: > On Mon, 10 Jun 2002, Paul Koning wrote: >>Excerpt of message (sent 10 June 2002) by Bill Studenmund: >> >>>I expect iSCSI 2 (or 1.1) will be on the order of a year or more out from >>>iSCSI. What does everyone else think? >>> >>If the spec is as good as it should be, that's a fine time frame. But >>if significant interop issues are found soon after RFC, then 1.1 will >>have to happen a whole lot sooner. >> > > What happens if we're somewhere inbetween? Or what if we find an issue > where 80% of the implementations all chose the same way? > > I'm trying to scope out the shades of gray we might run into. As a reminder about the IETF standards process, RFC2026. The IPS working group is driving towards "Proposed Standard" which by definition: "Implementors should treat Proposed Standards as immature specifications." The next step is "Draft Standard" where there is expectation that changes will be made between Proposed and Draft. "A Draft Standard is normally considered to be a final specification..." To move from Proposed to Draft is where two independant implementations are required and where the "80%" implementation problems are caught and fixed. The RFC we are driving towards is just the first step in a long path, there will be plenty of opportunities to fix "bugs" that are found we real implementations are built. Thus vendor specific keys are not needed, what we have today is not going to be the "Internet Standard." -David From owner-ips@ece.cmu.edu Sat Jun 15 12:26:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11197 for ; Sat, 15 Jun 2002 12:25:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5FFXcs01520 for ips-outgoing; Sat, 15 Jun 2002 11:33:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5FFXaw01515 for ; Sat, 15 Jun 2002 11:33:36 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5FFXQCo012054; Sat, 15 Jun 2002 17:33:27 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5FFXQ4114924; Sat, 15 Jun 2002 17:33:27 +0200 To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: use of Text/Login with no data segment X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 15 Jun 2002 18:33:22 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 15/06/2002 18:33:27, Serialize complete at 15/06/2002 18:33:27 Content-Type: multipart/alternative; boundary="=_alternative 0054B610C2256BD9_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0054B610C2256BD9_= Content-Type: text/plain; charset="us-ascii" Pat, The SHOULD is there to avoid abuse and I will fix the text Julo pat_thaler@agilent.com 06/15/2002 12:51 AM Please respond to pat_thaler To: "Julian Satran" , ips@ece.cmu.edu cc: Subject: iSCSI: use of Text/Login with no data segment Julian, 4.2 (page 72) of iSCSI-13 says: A target or initiator SHOULD NOT use a Text/Login Response or Text/ Login Request with no data segment (DataSegmentLength 0) unless responding to a Text/Login Request respective Text/Login Response with the C bit set to 1. "SHOULD NOT" is too strong here as there are times when one must send a Text/Login Response or Request with no data segment if one is to complete the login. For example, a Target might send a Login response with the T=0 and C=0. If the initiator doesn't have an keys it wants to send, then the initiator will have to send a Login Request with no data segment if the login is to complete. Also, wrt grammar, "respective" is not a conjunction so the normal way to use it would be "... A or B ... C or D, respectively, ...." At least that is the usage that I have seen and what the dictionary at hand supports. If one wants to retain the idea of not sending empty PDUs when you do have something to say, one could put in: A target or initiator SHOULD NOT use a Text/Login Response or Text/ Login Request with no data segment (DataSegmentLength 0) unless responding to a Text/Login Request or Text/Login Response, respectively, with the T bit set to 0 while the node has no keys to send or with the C bit set to 1. Pat --=_alternative 0054B610C2256BD9_= Content-Type: text/html; charset="us-ascii"
Pat,

The SHOULD is there to avoid abuse and I will fix the text

Julo


pat_thaler@agilent.com

06/15/2002 12:51 AM
Please respond to pat_thaler

       
        To:        "Julian Satran" <Julian_Satran@il.ibm.com>, ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI: use of Text/Login with no data segment

       


Julian,

4.2 (page 72) of iSCSI-13 says:
A target or initiator SHOULD NOT use a Text/Login Response or Text/
Login Request with no data segment (DataSegmentLength 0) unless
responding to a Text/Login Request respective Text/Login Response
with the C bit set to 1.

"SHOULD NOT" is too strong here as there are times when one must send a
Text/Login Response or Request with no data segment if one is to complete
the login.

For example, a Target might send a Login response with the T=0 and C=0. If
the initiator doesn't have an keys it wants to send, then the initiator will
have to send a Login Request with no data segment if the login is to
complete.

Also, wrt grammar, "respective" is not a conjunction so the normal way to
use it would be "... A or B ... C or D, respectively, ...." At least that is
the usage that I have seen and what the dictionary at hand supports.

If one wants to retain the idea of not sending empty PDUs when you do have
something to say, one could put in:
A target or initiator SHOULD NOT use a Text/Login Response or Text/
Login Request with no data segment (DataSegmentLength 0) unless
responding to a Text/Login Request or Text/Login Response, respectively,
with the T bit set to 0 while the node has no keys to send or with the C bit
set to 1.

Pat

--=_alternative 0054B610C2256BD9_=-- From owner-ips@ece.cmu.edu Sat Jun 15 12:28:13 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11220 for ; Sat, 15 Jun 2002 12:28:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5FG68K02748 for ips-outgoing; Sat, 15 Jun 2002 12:06:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5FG65w02737; Sat, 15 Jun 2002 12:06:05 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5FG5w5u086820; Sat, 15 Jun 2002 18:05:58 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5FG5v469696; Sat, 15 Jun 2002 18:05:57 +0200 To: "THALER,PAT (A-Roseville,ex1)" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: length and size X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 15 Jun 2002 19:05:50 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 15/06/2002 19:05:57, Serialize complete at 15/06/2002 19:05:57 Content-Type: multipart/alternative; boundary="=_alternative 0058303AC2256BD9_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0058303AC2256BD9_= Content-Type: text/plain; charset="us-ascii" Pat, Is this a wish or an issue for the WG last call? Julo "THALER,PAT (A-Roseville,ex1)" Sent by: owner-ips@ece.cmu.edu 06/15/2002 02:50 AM Please respond to "THALER,PAT (A-Roseville,ex1)" To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: iSCSI: length and size Julian, iSCSI-13 uses "length" quite a bit more than 100 times. Many of those times are in regard to the length of data, headers, and PDUs e.g. The basic header segment has a fixed length of 48 bytes. Expected Data Transfer Length Each PDU contains the payload length and the data offset.... It also uses size about 40 times with the same meaning as length. Most of these are the terms MaxBurstSize and FirstBurstSize and text associated with those terms. It would be better (less likely to confuse readers and better for those of us who look for information using search tools) to choose one of those terms and always use it when talking about length/size. I don't care which is chosen. Pat --=_alternative 0058303AC2256BD9_= Content-Type: text/html; charset="us-ascii"
Pat,

Is this a wish or an issue for the WG last call?

Julo


"THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>
Sent by: owner-ips@ece.cmu.edu

06/15/2002 02:50 AM
Please respond to "THALER,PAT (A-Roseville,ex1)"

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        iSCSI: length and size

       


Julian,

iSCSI-13 uses "length" quite a bit more than 100 times. Many of those times are in regard to the length of data, headers, and PDUs

e.g.
The basic header segment has a fixed length of 48 bytes.
Expected Data Transfer Length
Each PDU contains the payload length and the data offset....

It also uses size about 40 times with the same meaning as length. Most of these are the terms MaxBurstSize and FirstBurstSize and text associated with those terms.

It would be better (less likely to confuse readers and better for those of us who look for information using search tools) to choose one of those terms and always use it when talking about length/size. I don't care which is chosen.

Pat

--=_alternative 0058303AC2256BD9_=-- From owner-ips@ece.cmu.edu Sat Jun 15 12:28:35 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11235 for ; Sat, 15 Jun 2002 12:28:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5FG6BZ02756 for ips-outgoing; Sat, 15 Jun 2002 12:06:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5FG69w02750; Sat, 15 Jun 2002 12:06:09 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5FG5vk2016074; Sat, 15 Jun 2002 18:05:57 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5FG5q469694; Sat, 15 Jun 2002 18:05:56 +0200 To: "Mallikarjun C." Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu, "Bill Studenmund" MIME-Version: 1.0 Subject: Re: Reject PDUs and the F bit X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 15 Jun 2002 19:05:46 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 15/06/2002 19:05:56, Serialize complete at 15/06/2002 19:05:56 Content-Type: multipart/alternative; boundary="=_alternative 0057B41CC2256BD9_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0057B41CC2256BD9_= Content-Type: text/plain; charset="us-ascii" Mallikarjun, I suggest the following text that just spells out all cases: If the error is detected while data from the initiator is still expected (the com-mand PDU did not contain all the data and the target has not received a Data-out PDU with the Final bit 1 for the unsolicited data - if any and all outstanding R2Ts - if any), the target MUST wait until it receives the last expected Data-out PDUs with the F bit set to 1 Julo "Mallikarjun C." Sent by: owner-ips@ece.cmu.edu 06/15/2002 02:41 AM Please respond to "Mallikarjun C." To: "Bill Studenmund" , cc: Subject: Re: Reject PDUs and the F bit Bill, On your 1, the answer is yes. It is designed to allow a generic PDU reject handling code on both sides, which may or may not escalate to the task termination. If it did, it would be handled uniformly as any other SCSI Response. On your 2, the answer is yes, the target is expected to wait for all outstanding R2Ts to be responded to (section 6.5 specifies it clearly). Sorry, I agree that it isn't as clear as it can be here. Julian, I suggest replacing the last sentence of the quoted text with the below. If the error is detected while data from the initiator is still expected (the com- mand PDU did not contain all the data and/or the target has not received a Data-Out PDU with the F bit set to 1 in response to each outstanding R2T), the target MUST wait until it receives the last expected Data-out PDU with the F bit set to 1 before sending the Response PDU. Thanks! -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Bill Studenmund" To: Sent: Friday, June 14, 2002 1:12 PM Subject: Reject PDUs and the F bit > I haev a question about the following text in section 9.17.1 of 12-97 > (which I don't think's changed): > > In all the cases in which a pre-instantiated SCSI task is terminated > because of the reject, the target MUST issue a proper SCSI command > response with CHECK CONDITION as described in Section 9.4.3 Response. > In those cases in which a status for the SCSI task was already sent > before the reject no additional status is required. If the error is > detected while data from the initiator is still expected (the com- > mand PDU did not contain all the data and the target has not received > a Data-out PDU with the Final bit 1), the target MUST wait until it > receives the Data-out PDU with the F bit set to 1 before sending the > Response PDU. > > I'm confused on two points: > > 1) When do we need to send a Reject PDU if we're also sending a SCSI > Response that indicates error status? i.e. why send two PDUs? Is it to > provide both iSCSI and SCSI status? > > 2) I have a question about the, "If the error is detected while data from > the initiator is still expected ..." part. Say the command was an iSCSI > write, and I have three outstanding R2Ts. Part way through I realize that > I want to error away the task (for whatever reason). Am I correct in > reading the above text as saying I have to wait for all of my outstanding > R2Ts to close (send the F bit), or do I only have to wait for one to > close? > > Take care, > > Bill > > --=_alternative 0057B41CC2256BD9_= Content-Type: text/html; charset="us-ascii"
                Mallikarjun,

I suggest the following text that just spells out all cases:

If the error is detected while data from the initiator is still expected (the com-mand PDU did not contain all the data and the target has not received a Data-out PDU with the Final bit 1 for the unsolicited data - if any and all outstanding R2Ts - if any), the target MUST wait until it receives the last expected Data-out PDUs with the F bit set to 1

Julo


"Mallikarjun C." <cbm@rose.hp.com>
Sent by: owner-ips@ece.cmu.edu

06/15/2002 02:41 AM
Please respond to "Mallikarjun C."

       
        To:        "Bill Studenmund" <wrstuden@wasabisystems.com>, <ips@ece.cmu.edu>
        cc:        
        Subject:        Re: Reject PDUs and the F bit

       


Bill,

On your 1, the answer is yes.  It is designed to allow a generic PDU reject
handling code on both sides, which may or may not escalate to the task
termination.  If it did, it would be handled uniformly as any other SCSI Response.

On your 2, the answer is yes, the target is expected to wait for all outstanding
R2Ts to be responded to (section 6.5 specifies it clearly).  Sorry, I agree that it
isn't as clear as it can be here.

Julian, I suggest replacing the last sentence of the quoted text with the below.

    If the error is detected while data from the initiator is still expected (the com-
    mand PDU did not contain all the data and/or the target has not received
    a Data-Out PDU with the F bit set to 1 in response to each outstanding R2T),
    the target MUST wait until it receives the last expected Data-out PDU with
    the F bit set to 1 before sending the Response PDU.

Thanks!
--
Mallikarjun

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


----- Original Message -----
From: "Bill Studenmund" <wrstuden@wasabisystems.com>
To: <ips@ece.cmu.edu>
Sent: Friday, June 14, 2002 1:12 PM
Subject: Reject PDUs and the F bit


> I haev a question about the following text in section 9.17.1 of 12-97
> (which I don't think's changed):
>
>      In all the cases in which a pre-instantiated SCSI task is terminated
>      because of the reject, the target MUST issue a proper SCSI command
>      response with CHECK CONDITION as described in Section 9.4.3 Response.
>      In those cases in which a status for the SCSI task was already sent
>      before the reject no additional status is required. If the error is
>      detected while data from the initiator is still expected (the com-
>      mand PDU did not contain all the data and the target has not received
>      a Data-out PDU with the Final bit 1), the target MUST wait until it
>      receives the Data-out PDU with the F bit set to 1 before sending the
>      Response PDU.
>
> I'm confused on two points:
>
> 1) When do we need to send a Reject PDU if we're also sending a SCSI
> Response that indicates error status? i.e. why send two PDUs? Is it to
> provide both iSCSI and SCSI status?
>
> 2) I have a question about the, "If the error is detected while data from
> the initiator is still expected ..." part. Say the command was an iSCSI
> write, and I have three outstanding R2Ts. Part way through I realize that
> I want to error away the task (for whatever reason). Am I correct in
> reading the above text as saying I have to wait for all of my outstanding
> R2Ts to close (send the F bit), or do I only have to wait for one to
> close?
>
> Take care,
>
> Bill
>
>



--=_alternative 0057B41CC2256BD9_=-- From owner-ips@ece.cmu.edu Sat Jun 15 12:29:06 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11257 for ; Sat, 15 Jun 2002 12:29:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5FFiRE01918 for ips-outgoing; Sat, 15 Jun 2002 11:44:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5FFiPw01914 for ; Sat, 15 Jun 2002 11:44:25 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5FFiG5u072168; Sat, 15 Jun 2002 17:44:17 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5FFiG484694; Sat, 15 Jun 2002 17:44:16 +0200 To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu, mkrikis@yahoo.com, pat_thaler@agilent.com MIME-Version: 1.0 Subject: RE: iSCSI: use of Text/Login with no data segment X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 15 Jun 2002 18:44:11 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 15/06/2002 18:44:16, Serialize complete at 15/06/2002 18:44:16 Content-Type: multipart/alternative; boundary="=_alternative 00566A7BC2256BD9_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00566A7BC2256BD9_= Content-Type: text/plain; charset="us-ascii" I would like to keep Pat's wording including SHOULD. It has text about "nothing to say" and I put it there to avoid abuse and allow a cautious party to terminate a negotiation not standing by the rules. I even considered MUST but I think that some implementations may want to (seldom) send an empty PDU (simpler implementation). Julo pat_thaler@agilent.com 06/15/2002 02:38 AM Please respond to pat_thaler To: mkrikis@yahoo.com, pat_thaler@agilent.com, Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iSCSI: use of Text/Login with no data segment Martins, Your alternate wording looks fine to me. Pat -----Original Message----- From: Martins Krikis [mailto:mkrikis@yahoo.com] Sent: Friday, June 14, 2002 4:32 PM To: pat_thaler@agilent.com; Julian_Satran@il.ibm.com; ips@ece.cmu.edu Subject: Re: iSCSI: use of Text/Login with no data segment --- pat_thaler@agilent.com wrote: > If one wants to retain the idea of not sending empty > PDUs when you do have > something to say, one could put in: > A target or initiator SHOULD NOT use a Text/Login > Response or Text/ > Login Request with no data segment > (DataSegmentLength 0) unless > responding to a Text/Login Request or Text/Login > Response, respectively, > with the T bit set to 0 while the node has no keys > to send or with the C bit > set to 1. I don't see a problem with an implementation that deliberately sends an empty PDU to let the other side "speak" first. Doing this back-and-forth would not be a great situation, but IMHO it suffices to simply discourage such behavior, without resorting to "SHOULD NOT"-s. So, how about this instead? A target or initiator is discouraged from sending Text/Login Response or Text/Login Request with no data segment (DataSegmentLength 0) unless responding to a Text/Login Request or Text/Login Response, respectively, with the C bit set to 1, or the F/T bit set to 0 while having no keys to send. Or, let's just skip such restrictions/discouragements entirely. Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com --=_alternative 00566A7BC2256BD9_= Content-Type: text/html; charset="us-ascii"
I would like to keep Pat's wording including SHOULD.  It has text about "nothing to say" and I put it there to avoid abuse and allow a cautious party to terminate a negotiation not standing by the rules.  I even considered MUST but I think that some implementations may want to (seldom) send an empty PDU (simpler implementation).

Julo


pat_thaler@agilent.com

06/15/2002 02:38 AM
Please respond to pat_thaler

       
        To:        mkrikis@yahoo.com, pat_thaler@agilent.com, Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
        cc:        
        Subject:        RE: iSCSI: use of Text/Login with no data segment

       


Martins,

Your alternate wording looks fine to me.

Pat

-----Original Message-----
From: Martins Krikis [mailto:mkrikis@yahoo.com]
Sent: Friday, June 14, 2002 4:32 PM
To: pat_thaler@agilent.com; Julian_Satran@il.ibm.com; ips@ece.cmu.edu
Subject: Re: iSCSI: use of Text/Login with no data segment


--- pat_thaler@agilent.com wrote:

> If one wants to retain the idea of not sending empty
> PDUs when you do have
> something to say, one could put in:
> A target or initiator SHOULD NOT use a Text/Login
> Response or Text/
> Login Request with no data segment
> (DataSegmentLength 0) unless
> responding to a Text/Login Request or Text/Login
> Response, respectively,
> with the T bit set to 0 while the node has no keys
> to send or with the C bit
> set to 1.

I don't see a problem with an implementation that
deliberately sends an empty PDU to let the other
side "speak" first. Doing this back-and-forth would
not be a great situation, but IMHO it suffices to
simply discourage such behavior, without resorting
to "SHOULD NOT"-s.

So, how about this instead?

 A target or initiator is discouraged from
 sending Text/Login Response or Text/Login Request
 with no data segment (DataSegmentLength 0) unless
 responding to a Text/Login Request or Text/Login
 Response, respectively, with the C bit set to 1,
 or the F/T bit set to 0 while having no keys to
 send.

Or, let's just skip such restrictions/discouragements
entirely.

Martins Krikis, Intel Corp.

Disclaimer: these opinions are mine and may not
           be those of my employer.



__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--=_alternative 00566A7BC2256BD9_=-- From owner-ips@ece.cmu.edu Sat Jun 15 13:19:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12501 for ; Sat, 15 Jun 2002 13:19:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5FGRXD03559 for ips-outgoing; Sat, 15 Jun 2002 12:27:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5FGRVw03552 for ; Sat, 15 Jun 2002 12:27:31 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5FGRN5u023586; Sat, 15 Jun 2002 18:27:23 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5FGRMX129926; Sat, 15 Jun 2002 18:27:22 +0200 To: "THALER,PAT (A-Roseville,ex1)" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: advancing CmdSN after a command retry rule X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 15 Jun 2002 19:27:17 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 15/06/2002 19:27:22, Serialize complete at 15/06/2002 19:27:22 Content-Type: multipart/alternative; boundary="=_alternative 005A15F6C2256BD9_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005A15F6C2256BD9_= Content-Type: text/plain; charset="us-ascii" Pat, If the connection went through a "restart" (login with the same CID) then the "cleaning" is also not needed. Your text modified as follows is acceptable: If an initiator issues a command retry for a command with CmdSN R on a connection when the session CmdSN register is Q, it MUST NOT advance the CmdSN past R + 2**31 -1 unless the connection is no longer operational, or the connection has been reinstated (see Section 4.3.4 Connection reinstatement), or a non-immediate command with CmdSN equal or greater than Q was issued on the same connection and the reception of the command is acknowledged by the target (see Section 8.4 Command Retry and Cleaning Old Command Instances). Thanks, Julo "THALER,PAT (A-Roseville,ex1)" 06/15/2002 03:39 AM Please respond to "THALER,PAT (A-Roseville,ex1)" To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: iSCSI: advancing CmdSN after a command retry rule Julian, I'm having a little trouble understanding this text near the end of 2.2.2.1: If an initiator issues a command retry for a command with CmdSN R on a connection when the session CmdSN register is Q, it MUST NOT advance the CmdSN past R + 2**31 -1 unless a different non-immediate command with CmdSN equal or greater than Q was issued on the same connection if the connection is still operational, and the reception of the command is acknowledged by the target (see Section 8.4 Command Retry and Cleaning Old Command Instances). The second non-immediate command when sent, MUST be sent in-order after the retried command on the same connection. What does "different" mean in a different non-immediate command with CmdSN equal or greater than Q"? Isn't any command with a new CmdSN because it has a new CmdSN? What is the purpose of "if the connection is still operational"? If a new command is issued on the connection it must still be operational. Perhaps it was intended to mean that if the connection was not operational then CmdSN can be advanced past the limit without this requirement being met. There doesn't seem to be any definition of when a connection is "operational". Does the connection leave the operational state when it leaves S5 or is it when it has returned to S1? Does "second non-immediate command" mean the command sent on this connection with CmdSN equal or greater than Q? Other commands with Q <= CmdSN < R + 2**31 - 1 may be sent on other connections, so the second command is the second command on this connection, right? It isn't clear what the last sentence was intended to do since any command sent before the retry would advance Q so inherently any command sent after the retry with a new CmdSN must be in-order after the retry. I suggest the following text plus clarification of the meaning of operational for a connection: "If an initiator issues a command retry for a command with CmdSN R on a connection when the session CmdSN register is Q, it MUST NOT advance the CmdSN past R + 2**31 -1 unless the connection is no longer operational or a non-immediate command with CmdSN equal or greater than Q was issued on the same connection and the reception of the command is acknowledged by the target (see Section 8.4 Command Retry and Cleaning Old Command Instances). Pat --=_alternative 005A15F6C2256BD9_= Content-Type: text/html; charset="us-ascii"
Pat,

If the connection went through a "restart" (login with the same CID) then the "cleaning" is also not needed.
Your text modified as follows is acceptable:

If an initiator issues a command retry for a command with CmdSN R on
a connection when the session CmdSN register is Q, it MUST NOT advance the CmdSN past R + 2**31 -1 unless the connection is no longer operational, or the connection has been reinstated (see Section 4.3.4 Connection reinstatement), or a non-immediate command with CmdSN equal or greater than Q was issued on the same connection and the reception of the command is acknowledged by the target (see Section 8.4 Command Retry and Cleaning Old Command Instances).

Thanks,
Julo



"THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>

06/15/2002 03:39 AM
Please respond to "THALER,PAT (A-Roseville,ex1)"

       
        To:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI: advancing CmdSN after a command retry rule

       


Julian,

I'm having a little trouble understanding this text near the end of 2.2.2.1:

If an initiator issues a command retry for a command with CmdSN R on
a connection when the session CmdSN register is Q, it MUST NOT
advance the CmdSN past R + 2**31 -1 unless a different non-immediate
command with CmdSN equal or greater than Q was issued on the same
connection if the connection is still operational, and the reception
of the command is acknowledged by the target (see Section 8.4 Command
Retry and Cleaning Old Command Instances). The second non-immediate
command when sent, MUST be sent in-order after the retried
command on the same connection.

What does "different" mean in a different non-immediate command with CmdSN equal or greater than Q"? Isn't any command with a new CmdSN because it has a new CmdSN?

What is the purpose of "if the connection is still operational"? If a new command is issued on the connection it must still be operational. Perhaps it was intended to mean that if the connection was not operational then CmdSN can be advanced past the limit without this requirement being met.

There doesn't seem to be any definition of when a connection is "operational". Does the connection leave the operational state when it leaves S5 or is it when it has returned to S1?

Does "second non-immediate command" mean the command sent on this connection with CmdSN equal or greater than Q? Other commands with Q <= CmdSN < R + 2**31 - 1 may be sent on other connections, so the second command is the second command on this connection, right?

It isn't clear what the last sentence was intended to do since any command sent before the retry would advance Q so inherently any command sent after the retry with a new CmdSN must be in-order after the retry.

I suggest the following text plus clarification of the meaning of operational for a connection:
"If an initiator issues a command retry for a command with CmdSN R on
a connection when the session CmdSN register is Q, it MUST NOT
advance the CmdSN past R + 2**31 -1 unless the connection is no longer operational or a non-immediate command with CmdSN equal or greater than Q was issued on the same
connection and the reception of the command is acknowledged by the target (see Section 8.4 Command Retry and Cleaning Old Command Instances).

Pat


--=_alternative 005A15F6C2256BD9_=-- From owner-ips@ece.cmu.edu Sat Jun 15 17:25:25 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14867 for ; Sat, 15 Jun 2002 17:25:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5FKlbE12854 for ips-outgoing; Sat, 15 Jun 2002 16:47:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5FKlaw12849 for ; Sat, 15 Jun 2002 16:47:36 -0400 (EDT) Received: from cisco.com (dhcp-161-44-68-217.cisco.com [161.44.68.217]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA21899 for ; Sat, 15 Jun 2002 16:47:29 -0400 (EDT) Message-ID: <3D0BA7E1.42E15C77@cisco.com> Date: Sat, 15 Jun 2002 15:47:29 -0500 From: Steve Senum X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ips Subject: Re: iSCSI: 7.2.1 CHAP Considerations (12-98) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ofer Biran wrote: > > On initiator-only authentication this puts the responsibility > only on the initiator implementation who surely knows the > secret and its length. > While I believe the above is true in general, I think there might be situations where the the initiator could pass the challenge to another application (or system) to compute the reply, and thus not have direct access to the CHAP secret. Regards, Steve Senum From owner-ips@ece.cmu.edu Sun Jun 16 13:16:08 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05605 for ; Sun, 16 Jun 2002 13:16:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5GGQOR01145 for ips-outgoing; Sun, 16 Jun 2002 12:26:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5GGQMw01141 for ; Sun, 16 Jun 2002 12:26:22 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5GGQF5u026718 for ; Sun, 16 Jun 2002 18:26:16 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5GGQEN45294 for ; Sun, 16 Jun 2002 18:26:15 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: use of Text/Login with no data segment X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sun, 16 Jun 2002 19:26:11 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 16/06/2002 19:26:14, Serialize complete at 16/06/2002 19:26:14 Content-Type: multipart/alternative; boundary="=_alternative 005A1B5CC2256BDA_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005A1B5CC2256BDA_= Content-Type: text/plain; charset="us-ascii" Pat, On a second though the following text may be more appropriate: A target or initiator MUST NOT use a Text/Login Response or Text/ Login Request with no data segment (DataSegmentLength 0) unless explicitly required by a general or a key-specific negotiation rule. As it cover all the cases in which we wanted to avoid abuse. Julo ----- Forwarded by Julian Satran/Haifa/IBM on 06/16/2002 07:21 PM ----- Julian Satran 06/15/2002 06:25 PM To: pat_thaler@agilent.com cc: ips@ece.cmu.edu From: Julian Satran/Haifa/IBM@IBMIL Subject: Re: iSCSI: use of Text/Login with no data segment Pat, The SHOULD is there to avoid abuse and I will fix the text Julo pat_thaler@agilent.com 06/15/2002 12:51 AM Please respond to pat_thaler To: "Julian Satran" , ips@ece.cmu.edu cc: Subject: iSCSI: use of Text/Login with no data segment Julian, 4.2 (page 72) of iSCSI-13 says: A target or initiator SHOULD NOT use a Text/Login Response or Text/ Login Request with no data segment (DataSegmentLength 0) unless responding to a Text/Login Request respective Text/Login Response with the C bit set to 1. "SHOULD NOT" is too strong here as there are times when one must send a Text/Login Response or Request with no data segment if one is to complete the login. For example, a Target might send a Login response with the T=0 and C=0. If the initiator doesn't have an keys it wants to send, then the initiator will have to send a Login Request with no data segment if the login is to complete. Also, wrt grammar, "respective" is not a conjunction so the normal way to use it would be "... A or B ... C or D, respectively, ...." At least that is the usage that I have seen and what the dictionary at hand supports. If one wants to retain the idea of not sending empty PDUs when you do have something to say, one could put in: A target or initiator SHOULD NOT use a Text/Login Response or Text/ Login Request with no data segment (DataSegmentLength 0) unless responding to a Text/Login Request or Text/Login Response, respectively, with the T bit set to 0 while the node has no keys to send or with the C bit set to 1. Pat --=_alternative 005A1B5CC2256BDA_= Content-Type: text/html; charset="us-ascii"
Pat,

On a second though the following text may be more appropriate:

A target or initiator MUST NOT use a Text/Login Response or Text/
Login Request with no data segment (DataSegmentLength 0) unless explicitly required by a general or a key-specific negotiation rule.


As it cover all the cases in which we  wanted to avoid abuse.

Julo
----- Forwarded by Julian Satran/Haifa/IBM on 06/16/2002 07:21 PM -----
Julian Satran

06/15/2002 06:25 PM


        To:        pat_thaler@agilent.com
        cc:        ips@ece.cmu.edu
        From:        Julian Satran/Haifa/IBM@IBMIL
        Subject:        Re: iSCSI: use of Text/Login with no data segmentLink
 





Pat,

The SHOULD is there to avoid abuse and I will fix the text

Julo


pat_thaler@agilent.com

06/15/2002 12:51 AM
Please respond to pat_thaler

       
        To:        "Julian Satran" <Julian_Satran@il.ibm.com>, ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI: use of Text/Login with no data segment

       


Julian,

4.2 (page 72) of iSCSI-13 says:
A target or initiator SHOULD NOT use a Text/Login Response or Text/
Login Request with no data segment (DataSegmentLength 0) unless
responding to a Text/Login Request respective Text/Login Response
with the C bit set to 1.

"SHOULD NOT" is too strong here as there are times when one must send a
Text/Login Response or Request with no data segment if one is to complete
the login.

For example, a Target might send a Login response with the T=0 and C=0. If
the initiator doesn't have an keys it wants to send, then the initiator will
have to send a Login Request with no data segment if the login is to
complete.

Also, wrt grammar, "respective" is not a conjunction so the normal way to
use it would be "... A or B ... C or D, respectively, ...." At least that is
the usage that I have seen and what the dictionary at hand supports.

If one wants to retain the idea of not sending empty PDUs when you do have
something to say, one could put in:
A target or initiator SHOULD NOT use a Text/Login Response or Text/
Login Request with no data segment (DataSegmentLength 0) unless
responding to a Text/Login Request or Text/Login Response, respectively,
with the T bit set to 0 while the node has no keys to send or with the C bit
set to 1.

Pat



--=_alternative 005A1B5CC2256BDA_=-- From owner-ips@ece.cmu.edu Mon Jun 17 11:23:36 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07420 for ; Mon, 17 Jun 2002 11:23:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5HEYpO29971 for ips-outgoing; Mon, 17 Jun 2002 10:34:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5HEYjw29964 for ; Mon, 17 Jun 2002 10:34:45 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5HEYaX24588; Mon, 17 Jun 2002 10:34:37 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g5HEYY707619; Mon, 17 Jun 2002 10:34:36 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Jun 2002 10:32:57 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564BF87@CORPMX14> From: Black_David@emc.com To: eddy_quicksall@ivivity.com, ips@ece.cmu.edu Subject: RE: release projection Date: Mon, 17 Jun 2002 10:32:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > What's the new target date for the completion of the iSCSI standard? It depends on what is meant by completion or release. The first attempt at WG Last Call for iSCSI will begin in the next few days, once the -13 draft is on the Internet-Draft servers. iSCSI is unlikely to make it through WG Last Call on the first attempt, requiring a draft revision and another WG Last Call. While it could happen sooner, August is a reasonable guess for completion of iSCSI's successful WG Last Call. At that point the ips WG will be saying that we believe the draft to be complete from a technical standpoint - the draft then goes to the ADs and the IESG for further review and IETF Last Call. Technical changes are possible if problems/issues are uncovered as part of this, but the completion of WG Last Call is probably the "target date" Eddy was looking for. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Mon Jun 17 13:00:39 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11504 for ; Mon, 17 Jun 2002 13:00:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5HGGcq06057 for ips-outgoing; Mon, 17 Jun 2002 12:16:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from best.eurologic.com ([213.190.135.5]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5HGGYw06044 for ; Mon, 17 Jun 2002 12:16:35 -0400 (EDT) Received: from there (wombat [192.168.7.41]) by best.eurologic.com (8.9.3+Sun/8.9.3) with SMTP id RAA16412 for ; Mon, 17 Jun 2002 17:16:28 +0100 (BST) Message-Id: <200206171616.RAA16412@best.eurologic.com> Content-Type: text/plain; charset="iso-8859-1" From: Ken Sandars Organization: Eurologic Systems To: ips@ece.cmu.edu Subject: iSCSI: Is the TargetPortalGroupTag key allowed on a discovery session? Date: Mon, 17 Jun 2002 17:15:21 +0000 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi all, I can't see any reason for the target to provide a TargetPortalGroupTag when negotiating a discovery session. Are there any? If there aren't, can it be made clear that this key can only appear when negotiating a normal session please? Cheers, Ken -- Ken Sandars Eurologic Systems Ltd ksandars@eurologic.com From owner-ips@ece.cmu.edu Mon Jun 17 13:02:27 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11623 for ; Mon, 17 Jun 2002 13:02:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5HGbfp07344 for ips-outgoing; Mon, 17 Jun 2002 12:37:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5HGbcw07338 for ; Mon, 17 Jun 2002 12:37:38 -0400 (EDT) Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.192.94]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5HGbXVw034072 for ; Mon, 17 Jun 2002 12:37:33 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014h.boulder.ibm.com [9.17.194.13]) by westrelay04.boulder.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g5HGaPb78930 for ; Mon, 17 Jun 2002 10:36:25 -0600 X-Priority: 1 (High) Importance: Normal Subject: iSCSI 0.13 vs. iSCSI Plugfest To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Mon, 17 Jun 2002 09:35:29 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.10 |March 22, 2002) at 06/17/2002 10:37:32 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk The following are the items that are new in Draft 13: 1. Text cleanup 2. Limited decimal encoding to 64 bit integers 3. Logout Request reason code moved to byte 1 4. Renamed MaxRecvPDULength to MaxRecvDataSegmentLength 5. Large Numbers allowed only if explicitely stated 6. CHAP is the mandatory to implement in-band authentication and SRP is optional 7. A negotiation answer is permitted only if all key=value pairs are complete. A flag indicates completion. 8. Clearing effects appendix simplified - SCSI effects are now part of [SPC3] 9. Made explicit a rule a bout checking when committing a negotiation 10. Added code 4 for Asynch Message - request negotiation It is unlikely that the above will effect the Plugfest very much: only #3, #7, and #10 might have an effect in what is planned to be tested, and #7 needs to be checked. These are a small changes to most implimentations. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Mon Jun 17 13:02:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11639 for ; Mon, 17 Jun 2002 13:02:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5HGPKZ06597 for ips-outgoing; Mon, 17 Jun 2002 12:25:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5HGPJw06592 for ; Mon, 17 Jun 2002 12:25:19 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 8878515C9; Mon, 17 Jun 2002 10:25:16 -0600 (MDT) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 13F761D1; Mon, 17 Jun 2002 10:25:16 -0600 (MDT) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 17 Jun 2002 10:25:15 -0600 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Jun 2002 10:25:15 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C891386@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com, pat_thaler@agilent.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: advancing CmdSN after a command retry rule Date: Mon, 17 Jun 2002 10:25:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-82f14adb-820c-11d6-ac7f-009027aa5b50" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-82f14adb-820c-11d6-ac7f-009027aa5b50 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2161B.8F7BAB90" ------_=_NextPart_001_01C2161B.8F7BAB90 Content-Type: text/plain; charset="ISO-8859-1" Julian, Thanks. That still leaves the problem that there is no definition of when a connection is "operational" but that could be added to the last call issues. Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, June 15, 2002 9:27 AM To: THALER,PAT (A-Roseville,ex1) Cc: ips@ece.cmu.edu Subject: Re: iSCSI: advancing CmdSN after a command retry rule Pat, If the connection went through a "restart" (login with the same CID) then the "cleaning" is also not needed. Your text modified as follows is acceptable: If an initiator issues a command retry for a command with CmdSN R on a connection when the session CmdSN register is Q, it MUST NOT advance the CmdSN past R + 2**31 -1 unless the connection is no longer operational, or the connection has been reinstated (see Section 4.3.4 Connection reinstatement), or a non-immediate command with CmdSN equal or greater than Q was issued on the same connection and the reception of the command is acknowledged by the target (see Section 8.4 Command Retry and Cleaning Old Command Instances). Thanks, Julo "THALER,PAT (A-Roseville,ex1)" 06/15/2002 03:39 AM Please respond to "THALER,PAT (A-Roseville,ex1)" To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: iSCSI: advancing CmdSN after a command retry rule Julian, I'm having a little trouble understanding this text near the end of 2.2.2.1: If an initiator issues a command retry for a command with CmdSN R on a connection when the session CmdSN register is Q, it MUST NOT advance the CmdSN past R + 2**31 -1 unless a different non-immediate command with CmdSN equal or greater than Q was issued on the same connection if the connection is still operational, and the reception of the command is acknowledged by the target (see Section 8.4 Command Retry and Cleaning Old Command Instances). The second non-immediate command when sent, MUST be sent in-order after the retried command on the same connection. What does "different" mean in a different non-immediate command with CmdSN equal or greater than Q"? Isn't any command with a new CmdSN because it has a new CmdSN? What is the purpose of "if the connection is still operational"? If a new command is issued on the connection it must still be operational. Perhaps it was intended to mean that if the connection was not operational then CmdSN can be advanced past the limit without this requirement being met. There doesn't seem to be any definition of when a connection is "operational". Does the connection leave the operational state when it leaves S5 or is it when it has returned to S1? Does "second non-immediate command" mean the command sent on this connection with CmdSN equal or greater than Q? Other commands with Q <= CmdSN < R + 2**31 - 1 may be sent on other connections, so the second command is the second command on this connection, right? It isn't clear what the last sentence was intended to do since any command sent before the retry would advance Q so inherently any command sent after the retry with a new CmdSN must be in-order after the retry. I suggest the following text plus clarification of the meaning of operational for a connection: "If an initiator issues a command retry for a command with CmdSN R on a connection when the session CmdSN register is Q, it MUST NOT advance the CmdSN past R + 2**31 -1 unless the connection is no longer operational or a non-immediate command with CmdSN equal or greater than Q was issued on the same connection and the reception of the command is acknowledged by the target (see Section 8.4 Command Retry and Cleaning Old Command Instances). Pat ------_=_NextPart_001_01C2161B.8F7BAB90 Content-Type: text/html; charset="ISO-8859-1"
Julian,
 
Thanks. That still leaves the problem that there is no definition of when a connection is "operational" but that could be added to the last call issues.
 
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, June 15, 2002 9:27 AM
To: THALER,PAT (A-Roseville,ex1)
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI: advancing CmdSN after a command retry rule


Pat,

If the connection went through a "restart" (login with the same CID) then the "cleaning" is also not needed.
Your text modified as follows is acceptable:

If an initiator issues a command retry for a command with CmdSN R on
a connection when the session CmdSN register is Q, it MUST NOT advance the CmdSN past R + 2**31 -1 unless the connection is no longer operational, or the connection has been reinstated (see Section 4.3.4 Connection reinstatement), or a non-immediate command with CmdSN equal or greater than Q was issued on the same connection and the reception of the command is acknowledged by the target (see Section 8.4 Command Retry and Cleaning Old Command Instances).

Thanks,
Julo



"THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>

06/15/2002 03:39 AM
Please respond to "THALER,PAT (A-Roseville,ex1)"

       
        To:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI: advancing CmdSN after a command retry rule

       


Julian,

I'm having a little trouble understanding this text near the end of 2.2.2.1:

If an initiator issues a command retry for a command with CmdSN R on
a connection when the session CmdSN register is Q, it MUST NOT
advance the CmdSN past R + 2**31 -1 unless a different non-immediate
command with CmdSN equal or greater than Q was issued on the same
connection if the connection is still operational, and the reception
of the command is acknowledged by the target (see Section 8.4 Command
Retry and Cleaning Old Command Instances). The second non-immediate
command when sent, MUST be sent in-order after the retried
command on the same connection.

What does "different" mean in a different non-immediate command with CmdSN equal or greater than Q"? Isn't any command with a new CmdSN because it has a new CmdSN?

What is the purpose of "if the connection is still operational"? If a new command is issued on the connection it must still be operational. Perhaps it was intended to mean that if the connection was not operational then CmdSN can be advanced past the limit without this requirement being met.

There doesn't seem to be any definition of when a connection is "operational". Does the connection leave the operational state when it leaves S5 or is it when it has returned to S1?

Does "second non-immediate command" mean the command sent on this connection with CmdSN equal or greater than Q? Other commands with Q <= CmdSN < R + 2**31 - 1 may be sent on other connections, so the second command is the second command on this connection, right?

It isn't clear what the last sentence was intended to do since any command sent before the retry would advance Q so inherently any command sent after the retry with a new CmdSN must be in-order after the retry.

I suggest the following text plus clarification of the meaning of operational for a connection:
"If an initiator issues a command retry for a command with CmdSN R on
a connection when the session CmdSN register is Q, it MUST NOT
advance the CmdSN past R + 2**31 -1 unless the connection is no longer operational or a non-immediate command with CmdSN equal or greater than Q was issued on the same
connection and the reception of the command is acknowledged by the target (see Section 8.4 Command Retry and Cleaning Old Command Instances).

Pat


------_=_NextPart_001_01C2161B.8F7BAB90-- ------=_NextPartTM-000-82f14adb-820c-11d6-ac7f-009027aa5b50-- From owner-ips@ece.cmu.edu Mon Jun 17 13:12:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12007 for ; Mon, 17 Jun 2002 13:11:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5HGEsa05924 for ips-outgoing; Mon, 17 Jun 2002 12:14:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5HGEow05912; Mon, 17 Jun 2002 12:14:50 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id C6CBA1654; Mon, 17 Jun 2002 10:14:48 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 41C4B1A5; Mon, 17 Jun 2002 10:14:48 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 17 Jun 2002 10:14:48 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Jun 2002 10:14:47 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C89137D@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com, pat_thaler@agilent.com Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI: length and size Date: Mon, 17 Jun 2002 10:14:43 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-926f5bb7-a4df-42ae-b739-bb3c9a813859" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-926f5bb7-a4df-42ae-b739-bb3c9a813859 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2161A.1729EEA0" ------_=_NextPart_001_01C2161A.1729EEA0 Content-Type: text/plain; charset="iso-8859-1" Julian, It is an issue for last call. Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, June 15, 2002 9:06 AM To: THALER,PAT (A-Roseville,ex1) Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: length and size Pat, Is this a wish or an issue for the WG last call? Julo "THALER,PAT (A-Roseville,ex1)" Sent by: owner-ips@ece.cmu.edu 06/15/2002 02:50 AM Please respond to "THALER,PAT (A-Roseville,ex1)" To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: iSCSI: length and size Julian, iSCSI-13 uses "length" quite a bit more than 100 times. Many of those times are in regard to the length of data, headers, and PDUs e.g. The basic header segment has a fixed length of 48 bytes. Expected Data Transfer Length Each PDU contains the payload length and the data offset.... It also uses size about 40 times with the same meaning as length. Most of these are the terms MaxBurstSize and FirstBurstSize and text associated with those terms. It would be better (less likely to confuse readers and better for those of us who look for information using search tools) to choose one of those terms and always use it when talking about length/size. I don't care which is chosen. Pat ------_=_NextPart_001_01C2161A.1729EEA0 Content-Type: text/html; charset="iso-8859-1"
Julian, It is an issue for last call. Pat
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, June 15, 2002 9:06 AM
To: THALER,PAT (A-Roseville,ex1)
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iSCSI: length and size


Pat,

Is this a wish or an issue for the WG last call?

Julo


"THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>
Sent by: owner-ips@ece.cmu.edu

06/15/2002 02:50 AM
Please respond to "THALER,PAT (A-Roseville,ex1)"

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        iSCSI: length and size

       


Julian,

iSCSI-13 uses "length" quite a bit more than 100 times. Many of those times are in regard to the length of data, headers, and PDUs

e.g.
The basic header segment has a fixed length of 48 bytes.
Expected Data Transfer Length
Each PDU contains the payload length and the data offset....

It also uses size about 40 times with the same meaning as length. Most of these are the terms MaxBurstSize and FirstBurstSize and text associated with those terms.

It would be better (less likely to confuse readers and better for those of us who look for information using search tools) to choose one of those terms and always use it when talking about length/size. I don't care which is chosen.

Pat



------_=_NextPart_001_01C2161A.1729EEA0-- ------=_NextPartTM-000-926f5bb7-a4df-42ae-b739-bb3c9a813859-- From owner-ips@ece.cmu.edu Mon Jun 17 13:42:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13269 for ; Mon, 17 Jun 2002 13:42:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5HH0Kb08558 for ips-outgoing; Mon, 17 Jun 2002 13:00:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5HH0Iw08547 for ; Mon, 17 Jun 2002 13:00:18 -0400 (EDT) Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.192.94]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5HH0HRY055694 for ; Mon, 17 Jun 2002 13:00:17 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014h.boulder.ibm.com [9.17.194.13]) by westrelay04.boulder.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g5HGx8b62592 for ; Mon, 17 Jun 2002 10:59:08 -0600 X-Priority: 1 (High) Importance: Normal Subject: iSCSI 0.13 vs. iSCSI Plugfest To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Mon, 17 Jun 2002 09:58:12 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.10 |March 22, 2002) at 06/17/2002 11:00:15 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Pat Thaler pointed out to me that point 4 will also have an effect. (A constant will have to change.) . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com ---------------------- Forwarded by John Hufferd/San Jose/IBM on 06/17/2002 09:55 AM --------------------------- John Hufferd 06/17/2002 09:35 AM To: ips@ece.cmu.edu cc: From: John Hufferd/San Jose/IBM@IBMUS Subject: iSCSI 0.13 vs. iSCSI Plugfest The following are the items that are new in Draft 13: 1. Text cleanup 2. Limited decimal encoding to 64 bit integers 3. Logout Request reason code moved to byte 1 4. Renamed MaxRecvPDULength to MaxRecvDataSegmentLength 5. Large Numbers allowed only if explicitely stated 6. CHAP is the mandatory to implement in-band authentication and SRP is optional 7. A negotiation answer is permitted only if all key=value pairs are complete. A flag indicates completion. 8. Clearing effects appendix simplified - SCSI effects are now part of [SPC3] 9. Made explicit a rule a bout checking when committing a negotiation 10. Added code 4 for Asynch Message - request negotiation It is unlikely that the above will effect the Plugfest very much: only #3, #7, and #10 might have an effect in what is planned to be tested, and #7 needs to be checked. These are a small changes to most implimentations. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Mon Jun 17 13:43:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13282 for ; Mon, 17 Jun 2002 13:43:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5HGsYI08238 for ips-outgoing; Mon, 17 Jun 2002 12:54:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5HGsUw08229; Mon, 17 Jun 2002 12:54:30 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5HGsKGn030780; Mon, 17 Jun 2002 18:54:20 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5HGsJP78880; Mon, 17 Jun 2002 18:54:19 +0200 To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu, pat_thaler@agilent.com MIME-Version: 1.0 Subject: RE: iSCSI: length and size X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Mon, 17 Jun 2002 19:54:18 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 17/06/2002 19:54:19, Serialize complete at 17/06/2002 19:54:19 Content-Type: multipart/alternative; boundary="=_alternative 005C95DAC2256BDB_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005C95DAC2256BDB_= Content-Type: text/plain; charset="us-ascii" I personally find this as an abuse of the last call process. Julo pat_thaler@agilent.com 06/17/2002 07:14 PM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL, pat_thaler@agilent.com cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI: length and size Julian, It is an issue for last call. Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, June 15, 2002 9:06 AM To: THALER,PAT (A-Roseville,ex1) Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: length and size Pat, Is this a wish or an issue for the WG last call? Julo "THALER,PAT (A-Roseville,ex1)" Sent by: owner-ips@ece.cmu.edu 06/15/2002 02:50 AM Please respond to "THALER,PAT (A-Roseville,ex1)" To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: iSCSI: length and size Julian, iSCSI-13 uses "length" quite a bit more than 100 times. Many of those times are in regard to the length of data, headers, and PDUs e.g. The basic header segment has a fixed length of 48 bytes. Expected Data Transfer Length Each PDU contains the payload length and the data offset.... It also uses size about 40 times with the same meaning as length. Most of these are the terms MaxBurstSize and FirstBurstSize and text associated with those terms. It would be better (less likely to confuse readers and better for those of us who look for information using search tools) to choose one of those terms and always use it when talking about length/size. I don't care which is chosen. Pat --=_alternative 005C95DAC2256BDB_= Content-Type: text/html; charset="us-ascii"
I personally find this as an abuse of the last call process.

Julo


pat_thaler@agilent.com

06/17/2002 07:14 PM
Please respond to pat_thaler

       
        To:        Julian Satran/Haifa/IBM@IBMIL, pat_thaler@agilent.com
        cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
        Subject:        RE: iSCSI: length and size

       


Julian, It is an issue for last call. Pat
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, June 15, 2002 9:06 AM
To: THALER,PAT (A-Roseville,ex1)
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iSCSI: length and size

Pat,

Is this a wish or an issue for the WG last call?

Julo

"THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>
Sent by: owner-ips@ece.cmu.edu

06/15/2002 02:50 AM
Please respond to "THALER,PAT (A-Roseville,ex1)"

       
       To:        Julian Satran/Haifa/IBM@IBMIL
       cc:        ips@ece.cmu.edu
       Subject:        iSCSI: length and size

     



Julian,

iSCSI-13 uses "length" quite a bit more than 100 times. Many of those times are in regard to the length of data, headers, and PDUs

e.g.
The basic header segment has a fixed length of 48 bytes.
Expected Data Transfer Length
Each PDU contains the payload length and the data offset....

It also uses size about 40 times with the same meaning as length. Most of these are the terms MaxBurstSize and FirstBurstSize and text associated with those terms.

It would be better (less likely to confuse readers and better for those of us who look for information using search tools) to choose one of those terms and always use it when talking about length/size. I don't care which is chosen.

Pat

--=_alternative 005C95DAC2256BDB_=-- From owner-ips@ece.cmu.edu Mon Jun 17 18:07:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21497 for ; Mon, 17 Jun 2002 18:07:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5HLUfJ25667 for ips-outgoing; Mon, 17 Jun 2002 17:30:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5HLUcw25662; Mon, 17 Jun 2002 17:30:38 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id CA3BEA86A; Mon, 17 Jun 2002 15:30:37 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 9A372241; Mon, 17 Jun 2002 15:30:37 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 17 Jun 2002 15:30:37 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Jun 2002 15:30:37 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C8914D7@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI: length and size Date: Mon, 17 Jun 2002 15:30:35 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-0182ca33-06c9-4b59-aa83-5d21e906002f" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-0182ca33-06c9-4b59-aa83-5d21e906002f Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21646.376EB840" ------_=_NextPart_001_01C21646.376EB840 Content-Type: text/plain; charset="iso-8859-1" I don't understand why you find that. Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, June 17, 2002 9:54 AM To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com Subject: RE: iSCSI: length and size I personally find this as an abuse of the last call process. Julo pat_thaler@agilent.com 06/17/2002 07:14 PM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL, pat_thaler@agilent.com cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI: length and size Julian, It is an issue for last call. Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, June 15, 2002 9:06 AM To: THALER,PAT (A-Roseville,ex1) Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: length and size Pat, Is this a wish or an issue for the WG last call? Julo "THALER,PAT (A-Roseville,ex1)" Sent by: owner-ips@ece.cmu.edu 06/15/2002 02:50 AM Please respond to "THALER,PAT (A-Roseville,ex1)" To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: iSCSI: length and size Julian, iSCSI-13 uses "length" quite a bit more than 100 times. Many of those times are in regard to the length of data, headers, and PDUs e.g. The basic header segment has a fixed length of 48 bytes. Expected Data Transfer Length Each PDU contains the payload length and the data offset.... It also uses size about 40 times with the same meaning as length. Most of these are the terms MaxBurstSize and FirstBurstSize and text associated with those terms. It would be better (less likely to confuse readers and better for those of us who look for information using search tools) to choose one of those terms and always use it when talking about length/size. I don't care which is chosen. Pat ------_=_NextPart_001_01C21646.376EB840 Content-Type: text/html; charset="iso-8859-1"
I don't understand why you find that.
 
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Monday, June 17, 2002 9:54 AM
To: pat_thaler@agilent.com
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com
Subject: RE: iSCSI: length and size


I personally find this as an abuse of the last call process.

Julo


pat_thaler@agilent.com

06/17/2002 07:14 PM
Please respond to pat_thaler

       
        To:        Julian Satran/Haifa/IBM@IBMIL, pat_thaler@agilent.com
        cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
        Subject:        RE: iSCSI: length and size

       


Julian, It is an issue for last call. Pat
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, June 15, 2002 9:06 AM
To: THALER,PAT (A-Roseville,ex1)
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iSCSI: length and size


Pat,

Is this a wish or an issue for the WG last call?

Julo

"THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>
Sent by: owner-ips@ece.cmu.edu

06/15/2002 02:50 AM
Please respond to "THALER,PAT (A-Roseville,ex1)"

       
       To:        Julian Satran/Haifa/IBM@IBMIL
       cc:        ips@ece.cmu.edu
       Subject:        iSCSI: length and size

     



Julian,

iSCSI-13 uses "length" quite a bit more than 100 times. Many of those times are in regard to the length of data, headers, and PDUs

e.g.
The basic header segment has a fixed length of 48 bytes.
Expected Data Transfer Length
Each PDU contains the payload length and the data offset....

It also uses size about 40 times with the same meaning as length. Most of these are the terms MaxBurstSize and FirstBurstSize and text associated with those terms.

It would be better (less likely to confuse readers and better for those of us who look for information using search tools) to choose one of those terms and always use it when talking about length/size. I don't care which is chosen.

Pat




------_=_NextPart_001_01C21646.376EB840-- ------=_NextPartTM-000-0182ca33-06c9-4b59-aa83-5d21e906002f-- From owner-ips@ece.cmu.edu Mon Jun 17 18:08:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21510 for ; Mon, 17 Jun 2002 18:08:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5HLJPd24926 for ips-outgoing; Mon, 17 Jun 2002 17:19:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13705.mail.yahoo.com (web13705.mail.yahoo.com [216.136.175.138]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g5HLJOw24920 for ; Mon, 17 Jun 2002 17:19:24 -0400 (EDT) Message-ID: <20020617211923.90131.qmail@web13705.mail.yahoo.com> Received: from [192.55.52.3] by web13705.mail.yahoo.com via HTTP; Mon, 17 Jun 2002 14:19:23 PDT Date: Mon, 17 Jun 2002 14:19:23 -0700 (PDT) From: Martins Krikis Subject: Re: iSCSI: use of Text/Login with no data segment To: Julian Satran , ips@ece.cmu.edu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- Julian Satran wrote: > On a second though the following text may be more > appropriate: > > A target or initiator MUST NOT use a Text/Login > Response or Text/ > Login Request with no data segment > (DataSegmentLength 0) unless explicitly > required by a general or a key-specific negotiation > rule. I think the words are unnecessarily strong and disallow such nice guestures as "please, you speak first" from the iSCSI nodes... > As it cover all the cases in which we wanted to > avoid abuse. IMHO, you cannot really cover all abuse cases. What you have achieved is that the "abuser" (the guy, who says, "please, you first") now has to be a little more sophisticated, and instead of sending an empty data segment send the following: X-vendor_addr-you_speak_first-bogus_key_nr_x=yes. Whatever the response to this particular key is irrelevant, of course. But it achieved approximately the same effect as an empty PDU, and it can be used to abuse the negotiation process. This said, I don't think that the potential for abuse can be helped, nor do I think it is necessary to try to prevent all abuse. That's why I think this new wording was unnecessary, but it isn't really worth fighting over either. Martins Krikis, Intel Corp. Disclaimer: these are my own opinions and may not be my employer's. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Mon Jun 17 18:15:20 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21627 for ; Mon, 17 Jun 2002 18:15:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5HLqSm26894 for ips-outgoing; Mon, 17 Jun 2002 17:52:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5HLqQw26889 for ; Mon, 17 Jun 2002 17:52:27 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 4F69616B2; Mon, 17 Jun 2002 15:52:20 -0600 (MDT) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 57384391; Mon, 17 Jun 2002 15:52:19 -0600 (MDT) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 17 Jun 2002 15:52:10 -0600 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Jun 2002 15:52:10 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C8914E8@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI: use of Text/Login with no data segment Date: Mon, 17 Jun 2002 15:52:09 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-5b802533-822f-11d6-ac7f-009027aa5b50" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-5b802533-822f-11d6-ac7f-009027aa5b50 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21649.3AE009E0" ------_=_NextPart_001_01C21649.3AE009E0 Content-Type: text/plain; charset="ISO-8859-1" Julian, I think a MUST is too strong here. Also, the text "unless explicitly required by a general or a key-specific negotiation rule" may not cover the case of receiving a Text/Login R___ with F/T=0 and C=0 when one has no keys to send. I don't think there is any explicit rule in the draft requiring one to send with no data segment in that case. It is just implict that one must respond with such a PDU if the negotiation is to finish. Therefore, the following text would be better: A target or initiator SHOULD NOT use a Text/Login Response or Text/ Login Request with no data segment (DataSegmentLength 0) unless responding to a Text/Login Request or Text/Login Response, respectively, with the F/T bit set to 0 while the node has no keys to send or with the C bit set to 1. (This is the same as the text at the bottom except T bit is corrected to F/T to cover Text PDUs.) Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, June 16, 2002 9:26 AM To: ips@ece.cmu.edu Subject: Re: iSCSI: use of Text/Login with no data segment Pat, On a second though the following text may be more appropriate: A target or initiator MUST NOT use a Text/Login Response or Text/ Login Request with no data segment (DataSegmentLength 0) unless explicitly required by a general or a key-specific negotiation rule. As it cover all the cases in which we wanted to avoid abuse. Julo ----- Forwarded by Julian Satran/Haifa/IBM on 06/16/2002 07:21 PM ----- Julian Satran 06/15/2002 06:25 PM To: pat_thaler@agilent.com cc: ips@ece.cmu.edu From: Julian Satran/Haifa/IBM@IBMIL Subject: Re: iSCSI: use of Text/Login with no data segment Link Pat, The SHOULD is there to avoid abuse and I will fix the text Julo pat_thaler@agilent.com 06/15/2002 12:51 AM Please respond to pat_thaler To: "Julian Satran" , ips@ece.cmu.edu cc: Subject: iSCSI: use of Text/Login with no data segment Julian, 4.2 (page 72) of iSCSI-13 says: A target or initiator SHOULD NOT use a Text/Login Response or Text/ Login Request with no data segment (DataSegmentLength 0) unless responding to a Text/Login Request respective Text/Login Response with the C bit set to 1. "SHOULD NOT" is too strong here as there are times when one must send a Text/Login Response or Request with no data segment if one is to complete the login. For example, a Target might send a Login response with the T=0 and C=0. If the initiator doesn't have an keys it wants to send, then the initiator will have to send a Login Request with no data segment if the login is to complete. Also, wrt grammar, "respective" is not a conjunction so the normal way to use it would be "... A or B ... C or D, respectively, ...." At least that is the usage that I have seen and what the dictionary at hand supports. If one wants to retain the idea of not sending empty PDUs when you do have something to say, one could put in: A target or initiator SHOULD NOT use a Text/Login Response or Text/ Login Request with no data segment (DataSegmentLength 0) unless responding to a Text/Login Request or Text/Login Response, respectively, with the T bit set to 0 while the node has no keys to send or with the C bit set to 1. Pat ------_=_NextPart_001_01C21649.3AE009E0 Content-Type: text/html; charset="ISO-8859-1"
Julian,
 
I think a MUST is too strong here. Also, the text "unless explicitly required by a general or a key-specific negotiation rule" may not cover the case of  receiving a Text/Login R___ with F/T=0 and C=0 when one has no keys to send. I don't think there is any explicit rule in the draft requiring one to send with no data segment in that case. It is just implict that one must respond with such a PDU if the negotiation is to finish. Therefore, the following text would be better:
 
A target or initiator SHOULD NOT use a Text/Login Response or Text/
Login Request with no data segment (DataSegmentLength 0) unless
responding to a Text/Login Request or Text/Login Response, respectively,
with the F/T bit set to 0 while the node has no keys to send or with the C bit
set to 1.
(This is the same as the text at the bottom except T bit is corrected to F/T to cover Text PDUs.)
 
Pat
 
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Sunday, June 16, 2002 9:26 AM
To: ips@ece.cmu.edu
Subject: Re: iSCSI: use of Text/Login with no data segment


Pat,

On a second though the following text may be more appropriate:

A target or initiator MUST NOT use a Text/Login Response or Text/
Login Request with no data segment (DataSegmentLength 0) unless explicitly required by a general or a key-specific negotiation rule.


As it cover all the cases in which we  wanted to avoid abuse.

Julo
----- Forwarded by Julian Satran/Haifa/IBM on 06/16/2002 07:21 PM -----
Julian Satran

06/15/2002 06:25 PM


        To:        pat_thaler@agilent.com
        cc:        ips@ece.cmu.edu
        From:        Julian Satran/Haifa/IBM@IBMIL
        Subject:        Re: iSCSI: use of Text/Login with no data segmentLink
 





Pat,

The SHOULD is there to avoid abuse and I will fix the text

Julo


pat_thaler@agilent.com

06/15/2002 12:51 AM
Please respond to pat_thaler

       
        To:        "Julian Satran" <Julian_Satran@il.ibm.com>, ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI: use of Text/Login with no data segment

       


Julian,

4.2 (page 72) of iSCSI-13 says:
A target or initiator SHOULD NOT use a Text/Login Response or Text/
Login Request with no data segment (DataSegmentLength 0) unless
responding to a Text/Login Request respective Text/Login Response
with the C bit set to 1.

"SHOULD NOT" is too strong here as there are times when one must send a
Text/Login Response or Request with no data segment if one is to complete
the login.

For example, a Target might send a Login response with the T=0 and C=0. If
the initiator doesn't have an keys it wants to send, then the initiator will
have to send a Login Request with no data segment if the login is to
complete.

Also, wrt grammar, "respective" is not a conjunction so the normal way to
use it would be "... A or B ... C or D, respectively, ...." At least that is
the usage that I have seen and what the dictionary at hand supports.

If one wants to retain the idea of not sending empty PDUs when you do have
something to say, one could put in:
A target or initiator SHOULD NOT use a Text/Login Response or Text/
Login Request with no data segment (DataSegmentLength 0) unless
responding to a Text/Login Request or Text/Login Response, respectively,
with the T bit set to 0 while the node has no keys to send or with the C bit
set to 1.

Pat




------_=_NextPart_001_01C21649.3AE009E0-- ------=_NextPartTM-000-5b802533-822f-11d6-ac7f-009027aa5b50-- From owner-ips@ece.cmu.edu Mon Jun 17 18:58:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22547 for ; Mon, 17 Jun 2002 18:58:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5HMIo028314 for ips-outgoing; Mon, 17 Jun 2002 18:18:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5HMInw28309 for ; Mon, 17 Jun 2002 18:18:49 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 7630D8B2; Mon, 17 Jun 2002 16:18:48 -0600 (MDT) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id E9BB612A; Mon, 17 Jun 2002 16:18:47 -0600 (MDT) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 17 Jun 2002 16:18:46 -0600 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Jun 2002 16:18:45 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C8914FD@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: iSCSI: Negotiating a parameter more than once Date: Mon, 17 Jun 2002 16:18:43 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, The following text appears in 4.3 (page 78 just before 4.3.1): Neither the initiator nor the target should attempt to negotiate a parameter more than once during login. If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection. and nearly the same text in 4.4 (page 85 near the end): Neither the initiator nor the target should attempt to negotiate a parameter more than once during any negotiation sequence without an intervening reset. If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above. This is confusing partly because "negotiate" seems to be generally used covering both negotiations and declarations and in some cases covering only negotiations. It isn't clear in which sense it is used. If the text above applies only to negotiated values, then it would be allowable to send parameters such as Initiator Name, SessionType, and MaxRecvDataSegmentLength over which doesn't seem to be a good idea. However, there are other declarative parameters which are sent multiple times - SendTargets where there are multiple targets or multiple addresses for a target requires sending the same parameter multiple times. Perhaps the text should be changed to: Neither the initiator nor the target should attempt to declare or negotiate a parameter other than TargetName, TargetAlias or TargetAddress more than once.... Regards, Pat From owner-ips@ece.cmu.edu Mon Jun 17 20:00:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23848 for ; Mon, 17 Jun 2002 20:00:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5HN5Mm00690 for ips-outgoing; Mon, 17 Jun 2002 19:05:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5HN5Lw00686 for ; Mon, 17 Jun 2002 19:05:21 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 866CEB6AF; Mon, 17 Jun 2002 17:05:20 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 660AAE8; Mon, 17 Jun 2002 17:05:20 -0600 (MDT) Received: from 130.29.152.143 by axcsbh1.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 17 Jun 2002 17:05:19 -0600 Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Jun 2002 17:05:19 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C891514@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Negotiating a parameter more than once Date: Mon, 17 Jun 2002 17:05:18 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, It also isn't clear whether SendTargets can be sent more than once during a negotiation sequence. It would be reasonable for the Initiator to set the F bit when it sends SendTargets and then when the Target sets the F bit the initiator will know that the response is complete. However if SendTargets isn't covered by the limitation on negotiating a parameter only once per negotiation sequence, an initiator could also leave the F bit at zero, assume the response is done when it gets a response with an empty text field, and send SendTargets again later in the same negotiation sequence. An initiatior could even send a single PDU with something like: SendTargets=; SendTargets=; SendTargets=. There doesn't seem to be anything in Appendix D to say which of these is intended. The first possibility - allowing SendTargets to be sent only once during a negotiation sequence - seems adequate and simpler. Pat -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Monday, June 17, 2002 3:19 PM To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: iSCSI: Negotiating a parameter more than once Julian, The following text appears in 4.3 (page 78 just before 4.3.1): Neither the initiator nor the target should attempt to negotiate a parameter more than once during login. If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection. and nearly the same text in 4.4 (page 85 near the end): Neither the initiator nor the target should attempt to negotiate a parameter more than once during any negotiation sequence without an intervening reset. If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above. This is confusing partly because "negotiate" seems to be generally used covering both negotiations and declarations and in some cases covering only negotiations. It isn't clear in which sense it is used. If the text above applies only to negotiated values, then it would be allowable to send parameters such as Initiator Name, SessionType, and MaxRecvDataSegmentLength over which doesn't seem to be a good idea. However, there are other declarative parameters which are sent multiple times - SendTargets where there are multiple targets or multiple addresses for a target requires sending the same parameter multiple times. Perhaps the text should be changed to: Neither the initiator nor the target should attempt to declare or negotiate a parameter other than TargetName, TargetAlias or TargetAddress more than once.... Regards, Pat From owner-ips@ece.cmu.edu Mon Jun 17 20:44:26 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24414 for ; Mon, 17 Jun 2002 20:44:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5HNuC503313 for ips-outgoing; Mon, 17 Jun 2002 19:56:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5HNuAw03306 for ; Mon, 17 Jun 2002 19:56:10 -0400 (EDT) Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel6.hp.com (Postfix) with ESMTP id 39BD6266; Mon, 17 Jun 2002 19:56:05 -0400 (EDT) Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 32F97109; Mon, 17 Jun 2002 19:56:05 -0400 (EDT) Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Jun 2002 19:56:05 -0400 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF671@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'THALER,PAT (A-Roseville,ex1)'" Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Negotiating a parameter more than once Date: Mon, 17 Jun 2002 19:56:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk The section you reference is titled "Login Phase" - SendTarget's isn't valid during the login phase, and it's not a negotiation. It's a request/declaration, and its only valid during FFP. Sorry, I don't see a problem with the text you quoted. Marjorie > -----Original Message----- > From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@agilent.com] > Sent: Monday, June 17, 2002 4:05 PM > To: Julian_Satran@il.ibm.com > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI: Negotiating a parameter more than once > > > Julian, > > It also isn't clear whether SendTargets can be sent more than > once during a negotiation sequence. > > It would be reasonable for the Initiator to set the F bit > when it sends SendTargets and then when the Target sets the F > bit the initiator will know that the response is complete. > However if SendTargets isn't covered by the limitation on > negotiating a parameter only once per negotiation sequence, > an initiator could also leave the F bit at zero, assume the > response is done when it gets a response with an empty text > field, and send SendTargets again later in the same > negotiation sequence. An initiatior could even send a single > PDU with something like: SendTargets=; > SendTargets=; SendTargets=. > > There doesn't seem to be anything in Appendix D to say which > of these is intended. The first possibility - allowing > SendTargets to be sent only once during a negotiation > sequence - seems adequate and simpler. > > Pat > > -----Original Message----- > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > Sent: Monday, June 17, 2002 3:19 PM > To: Julian_Satran@il.ibm.com > Cc: ips@ece.cmu.edu > Subject: iSCSI: Negotiating a parameter more than once > > > Julian, > > The following text appears in 4.3 (page 78 just before 4.3.1): > > Neither the initiator nor the target should attempt to negotiate a > parameter more than once during login. If detected by the target this > MUST result in a Login reject (initiator error). The initiator MUST > drop the connection. > > and nearly the same text in 4.4 (page 85 near the end): > > Neither the initiator nor the target should attempt to negotiate a > parameter more than once during any negotiation sequence without an > intervening reset. If detected by the target this MUST result in a > Reject with a reason of "protocol error". The initiator MUST reset > the negotiation as outlined above. > > This is confusing partly because "negotiate" seems to be > generally used covering both negotiations and declarations > and in some cases covering only negotiations. It isn't clear > in which sense it is used. If the text above applies only to > negotiated values, then it would be allowable to send > parameters such as Initiator Name, SessionType, and > MaxRecvDataSegmentLength over which doesn't seem to be a good > idea. However, there are other declarative parameters which > are sent multiple times - SendTargets where there are > multiple targets or multiple addresses for a target requires > sending the same parameter multiple times. > > Perhaps the text should be changed to: > > Neither the initiator nor the target should attempt to > declare or negotiate a > parameter other than TargetName, TargetAlias or TargetAddress > more than once.... > > Regards, > Pat > From owner-ips@ece.cmu.edu Mon Jun 17 20:48:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24446 for ; Mon, 17 Jun 2002 20:47:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5I0Qnh04756 for ips-outgoing; Mon, 17 Jun 2002 20:26:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5I0Qmw04751 for ; Mon, 17 Jun 2002 20:26:48 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 269FBB5CD; Mon, 17 Jun 2002 18:26:47 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 05AAFEB; Mon, 17 Jun 2002 18:26:47 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 17 Jun 2002 18:26:46 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Jun 2002 18:26:46 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C891538@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: marjorie_krueger@hp.com, pat_thaler@agilent.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Negotiating a parameter more than once Date: Mon, 17 Jun 2002 18:26:37 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I referenced two sections - 4.3 and 4.4. I agree that 4.3 isn't relevant to SendTargets, but the similar text in 4.4 is. Pat -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie_krueger@hp.com] Sent: Monday, June 17, 2002 4:56 PM To: 'THALER,PAT (A-Roseville,ex1)' Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Negotiating a parameter more than once The section you reference is titled "Login Phase" - SendTarget's isn't valid during the login phase, and it's not a negotiation. It's a request/declaration, and its only valid during FFP. Sorry, I don't see a problem with the text you quoted. Marjorie > -----Original Message----- > From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@agilent.com] > Sent: Monday, June 17, 2002 4:05 PM > To: Julian_Satran@il.ibm.com > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI: Negotiating a parameter more than once > > > Julian, > > It also isn't clear whether SendTargets can be sent more than > once during a negotiation sequence. > > It would be reasonable for the Initiator to set the F bit > when it sends SendTargets and then when the Target sets the F > bit the initiator will know that the response is complete. > However if SendTargets isn't covered by the limitation on > negotiating a parameter only once per negotiation sequence, > an initiator could also leave the F bit at zero, assume the > response is done when it gets a response with an empty text > field, and send SendTargets again later in the same > negotiation sequence. An initiatior could even send a single > PDU with something like: SendTargets=; > SendTargets=; SendTargets=. > > There doesn't seem to be anything in Appendix D to say which > of these is intended. The first possibility - allowing > SendTargets to be sent only once during a negotiation > sequence - seems adequate and simpler. > > Pat > > -----Original Message----- > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > Sent: Monday, June 17, 2002 3:19 PM > To: Julian_Satran@il.ibm.com > Cc: ips@ece.cmu.edu > Subject: iSCSI: Negotiating a parameter more than once > > > Julian, > > The following text appears in 4.3 (page 78 just before 4.3.1): > > Neither the initiator nor the target should attempt to negotiate a > parameter more than once during login. If detected by the target this > MUST result in a Login reject (initiator error). The initiator MUST > drop the connection. > > and nearly the same text in 4.4 (page 85 near the end): > > Neither the initiator nor the target should attempt to negotiate a > parameter more than once during any negotiation sequence without an > intervening reset. If detected by the target this MUST result in a > Reject with a reason of "protocol error". The initiator MUST reset > the negotiation as outlined above. > > This is confusing partly because "negotiate" seems to be > generally used covering both negotiations and declarations > and in some cases covering only negotiations. It isn't clear > in which sense it is used. If the text above applies only to > negotiated values, then it would be allowable to send > parameters such as Initiator Name, SessionType, and > MaxRecvDataSegmentLength over which doesn't seem to be a good > idea. However, there are other declarative parameters which > are sent multiple times - SendTargets where there are > multiple targets or multiple addresses for a target requires > sending the same parameter multiple times. > > Perhaps the text should be changed to: > > Neither the initiator nor the target should attempt to > declare or negotiate a > parameter other than TargetName, TargetAlias or TargetAddress > more than once.... > > Regards, > Pat > From owner-ips@ece.cmu.edu Mon Jun 17 21:29:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24849 for ; Mon, 17 Jun 2002 21:28:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5I0dRV05360 for ips-outgoing; Mon, 17 Jun 2002 20:39:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5I0dPw05356 for ; Mon, 17 Jun 2002 20:39:25 -0400 (EDT) Received: from xparelay2.corp.hp.com (xparelay2.corp.hp.com [15.58.137.112]) by palrel11.hp.com (Postfix) with ESMTP id 140CC6004BB for ; Mon, 17 Jun 2002 17:39:20 -0700 (PDT) Received: from xpabh4.corp.hp.com (xpabh4.corp.hp.com [15.58.136.1]) by xparelay2.corp.hp.com (Postfix) with ESMTP id 0B9A19E for ; Mon, 17 Jun 2002 17:39:20 -0700 (PDT) Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Jun 2002 17:39:19 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF672@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: ips@ece.cmu.edu Subject: RE: iSCSI: Negotiating a parameter more than once Date: Mon, 17 Jun 2002 17:39:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Seems to me that the text in 4.4 should be deleted, since even reworded, its only confusing here. Currently, there's no "negotiation" that's valid in FFP - SendTargets and MaxPDUDataLength are declarative. > -----Original Message----- > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > Sent: Monday, June 17, 2002 5:27 PM > To: marjorie_krueger@hp.com; pat_thaler@agilent.com > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI: Negotiating a parameter more than once > > > I referenced two sections - 4.3 and 4.4. I agree that 4.3 > isn't relevant to SendTargets, but the similar text in 4.4 is. > > Pat > > -----Original Message----- > From: KRUEGER,MARJORIE (HP-Roseville,ex1) > [mailto:marjorie_krueger@hp.com] > Sent: Monday, June 17, 2002 4:56 PM > To: 'THALER,PAT (A-Roseville,ex1)' > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI: Negotiating a parameter more than once > > > The section you reference is titled "Login Phase" - > SendTarget's isn't valid > during the login phase, and it's not a negotiation. It's a > request/declaration, and its only valid during FFP. Sorry, I > don't see a > problem with the text you quoted. > > Marjorie > > > -----Original Message----- > > From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@agilent.com] > > Sent: Monday, June 17, 2002 4:05 PM > > To: Julian_Satran@il.ibm.com > > Cc: ips@ece.cmu.edu > > Subject: RE: iSCSI: Negotiating a parameter more than once > > > > > > Julian, > > > > It also isn't clear whether SendTargets can be sent more than > > once during a negotiation sequence. > > > > It would be reasonable for the Initiator to set the F bit > > when it sends SendTargets and then when the Target sets the F > > bit the initiator will know that the response is complete. > > However if SendTargets isn't covered by the limitation on > > negotiating a parameter only once per negotiation sequence, > > an initiator could also leave the F bit at zero, assume the > > response is done when it gets a response with an empty text > > field, and send SendTargets again later in the same > > negotiation sequence. An initiatior could even send a single > > PDU with something like: SendTargets=; > > SendTargets=; > SendTargets=. > > > > There doesn't seem to be anything in Appendix D to say which > > of these is intended. The first possibility - allowing > > SendTargets to be sent only once during a negotiation > > sequence - seems adequate and simpler. > > > > Pat > > > > -----Original Message----- > > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > > Sent: Monday, June 17, 2002 3:19 PM > > To: Julian_Satran@il.ibm.com > > Cc: ips@ece.cmu.edu > > Subject: iSCSI: Negotiating a parameter more than once > > > > > > Julian, > > > > The following text appears in 4.3 (page 78 just before 4.3.1): > > > > Neither the initiator nor the target should attempt to negotiate a > > parameter more than once during login. If detected by the > target this > > MUST result in a Login reject (initiator error). The initiator MUST > > drop the connection. > > > > and nearly the same text in 4.4 (page 85 near the end): > > > > Neither the initiator nor the target should attempt to negotiate a > > parameter more than once during any negotiation sequence without an > > intervening reset. If detected by the target this MUST result in a > > Reject with a reason of "protocol error". The initiator MUST reset > > the negotiation as outlined above. > > > > This is confusing partly because "negotiate" seems to be > > generally used covering both negotiations and declarations > > and in some cases covering only negotiations. It isn't clear > > in which sense it is used. If the text above applies only to > > negotiated values, then it would be allowable to send > > parameters such as Initiator Name, SessionType, and > > MaxRecvDataSegmentLength over which doesn't seem to be a good > > idea. However, there are other declarative parameters which > > are sent multiple times - SendTargets where there are > > multiple targets or multiple addresses for a target requires > > sending the same parameter multiple times. > > > > Perhaps the text should be changed to: > > > > Neither the initiator nor the target should attempt to > > declare or negotiate a > > parameter other than TargetName, TargetAlias or TargetAddress > > more than once.... > > > > Regards, > > Pat > > > From owner-ips@ece.cmu.edu Tue Jun 18 10:27:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19169 for ; Tue, 18 Jun 2002 10:27:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5IDGj919422 for ips-outgoing; Tue, 18 Jun 2002 09:16:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5IBQ3w14263 for ; Tue, 18 Jun 2002 07:26:03 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12483; Tue, 18 Jun 2002 07:25:07 -0400 (EDT) Message-Id: <200206181125.HAA12483@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-iscsi-13.txt,.pdf Date: Tue, 18 Jun 2002 07:25:07 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : iSCSI Author(s) : J. Satran et al. Filename : draft-ietf-ips-iscsi-13.txt,.pdf Pages : 274 Date : 17-Jun-02 The Small Computer Systems Interface (SCSI) is a popular family of protocols for communicating with I/O devices, especially storage devices. This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the rules laid out in the SCSI Architecture Model - 2 [SAM2] document. This current version of iSCSI is 0. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-13.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020617142215.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020617142215.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Tue Jun 18 11:34:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22898 for ; Tue, 18 Jun 2002 11:34:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5IEebJ26227 for ips-outgoing; Tue, 18 Jun 2002 10:40:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from best.eurologic.com ([213.190.135.5]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5IEeYw26222 for ; Tue, 18 Jun 2002 10:40:34 -0400 (EDT) Received: from there (wombat [192.168.7.41]) by best.eurologic.com (8.9.3+Sun/8.9.3) with SMTP id PAA22600 for ; Tue, 18 Jun 2002 15:40:28 +0100 (BST) Message-Id: <200206181440.PAA22600@best.eurologic.com> Content-Type: text/plain; charset="iso-8859-1" From: Ken Sandars Organization: Eurologic Systems To: ips@ece.cmu.edu Subject: Another question of the obvious Date: Tue, 18 Jun 2002 15:39:17 +0000 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi again, I've re-re-read (no, not a stutter) the spec and cannot determine the correct handling for the LUN field in the Data-In and/or Response pdus. If an initiator issues a SCSI READ10 command on LUN52 does the target set its LUN field in the Data-In pdu to: (a) 52 (ie same as what the initiator had) (b) 0 (treating it as reserved)? And does the target set its LUN field in the Response pdu to: (a) 52 (ie same as what the initiator had) (b) 0 (treating it as reserved)? Could the answers to the above change for different SCSI Commands? TIA, Ken -- Ken Sandars Eurologic Systems Ltd ksandars@eurologic.com From owner-ips@ece.cmu.edu Tue Jun 18 13:42:39 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27952 for ; Tue, 18 Jun 2002 13:42:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5IGk7Y04618 for ips-outgoing; Tue, 18 Jun 2002 12:46:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5IGk5w04613 for ; Tue, 18 Jun 2002 12:46:05 -0400 (EDT) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5IGk4Vw039328; Tue, 18 Jun 2002 12:46:04 -0400 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.203.135]) by westrelay01.boulder.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g5IGk3r77188; Tue, 18 Jun 2002 10:46:03 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: Another question of the obvious To: Ken Sandars Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Tue, 18 Jun 2002 09:43:56 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.10 |March 22, 2002) at 06/18/2002 10:46:02 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk The general answer to your questions is "b." in both cases. The SCSI Response PDU only shows that field as Reserved (with no other options). The only time that the LUN field is used with Data-In PDUs, is in relationship to setting the A-bit. In that case it is set along with the TTT so that it can be returned with the SNACK. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Ken Sandars @ece.cmu.edu on 06/18/2002 08:39:17 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Another question of the obvious Hi again, I've re-re-read (no, not a stutter) the spec and cannot determine the correct handling for the LUN field in the Data-In and/or Response pdus. If an initiator issues a SCSI READ10 command on LUN52 does the target set its LUN field in the Data-In pdu to: (a) 52 (ie same as what the initiator had) (b) 0 (treating it as reserved)? And does the target set its LUN field in the Response pdu to: (a) 52 (ie same as what the initiator had) (b) 0 (treating it as reserved)? Could the answers to the above change for different SCSI Commands? TIA, Ken -- Ken Sandars Eurologic Systems Ltd ksandars@eurologic.com From owner-ips@ece.cmu.edu Tue Jun 18 14:17:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29256 for ; Tue, 18 Jun 2002 14:17:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5IHNpC07088 for ips-outgoing; Tue, 18 Jun 2002 13:23:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5IHNnw07084 for ; Tue, 18 Jun 2002 13:23:49 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id D7A1F1852; Tue, 18 Jun 2002 11:23:48 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with SMTP id A0B63331; Tue, 18 Jun 2002 11:23:48 -0600 (MDT) Received: from 130.29.152.143 by axcsbh1.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 18 Jun 2002 11:23:47 -0600 Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Jun 2002 11:23:47 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C8916CC@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: shesha bhushan , ips@ece.cmu.edu Subject: RE: SCSI-Target ID in ISCSI Date: Tue, 18 Jun 2002 11:23:37 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Shesha, I'm not clear on why you bring a router and its IP address into this question. An iSCSI server or client (HBA) will have an IP address (or in some cases it may have multiple IP addresses). An iSCSI server may contain multiple targets but when an iSCSI session is created, the initiator identifies the target for that session using the iSCSI Target name. Once that session is created, the target is accessed using SCSI commands and the process of reading disk or LUN identifications would be done the same as over any other SCSI transport. Pat -----Original Message----- From: shesha bhushan [mailto:bhushan_vadulas@hotmail.com] Sent: Friday, June 14, 2002 2:20 PM To: ips@ece.cmu.edu Subject: SCSI-Target ID in ISCSI Hi All, I have a disk array. Each disk in that array has a saperate ID. The devices are internally conncted using SCSI. If I have iSCSI HBA on the array, (with a router attached to it). The router will have an IP address. Say IP Address + target ID indentifies uniquily a disk. How is the SCSI-Target ID(NOT the LUN#) is transmitted from the iSCSI-Initiator to the iSCSI-Target. Thanks in advance for any of your comments Shesha _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. From owner-ips@ece.cmu.edu Tue Jun 18 16:48:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04471 for ; Tue, 18 Jun 2002 16:48:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5IJxov18244 for ips-outgoing; Tue, 18 Jun 2002 15:59:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5IJxmw18239 for ; Tue, 18 Jun 2002 15:59:48 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel6.hp.com (Postfix) with ESMTP id 437A76AF; Tue, 18 Jun 2002 15:59:37 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id NAA09110; Tue, 18 Jun 2002 13:01:26 -0700 (PDT) Message-ID: <008f01c21702$abc6a150$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Julian Satran" Cc: Subject: iSCSI: Target reset text Date: Tue, 18 Jun 2002 12:59:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, - While reviewing a related T10 proposal, I realized that SAM-2 (clause 5.8.6) does not allow access controls for any protocol-specific hard reset events (and Target Cold Reset TMF is one such). The current rev13 text seems to imply that both reset flavors are subject to access controls. In any case, it would help to make the point. - It is somewhat unclear at the moment if Target cold reset should/should not return a response. But judging by the "equivalent to SAM-2's Target Reset" wording, and because SAM-2 requires a function response to be returned, one would have to interpret that a response is required for Cold Reset. I had received internal feedback about interoperability issues on this interpretation. - I also noticed that the words "TARGET RESET" and "Target Reset" are apparently used interchangeably in section 9.5.1, while the former is an iSCSI-generic name for both flavors and the latter is the SAM-2 TMF. - We had earlier talked about the Target Cold Reset function being equivalent to to a power on event (as is stated by Appendix F.2), but I think we should specify it in this section to make it clear to the implementers. I suggest the following text in 9.5.1 to address the above issues. 8<----------------------- The implementation of the TARGET WARM RESET function and the TARGET COLD RESET function is OPTIONAL and when implemented, should act as described below. The TARGET WARM RESET function MAY also be subject to SCSI access controls on the requesting initiator. When authorization fails at the target, the appropriate response as described in Section 9.6 "Task Management Function Response" must be returned by the target. The TARGET COLD RESET function is not subject to SCSI access controls, but its execution privileges may be managed by iSCSI mechanisms such as login authentication. When executing the TARGET WARM RESET and TARGET COLD RESET functions, the target cancels all pending operations. Both functions are equivalent to the Target Reset function specified by [SAM2]. They can affect many other initiators logged in with the servicing SCSI target port. The target MUST treat the TARGET COLD RESET function additionally as a power on event, thus terminating all of its TCP connections to all initiators (all sessions are terminated). For this reason, the Service Response (defined by [SAM2]) for this SCSI task management function may not be reliably delivered to the issuing initiator port. 8<----------------------- Thanks! -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com From owner-ips@ece.cmu.edu Tue Jun 18 20:26:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09421 for ; Tue, 18 Jun 2002 20:26:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5INw4v01478 for ips-outgoing; Tue, 18 Jun 2002 19:58:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5INw2w01473 for ; Tue, 18 Jun 2002 19:58:02 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 54A6430706; Tue, 18 Jun 2002 19:58:02 -0400 (EDT) Date: Tue, 18 Jun 2002 16:55:31 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Subject: Question regarding SNACK and bidi transfers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk I have a question about SNACK type 0 requests. In the text, they are described as being for Data-In PDUs or R2T PDUs. For a bidi command, how do you know which? Does this mean that for a bidi command, data-in and R2TSNs have to be mutually-unique (i.e. drawn from the same pool)? Take care, Bill From owner-ips@ece.cmu.edu Tue Jun 18 20:28:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09457 for ; Tue, 18 Jun 2002 20:28:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5INjbh00924 for ips-outgoing; Tue, 18 Jun 2002 19:45:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5INjaw00919 for ; Tue, 18 Jun 2002 19:45:36 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Jun 2002 19:45:30 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564BF96@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: End of FCIP and iFCP WG Last Call Date: Tue, 18 Jun 2002 19:43:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk The WG Last Call period on these two drafts ended yesterday. As there have been no technical comments on these drafts on the list during the WG Last Call period, these drafts have passed WG Last Call, although there are some editorial changes that will probably require new versions of both drafts. Congratulations to the authors and contributors. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Jun 18 20:28:22 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09475 for ; Tue, 18 Jun 2002 20:28:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5INgvw00782 for ips-outgoing; Tue, 18 Jun 2002 19:42:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5INgtw00777 for ; Tue, 18 Jun 2002 19:42:55 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5INgkh28663; Tue, 18 Jun 2002 19:42:47 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g5INgk723959; Tue, 18 Jun 2002 19:42:46 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Jun 2002 19:41:08 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564BF95@CORPMX14> From: Black_David@emc.com To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: length and size Date: Tue, 18 Jun 2002 19:41:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21721.9D48D1B0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21721.9D48D1B0 Content-Type: text/plain; charset="iso-8859-1" Julian, I tend to agree with Pat - this is an editorial issue regarding clarity of the document, and raising it is not abuse of the WG Last Call process. It's ok to raise the issue - given your (document editor/primary author) reluctance to make the requested change, the WG co-chairs will have to make a decision about how to resolve this (probably around the end of the Last Call period) - one possible resolution is to decide that the document is ok without the change. BTW - this is a general principle of WG Last Call - the WG co-chairs have some discretion (particularly with editorial comments) in deciding whether an issue raised during WG Last Call requires changes in the draft. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Monday, June 17, 2002 5:31 PM To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iSCSI: length and size I don't understand why you find that. Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, June 17, 2002 9:54 AM To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com Subject: RE: iSCSI: length and size I personally find this as an abuse of the last call process. Julo pat_thaler@agilent.com 06/17/2002 07:14 PM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL, pat_thaler@agilent.com cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI: length and size Julian, It is an issue for last call. Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, June 15, 2002 9:06 AM To: THALER,PAT (A-Roseville,ex1) Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: length and size Pat, Is this a wish or an issue for the WG last call? Julo "THALER,PAT (A-Roseville,ex1)" Sent by: owner-ips@ece.cmu.edu 06/15/2002 02:50 AM Please respond to "THALER,PAT (A-Roseville,ex1)" To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: iSCSI: length and size Julian, iSCSI-13 uses "length" quite a bit more than 100 times. Many of those times are in regard to the length of data, headers, and PDUs e.g. The basic header segment has a fixed length of 48 bytes. Expected Data Transfer Length Each PDU contains the payload length and the data offset.... It also uses size about 40 times with the same meaning as length. Most of these are the terms MaxBurstSize and FirstBurstSize and text associated with those terms. It would be better (less likely to confuse readers and better for those of us who look for information using search tools) to choose one of those terms and always use it when talking about length/size. I don't care which is chosen. Pat ------_=_NextPart_001_01C21721.9D48D1B0 Content-Type: text/html; charset="iso-8859-1"
Julian,
 
I tend to agree with Pat - this is an editorial issue
regarding clarity of the document, and raising it is not
abuse of the WG Last Call process.  It's ok to raise
the issue - given your (document editor/primary author)
reluctance to make the requested change, the WG co-chairs
will have to make a decision about how to resolve this
(probably around the end of the Last Call period) - one
possible resolution is to decide that the document is ok
without the change.
 
BTW - this is a general principle of WG Last Call - the
WG co-chairs have some discretion (particularly with editorial
comments) in deciding whether an issue raised during WG
Last Call requires changes in the draft.
 
Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
black_david@emc.com         Cell: +1 (978) 394-7754
---------------------------------------------------

-----Original Message-----
From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]
Sent: Monday, June 17, 2002 5:31 PM
To: Julian_Satran@il.ibm.com
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iSCSI: length and size

I don't understand why you find that.
 
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Monday, June 17, 2002 9:54 AM
To: pat_thaler@agilent.com
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com
Subject: RE: iSCSI: length and size


I personally find this as an abuse of the last call process.

Julo


pat_thaler@agilent.com

06/17/2002 07:14 PM
Please respond to pat_thaler

       
        To:        Julian Satran/Haifa/IBM@IBMIL, pat_thaler@agilent.com
        cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
        Subject:        RE: iSCSI: length and size

       


Julian, It is an issue for last call. Pat
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, June 15, 2002 9:06 AM
To: THALER,PAT (A-Roseville,ex1)
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iSCSI: length and size


Pat,

Is this a wish or an issue for the WG last call?

Julo

"THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>
Sent by: owner-ips@ece.cmu.edu

06/15/2002 02:50 AM
Please respond to "THALER,PAT (A-Roseville,ex1)"

       
       To:        Julian Satran/Haifa/IBM@IBMIL
       cc:        ips@ece.cmu.edu
       Subject:        iSCSI: length and size

     



Julian,

iSCSI-13 uses "length" quite a bit more than 100 times. Many of those times are in regard to the length of data, headers, and PDUs

e.g.
The basic header segment has a fixed length of 48 bytes.
Expected Data Transfer Length
Each PDU contains the payload length and the data offset....

It also uses size about 40 times with the same meaning as length. Most of these are the terms MaxBurstSize and FirstBurstSize and text associated with those terms.

It would be better (less likely to confuse readers and better for those of us who look for information using search tools) to choose one of those terms and always use it when talking about length/size. I don't care which is chosen.

Pat




------_=_NextPart_001_01C21721.9D48D1B0-- From owner-ips@ece.cmu.edu Wed Jun 19 02:27:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08764 for ; Wed, 19 Jun 2002 02:27:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5J5gip17297 for ips-outgoing; Wed, 19 Jun 2002 01:42:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lmail.actcom.co.il (mail.actcom.co.il [192.114.47.13]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5J5bBw17012 for ; Wed, 19 Jun 2002 01:37:11 -0400 (EDT) Received: from JA31 (line26-50.adsl.actcom.co.il [192.115.26.50] (may be forged)) by lmail.actcom.co.il (8.11.6/8.11.6) with SMTP id g5J5b8V21716 for ; Wed, 19 Jun 2002 08:37:09 +0300 Message-ID: <000501c21753$596d87b0$0500000a@JA31> From: "Julo-Actcom" To: "ips" Subject: Emailing: msg10868.txt Date: Wed, 19 Jun 2002 08:37:06 +0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01C2176C.7E72E140" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C2176C.7E72E140 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0002_01C2176C.7E72E140" ------=_NextPart_001_0002_01C2176C.7E72E140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable LUN field is reserved in response. I don't know why you had to re-re-re-read (no stutter). Julo ------=_NextPart_001_0002_01C2176C.7E72E140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
LUN field is reserved in = response.
I don't know why you had to = re-re-re-read (no=20 stutter).
 
Julo
------=_NextPart_001_0002_01C2176C.7E72E140-- ------=_NextPart_000_0001_01C2176C.7E72E140 Content-Type: text/plain; name="msg10868.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="msg10868.txt" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Another question of the obvious=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=

=0A= =0A= =0A= =0A=
=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
=0A= SORT = BY:=0A= =0A=

=0A= LIST ORDER=0A= =0A=
=0A= THREAD=0A= =0A=
AUTHOR=0A= =0A=
SUBJECT=0A=

=0A=


SEARCH=0A= =0A=

=0A=
=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
=0A= =0A=

=0A= =0A= IPS HOME=0A= =0A= =0A= =0A=

=0A= =0A= 		=0A= =0A=
    =0A= =0A= =0A= =0A=
    =0A= [Date Prev][Date = Next][Thread Prev][Thread Next][Date Index][Thread Index]=0A= =0A= =0A= =0A=

    Another question of the obvious

    =0A=
    =0A= =0A= =0A=
      =0A=
    • To: ips@ece.cmu.edu
      • =0A=
    • Subject: Another question of the = obvious
      • =0A=
    • From: Ken Sandars <ksandars@eurologic.com>
      • =0A=
    • Date: Tue, 18 Jun 2002 15:39:17 +0000
      • =0A=
    • Content-Transfer-Encoding: 8bit
      • =0A=
    • Content-Type: text/plain; charset=3D"iso-8859-1"
      • =0A=
    • Organization: Eurologic Systems
      • =0A=
    • Sender: owner-ips@ece.cmu.edu
      • =0A=
    =0A= =0A= =0A=
    =0A= =0A= =0A= 
    =0A=
Hi again,=0A=
=0A=
I've re-re-read (no, not a stutter) the spec and cannot determine the =
correct =0A=
handling for the LUN field in the Data-In and/or Response pdus.=0A=
=0A=
If an initiator issues a SCSI READ10 command on LUN52 does the target =
set its =0A=
LUN field in the Data-In pdu to:=0A=
(a) 52 (ie same as what the initiator had)=0A=
(b) 0   (treating it as reserved)?=0A=
=0A=
And does the target set its LUN field in the Response pdu to:=0A=
(a) 52 (ie same as what the initiator had)=0A=
(b) 0   (treating it as reserved)?=0A=
=0A=
Could the answers to the above change for different SCSI Commands?=0A=
=0A=
=0A=
TIA,=0A=
Ken=0A=
=0A=
-- =0A=
Ken Sandars=0A=
Eurologic Systems Ltd=0A=
ksandars@eurologic.com=0A=
    =0A= =0A= =0A= =0A= =0A=
    =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
=0A=

=0A=

=0A= =0A= Home=0A= =0A= =0A=

=0A=

=0A= Last updated: Tue Jun 18 13:18:46 2002
=0A= 10870 messages in chronological order
=0A=
=0A=
=0A= =0A= =0A= =0A= =0A= =0A= ------=_NextPart_000_0001_01C2176C.7E72E140-- From owner-ips@ece.cmu.edu Wed Jun 19 02:27:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08827 for ; Wed, 19 Jun 2002 02:27:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5J5gFW17261 for ips-outgoing; Wed, 19 Jun 2002 01:42:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lmail.actcom.co.il (mail.actcom.co.il [192.114.47.13]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5J4mxw14929 for ; Wed, 19 Jun 2002 00:48:59 -0400 (EDT) Received: from JA31 (line26-50.adsl.actcom.co.il [192.115.26.50] (may be forged)) by lmail.actcom.co.il (8.11.6/8.11.6) with SMTP id g5J4mvV10008 for ; Wed, 19 Jun 2002 07:48:57 +0300 Message-ID: <005601c2174c$9e2ba910$0500000a@JA31> From: "Julo-Actcom" To: Subject: iSCSI - empty PDUs Date: Wed, 19 Jun 2002 07:48:55 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0053_01C21765.C34AF340" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0053_01C21765.C34AF340 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Pat, SHOULD is probably OK. The intent of my text was to cover any case in which rules may require = an empty PDU current and future. I don't understand your point about nothing to send. If an initiator has nothing to send it should not send unless prompted = by an Asynch Message and a target must send if F=3D0. Julo To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu=20 a.. Subject: RE: iSCSI: use of Text/Login with no data segment=20 b.. From: pat_thaler@agilent.com=20 c.. Date: Mon, 17 Jun 2002 15:52:09 -0600=20 d.. Content-Type: = multipart/mixed;boundary=3D"----=3D_NextPartTM-000-5b802533-822f-11d6-ac7= f-009027aa5b50"=20 e.. Sender: owner-ips@ece.cmu.edu=20 -------------------------------------------------------------------------= ------- Julian, I think a MUST is too strong here. Also, the text "unless explicitly = required by a general or a key-specific negotiation rule" may not cover = the case of receiving a Text/Login R___ with F/T=3D0 and C=3D0 when one = has no keys to send. I don't think there is any explicit rule in the = draft requiring one to send with no data segment in that case. It is = just implict that one must respond with such a PDU if the negotiation is = to finish. Therefore, the following text would be better: A target or initiator SHOULD NOT use a Text/Login Response or Text/ Login Request with no data segment (DataSegmentLength 0) unless responding to a Text/Login Request or Text/Login Response, respectively, with the F/T bit set to 0 while the node has no keys to send or with the = C bit set to 1. (This is the same as the text at the bottom except T bit is corrected to = F/T to cover Text PDUs.)=20 Pat ------=_NextPart_000_0053_01C21765.C34AF340 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Pat,
 
SHOULD  is probably = OK.
The intent of my text was to cover any = case in=20 which rules may require an empty PDU current and future.
 
I don't understand your point about = nothing to=20 send.
 
If an initiator has nothing to send it = should not=20 send unless prompted by an Asynch Message and a target must send if=20 F=3D0.
 
Julo
 
 
To: Julian_Satran@il.ibm.com, = ips@ece.cmu.edu
  • Subject: RE: iSCSI: use of Text/Login = with no=20 data segment=20
  • From: pat_thaler@agilent.com=20
  • Date: Mon, 17 Jun 2002 15:52:09 -0600=20
  • Content-Type:=20 = multipart/mixed;boundary=3D"----=3D_NextPartTM-000-5b802533-822f-11d6-ac7= f-009027aa5b50"=20
  • Sender: owner-ips@ece.cmu.edu=20
Julian,
 
I = think a MUST is=20 too strong here. Also, the text "unless explicitly required by a general = or a=20 key-specific negotiation rule" may not cover the case of  receiving = a=20 Text/Login R___ with F/T=3D0 and C=3D0 when one has no keys to send. I = don't think=20 there is any explicit rule in the draft requiring one to send with no = data=20 segment in that case. It is just implict that one must respond with such = a PDU=20 if the negotiation is to finish. Therefore, the following text would be=20 better:
 
A target or=20 initiator SHOULD NOT use a Text/Login Response or Text/
Login Request = with no=20 data segment (DataSegmentLength 0) unless
responding to a Text/Login = Request=20 or Text/Login Response, respectively,
with the F/T bit set to 0 while = the=20 node has no keys to send or with the C bit
set to = 1.
(This = is the same as=20 the text at the bottom except T bit is corrected to F/T to cover Text = PDUs.)=20
 
Pat
------=_NextPart_000_0053_01C21765.C34AF340-- From owner-ips@ece.cmu.edu Wed Jun 19 02:30:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08869 for ; Wed, 19 Jun 2002 02:30:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5J5gLf17272 for ips-outgoing; Wed, 19 Jun 2002 01:42:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lmail.actcom.co.il (mail.actcom.co.il [192.114.47.13]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5J5CDw15917 for ; Wed, 19 Jun 2002 01:12:13 -0400 (EDT) Received: from JA31 (line26-50.adsl.actcom.co.il [192.115.26.50] (may be forged)) by lmail.actcom.co.il (8.11.6/8.11.6) with SMTP id g5J5CBV15033 for ; Wed, 19 Jun 2002 08:12:11 +0300 Message-ID: <006101c2174f$dcee1180$0500000a@JA31> From: "Julo-Actcom" To: Subject: RE: iSCSI: Negotiating a parameter more than once Date: Wed, 19 Jun 2002 08:12:09 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005E_01C21769.01FFA010" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_005E_01C21769.01FFA010 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Pat, 4.3 and 4.4 cover two diferent phases. Parameters should not be negotiated or declared twice. I think that you refer to the responses to SendTargets - those contain = more than an instance of the declarations and have to outlined. How about the following text in 4.4: Neither the initiator nor the target should attempt to negotiate a = parameter more than once during login except for responses to specific = keys that explicitly allow repeated key declarations (e.g. SendTargets). = If detected by the target this MUST result in a Login reject (initiator = error). The initiator MUST drop the connection. and in 4.4: Neither the initiator nor the target should attempt to negotiate a = parameter more than once during any negotiation sequence without an = intervening reset except for responses to specific keys that explicitly = allow repeated key declarations. If detected by the target this MUST = result in a Reject with a reason of "protocol error". The initiator MUST = reset the negotiation as outlined above. Julo -------------------------------------------------------------------------= ------- =20 a.. To: Julian_Satran@il.ibm.com=20 b.. Subject: iSCSI: Negotiating a parameter more than once=20 c.. From: pat_thaler@agilent.com=20 d.. Date: Mon, 17 Jun 2002 16:18:43 -0600=20 e.. Cc: ips@ece.cmu.edu=20 f.. Content-Type: text/plain;charset=3D"ISO-8859-1"=20 g.. Sender: owner-ips@ece.cmu.edu=20 -------------------------------------------------------------------------= ------- Julian, The following text appears in 4.3 (page 78 just before 4.3.1): Neither the initiator nor the target should attempt to negotiate a parameter more than once during login. If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection. and nearly the same text in 4.4 (page 85 near the end): Neither the initiator nor the target should attempt to negotiate a parameter more than once during any negotiation sequence without an intervening reset. If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above. This is confusing partly because "negotiate" seems to be generally used = covering both negotiations and declarations and in some cases covering = only negotiations. It isn't clear in which sense it is used. If the text = above applies only to negotiated values, then it would be allowable to = send parameters such as Initiator Name, SessionType, and = MaxRecvDataSegmentLength over which doesn't seem to be a good idea. = However, there are other declarative parameters which are sent multiple = times - SendTargets where there are multiple targets or multiple = addresses for a target requires sending the same parameter multiple = times.=20 Perhaps the text should be changed to: Neither the initiator nor the target should attempt to declare or = negotiate a parameter other than TargetName, TargetAlias or TargetAddress more than = once.... Regards, Pat -------------------------------------------------------------------------= ------- a.. Prev by Date: RE: iSCSI: use of Text/Login with no data segment=20 b.. Next by Date: RE: iSCSI: Negotiating a parameter more than once=20 c.. Prev by thread: iSCSI 0.13 vs. iSCSI Plugfest=20 d.. Next by thread: RE: iSCSI: Negotiating a parameter more than once=20 e.. Index(es):=20 a.. Date=20 b.. Thread=20 ------=_NextPart_000_005E_01C21769.01FFA010 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Pat,
 
4.3 and 4.4 cover two diferent = phases.
Parameters should not be negotiated or = declared=20 twice.
 
I think that you refer to the responses = to=20 SendTargets - those contain more than an instance of the declarations = and have=20 to outlined.
 
How about the following text in = 4.4:
 

Neither the initiator nor the target should attempt to negotiate a = parameter=20 more than once during login except for responses to specific keys that=20 explicitly allow repeated key declarations (e.g. SendTargets). If = detected by=20 the target this MUST result in a Login reject (initiator error). The = initiator=20 MUST drop the connection.

 

and in=20 4.4:

 

Neither the initiator nor the target should attempt to negotiate a = parameter=20 more than once during any negotiation sequence without an intervening = reset=20 except for responses to specific keys that explicitly allow repeated key = declarations. If detected by the target this MUST result in a Reject = with a=20 reason of "protocol error". The initiator MUST reset the negotiation as = outlined=20 above.
Julo
  • To: Julian_Satran@il.ibm.com=20
  • Subject: iSCSI: Negotiating a parameter = more than=20 once=20
  • From: pat_thaler@agilent.com=20
  • Date: Mon, 17 Jun 2002 16:18:43 -0600=20
  • Cc: ips@ece.cmu.edu=20
  • Content-Type: text/plain;charset=3D"ISO-8859-1"=20
  • Sender: owner-ips@ece.cmu.edu=20 
Julian,

The following text appears in 4.3 (page 78 just before 4.3.1):

Neither the initiator nor the target should attempt to negotiate a
parameter more than once during login. If detected by the target this
MUST result in a Login reject (initiator error). The initiator MUST
drop the connection.

and nearly the same text in 4.4 (page 85 near the end):

Neither the initiator nor the target should attempt to negotiate a
parameter more than once during any negotiation sequence without an
intervening reset. If detected by the target this MUST result in a
Reject with a reason of "protocol error". The initiator MUST reset
the negotiation as outlined above.

This is confusing partly because "negotiate" seems to be generally used =
covering both negotiations and declarations and in some cases covering =
only negotiations. It isn't clear in which sense it is used. If the text =
above applies only to negotiated values, then it would be allowable to =
send parameters such as Initiator Name, SessionType, and =
MaxRecvDataSegmentLength over which doesn't seem to be a good idea. =
However, there are other declarative parameters which are sent multiple =
times - SendTargets where there are multiple targets or multiple =
addresses for a target requires sending the same parameter multiple =
times.=20

Perhaps the text should be changed to:

Neither the initiator nor the target should attempt to declare or =
negotiate a
parameter other than TargetName, TargetAlias or TargetAddress more than =
once....

Regards,
Pat
=
  • Prev by Date: RE: = iSCSI:=20 use of Text/Login with no data segment=20
  • Next by Date: RE: = iSCSI:=20 Negotiating a parameter more than once=20
  • Prev by thread: iSCSI= 0.13=20 vs. iSCSI Plugfest=20
  • Next by thread: RE: = iSCSI:=20 Negotiating a parameter more than once=20
  • Index(es):=20
    • Date=20
    • = Thread=20 =
<= /HTML> ------=_NextPart_000_005E_01C21769.01FFA010-- From owner-ips@ece.cmu.edu Wed Jun 19 02:30:30 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08894 for ; Wed, 19 Jun 2002 02:30:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5J61CZ18139 for ips-outgoing; Wed, 19 Jun 2002 02:01:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lmail.actcom.co.il (mail.actcom.co.il [192.114.47.13]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5J619w18131 for ; Wed, 19 Jun 2002 02:01:09 -0400 (EDT) Received: from JA31 (line26-50.adsl.actcom.co.il [192.115.26.50] (may be forged)) by lmail.actcom.co.il (8.11.6/8.11.6) with SMTP id g5J617V28380 for ; Wed, 19 Jun 2002 09:01:07 +0300 Message-ID: <009401c21756$b3172520$0500000a@JA31> From: "Julo-Actcom" To: "ips" Subject: Fw: Emailing: msg10868.txt Date: Wed, 19 Jun 2002 09:01:05 +0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0090_01C2176F.D82D4790" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0090_01C2176F.D82D4790 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0091_01C2176F.D82D4790" ------=_NextPart_001_0091_01C2176F.D82D4790 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 From: Julo-Actcom=20 To: ips=20 Sent: Wednesday, June 19, 2002 8:37 AM Subject: Emailing: msg10868.txt LUN field is reserved in response. I don't know why you had to re-re-re-read (no stutter). Julo ------=_NextPart_001_0091_01C2176F.D82D4790 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
----- Original Message -----=20
From: Julo-Actcom
To: ips=20
Sent: Wednesday, June 19, 2002 8:37 AM
Subject: Emailing: msg10868.txt

LUN field is reserved in = response.
I don't know why you had to = re-re-re-read (no=20 stutter).
 
Julo
------=_NextPart_001_0091_01C2176F.D82D4790-- ------=_NextPart_000_0090_01C2176F.D82D4790 Content-Type: text/plain; name="msg10868.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="msg10868.txt" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Another question of the obvious=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=

=0A= =0A= =0A= =0A=
=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
=0A= SORT = BY:=0A= =0A=

=0A= LIST ORDER=0A= =0A=
=0A= THREAD=0A= =0A=
AUTHOR=0A= =0A=
SUBJECT=0A=

=0A=


SEARCH=0A= =0A=

=0A=
=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
=0A= =0A=

=0A= =0A= IPS HOME=0A= =0A= =0A= =0A=

=0A= =0A= 		=0A= =0A=
    =0A= =0A= =0A= =0A=
    =0A= [Date Prev][Date = Next][Thread Prev][Thread Next][Date Index][Thread Index]=0A= =0A= =0A= =0A=

    Another question of the obvious

    =0A=
    =0A= =0A= =0A=
      =0A=
    • To: ips@ece.cmu.edu
      • =0A=
    • Subject: Another question of the = obvious
      • =0A=
    • From: Ken Sandars <ksandars@eurologic.com>
      • =0A=
    • Date: Tue, 18 Jun 2002 15:39:17 +0000
      • =0A=
    • Content-Transfer-Encoding: 8bit
      • =0A=
    • Content-Type: text/plain; charset=3D"iso-8859-1"
      • =0A=
    • Organization: Eurologic Systems
      • =0A=
    • Sender: owner-ips@ece.cmu.edu
      • =0A=
    =0A= =0A= =0A=
    =0A= =0A= =0A= 
    =0A=
Hi again,=0A=
=0A=
I've re-re-read (no, not a stutter) the spec and cannot determine the =
correct =0A=
handling for the LUN field in the Data-In and/or Response pdus.=0A=
=0A=
If an initiator issues a SCSI READ10 command on LUN52 does the target =
set its =0A=
LUN field in the Data-In pdu to:=0A=
(a) 52 (ie same as what the initiator had)=0A=
(b) 0   (treating it as reserved)?=0A=
=0A=
And does the target set its LUN field in the Response pdu to:=0A=
(a) 52 (ie same as what the initiator had)=0A=
(b) 0   (treating it as reserved)?=0A=
=0A=
Could the answers to the above change for different SCSI Commands?=0A=
=0A=
=0A=
TIA,=0A=
Ken=0A=
=0A=
-- =0A=
Ken Sandars=0A=
Eurologic Systems Ltd=0A=
ksandars@eurologic.com=0A=
    =0A= =0A= =0A= =0A= =0A=
    =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
=0A=

=0A=

=0A= =0A= Home=0A= =0A= =0A=

=0A=

=0A= Last updated: Tue Jun 18 13:18:46 2002
=0A= 10870 messages in chronological order
=0A=
=0A=
=0A= =0A= =0A= =0A= =0A= =0A= ------=_NextPart_000_0090_01C2176F.D82D4790-- From owner-ips@ece.cmu.edu Wed Jun 19 02:32:44 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09027 for ; Wed, 19 Jun 2002 02:32:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5J5gQW17281 for ips-outgoing; Wed, 19 Jun 2002 01:42:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lmail.actcom.co.il (mail.actcom.co.il [192.114.47.13]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5J5HFw16157 for ; Wed, 19 Jun 2002 01:17:15 -0400 (EDT) Received: from JA31 (line26-50.adsl.actcom.co.il [192.115.26.50] (may be forged)) by lmail.actcom.co.il (8.11.6/8.11.6) with SMTP id g5J5HDV16406 for ; Wed, 19 Jun 2002 08:17:13 +0300 Message-ID: <006a01c21750$90b63d00$0500000a@JA31> From: "Julo-Actcom" To: Subject: iSCSI - Sendtargets Date: Wed, 19 Jun 2002 08:17:10 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0067_01C21769.B5C7CB90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0067_01C21769.B5C7CB90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Pat, I don't see why we have to say something specific about SendTargets. It should be sent only once during a negotiiation. Why should we mandate the F bit? Julo -------------------------------------------------------------------------= ------- =20 a.. To: Julian_Satran@il.ibm.com=20 b.. Subject: RE: iSCSI: Negotiating a parameter more than once=20 c.. From: "THALER,PAT (A-Roseville,ex1)" =20 d.. Date: Mon, 17 Jun 2002 17:05:18 -0600=20 e.. Cc: ips@ece.cmu.edu=20 f.. Content-Type: text/plain;charset=3D"ISO-8859-1"=20 g.. Sender: owner-ips@ece.cmu.edu=20 -------------------------------------------------------------------------= ------- Julian, It also isn't clear whether SendTargets can be sent more than once = during a negotiation sequence. It would be reasonable for the Initiator to set the F bit when it sends = SendTargets and then when the Target sets the F bit the initiator will = know that the response is complete. However if SendTargets isn't covered = by the limitation on negotiating a parameter only once per negotiation = sequence, an initiator could also leave the F bit at zero, assume the = response is done when it gets a response with an empty text field, and = send SendTargets again later in the same negotiation sequence. An = initiatior could even send a single PDU with something like: = SendTargets=3D; = SendTargets=3D; = SendTargets=3D.=20 There doesn't seem to be anything in Appendix D to say which of these is = intended. The first possibility - allowing SendTargets to be sent only = once during a negotiation sequence - seems adequate and simpler. Pat -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Monday, June 17, 2002 3:19 PM To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: iSCSI: Negotiating a parameter more than once Julian, The following text appears in 4.3 (page 78 just before 4.3.1): Neither the initiator nor the target should attempt to negotiate a parameter more than once during login. If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection. and nearly the same text in 4.4 (page 85 near the end): Neither the initiator nor the target should attempt to negotiate a parameter more than once during any negotiation sequence without an intervening reset. If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above. This is confusing partly because "negotiate" seems to be generally used = covering both negotiations and declarations and in some cases covering = only negotiations. It isn't clear in which sense it is used. If the text = above applies only to negotiated values, then it would be allowable to = send parameters such as Initiator Name, SessionType, and = MaxRecvDataSegmentLength over which doesn't seem to be a good idea. = However, there are other declarative parameters which are sent multiple = times - SendTargets where there are multiple targets or multiple = addresses for a target requires sending the same parameter multiple = times.=20 Perhaps the text should be changed to: Neither the initiator nor the target should attempt to declare or = negotiate a parameter other than TargetName, TargetAlias or TargetAddress more than = once.... Regards, Pat -------------------------------------------------------------------------= ------- a.. Prev by Date: iSCSI: Negotiating a parameter more than once=20 b.. Next by Date: RE: iSCSI: Negotiating a parameter more than once=20 c.. Prev by thread: iSCSI: Negotiating a parameter more than once=20 d.. Next by thread: RE: iSCSI: Negotiating a parameter more than once=20 e.. Index(es):=20 a.. Date=20 b.. Thread=20 -------------------------------------------------------------------------= ------- Home=20 Last updated: Mon Jun 17 20:18:42 2002 10865 messages in chronological order ------=_NextPart_000_0067_01C21769.B5C7CB90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Pat,
 
I don't see why we have to say = something specific=20 about SendTargets.
It should be sent only once during a=20 negotiiation.
 
Why should we mandate the F = bit?
 
Julo
 
  • To: Julian_Satran@il.ibm.com=20
  • Subject: RE: iSCSI: Negotiating a = parameter more=20 than once=20
  • From: "THALER,PAT (A-Roseville,ex1)" = <pat_thaler@agilent.com>=20
  • Date: Mon, 17 Jun 2002 17:05:18 -0600=20
  • Cc: ips@ece.cmu.edu=20
  • Content-Type: text/plain;charset=3D"ISO-8859-1"=20
  • Sender: owner-ips@ece.cmu.edu=20 
Julian,

It also isn't clear whether SendTargets can be sent more than once =
during a negotiation sequence.

It would be reasonable for the Initiator to set the F bit when it sends =
SendTargets and then when the Target sets the F bit the initiator will =
know that the response is complete. However if SendTargets isn't covered =
by the limitation on negotiating a parameter only once per negotiation =
sequence, an initiator could also leave the F bit at zero, assume the =
response is done when it gets a response with an empty text field, and =
send SendTargets again later in the same negotiation sequence. An =
initiatior could even send a single PDU with something like: =
SendTargets=3D<iSCSI-target-name-A>; =
SendTargets=3D<iSCSI-target-name-B>; =
SendTargets=3D<iSCSI-target-name-C>.=20

There doesn't seem to be anything in Appendix D to say which of these is =
intended. The first possibility - allowing SendTargets to be sent only =
once during a negotiation sequence - seems adequate and simpler.

Pat

-----Original Message-----
From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]=

Sent: Monday, June 17, 2002 3:19 PM
To: Julian_Satran@il.ibm.com
Cc: ips@ece.cmu.edu
Subject: iSCSI: Negotiating a parameter more than once


Julian,

The following text appears in 4.3 (page 78 just before 4.3.1):

Neither the initiator nor the target should attempt to negotiate a
parameter more than once during login. If detected by the target this
MUST result in a Login reject (initiator error). The initiator MUST
drop the connection.

and nearly the same text in 4.4 (page 85 near the end):

Neither the initiator nor the target should attempt to negotiate a
parameter more than once during any negotiation sequence without an
intervening reset. If detected by the target this MUST result in a
Reject with a reason of "protocol error". The initiator MUST reset
the negotiation as outlined above.

This is confusing partly because "negotiate" seems to be generally used =
covering both negotiations and declarations and in some cases covering =
only negotiations. It isn't clear in which sense it is used. If the text =
above applies only to negotiated values, then it would be allowable to =
send parameters such as Initiator Name, SessionType, and =
MaxRecvDataSegmentLength over which doesn't seem to be a good idea. =
However, there are other declarative parameters which are sent multiple =
times - SendTargets where there are multiple targets or multiple =
addresses for a target requires sending the same parameter multiple =
times.=20

Perhaps the text should be changed to:

Neither the initiator nor the target should attempt to declare or =
negotiate a
parameter other than TargetName, TargetAlias or TargetAddress more than =
once....

Regards,
Pat
=
  • Prev by Date: iSCSI= :=20 Negotiating a parameter more than once=20
  • Next by Date: RE: = iSCSI:=20 Negotiating a parameter more than once=20
  • Prev by thread: iSCSI= :=20 Negotiating a parameter more than once=20
  • Next by thread: RE: = iSCSI:=20 Negotiating a parameter more than once=20
  • Index(es):=20
    • Date=20
    • = Thread=20

Home

Last updated: Mon Jun 17 20:18:42 2002
10865 messages in=20 chronological order
------=_NextPart_000_0067_01C21769.B5C7CB90-- From owner-ips@ece.cmu.edu Wed Jun 19 02:36:42 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09119 for ; Wed, 19 Jun 2002 02:36:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5J5wsh18044 for ips-outgoing; Wed, 19 Jun 2002 01:58:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lmail.actcom.co.il (mail.actcom.co.il [192.114.47.13]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5J5wpw18036 for ; Wed, 19 Jun 2002 01:58:52 -0400 (EDT) Received: from JA31 (line26-50.adsl.actcom.co.il [192.115.26.50] (may be forged)) by lmail.actcom.co.il (8.11.6/8.11.6) with SMTP id g5J5woV27705 for ; Wed, 19 Jun 2002 08:58:50 +0300 Message-ID: <001101c21756$60f042e0$0500000a@JA31> From: "Julo-Actcom" To: "ips" Subject: Emailing: msg10874.txt Date: Wed, 19 Jun 2002 08:58:47 +0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000D_01C2176F.85FBB6F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C2176F.85FBB6F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C2176F.85FBB6F0" ------=_NextPart_001_000E_01C2176F.85FBB6F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable That is correct - Julo ------=_NextPart_001_000E_01C2176F.85FBB6F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
That  is correct -=20 Julo
------=_NextPart_001_000E_01C2176F.85FBB6F0-- ------=_NextPart_000_000D_01C2176F.85FBB6F0 Content-Type: text/plain; name="msg10874.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="msg10874.txt" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Question regarding SNACK and bidi transfers=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=

=0A= =0A= =0A= =0A=
=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
=0A= SORT = BY:=0A= =0A=

=0A= LIST ORDER=0A= =0A=
=0A= THREAD=0A= =0A=
AUTHOR=0A= =0A=
SUBJECT=0A=

=0A=


SEARCH=0A= =0A=

=0A=
=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
=0A= =0A=

=0A= =0A= IPS HOME=0A= =0A= =0A= =0A=

=0A= =0A= 		=0A= =0A=
    =0A= =0A= =0A= =0A=
    =0A= [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]=0A= =0A= =0A= =0A=

    Question regarding SNACK and bidi transfers

    =0A=
    =0A= =0A= =0A= =0A= =0A= =0A=
    =0A= =0A= =0A= 
    =0A=
I have a question about SNACK type 0 requests. In the text, they are=0A=
described as being for Data-In PDUs or R2T PDUs.=0A=
=0A=
For a bidi command, how do you know which? Does this mean that for a bidi=0A=
command, data-in and R2TSNs have to be mutually-unique (i.e. drawn from=0A=
the same pool)?=0A=
=0A=
Take care,=0A=
=0A=
Bill=0A=
=0A=
    =0A= =0A= =0A= =0A= =0A=
    =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
=0A=

=0A=

=0A= =0A= Home=0A= =0A= =0A=

=0A=

=0A= Last updated: Tue Jun 18 20:18:44 2002
=0A= 10875 messages in chronological order
=0A=
=0A=
=0A= =0A= =0A= =0A= =0A= =0A= ------=_NextPart_000_000D_01C2176F.85FBB6F0-- From owner-ips@ece.cmu.edu Wed Jun 19 07:01:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12828 for ; Wed, 19 Jun 2002 07:01:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5JAC4S09324 for ips-outgoing; Wed, 19 Jun 2002 06:12:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5JAC2w09320 for ; Wed, 19 Jun 2002 06:12:02 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Jun 2002 06:12:01 -0400 Message-ID: From: Eddy Quicksall To: julian_satran@il.ibm.com Cc: ips@ece.cmu.edu, Bill Studenmund Subject: RE: Question regarding SNACK and bidi transfers Date: Wed, 19 Jun 2002 06:11:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julo, Since the answer to the 2nd question is "yes" (see your EMAIL with subject "Emailing: msg10874.txt"), then I think the spec should make that more clear in sections 9.8.1 and 9.7. Perhaps in section 9.8.1, it should say something like "Except, when used with a bidirectional command and SNACK is being supported, the R2TSN must start with a number that couples the R2TSN and DataSN together as one continuous sequence". And a similar statement added to 9.7. Eddy -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Tuesday, June 18, 2002 7:56 PM To: ips@ece.cmu.edu Subject: Question regarding SNACK and bidi transfers I have a question about SNACK type 0 requests. In the text, they are described as being for Data-In PDUs or R2T PDUs. For a bidi command, how do you know which? Does this mean that for a bidi command, data-in and R2TSNs have to be mutually-unique (i.e. drawn from the same pool)? Take care, Bill From owner-ips@ece.cmu.edu Wed Jun 19 12:27:13 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25601 for ; Wed, 19 Jun 2002 12:27:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5JG6J028138 for ips-outgoing; Wed, 19 Jun 2002 12:06:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5JG6Iw28134 for ; Wed, 19 Jun 2002 12:06:18 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id B7B213070E; Wed, 19 Jun 2002 12:06:17 -0400 (EDT) Date: Wed, 19 Jun 2002 09:03:35 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Eddy Quicksall Cc: , Subject: RE: Question regarding SNACK and bidi transfers In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Wed, 19 Jun 2002, Eddy Quicksall wrote: > Julo, > > Since the answer to the 2nd question is "yes" (see your EMAIL with subject > "Emailing: msg10874.txt"), then I think the spec should make that more clear > in sections 9.8.1 and 9.7. > > Perhaps in section 9.8.1, it should say something like "Except, when used > with a bidirectional command and SNACK is being supported, the R2TSN must > start with a number that couples the R2TSN and DataSN together as one > continuous sequence". And a similar statement added to 9.7. I'm curious about the use of except. I would think that bidi commands are the very time we would have both R2TSN and DataSN in use at once. ?? Take care, Bill From owner-ips@ece.cmu.edu Wed Jun 19 12:28:12 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25637 for ; Wed, 19 Jun 2002 12:28:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5JFfdY26795 for ips-outgoing; Wed, 19 Jun 2002 11:41:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (oe45.law10.hotmail.com [64.4.14.17]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5JFfaw26787 for ; Wed, 19 Jun 2002 11:41:36 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 19 Jun 2002 08:41:30 -0700 X-Originating-IP: [192.115.216.85] From: "Juian Satran \(Hotmail\)" To: "ips" Cc: "Juian Satran \(Hotmail\)" Subject: Emailing: msg10855.txt Date: Wed, 19 Jun 2002 18:41:19 +0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0013_01C217C0.E6C9CDE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 19 Jun 2002 15:41:30.0781 (UTC) FILETIME=[C8555CD0:01C217A7] Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C217C0.E6C9CDE0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0014_01C217C0.E6C9CDE0" ------=_NextPart_001_0014_01C217C0.E6C9CDE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Pat, Your "issue" with operational is probably related to a missreading of = the text. The barrier (dissalow wrapping) is on CmdSN. CmdSN advances accross al = connections but the barrier "stays" while the connection is = operational and will be "removed" if the connection goes away. The barrier is there to avoid stale commands popping-up at the target = after a recovery. Julo ------=_NextPart_001_0014_01C217C0.E6C9CDE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Pat,
 
Your "issue" with operational is = probably related=20 to a missreading of the text.
The barrier (dissalow wrapping) is on = CmdSN. CmdSN=20 advances accross al connections  but the barrier "stays"  = while the=20 connection is operational and will be "removed" if the connection = goes=20 away.
The barrier is there to avoid stale = commands=20 popping-up at the target after a recovery.
 
Julo
------=_NextPart_001_0014_01C217C0.E6C9CDE0-- ------=_NextPart_000_0013_01C217C0.E6C9CDE0 Content-Type: text/plain; name="msg10855.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="msg10855.txt" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= RE: iSCSI: advancing CmdSN after a command retry rule=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=

=0A= =0A= =0A= =0A=
=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
=0A= SORT = BY:=0A= =0A=

=0A= LIST ORDER=0A= =0A=
=0A= THREAD=0A= =0A=
AUTHOR=0A= =0A=
SUBJECT=0A=

=0A=


SEARCH=0A= =0A=

=0A=
=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
=0A= =0A=

=0A= =0A= IPS HOME=0A= =0A= =0A= =0A=

=0A= =0A= 		=0A= =0A=
    =0A= =0A= =0A= =0A=
    =0A= [Date Prev][Date = Next][Thread Prev][Thread Next][Date Index][Thread Index]=0A= =0A= =0A= =0A=

    RE: iSCSI: advancing CmdSN after a command retry rule

    =0A=
    =0A= =0A= =0A= =0A= =0A= =0A=
    =0A= =0A= =0A= =0A= =0A= =0A=
    Julian,
    =0A=
     
    =0A=
    Thanks. That still =0A= leaves the problem that there is no definition of when a connection is =0A= "operational" but that could be added to the last call =0A= issues.
    =0A=
     
    =0A=
    Pat
    =0A=
     
    =0A=
    -----Original Message-----
    From: Julian Satran =0A= [mailto:Julian_Satran@il.ibm.com]
    Sent: Saturday, June 15, = 2002 9:27 =0A= AM
    To: THALER,PAT (A-Roseville,ex1)
    Cc: =0A= ips@ece.cmu.edu
    Subject: Re: iSCSI: advancing CmdSN after a = command =0A= retry rule


    Pat, =0A=

    If the connection went through = a "restart" =0A= (login with the same CID) then the "cleaning" is also not needed. =0A=
    Your text modified as follows is =0A= acceptable:

    If an = initiator =0A= issues a command retry for a command with CmdSN R on
    a connection when the session CmdSN = register is Q, it =0A= MUST NOT advance the CmdSN past R + 2**31 -1 unless the connection is no = longer =0A= operational, or the connection has been reinstated (see Section 4.3.4 = Connection =0A= reinstatement), or a non-immediate command with CmdSN equal or greater = than Q =0A= was issued on the same connection and the reception of the command is =0A= acknowledged by the target (see Section 8.4 Command Retry and Cleaning = Old =0A= Command Instances).

    Thanks, =0A=
    Julo



    =0A= =0A= =0A= =0A=
    =0A= "THALER,PAT = (A-Roseville,ex1)" =0A= <pat_thaler@agilent.com> =0A=

    06/15/2002 03:39 AM =
    Please respond to "THALER,PAT =0A= (A-Roseville,ex1)"

    =0A=     		        =
            To:   =   =0A=    Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu =0A=
            = cc:   =0A=      
        =0A=     Subject:        iSCSI: advancing = CmdSN =0A= after a command retry rule

      =0A=      


    Julian,

    I'm having a little trouble understanding this = text near =0A= the end of 2.2.2.1:

    If an initiator issues a command retry for a = command =0A= with CmdSN R on
    a connection when the session CmdSN register is Q, it = MUST =0A= NOT
    advance the CmdSN past R + 2**31 -1 unless a different =0A= non-immediate
    command with CmdSN equal or greater than Q was issued = on the =0A= same
    connection if the connection is still operational, and the =0A= reception
    of the command is acknowledged by the target (see Section = 8.4 =0A= Command
    Retry and Cleaning Old Command Instances). The second =0A= non-immediate
    command when sent, MUST be sent in-order after the =0A= retried
    command on the same connection.

    What does "different" = mean in =0A= a different non-immediate command with CmdSN equal or greater than Q"? = Isn't any =0A= command with a new CmdSN because it has a new CmdSN?

    What is the = purpose =0A= of "if the connection is still operational"? If a new command is issued = on the =0A= connection it must still be operational. Perhaps it was intended to mean = that if =0A= the connection was not operational then CmdSN can be advanced past the = limit =0A= without this requirement being met.

    There doesn't seem to be any =0A= definition of when a connection is "operational". Does the connection = leave the =0A= operational state when it leaves S5 or is it when it has returned to =0A= S1?

    Does "second non-immediate command" mean the command sent on = this =0A= connection with CmdSN equal or greater than Q? Other commands with Q = <=3D CmdSN =0A= < R + 2**31 - 1 may be sent on other connections, so the second = command is =0A= the second command on this connection, right?

    It isn't clear what = the =0A= last sentence was intended to do since any command sent before the retry = would =0A= advance Q so inherently any command sent after the retry with a new = CmdSN must =0A= be in-order after the retry.

    I suggest the following text plus =0A= clarification of the meaning of operational for a connection:
    "If an =0A= initiator issues a command retry for a command with CmdSN R on
    a = connection =0A= when the session CmdSN register is Q, it MUST NOT
    advance the CmdSN = past R + =0A= 2**31 -1 unless the connection is no longer operational or a = non-immediate =0A= command with CmdSN equal or greater than Q was issued on the = same
    connection =0A= and the reception of the command is acknowledged by the target (see = Section 8.4 =0A= Command Retry and Cleaning Old Command Instances).

    Pat =0A=


    =0A= =0A= =0A= =0A= =0A=
    =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
=0A=

=0A=

=0A= =0A= Home=0A= =0A= =0A=

=0A=

=0A= Last updated: Mon Jun 17 13:18:48 2002
=0A= 10859 messages in chronological order
=0A=
=0A=
=0A= =0A= =0A= =0A= =0A= =0A= ------=_NextPart_000_0013_01C217C0.E6C9CDE0-- From owner-ips@ece.cmu.edu Wed Jun 19 12:28:14 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25653 for ; Wed, 19 Jun 2002 12:28:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5JG0LA27830 for ips-outgoing; Wed, 19 Jun 2002 12:00:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5JG0Jw27826 for ; Wed, 19 Jun 2002 12:00:20 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 161B13070E; Wed, 19 Jun 2002 12:00:19 -0400 (EDT) Date: Wed, 19 Jun 2002 08:57:36 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Amir Shalit Cc: Eddy Quicksall , , Subject: RE: Question regarding SNACK and bidi transfers In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Wed, 19 Jun 2002, Amir Shalit wrote: > How do you "couple" R2TSN and DataSN together? Would it be better > using an option bit indicating what we are asking for? Well, I'm not Eddie, but I envision it as you have a counter that you start at zero. You grab the current value & incriment each time you number a data-in pdu or you need an R2TSN. That way a SNACK number refers to either a DATA-IN or an R2T PDU. Take care, Bill From owner-ips@ece.cmu.edu Wed Jun 19 12:29:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25695 for ; Wed, 19 Jun 2002 12:28:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5JFids26979 for ips-outgoing; Wed, 19 Jun 2002 11:44:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from astutenetworks.com (2.astutenetworks.com [216.142.74.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5JFiaw26970 for ; Wed, 19 Jun 2002 11:44:37 -0400 (EDT) Received: from amirdesktop (dhcp62 [172.21.2.62]) by astutenetworks.com (8.11.6/8.11.2) with SMTP id g5JFiME08401; Wed, 19 Jun 2002 08:44:22 -0700 From: "Amir Shalit" To: "Eddy Quicksall" , Cc: , "Bill Studenmund" Subject: RE: Question regarding SNACK and bidi transfers Date: Wed, 19 Jun 2002 08:44:14 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-reply-to: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Eddy, How do you "couple" R2TSN and DataSN together? Would it be better using an option bit indicating what we are asking for? Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Eddy Quicksall Sent: Wednesday, June 19, 2002 3:12 AM To: julian_satran@il.ibm.com Cc: ips@ece.cmu.edu; Bill Studenmund Subject: RE: Question regarding SNACK and bidi transfers Julo, Since the answer to the 2nd question is "yes" (see your EMAIL with subject "Emailing: msg10874.txt"), then I think the spec should make that more clear in sections 9.8.1 and 9.7. Perhaps in section 9.8.1, it should say something like "Except, when used with a bidirectional command and SNACK is being supported, the R2TSN must start with a number that couples the R2TSN and DataSN together as one continuous sequence". And a similar statement added to 9.7. Eddy -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Tuesday, June 18, 2002 7:56 PM To: ips@ece.cmu.edu Subject: Question regarding SNACK and bidi transfers I have a question about SNACK type 0 requests. In the text, they are described as being for Data-In PDUs or R2T PDUs. For a bidi command, how do you know which? Does this mean that for a bidi command, data-in and R2TSNs have to be mutually-unique (i.e. drawn from the same pool)? Take care, Bill From owner-ips@ece.cmu.edu Wed Jun 19 12:37:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25958 for ; Wed, 19 Jun 2002 12:36:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5JFZZx26443 for ips-outgoing; Wed, 19 Jun 2002 11:35:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5JFZXw26439 for ; Wed, 19 Jun 2002 11:35:33 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5JFZJi8041320; Wed, 19 Jun 2002 17:35:19 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5JFZIc24080; Wed, 19 Jun 2002 17:35:18 +0200 To: Eddy Quicksall Cc: ips@ece.cmu.edu, Bill Studenmund MIME-Version: 1.0 Subject: RE: Question regarding SNACK and bidi transfers X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 19 Jun 2002 18:35:14 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 19/06/2002 18:35:19, Serialize complete at 19/06/2002 18:35:19 Content-Type: multipart/alternative; boundary="=_alternative 00550765C2256BDD_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00550765C2256BDD_= Content-Type: text/plain; charset="us-ascii" Eddy, In fact 2.2.2.3 contains: For bidirectional commands, the target uses the DataSN/R2TSN to sequence Data-In and R2T PDUs in one continuous sequence (undifferentiated). Do you think I should repeat this in 9.8.1 and 9.7 ? Julo Eddy Quicksall 06/19/2002 01:11 PM Please respond to Eddy Quicksall To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, Bill Studenmund Subject: RE: Question regarding SNACK and bidi transfers Julo, Since the answer to the 2nd question is "yes" (see your EMAIL with subject "Emailing: msg10874.txt"), then I think the spec should make that more clear in sections 9.8.1 and 9.7. Perhaps in section 9.8.1, it should say something like "Except, when used with a bidirectional command and SNACK is being supported, the R2TSN must start with a number that couples the R2TSN and DataSN together as one continuous sequence". And a similar statement added to 9.7. Eddy -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Tuesday, June 18, 2002 7:56 PM To: ips@ece.cmu.edu Subject: Question regarding SNACK and bidi transfers I have a question about SNACK type 0 requests. In the text, they are described as being for Data-In PDUs or R2T PDUs. For a bidi command, how do you know which? Does this mean that for a bidi command, data-in and R2TSNs have to be mutually-unique (i.e. drawn from the same pool)? Take care, Bill --=_alternative 00550765C2256BDD_= Content-Type: text/html; charset="us-ascii"
Eddy,

In fact 2.2.2.3 contains:

For bidirectional commands, the target uses the DataSN/R2TSN to sequence Data-In and R2T PDUs in one continuous sequence (undifferentiated).

Do you think I should repeat this in 9.8.1 and 9.7 ?

Julo


Eddy Quicksall <eddy_quicksall@ivivity.com>

06/19/2002 01:11 PM
Please respond to Eddy Quicksall

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu, Bill Studenmund <wrstuden@wasabisystems.com>
        Subject:        RE: Question regarding SNACK and bidi transfers

       


Julo,

Since the answer to the 2nd question is "yes" (see your EMAIL with subject
"Emailing: msg10874.txt"), then I think the spec should make that more clear
in sections 9.8.1 and 9.7.

Perhaps in section 9.8.1, it should say something like "Except, when used
with a bidirectional command and SNACK is being supported, the R2TSN must
start with a number that couples the R2TSN and DataSN together as one
continuous sequence". And a similar statement added to 9.7.

Eddy

-----Original Message-----
From: Bill Studenmund [mailto:wrstuden@wasabisystems.com]
Sent: Tuesday, June 18, 2002 7:56 PM
To: ips@ece.cmu.edu
Subject: Question regarding SNACK and bidi transfers


I have a question about SNACK type 0 requests. In the text, they are
described as being for Data-In PDUs or R2T PDUs.

For a bidi command, how do you know which? Does this mean that for a bidi
command, data-in and R2TSNs have to be mutually-unique (i.e. drawn from
the same pool)?

Take care,

Bill

--=_alternative 00550765C2256BDD_=-- From owner-ips@ece.cmu.edu Wed Jun 19 14:02:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29425 for ; Wed, 19 Jun 2002 14:02:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5JHYUL03232 for ips-outgoing; Wed, 19 Jun 2002 13:34:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5JHYSw03228 for ; Wed, 19 Jun 2002 13:34:28 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel12.hp.com (Postfix) with ESMTP id 283D0E006DD; Wed, 19 Jun 2002 10:34:23 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id KAA06218; Wed, 19 Jun 2002 10:36:12 -0700 (PDT) Message-ID: <002001c217b7$8caa24d0$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Eddy Quicksall" , Cc: , "Bill Studenmund" References: Subject: Re: Question regarding SNACK and bidi transfers Date: Wed, 19 Jun 2002 10:34:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Section 2.2.2.3 of rev13 currently says the following, which seems the right place for specifying this. "For bidirectional commands, the target uses the DataSN/R2TSN to sequence Data-In and R2T PDUs in one continuous sequence (undifferentiated)." -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Eddy Quicksall" To: Cc: ; "Bill Studenmund" Sent: Wednesday, June 19, 2002 3:11 AM Subject: RE: Question regarding SNACK and bidi transfers > Julo, > > Since the answer to the 2nd question is "yes" (see your EMAIL with subject > "Emailing: msg10874.txt"), then I think the spec should make that more clear > in sections 9.8.1 and 9.7. > > Perhaps in section 9.8.1, it should say something like "Except, when used > with a bidirectional command and SNACK is being supported, the R2TSN must > start with a number that couples the R2TSN and DataSN together as one > continuous sequence". And a similar statement added to 9.7. > > Eddy > > -----Original Message----- > From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] > Sent: Tuesday, June 18, 2002 7:56 PM > To: ips@ece.cmu.edu > Subject: Question regarding SNACK and bidi transfers > > > I have a question about SNACK type 0 requests. In the text, they are > described as being for Data-In PDUs or R2T PDUs. > > For a bidi command, how do you know which? Does this mean that for a bidi > command, data-in and R2TSNs have to be mutually-unique (i.e. drawn from > the same pool)? > > Take care, > > Bill > From owner-ips@ece.cmu.edu Wed Jun 19 14:06:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29503 for ; Wed, 19 Jun 2002 14:05:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5JHV4m03013 for ips-outgoing; Wed, 19 Jun 2002 13:31:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5JHV1w03008 for ; Wed, 19 Jun 2002 13:31:01 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id ABD0FBCE6; Wed, 19 Jun 2002 11:31:00 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 2A8EE1B2; Wed, 19 Jun 2002 11:31:00 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 19 Jun 2002 11:30:59 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Jun 2002 11:30:59 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C8918F2@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: Emailing: msg10855.txt Date: Wed, 19 Jun 2002 11:30:57 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-aacedc6c-525d-4bfb-81c8-4e55c333dcb0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-aacedc6c-525d-4bfb-81c8-4e55c333dcb0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C217B7.126A0FF0" ------_=_NextPart_001_01C217B7.126A0FF0 Content-Type: text/plain; charset="iso-8859-1" Julian, I don't think it is a misreading of the text. I will try restating the question. You say below "the barrier "stays" while the connection is operational and will be "removed" if the connection goes away. Does "the connection goes away" mean that the connection state machine leaves S5: LOGGED_IN state or does it mean that the connection state machine has returned to S1: FREE state? Pat -----Original Message----- From: Juian Satran (Hotmail) [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 19, 2002 8:41 AM To: ips Cc: Juian Satran (Hotmail) Subject: Emailing: msg10855.txt Pat, Your "issue" with operational is probably related to a missreading of the text. The barrier (dissalow wrapping) is on CmdSN. CmdSN advances accross al connections but the barrier "stays" while the connection is operational and will be "removed" if the connection goes away. The barrier is there to avoid stale commands popping-up at the target after a recovery. Julo ------_=_NextPart_001_01C217B7.126A0FF0 Content-Type: text/html; charset="iso-8859-1"

Julian,
 
I don't think it is a misreading of the text. I will try restating the question.
 
You say below "the barrier "stays"  while the connection is operational and will be "removed" if the connection goes away.
 
Does "the connection goes away" mean that the connection state machine leaves S5: LOGGED_IN state or does it mean that the connection state machine has returned to S1: FREE state?
 
Pat
 
 
-----Original Message-----
From: Juian Satran (Hotmail) [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 19, 2002 8:41 AM
To: ips
Cc: Juian Satran (Hotmail)
Subject: Emailing: msg10855.txt

Pat,
 
Your "issue" with operational is probably related to a missreading of the text.
The barrier (dissalow wrapping) is on CmdSN. CmdSN advances accross al connections  but the barrier "stays"  while the connection is operational and will be "removed" if the connection goes away.
The barrier is there to avoid stale commands popping-up at the target after a recovery.
 
Julo
------_=_NextPart_001_01C217B7.126A0FF0-- ------=_NextPartTM-000-aacedc6c-525d-4bfb-81c8-4e55c333dcb0-- From owner-ips@ece.cmu.edu Wed Jun 19 14:06:51 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29539 for ; Wed, 19 Jun 2002 14:06:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5JHPId02665 for ips-outgoing; Wed, 19 Jun 2002 13:25:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5JHPGw02661 for ; Wed, 19 Jun 2002 13:25:16 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id E12DBB612; Wed, 19 Jun 2002 11:25:15 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 86F9128F; Wed, 19 Jun 2002 11:25:15 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 19 Jun 2002 11:25:14 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Jun 2002 11:25:14 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C8918EF@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@actcom.net.il, ips@ece.cmu.edu Subject: RE: iSCSI - Sendtargets Date: Wed, 19 Jun 2002 11:25:13 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-0c364eef-de5f-4fb6-bba8-92e9d4787063" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-0c364eef-de5f-4fb6-bba8-92e9d4787063 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C217B6.45886A90" ------_=_NextPart_001_01C217B6.45886A90 Content-Type: text/plain; charset="iso-8859-1" Julian, We don't need to mandate the F bit, but it currently isn't clear whether it can be sent only once or more than once per negotiaiton. I would be happy with an explicit clarification of that - which could be covered by the change for the other string on negotiating a parameter more than once. Pat -----Original Message----- From: Julo-Actcom [mailto:Julian_Satran@actcom.net.il] Sent: Tuesday, June 18, 2002 10:17 PM To: ips@ece.cmu.edu Subject: iSCSI - Sendtargets Pat, I don't see why we have to say something specific about SendTargets. It should be sent only once during a negotiiation. Why should we mandate the F bit? Julo _____ * To: Julian_Satran@il.ibm.com * Subject: RE: iSCSI: Negotiating a parameter more than once * From: "THALER,PAT (A-Roseville,ex1)" < pat_thaler@agilent.com > * Date: Mon, 17 Jun 2002 17:05:18 -0600 * Cc: ips@ece.cmu.edu * Content-Type: text/plain;charset="ISO-8859-1" * Sender: owner-ips@ece.cmu.edu _____ Julian, It also isn't clear whether SendTargets can be sent more than once during a negotiation sequence. It would be reasonable for the Initiator to set the F bit when it sends SendTargets and then when the Target sets the F bit the initiator will know that the response is complete. However if SendTargets isn't covered by the limitation on negotiating a parameter only once per negotiation sequence, an initiator could also leave the F bit at zero, assume the response is done when it gets a response with an empty text field, and send SendTargets again later in the same negotiation sequence. An initiatior could even send a single PDU with something like: SendTargets=; SendTargets=; SendTargets=. There doesn't seem to be anything in Appendix D to say which of these is intended. The first possibility - allowing SendTargets to be sent only once during a negotiation sequence - seems adequate and simpler. Pat -----Original Message----- From: pat_thaler@agilent.com [ mailto:pat_thaler@agilent.com ] Sent: Monday, June 17, 2002 3:19 PM To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: iSCSI: Negotiating a parameter more than once Julian, The following text appears in 4.3 (page 78 just before 4.3.1): Neither the initiator nor the target should attempt to negotiate a parameter more than once during login. If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection. and nearly the same text in 4.4 (page 85 near the end): Neither the initiator nor the target should attempt to negotiate a parameter more than once during any negotiation sequence without an intervening reset. If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above. This is confusing partly because "negotiate" seems to be generally used covering both negotiations and declarations and in some cases covering only negotiations. It isn't clear in which sense it is used. If the text above applies only to negotiated values, then it would be allowable to send parameters such as Initiator Name, SessionType, and MaxRecvDataSegmentLength over which doesn't seem to be a good idea. However, there are other declarative parameters which are sent multiple times - SendTargets where there are multiple targets or multiple addresses for a target requires sending the same parameter multiple times. Perhaps the text should be changed to: Neither the initiator nor the target should attempt to declare or negotiate a parameter other than TargetName, TargetAlias or TargetAddress more than once.... Regards, Pat _____ * Prev by Date: iSCSI: Negotiating a parameter more than once * Next by Date: RE: iSCSI: Negotiating a parameter more than once * Prev by thread: iSCSI: Negotiating a parameter more than once * Next by thread: RE: iSCSI: Negotiating a parameter more than once * Index(es): * Date * Thread _____ Home Last updated: Mon Jun 17 20:18:42 2002 10865 messages in chronological order ------_=_NextPart_001_01C217B6.45886A90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Julian,
 
We = don't need to=20 mandate the F bit, but it currently isn't clear whether it can be sent = only once=20 or more than once per negotiaiton. I would be happy with an explicit=20 clarification of that - which could be covered by the change for the = other=20 string on negotiating a parameter more than once.
 
Pat
-----Original Message-----
From: Julo-Actcom=20 [mailto:Julian_Satran@actcom.net.il]
Sent: Tuesday, June 18, = 2002=20 10:17 PM
To: ips@ece.cmu.edu
Subject: iSCSI -=20 Sendtargets

Pat,
 
I don't see why we have to say = something specific=20 about SendTargets.
It should be sent only once during a=20 negotiiation.
 
Why should we mandate the F = bit?
 
Julo
 
  • To: Julian_Satran@il.ibm.com=20
  • Subject: RE: iSCSI: Negotiating a = parameter more=20 than once=20
  • From: "THALER,PAT (A-Roseville,ex1)" = <pat_thaler@agilent.com>=20
  • Date: Mon, 17 Jun 2002 17:05:18 -0600=20
  • Cc: ips@ece.cmu.edu=20
  • Content-Type: text/plain;charset=3D"ISO-8859-1"=20
  • Sender: owner-ips@ece.cmu.edu=20 
Julian,

It also isn't clear whether SendTargets can be sent more than once =
during a negotiation sequence.

It would be reasonable for the Initiator to set the F bit when it sends =
SendTargets and then when the Target sets the F bit the initiator will =
know that the response is complete. However if SendTargets isn't =
covered by the limitation on negotiating a parameter only once per =
negotiation sequence, an initiator could also leave the F bit at zero, =
assume the response is done when it gets a response with an empty text =
field, and send SendTargets again later in the same negotiation =
sequence. An initiatior could even send a single PDU with something =
like: SendTargets=3D<iSCSI-target-name-A>; =
SendTargets=3D<iSCSI-target-name-B>; =
SendTargets=3D<iSCSI-target-name-C>.=20

There doesn't seem to be anything in Appendix D to say which of these =
is intended. The first possibility - allowing SendTargets to be sent =
only once during a negotiation sequence - seems adequate and simpler.

Pat

-----Original Message-----
From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com=
]
Sent: Monday, June 17, 2002 3:19 PM
To: Julian_Satran@il.ibm.com
Cc: ips@ece.cmu.edu
Subject: iSCSI: Negotiating a parameter more than once


Julian,

The following text appears in 4.3 (page 78 just before 4.3.1):

Neither the initiator nor the target should attempt to negotiate a
parameter more than once during login. If detected by the target this
MUST result in a Login reject (initiator error). The initiator MUST
drop the connection.

and nearly the same text in 4.4 (page 85 near the end):

Neither the initiator nor the target should attempt to negotiate a
parameter more than once during any negotiation sequence without an
intervening reset. If detected by the target this MUST result in a
Reject with a reason of "protocol error". The initiator MUST reset
the negotiation as outlined above.

This is confusing partly because "negotiate" seems to be generally used =
covering both negotiations and declarations and in some cases covering =
only negotiations. It isn't clear in which sense it is used. If the =
text above applies only to negotiated values, then it would be =
allowable to send parameters such as Initiator Name, SessionType, and =
MaxRecvDataSegmentLength over which doesn't seem to be a good idea. =
However, there are other declarative parameters which are sent multiple =
times - SendTargets where there are multiple targets or multiple =
addresses for a target requires sending the same parameter multiple =
times.=20

Perhaps the text should be changed to:

Neither the initiator nor the target should attempt to declare or =
negotiate a
parameter other than TargetName, TargetAlias or TargetAddress more than =
once....

Regards,
Pat
  • Prev by Date: iSCS= I:=20 Negotiating a parameter more than once=20
  • Next by Date: RE: = iSCSI:=20 Negotiating a parameter more than once=20
  • Prev by thread: iSCS= I:=20 Negotiating a parameter more than once=20
  • Next by thread: RE: = iSCSI:=20 Negotiating a parameter more than once=20
  • Index(es):=20
    • Date=20
    • Thread=20

Home

Last updated: Mon Jun 17 20:18:42 2002
10865 messages in=20 chronological order
------_=_NextPart_001_01C217B6.45886A90-- ------=_NextPartTM-000-0c364eef-de5f-4fb6-bba8-92e9d4787063-- From owner-ips@ece.cmu.edu Wed Jun 19 14:07:17 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29556 for ; Wed, 19 Jun 2002 14:07:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5JHIuY02246 for ips-outgoing; Wed, 19 Jun 2002 13:18:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5JHIsw02240 for ; Wed, 19 Jun 2002 13:18:54 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 8D379676B; Wed, 19 Jun 2002 11:18:53 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 4BDEF1D94; Wed, 19 Jun 2002 11:18:53 -0600 (MDT) Received: from 130.29.152.143 by axcsbh1.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 19 Jun 2002 11:18:51 -0600 Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Jun 2002 11:18:51 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C8918E7@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Julo-Actcom , ips@ece.cmu.edu Subject: RE: iSCSI: Negotiating a parameter more than once Date: Wed, 19 Jun 2002 11:18:44 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-3fbc798a-83a2-11d6-bae4-009027404a4a" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-3fbc798a-83a2-11d6-bae4-009027404a4a Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C217B5.5D9D6230" ------_=_NextPart_001_01C217B5.5D9D6230 Content-Type: text/plain; charset="ISO-8859-1" Julian, If declarations should not be repeated (except for those where it is explicitly allowed), then it should be "negotiate or declare" because "negotiate" doesn't cover declarations. Alternatively, one could add an explicit definition that "Negotiate" includes both declarations and negotiations. Secondly, SendTargets is not a valid example for login as it is FFPO. I think the only parameter explicitly allowed to be duplicated during Login is TargetAddress (when returned as a result of a redirect). Furthermore, I can not find any explicit statement that SendTargets may be repeated during a FFP negotiation sequence. Only TargetName and TargetAddress have explicit text allowing them to be repeated (in Appendix B for both and in the description of redirection for LoginResponse for TargetAddress). Therefore, I suggest: For 4.3: Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during login except for responses to specific keys that explicitly allow repeated key declarations (e.g. TargetAddress). If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection For 4.4: Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during any negotiation sequence without an intervening reset except for responses to specific keys that explicitly allow repeated key declarations (e.g. TargetAddress). If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above. Pat -----Original Message----- From: Julo-Actcom [mailto:Julian_Satran@actcom.net.il] Sent: Tuesday, June 18, 2002 10:12 PM To: ips@ece.cmu.edu Subject: RE: iSCSI: Negotiating a parameter more than once Pat, 4.3 and 4.4 cover two diferent phases. Parameters should not be negotiated or declared twice. I think that you refer to the responses to SendTargets - those contain more than an instance of the declarations and have to outlined. How about the following text in 4.4: Neither the initiator nor the target should attempt to negotiate a parameter more than once during login except for responses to specific keys that explicitly allow repeated key declarations (e.g. SendTargets). If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection. and in 4.4: Neither the initiator nor the target should attempt to negotiate a parameter more than once during any negotiation sequence without an intervening reset except for responses to specific keys that explicitly allow repeated key declarations. If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above. Julo _____ * To: Julian_Satran@il.ibm.com * Subject: iSCSI: Negotiating a parameter more than once * From: pat_thaler@agilent.com * Date: Mon, 17 Jun 2002 16:18:43 -0600 * Cc: ips@ece.cmu.edu * Content-Type: text/plain;charset="ISO-8859-1" * Sender: owner-ips@ece.cmu.edu _____ Julian, The following text appears in 4.3 (page 78 just before 4.3.1): Neither the initiator nor the target should attempt to negotiate a parameter more than once during login. If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection. and nearly the same text in 4.4 (page 85 near the end): Neither the initiator nor the target should attempt to negotiate a parameter more than once during any negotiation sequence without an intervening reset. If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above. This is confusing partly because "negotiate" seems to be generally used covering both negotiations and declarations and in some cases covering only negotiations. It isn't clear in which sense it is used. If the text above applies only to negotiated values, then it would be allowable to send parameters such as Initiator Name, SessionType, and MaxRecvDataSegmentLength over which doesn't seem to be a good idea. However, there are other declarative parameters which are sent multiple times - SendTargets where there are multiple targets or multiple addresses for a target requires sending the same parameter multiple times. Perhaps the text should be changed to: Neither the initiator nor the target should attempt to declare or negotiate a parameter other than TargetName, TargetAlias or TargetAddress more than once.... Regards, Pat _____ * Prev by Date: RE: iSCSI: use of Text/Login with no data segment * Next by Date: RE: iSCSI: Negotiating a parameter more than once * Prev by thread: iSCSI 0.13 vs. iSCSI Plugfest * Next by thread: RE: iSCSI: Negotiating a parameter more than once * Index(es): * Date * Thread ------_=_NextPart_001_01C217B5.5D9D6230 Content-Type: text/html; charset="ISO-8859-1"
Julian,
 
If declarations should not be repeated (except for those where it is explicitly allowed), then it should be "negotiate or declare" because "negotiate" doesn't cover declarations. Alternatively, one could add an explicit definition that "Negotiate" includes both declarations and negotiations. Secondly, SendTargets is not a valid example for login as it is FFPO. I think the only parameter explicitly allowed to be duplicated during Login is TargetAddress (when returned as a result of a redirect). Furthermore, I can not find any explicit statement that SendTargets may be repeated during a FFP negotiation sequence. Only TargetName and TargetAddress have explicit text allowing them to be repeated (in Appendix B for both and in the description of redirection for LoginResponse for TargetAddress).
 
Therefore, I suggest:
For 4.3:
Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during login except for responses to specific keys that explicitly allow repeated key declarations (e.g. TargetAddress). If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection
 
For 4.4:
Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during any negotiation sequence without an intervening reset except for responses to specific keys that explicitly allow repeated key declarations (e.g. TargetAddress). If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above.
 
Pat
-----Original Message-----
From: Julo-Actcom [mailto:Julian_Satran@actcom.net.il]
Sent: Tuesday, June 18, 2002 10:12 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI: Negotiating a parameter more than once

Pat,
 
4.3 and 4.4 cover two diferent phases.
Parameters should not be negotiated or declared twice.
 
I think that you refer to the responses to SendTargets - those contain more than an instance of the declarations and have to outlined.
 
How about the following text in 4.4:
 

Neither the initiator nor the target should attempt to negotiate a parameter more than once during login except for responses to specific keys that explicitly allow repeated key declarations (e.g. SendTargets). If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection.

 

and in 4.4:

 

Neither the initiator nor the target should attempt to negotiate a parameter more than once during any negotiation sequence without an intervening reset except for responses to specific keys that explicitly allow repeated key declarations. If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above.
Julo
Julian,

The following text appears in 4.3 (page 78 just before 4.3.1):

Neither the initiator nor the target should attempt to negotiate a
parameter more than once during login. If detected by the target this
MUST result in a Login reject (initiator error). The initiator MUST
drop the connection.

and nearly the same text in 4.4 (page 85 near the end):

Neither the initiator nor the target should attempt to negotiate a
parameter more than once during any negotiation sequence without an
intervening reset. If detected by the target this MUST result in a
Reject with a reason of "protocol error". The initiator MUST reset
the negotiation as outlined above.

This is confusing partly because "negotiate" seems to be generally used covering both negotiations and declarations and in some cases covering only negotiations. It isn't clear in which sense it is used. If the text above applies only to negotiated values, then it would be allowable to send parameters such as Initiator Name, SessionType, and MaxRecvDataSegmentLength over which doesn't seem to be a good idea. However, there are other declarative parameters which are sent multiple times - SendTargets where there are multiple targets or multiple addresses for a target requires sending the same parameter multiple times. 

Perhaps the text should be changed to:

Neither the initiator nor the target should attempt to declare or negotiate a
parameter other than TargetName, TargetAlias or TargetAddress more than once....

Regards,
Pat
------_=_NextPart_001_01C217B5.5D9D6230-- ------=_NextPartTM-000-3fbc798a-83a2-11d6-bae4-009027404a4a-- From owner-ips@ece.cmu.edu Wed Jun 19 15:25:32 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01536 for ; Wed, 19 Jun 2002 15:25:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5JJ03j08004 for ips-outgoing; Wed, 19 Jun 2002 15:00:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5JIxuw07983 for ; Wed, 19 Jun 2002 14:59:56 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5JIxlKf065232; Wed, 19 Jun 2002 20:59:47 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5JIxkc26012; Wed, 19 Jun 2002 20:59:46 +0200 MIME-Version: 1.0 To: "THALER,PAT (A-Roseville,ex1)" Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Negotiating a parameter more than once X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 19 Jun 2002 21:59:40 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 19/06/2002 21:59:46, Serialize complete at 19/06/2002 21:59:46 Content-Type: multipart/alternative; boundary="=_alternative 00657271C2256BDD_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00657271C2256BDD_= Content-Type: text/plain; charset="us-ascii" OK Julo "THALER,PAT (A-Roseville,ex1)" Sent by: owner-ips@ece.cmu.edu 06/19/2002 08:18 PM Please respond to "THALER,PAT (A-Roseville,ex1)" To: Julo-Actcom , ips@ece.cmu.edu cc: Subject: RE: iSCSI: Negotiating a parameter more than once Julian, If declarations should not be repeated (except for those where it is explicitly allowed), then it should be "negotiate or declare" because "negotiate" doesn't cover declarations. Alternatively, one could add an explicit definition that "Negotiate" includes both declarations and negotiations. Secondly, SendTargets is not a valid example for login as it is FFPO. I think the only parameter explicitly allowed to be duplicated during Login is TargetAddress (when returned as a result of a redirect). Furthermore, I can not find any explicit statement that SendTargets may be repeated during a FFP negotiation sequence. Only TargetName and TargetAddress have explicit text allowing them to be repeated (in Appendix B for both and in the description of redirection for LoginResponse for TargetAddress). Therefore, I suggest: For 4.3: Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during login except for responses to specific keys that explicitly allow repeated key declarations (e.g. TargetAddress). If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection For 4.4: Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during any negotiation sequence without an intervening reset except for responses to specific keys that explicitly allow repeated key declarations (e.g. TargetAddress). If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above. Pat -----Original Message----- From: Julo-Actcom [mailto:Julian_Satran@actcom.net.il] Sent: Tuesday, June 18, 2002 10:12 PM To: ips@ece.cmu.edu Subject: RE: iSCSI: Negotiating a parameter more than once Pat, 4.3 and 4.4 cover two diferent phases. Parameters should not be negotiated or declared twice. I think that you refer to the responses to SendTargets - those contain more than an instance of the declarations and have to outlined. How about the following text in 4.4: Neither the initiator nor the target should attempt to negotiate a parameter more than once during login except for responses to specific keys that explicitly allow repeated key declarations (e.g. SendTargets). If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection. and in 4.4: Neither the initiator nor the target should attempt to negotiate a parameter more than once during any negotiation sequence without an intervening reset except for responses to specific keys that explicitly allow repeated key declarations. If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above. Julo To: Julian_Satran@il.ibm.com Subject: iSCSI: Negotiating a parameter more than once From: pat_thaler@agilent.com Date: Mon, 17 Jun 2002 16:18:43 -0600 Cc: ips@ece.cmu.edu Content-Type: text/plain;charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Julian, The following text appears in 4.3 (page 78 just before 4.3.1): Neither the initiator nor the target should attempt to negotiate a parameter more than once during login. If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection. and nearly the same text in 4.4 (page 85 near the end): Neither the initiator nor the target should attempt to negotiate a parameter more than once during any negotiation sequence without an intervening reset. If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above. This is confusing partly because "negotiate" seems to be generally used covering both negotiations and declarations and in some cases covering only negotiations. It isn't clear in which sense it is used. If the text above applies only to negotiated values, then it would be allowable to send parameters such as Initiator Name, SessionType, and MaxRecvDataSegmentLength over which doesn't seem to be a good idea. However, there are other declarative parameters which are sent multiple times - SendTargets where there are multiple targets or multiple addresses for a target requires sending the same parameter multiple times. Perhaps the text should be changed to: Neither the initiator nor the target should attempt to declare or negotiate a parameter other than TargetName, TargetAlias or TargetAddress more than once.... Regards, Pat Prev by Date: RE: iSCSI: use of Text/Login with no data segment Next by Date: RE: iSCSI: Negotiating a parameter more than once Prev by thread: iSCSI 0.13 vs. iSCSI Plugfest Next by thread: RE: iSCSI: Negotiating a parameter more than once Index(es): Date Thread --=_alternative 00657271C2256BDD_= Content-Type: text/html; charset="us-ascii"
OK Julo


"THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>
Sent by: owner-ips@ece.cmu.edu

06/19/2002 08:18 PM
Please respond to "THALER,PAT (A-Roseville,ex1)"

       
        To:        Julo-Actcom <Julian_Satran@actcom.net.il>, ips@ece.cmu.edu
        cc:        
        Subject:        RE: iSCSI: Negotiating a parameter more than once

       


Julian,
 
If declarations should not be repeated (except for those where it is explicitly allowed), then it should be "negotiate or declare" because "negotiate" doesn't cover declarations. Alternatively, one could add an explicit definition that "Negotiate" includes both declarations and negotiations. Secondly, SendTargets is not a valid example for login as it is FFPO. I think the only parameter explicitly allowed to be duplicated during Login is TargetAddress (when returned as a result of a redirect). Furthermore, I can not find any explicit statement that SendTargets may be repeated during a FFP negotiation sequence. Only TargetName and TargetAddress have explicit text allowing them to be repeated (in Appendix B for both and in the description of redirection for LoginResponse for TargetAddress).
 
Therefore, I suggest:
For 4.3:
Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during login except for responses to specific keys that explicitly allow repeated key declarations (e.g. TargetAddress). If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection
 
For 4.4:
Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during any negotiation sequence without an intervening reset except for responses to specific keys that explicitly allow repeated key declarations (e.g. TargetAddress). If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above.
 
Pat
-----Original Message-----
From: Julo-Actcom [mailto:Julian_Satran@actcom.net.il]
Sent: Tuesday, June 18, 2002 10:12 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI: Negotiating a parameter more than once
Pat,
 
4.3 and 4.4 cover two diferent phases.
Parameters should not be negotiated or declared twice.
 
I think that you refer to the responses to SendTargets - those contain more than an instance of the declarations and have to outlined.
 
How about the following text in 4.4:
 

Neither the initiator nor the target should attempt to negotiate a parameter more than once during login except for responses to specific keys that explicitly allow repeated key declarations (e.g. SendTargets). If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection.

 

and in 4.4:

 

Neither the initiator nor the target should attempt to negotiate a parameter more than once during any negotiation sequence without an intervening reset except for responses to specific keys that explicitly allow repeated key declarations. If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above.

Julo

  • To: Julian_Satran@il.ibm.com
  • Subject: iSCSI: Negotiating a parameter more than once
  • From: pat_thaler@agilent.com
  • Date: Mon, 17 Jun 2002 16:18:43 -0600
  • Cc: ips@ece.cmu.edu
  • Content-Type: text/plain;charset="ISO-8859-1"
  • Sender: owner-ips@ece.cmu.edu

    Julian,

    The following text appears in 4.3 (page 78 just before 4.3.1):

    Neither the initiator nor the target should attempt to negotiate a
    parameter more than once during login. If detected by the target this
    MUST result in a Login reject (initiator error). The initiator MUST
    drop the connection.

    and nearly the same text in 4.4 (page 85 near the end):

    Neither the initiator nor the target should attempt to negotiate a
    parameter more than once during any negotiation sequence without an
    intervening reset. If detected by the target this MUST result in a
    Reject with a reason of "protocol error". The initiator MUST reset
    the negotiation as outlined above.

    This is confusing partly because "negotiate" seems to be generally used covering both negotiations and declarations and in some cases covering only negotiations. It isn't clear in which sense it is used. If the text above applies only to negotiated values, then it would be allowable to send parameters such as Initiator Name, SessionType, and MaxRecvDataSegmentLength over which doesn't seem to be a good idea. However, there are other declarative parameters which are sent multiple times - SendTargets where there are multiple targets or multiple addresses for a target requires sending the same parameter multiple times.

    Perhaps the text should be changed to:

    Neither the initiator nor the target should attempt to declare or negotiate a
    parameter other than TargetName, TargetAlias or TargetAddress more than once....

    Regards,
    Pat
--=_alternative 00657271C2256BDD_=-- From owner-ips@ece.cmu.edu Wed Jun 19 15:25:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01550 for ; Wed, 19 Jun 2002 15:25:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5JIxxd07992 for ips-outgoing; Wed, 19 Jun 2002 14:59:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5JIxvw07984 for ; Wed, 19 Jun 2002 14:59:57 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5JIxmKf065234; Wed, 19 Jun 2002 20:59:48 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5JIxlc26014; Wed, 19 Jun 2002 20:59:47 +0200 To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: Emailing: msg10855.txt X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 19 Jun 2002 21:59:42 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 19/06/2002 21:59:47, Serialize complete at 19/06/2002 21:59:47 Content-Type: multipart/alternative; boundary="=_alternative 00669C19C2256BDD_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00669C19C2256BDD_= Content-Type: text/plain; charset="us-ascii" I mean S1. S5 is not "fully synchronized" - stale commands getting out at the target while the initiator logs out may be perceive as within a valid window (a very improbable event but possible nevertheless). Julo pat_thaler@agilent.com 06/19/2002 08:30 PM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: Emailing: msg10855.txt Julian, I don't think it is a misreading of the text. I will try restating the question. You say below "the barrier "stays" while the connection is operational and will be "removed" if the connection goes away. Does "the connection goes away" mean that the connection state machine leaves S5: LOGGED_IN state or does it mean that the connection state machine has returned to S1: FREE state? Pat -----Original Message----- From: Juian Satran (Hotmail) [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 19, 2002 8:41 AM To: ips Cc: Juian Satran (Hotmail) Subject: Emailing: msg10855.txt Pat, Your "issue" with operational is probably related to a missreading of the text. The barrier (dissalow wrapping) is on CmdSN. CmdSN advances accross al connections but the barrier "stays" while the connection is operational and will be "removed" if the connection goes away. The barrier is there to avoid stale commands popping-up at the target after a recovery. Julo --=_alternative 00669C19C2256BDD_= Content-Type: text/html; charset="us-ascii"
I mean S1.   S5 is not "fully synchronized" - stale commands getting out at the target while the initiator logs out may  be perceive as within a valid window (a very improbable event but possible nevertheless).

Julo


pat_thaler@agilent.com

06/19/2002 08:30 PM
Please respond to pat_thaler

       
        To:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
        cc:        
        Subject:        RE: Emailing: msg10855.txt

       


Julian,
 
I don't think it is a misreading of the text. I will try restating the question.
 
You say below "the barrier "stays"  while the connection is operational and will be "removed" if the connection goes away.
 
Does "the connection goes away" mean that the connection state machine leaves S5: LOGGED_IN state or does it mean that the connection state machine has returned to S1: FREE state?
 
Pat
 
 
-----Original Message-----
From: Juian Satran (Hotmail) [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 19, 2002 8:41 AM
To: ips
Cc: Juian Satran (Hotmail)
Subject: Emailing: msg10855.txt
Pat,
 
Your "issue" with operational is probably related to a missreading of the text.
The barrier (dissalow wrapping) is on CmdSN. CmdSN advances accross al connections  but the barrier "stays"  while the connection is operational and will be "removed" if the connection goes away.
The barrier is there to avoid stale commands popping-up at the target after a recovery.
 
Julo

--=_alternative 00669C19C2256BDD_=-- From owner-ips@ece.cmu.edu Wed Jun 19 15:28:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01632 for ; Wed, 19 Jun 2002 15:27:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5JIVra06456 for ips-outgoing; Wed, 19 Jun 2002 14:31:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5JIVpw06451 for ; Wed, 19 Jun 2002 14:31:51 -0400 (EDT) Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel9.hp.com (Postfix) with ESMTP id EA57F8050C3; Sat, 22 Jun 2002 17:23:12 -0400 (EDT) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 1E3F14000AB; Wed, 19 Jun 2002 14:31:44 -0400 (EDT) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Jun 2002 14:31:43 -0400 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF674@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'THALER,PAT (A-Roseville,ex1)'" , Julo-Actcom , ips@ece.cmu.edu Subject: RE: iSCSI: Negotiating a parameter more than once Date: Wed, 19 Jun 2002 14:31:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C217BF.8E1D6A40" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C217BF.8E1D6A40 Content-Type: text/plain; charset="iso-8859-1" In the context of the two keys that are valid during FFP, neither of these suggested edits to that paragraph make sense. Currently, there is no "negotiation" key that's valid in FFP, and the "declarative" keys that are valid, - SendTargets and MaxPDUDataLength *can* validly be repeated. If an initiator opens a discovery session, it may keep it open, and it may repeat SendTargets requests as it deems necessary to keep it's target information up to date. In the course of a SendTargets response, the target validly repeats certain keys. The MaxPDUDataLength key can be sent by the initiator as often as the PMTU changes. Why not just delete this paragraph? In the future if there are keys added that are valid during FFP, the RFC that specifies those keys can specify whether or not they can be "renegotiated". Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard -----Original Message----- From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@agilent.com] Sent: Wednesday, June 19, 2002 10:19 AM To: Julo-Actcom; ips@ece.cmu.edu Subject: RE: iSCSI: Negotiating a parameter more than once Julian, If declarations should not be repeated (except for those where it is explicitly allowed), then it should be "negotiate or declare" because "negotiate" doesn't cover declarations. Alternatively, one could add an explicit definition that "Negotiate" includes both declarations and negotiations. Secondly, SendTargets is not a valid example for login as it is FFPO. I think the only parameter explicitly allowed to be duplicated during Login is TargetAddress (when returned as a result of a redirect). Furthermore, I can not find any explicit statement that SendTargets may be repeated during a FFP negotiation sequence. Only TargetName and TargetAddress have explicit text allowing them to be repeated (in Appendix B for both and in the description of redirection for LoginResponse for TargetAddress). Therefore, I suggest: For 4.3: Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during login except for responses to specific keys that explicitly allow repeated key declarations (e.g. TargetAddress). If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection For 4.4: Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during any negotiation sequence without an intervening reset except for responses to specific keys that explicitly allow repeated key declarations (e.g. TargetAddress). If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above. Pat -----Original Message----- From: Julo-Actcom [mailto:Julian_Satran@actcom.net.il] Sent: Tuesday, June 18, 2002 10:12 PM To: ips@ece.cmu.edu Subject: RE: iSCSI: Negotiating a parameter more than once Pat, 4.3 and 4.4 cover two diferent phases. Parameters should not be negotiated or declared twice. I think that you refer to the responses to SendTargets - those contain more than an instance of the declarations and have to outlined. How about the following text in 4.4: Neither the initiator nor the target should attempt to negotiate a parameter more than once during login except for responses to specific keys that explicitly allow repeated key declarations (e.g. SendTargets). If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection. and in 4.4: Neither the initiator nor the target should attempt to negotiate a parameter more than once during any negotiation sequence without an intervening reset except for responses to specific keys that explicitly allow repeated key declarations. If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above. Julo _____ * To: Julian_Satran@il.ibm.com * Subject: iSCSI: Negotiating a parameter more than once * From: pat_thaler@agilent.com * Date: Mon, 17 Jun 2002 16:18:43 -0600 * Cc: ips@ece.cmu.edu * Content-Type: text/plain;charset="ISO-8859-1" * Sender: owner-ips@ece.cmu.edu _____ Julian, The following text appears in 4.3 (page 78 just before 4.3.1): Neither the initiator nor the target should attempt to negotiate a parameter more than once during login. If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection. and nearly the same text in 4.4 (page 85 near the end): Neither the initiator nor the target should attempt to negotiate a parameter more than once during any negotiation sequence without an intervening reset. If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above. This is confusing partly because "negotiate" seems to be generally used covering both negotiations and declarations and in some cases covering only negotiations. It isn't clear in which sense it is used. If the text above applies only to negotiated values, then it would be allowable to send parameters such as Initiator Name, SessionType, and MaxRecvDataSegmentLength over which doesn't seem to be a good idea. However, there are other declarative parameters which are sent multiple times - SendTargets where there are multiple targets or multiple addresses for a target requires sending the same parameter multiple times. Perhaps the text should be changed to: Neither the initiator nor the target should attempt to declare or negotiate a parameter other than TargetName, TargetAlias or TargetAddress more than once.... Regards, Pat _____ * Prev by Date: RE: iSCSI: use of Text/Login with no data segment * Next by Date: RE: iSCSI: Negotiating a parameter more than once * Prev by thread: iSCSI 0.13 vs. iSCSI Plugfest * Next by thread: RE: iSCSI: Negotiating a parameter more than once * Index(es): * Date * Thread ------_=_NextPart_001_01C217BF.8E1D6A40 Content-Type: text/html; charset="iso-8859-1"
In the context of the two keys that are valid during FFP, neither of these suggested edits to that paragraph make sense.  Currently, there is no "negotiation" key that's valid in FFP, and the "declarative" keys that are valid, - SendTargets and MaxPDUDataLength *can* validly be repeated.  If an initiator opens a discovery session, it may keep it open, and it may repeat SendTargets requests as it deems necessary to keep it's target information up to date.  In the course of a SendTargets response, the target validly repeats certain keys.  The MaxPDUDataLength key can be sent by the initiator as often as the PMTU changes.
 
Why not just delete this paragraph?  In the future if there are keys added that are valid during FFP, the RFC that specifies those keys can specify whether or not they can be "renegotiated".
 
Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
 
-----Original Message-----
From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@agilent.com]
Sent: Wednesday, June 19, 2002 10:19 AM
To: Julo-Actcom; ips@ece.cmu.edu
Subject: RE: iSCSI: Negotiating a parameter more than once

Julian,
 
If declarations should not be repeated (except for those where it is explicitly allowed), then it should be "negotiate or declare" because "negotiate" doesn't cover declarations. Alternatively, one could add an explicit definition that "Negotiate" includes both declarations and negotiations. Secondly, SendTargets is not a valid example for login as it is FFPO. I think the only parameter explicitly allowed to be duplicated during Login is TargetAddress (when returned as a result of a redirect). Furthermore, I can not find any explicit statement that SendTargets may be repeated during a FFP negotiation sequence. Only TargetName and TargetAddress have explicit text allowing them to be repeated (in Appendix B for both and in the description of redirection for LoginResponse for TargetAddress).
 
Therefore, I suggest:
For 4.3:
Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during login except for responses to specific keys that explicitly allow repeated key declarations (e.g. TargetAddress). If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection
 
For 4.4:
Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during any negotiation sequence without an intervening reset except for responses to specific keys that explicitly allow repeated key declarations (e.g. TargetAddress). If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above.
 
Pat
-----Original Message-----
From: Julo-Actcom [mailto:Julian_Satran@actcom.net.il]
Sent: Tuesday, June 18, 2002 10:12 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI: Negotiating a parameter more than once

Pat,
 
4.3 and 4.4 cover two diferent phases.
Parameters should not be negotiated or declared twice.
 
I think that you refer to the responses to SendTargets - those contain more than an instance of the declarations and have to outlined.
 
How about the following text in 4.4:
 

Neither the initiator nor the target should attempt to negotiate a parameter more than once during login except for responses to specific keys that explicitly allow repeated key declarations (e.g. SendTargets). If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection.

 

and in 4.4:

 

Neither the initiator nor the target should attempt to negotiate a parameter more than once during any negotiation sequence without an intervening reset except for responses to specific keys that explicitly allow repeated key declarations. If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above.
Julo
Julian,

The following text appears in 4.3 (page 78 just before 4.3.1):

Neither the initiator nor the target should attempt to negotiate a
parameter more than once during login. If detected by the target this
MUST result in a Login reject (initiator error). The initiator MUST
drop the connection.

and nearly the same text in 4.4 (page 85 near the end):

Neither the initiator nor the target should attempt to negotiate a
parameter more than once during any negotiation sequence without an
intervening reset. If detected by the target this MUST result in a
Reject with a reason of "protocol error". The initiator MUST reset
the negotiation as outlined above.

This is confusing partly because "negotiate" seems to be generally used covering both negotiations and declarations and in some cases covering only negotiations. It isn't clear in which sense it is used. If the text above applies only to negotiated values, then it would be allowable to send parameters such as Initiator Name, SessionType, and MaxRecvDataSegmentLength over which doesn't seem to be a good idea. However, there are other declarative parameters which are sent multiple times - SendTargets where there are multiple targets or multiple addresses for a target requires sending the same parameter multiple times. 

Perhaps the text should be changed to:

Neither the initiator nor the target should attempt to declare or negotiate a
parameter other than TargetName, TargetAlias or TargetAddress more than once....

Regards,
Pat
------_=_NextPart_001_01C217BF.8E1D6A40-- From owner-ips@ece.cmu.edu Wed Jun 19 16:41:55 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03027 for ; Wed, 19 Jun 2002 16:41:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5JK6gp11782 for ips-outgoing; Wed, 19 Jun 2002 16:06:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5JK6dw11775 for ; Wed, 19 Jun 2002 16:06:39 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel11.hp.com (Postfix) with ESMTP id 615D66002F3; Wed, 19 Jun 2002 13:06:33 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id NAA06886; Wed, 19 Jun 2002 13:08:22 -0700 (PDT) Message-ID: <00bf01c217cc$ce9da3c0$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Julian Satran" Cc: Subject: iSCSI: adding a new rule to section 5.2 Date: Wed, 19 Jun 2002 13:06:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, I suggest adding one new para to section 5.2 just before the sentence - "The following state diagram applies to both initiators and targets." The new para I suggest is: "An initiator must initiate an explicit or implicit connection logout for a connection in the CLEANUP_WAIT state, if the initiator intends to continue using the associated iSCSI session." The reason is: We don't want initiators sitting on failed connections for the (DefaultTime2Wait+DefaultTime2Retain) period even while using the session on other connections, and then assuming that the connection must had been freed up on the target. A target may not always see the connection failure that the initiator did, and may not have any TCP/iSCSI keep-alive to detect that the connection failed, so may continue to indefinitely keep the connection state around (and receive stale commands) without ever going through the connection state timeout path. The problem becomes clear if we look at the case where both timeouts were negotiated to be zero. Comments? Mallikarjun From owner-ips@ece.cmu.edu Wed Jun 19 16:44:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03069 for ; Wed, 19 Jun 2002 16:44:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5JJfBB10291 for ips-outgoing; Wed, 19 Jun 2002 15:41:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5JJf9w10287 for ; Wed, 19 Jun 2002 15:41:09 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel7.hp.com (Postfix) with ESMTP id DE0738054BC; Wed, 19 Jun 2002 15:40:59 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id MAA01928; Wed, 19 Jun 2002 12:42:49 -0700 (PDT) Message-ID: <00b301c217c9$3c8bb790$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: , , References: <1BEBA5E8600DD4119A50009027AF54A00C8918F2@axcs04.cos.agilent.com> Subject: Re: Emailing: msg10855.txt Date: Wed, 19 Jun 2002 12:40:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat, The answer is the latter - initiator connection state machine must return to S1 (FREE) before the barrier is removed. An explanation follows. The reason behind the rule was to ensure that a target doesn't see a stale command (which was in fact a retry of an old command delivered at just the wrong time). A target would continue to "see" commands arriving on a connection as long as the *target's* connection state machine is in LOGGED_IN (even after the initiator's connection state machine may have transitioned to CLEANUP_WAIT, say on a local NIC failure). For this reason, initiator must ensure that the connection state machine transitions to FREE (going through the connection cleanup state diagram), before advancing the CmdSN window. May be we should replace the phrase "if the connection is still operational," with "if the connection is in the LOGGED_IN state or the connection cleanup (see Section 5.2) is not complete,". Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: To: ; Sent: Wednesday, June 19, 2002 10:30 AM Subject: RE: Emailing: msg10855.txt > Julian, > > I don't think it is a misreading of the text. I will try restating the question. > > You say below "the barrier "stays" while the connection is operational and will be "removed" if the connection goes away. > > Does "the connection goes away" mean that the connection state machine leaves S5: LOGGED_IN state or does it mean that the connection state machine has returned to S1: FREE state? > > Pat > > > -----Original Message----- > From: Juian Satran (Hotmail) [mailto:Julian_Satran@il.ibm.com] > Sent: Wednesday, June 19, 2002 8:41 AM > To: ips > Cc: Juian Satran (Hotmail) > Subject: Emailing: msg10855.txt > > > Pat, > > Your "issue" with operational is probably related to a missreading of the text. > The barrier (dissalow wrapping) is on CmdSN. CmdSN advances accross al connections but the barrier "stays" while the connection is operational and will be "removed" if the connection goes away. > The barrier is there to avoid stale commands popping-up at the target after a recovery. > > Julo > From owner-ips@ece.cmu.edu Wed Jun 19 16:53:08 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03241 for ; Wed, 19 Jun 2002 16:53:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5JKT4u13259 for ips-outgoing; Wed, 19 Jun 2002 16:29:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13704.mail.yahoo.com (web13704.mail.yahoo.com [216.136.175.137]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g5JKT2w13255 for ; Wed, 19 Jun 2002 16:29:02 -0400 (EDT) Message-ID: <20020619202901.63765.qmail@web13704.mail.yahoo.com> Received: from [192.52.58.5] by web13704.mail.yahoo.com via HTTP; Wed, 19 Jun 2002 13:29:01 PDT Date: Wed, 19 Jun 2002 13:29:01 -0700 (PDT) From: Martins Krikis Subject: RE: iSCSI: Negotiating a parameter more than once To: "KRUEGER,MARJORIE \(HP-Roseville,ex1\)" , "'THALER,PAT \(A-Roseville,ex1\)'" , Julo-Actcom , ips@ece.cmu.edu In-Reply-To: <6BD67FFB937FD411A04F00D0B74FE87805CCF674@xrose06.rose.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk wrote: > In the context of the two keys that are valid during > FFP, neither of these > suggested edits to that paragraph make sense. > Currently, there is no > "negotiation" key that's valid in FFP, and the > "declarative" keys that are > valid, - SendTargets and MaxPDUDataLength *can* > validly be repeated. If an > initiator opens a discovery session, it may keep it > open, and it may repeat > SendTargets requests as it deems necessary to keep > it's target information > up to date. In the course of a SendTargets > response, the target validly > repeats certain keys. The MaxPDUDataLength key can > be sent by the initiator > as often as the PMTU changes. I don't see why the repetition of SendTargets and MaxRecvDataSegmentLength must happen in the same "negotiation sequence". If a node wants to repeat them, it can easily cause it to happen in a new sequence. Thus, I think that the paragraphs in question do make sense and that only the keys sent in response to SendTargets should be allowed to be repeated. > Why not just delete this paragraph? In the future > if there are keys added > that are valid during FFP, the RFC that specifies > those keys can specify > whether or not they can be "renegotiated". The paragraphs are needed because they are the only rules disallowing renegotiation and redeclaration (in the same negotiation sequence). As to the future keys, I'd like them too to be non-renegotiable. Martins Krikis, Intel Corp. Disclaimer: these are my opinions and may not be those of my employer. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Wed Jun 19 17:47:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04483 for ; Wed, 19 Jun 2002 17:46:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5JL21S15213 for ips-outgoing; Wed, 19 Jun 2002 17:02:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ariel.nishansystems.com (ultrex.nishansystems.com [12.36.127.195]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5JL1xw15203 for ; Wed, 19 Jun 2002 17:01:59 -0400 (EDT) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Jun 2002 14:01:53 -0700 Message-ID: From: Charles Monia To: "Ips (E-mail)" Subject: iFCP: Last call issues received at the bell Date: Wed, 19 Jun 2002 14:01:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk A last minute scan of the text by the editor and co-authors surfaced the following issues. The existing and revised text are included. With the exception of the IPR notice to be included, all are technical. Section 2.1, Glossary Comment: The glossary definition of an iFCP session should be modified to account for sessions not created as the result of a PLOGI. Revision 11 text: iFCP Session -- An association created when an N_PORT sends a PLOGI request to a remotely attached N_PORT. It is comprised of the N_PORTs and TCP connection that carries traffic between them. Proposed revision: iFCP Session -- An association comprised of a pair of N_PORTs and a TCP connection that carries traffic between them. An iFCP session may be created as the result of a PLOGI fibre channel login operation. Section 4.1, item (b) Comment The resolution of review comment 26 for revision 10 states that the iFCP protocol layer provides transport services only and is not responsible for the execution of the fibre channel fabric-supplied functions defined in the FC standards. Therefore the following item in the enumeration of functions performed by the iFCP layer should be deleted: Text to be deleted: b) Execution of fabric-supplied link services addressed to one of the well-known fibre channel N_PORT addresses. Section 5.3.4, page 45, para 4: Add upper case "SHALL. Delete erroneous reference to address translation mode, which is properly described in the subsequent enumeration. Revision 11 text: The gateway shall then de-encapsulate the frame. If operating in address translation mode, the gateway SHALL: Proposed revision: The gateway SHALL then de-encapsulate the frame as follows: Section 10.3.1, page 89, last paragraph Comment: The following text is modified so that the required iSNS query is not performed by the IKE layer. Revision 11 text: An IKE responder must verify the IKE initiator's IP address and port number (IDcr) using the IP address and port number that result from a successful query to an iSNS server. Proposed text: The gateway creating the iFCP session must query the iSNS server as described in section 5.2.2 to determine the appropriate port on which to initiate the associated TCP connection. Upon a successful IKE Phase 2 exchange, the IKE responder enforces the negotiated selectors on the IPsec SAs. Any subsequent iFCP session creation requires the iFCP peer to query its iSNS server for access control (in accordance with the session creation requirements specified in section 5.2.2.1) Page 103, Notice of Intellectual Property Rights Comment: In view of Nishan's IPR disclosure, the following IETF boilerplate from RFC 2026 should be added after the copyright notice: Notice of Intellectual Property Rights The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Charles From owner-ips@ece.cmu.edu Wed Jun 19 18:18:15 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05264 for ; Wed, 19 Jun 2002 18:18:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5JLdWa17135 for ips-outgoing; Wed, 19 Jun 2002 17:39:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5JLdUw17128 for ; Wed, 19 Jun 2002 17:39:30 -0400 (EDT) Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id OAA05180; Wed, 19 Jun 2002 14:39:22 -0700 (PDT) From: Keith McCloghrie Message-Id: <200206192139.OAA05180@cisco.com> Subject: Re: FC Mgmt mib To: charissa.willard@sanvalley.com Date: Wed, 19 Jun 2002 14:39:22 -0700 (PDT) Cc: kzm@cisco.com ('Keith McCloghrie'), arvindp@cisco.com, ips@ece.cmu.edu, smoffett@cisco.com, sriramnj@cisco.com, nramesh@cisco.com, gklee@cisco.com In-Reply-To: <73DE11092C445F478CB3629910B2F494B8A47E@webmail.sanvalley.com> from "charissa.willard@sanvalley.com" at May 29, 2002 03:38:47 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Charissa, Sorry for the delay, but I have spoken with Arvind and he agrees that "encapsulates FC frames within another protocol" is a wide enough scope to cover his device, and thus, you're right that no change is needed for the FcUnitFunction TC. Further, the two objects within the current fcmEPortTable (i.e., fcmEPortClassFCredit and fcmEPortClassFDataFieldSize) can both be applied to Arvind's device. Now, you comment that fcmEPortClassFCredit applies to B_Ports, and I'm confident that fcmEPortClassFDataFieldSize does also. Thus, the fcmEPortTable actually applies to E_Ports and B_Ports. So, rather than have separate tables for B_Ports and E_Ports, with the same objects defined in both (i.e., a duplication), I'd like to use the existing table for both types. All that is required is to change the name to, say, the fcmInterSwitchPortTable (which is roughly what you suggested in your previous message), and update its definition to say it applies to E_Ports, B_Ports and any other type of port which interfaces to an inter-switch link. If you agree, I'll go ahead and update the MIB. Keith. > Keith, > > > > > 3. A new table for 'tunnel' ports > > > > - I'd rather not add a new table unless it's absolutely necessary. > > How about I just broaden the scope of the fcmEPortTable so that > > it applies not only to E_Ports but also to 'tunnel' ports ?? > > > > > The MIB will also need a new group for devices supporting 'tunnel' > > functionality, which will contain just fcmEPortClassFCredit > > and fcmEPortClassFDataFieldSize, right ?? > > For FC over IP a port can be either a B_port or an E_port. A B_port supports > Class F frames and thus could at least use the Class F BB_Credit object that > you specified in fcmEPortTable. > > The MIB defines the FcUnitFunction type of 'bridge' as "encapsulates FC > frames within another protocol". Doesn't this imply "tunneling"? > > Since a B_port is transparent to the Fabric, just providing a table for > B_Ports may provide a solution for other devices/ports that are transparent > to the Fabric and need an object for BB_Credit. > > Thanks, > Charissa > From owner-ips@ece.cmu.edu Wed Jun 19 19:00:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05834 for ; Wed, 19 Jun 2002 19:00:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5JMGhU18854 for ips-outgoing; Wed, 19 Jun 2002 18:16:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gatekeeper2.sanvalley.com ([63.170.126.67]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5JLgEw17269 for ; Wed, 19 Jun 2002 17:42:14 -0400 (EDT) Received: from webmail.sanvalley.com (webmail [10.128.0.100]) by gatekeeper2.sanvalley.com (Netscape Messaging Server 4.15) with ESMTP id GXZ35900.B05; Wed, 19 Jun 2002 14:46:21 -0700 Received: by webmail.sanvalley.com with Internet Mail Service (5.5.2650.21) id ; Wed, 19 Jun 2002 14:42:13 -0700 Message-ID: <73DE11092C445F478CB3629910B2F494B8A4AF@webmail.sanvalley.com> From: charissa.willard@sanvalley.com To: "'Keith McCloghrie'" , charissa.willard@sanvalley.com Cc: arvindp@cisco.com, ips@ece.cmu.edu, smoffett@cisco.com, sriramnj@cisco.com, nramesh@cisco.com, gklee@cisco.com Subject: RE: FC Mgmt mib Date: Wed, 19 Jun 2002 14:42:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Keith, That solution sounds good to me. Thanks, Charissa > -----Original Message----- > From: Keith McCloghrie [mailto:kzm@cisco.com] > Sent: Wednesday, June 19, 2002 2:39 PM > To: charissa.willard@sanvalley.com > Cc: kzm@cisco.com; arvindp@cisco.com; ips@ece.cmu.edu; > smoffett@cisco.com; sriramnj@cisco.com; nramesh@cisco.com; > gklee@cisco.com > Subject: Re: FC Mgmt mib > > > Charissa, > > Sorry for the delay, but I have spoken with Arvind and he agrees > that "encapsulates FC frames within another protocol" is a wide > enough scope to cover his device, and thus, you're right that no > change is needed for the FcUnitFunction TC. > > Further, the two objects within the current fcmEPortTable (i.e., > fcmEPortClassFCredit and fcmEPortClassFDataFieldSize) can both be > applied to Arvind's device. Now, you comment that > fcmEPortClassFCredit > applies to B_Ports, and I'm confident that fcmEPortClassFDataFieldSize > does also. Thus, the fcmEPortTable actually applies to E_Ports and > B_Ports. So, rather than have separate tables for B_Ports > and E_Ports, > with the same objects defined in both (i.e., a duplication), I'd like > to use the existing table for both types. All that is required is to > change the name to, say, the fcmInterSwitchPortTable (which is roughly > what you suggested in your previous message), and update its > definition > to say it applies to E_Ports, B_Ports and any other type of port which > interfaces to an inter-switch link. > > If you agree, I'll go ahead and update the MIB. > > Keith. > > > > Keith, > > > > > > > > 3. A new table for 'tunnel' ports > > > > > > - I'd rather not add a new table unless it's absolutely necessary. > > > How about I just broaden the scope of the fcmEPortTable so that > > > it applies not only to E_Ports but also to 'tunnel' ports ?? > > > > > > > > The MIB will also need a new group for devices supporting 'tunnel' > > > functionality, which will contain just fcmEPortClassFCredit > > > and fcmEPortClassFDataFieldSize, right ?? > > > > For FC over IP a port can be either a B_port or an E_port. > A B_port supports > > Class F frames and thus could at least use the Class F > BB_Credit object that > > you specified in fcmEPortTable. > > > > The MIB defines the FcUnitFunction type of 'bridge' as > "encapsulates FC > > frames within another protocol". Doesn't this imply "tunneling"? > > > > Since a B_port is transparent to the Fabric, just providing > a table for > > B_Ports may provide a solution for other devices/ports that > are transparent > > to the Fabric and need an object for BB_Credit. > > > > Thanks, > > Charissa > > > From owner-ips@ece.cmu.edu Wed Jun 19 20:21:23 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06653 for ; Wed, 19 Jun 2002 20:21:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5JNqY722451 for ips-outgoing; Wed, 19 Jun 2002 19:52:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5JNqWw22447 for ; Wed, 19 Jun 2002 19:52:33 -0400 (EDT) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 19 Jun 2002 16:52:23 -0700 Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 19 Jun 2002 16:52:23 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 19 Jun 2002 16:52:22 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 19 Jun 2002 16:52:22 -0700 Received: from win-msg-03.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.198]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Wed, 19 Jun 2002 16:52:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6236.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: iSCSI: TargetAuth Date: Wed, 19 Jun 2002 16:52:22 -0700 Message-ID: Thread-Topic: iSCSI: TargetAuth Thread-Index: AcIX7F5JRV0cNLyATrOXOZcsta0xfQ== From: "Lakshmi Ramasubramanian" To: X-OriginalArrivalTime: 19 Jun 2002 23:52:22.0603 (UTC) FILETIME=[5AFCC1B0:01C217EC] Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C217EC.5AEE2462" ------_=_NextPart_001_01C217EC.5AEE2462 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the Login phase examples given, the key TargetAuth is used ONLY with SRP. Does this mean that target authentication needs to be negotiated only for SRP? If so, what is the default behaviour for other authentication methods? Is there any way to negotiate this? =20 It'll be good to have both sides authenticate each other (by default) for all authentication methods. =20 thanks! -lakshmi ------_=_NextPart_001_01C217EC.5AEE2462 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
In the Login phase examples given, the key = TargetAuth=20 is used
ONLY with SRP. Does this mean that target=20 authentication needs
to be negotiated only for SRP? If so, what is = the=20 default
behaviour for other authentication methods? = Is there=20 any way
to negotiate this?
 
It'll be good to have both sides authenticate = each=20 other (by default)
for all authentication = methods.
 
thanks!
 -lakshmi
=00 ------_=_NextPart_001_01C217EC.5AEE2462-- --------------InterScan_NT_MIME_Boundary-- From owner-ips@ece.cmu.edu Wed Jun 19 20:21:56 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06669 for ; Wed, 19 Jun 2002 20:21:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5JNewp21987 for ips-outgoing; Wed, 19 Jun 2002 19:40:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5JNetw21980 for ; Wed, 19 Jun 2002 19:40:55 -0400 (EDT) Received: from xparelay2.corp.hp.com (xparelay2.corp.hp.com [15.58.137.112]) by palrel11.hp.com (Postfix) with ESMTP id 75FAA600700; Wed, 19 Jun 2002 16:40:49 -0700 (PDT) Received: from xpabh1.corp.hp.com (xpabh1.corp.hp.com [15.58.136.191]) by xparelay2.corp.hp.com (Postfix) with ESMTP id E7550B4; Wed, 19 Jun 2002 16:40:48 -0700 (PDT) Received: by xpabh1.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Jun 2002 16:40:48 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF678@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'THALER,PAT (A-Roseville,ex1)'" , Julo-Actcom , ips@ece.cmu.edu Subject: RE: iSCSI: Negotiating a parameter more than once Date: Wed, 19 Jun 2002 16:40:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C217EA.B32E5760" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C217EA.B32E5760 Content-Type: text/plain; charset="iso-8859-1" Sorry Pat, I read your response too quickly and misinterpreted the definition of "negotiation sequence". I agree with you, the text you suggest is appropriate. In addition, it would be nice if section 11 had an explicit "Use" indication distinguishing keys that can be repeated w/in a declaration sequence (targetAddress, targetAlias, targetName) and keys that cannot be repeated. You mentioned that you couldn' t find text that says the SendTargets command can be repeated w/in a declaration sequence - in fact, Appendix D paragraph 6 says: "A SendTargets command consists of a single Text request PDU. This PDU contains exactly one text key and value. The text key MUST be SendTargets. The expected response depends upon the value, as well as whether the session is a discovery or operational session." This seems OK to me, if an initiator wants information about another target, it can just initiate another SendTargets "negotiation sequence"?? Marj -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie_krueger@hp.com] Sent: Wednesday, June 19, 2002 11:32 AM To: 'THALER,PAT (A-Roseville,ex1)'; Julo-Actcom; ips@ece.cmu.edu Subject: RE: iSCSI: Negotiating a parameter more than once In the context of the two keys that are valid during FFP, neither of these suggested edits to that paragraph make sense. Currently, there is no "negotiation" key that's valid in FFP, and the "declarative" keys that are valid, - SendTargets and MaxPDUDataLength *can* validly be repeated. If an initiator opens a discovery session, it may keep it open, and it may repeat SendTargets requests as it deems necessary to keep it's target information up to date. In the course of a SendTargets response, the target validly repeats certain keys. The MaxPDUDataLength key can be sent by the initiator as often as the PMTU changes. Why not just delete this paragraph? In the future if there are keys added that are valid during FFP, the RFC that specifies those keys can specify whether or not they can be "renegotiated". Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard -----Original Message----- From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@agilent.com] Sent: Wednesday, June 19, 2002 10:19 AM To: Julo-Actcom; ips@ece.cmu.edu Subject: RE: iSCSI: Negotiating a parameter more than once Julian, If declarations should not be repeated (except for those where it is explicitly allowed), then it should be "negotiate or declare" because "negotiate" doesn't cover declarations. Alternatively, one could add an explicit definition that "Negotiate" includes both declarations and negotiations. Secondly, SendTargets is not a valid example for login as it is FFPO. I think the only parameter explicitly allowed to be duplicated during Login is TargetAddress (when returned as a result of a redirect). Furthermore, I can not find any explicit statement that SendTargets may be repeated during a FFP negotiation sequence. Only TargetName and TargetAddress have explicit text allowing them to be repeated (in Appendix B for both and in the description of redirection for LoginResponse for TargetAddress). Therefore, I suggest: For 4.3: Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during login except for responses to specific keys that explicitly allow repeated key declarations (e.g. TargetAddress). If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection For 4.4: Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during any negotiation sequence without an intervening reset except for responses to specific keys that explicitly allow repeated key declarations (e.g. TargetAddress). If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above. Pat -----Original Message----- From: Julo-Actcom [mailto:Julian_Satran@actcom.net.il] Sent: Tuesday, June 18, 2002 10:12 PM To: ips@ece.cmu.edu Subject: RE: iSCSI: Negotiating a parameter more than once Pat, 4.3 and 4.4 cover two diferent phases. Parameters should not be negotiated or declared twice. I think that you refer to the responses to SendTargets - those contain more than an instance of the declarations and have to outlined. How about the following text in 4.4: Neither the initiator nor the target should attempt to negotiate a parameter more than once during login except for responses to specific keys that explicitly allow repeated key declarations (e.g. SendTargets). If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection. and in 4.4: Neither the initiator nor the target should attempt to negotiate a parameter more than once during any negotiation sequence without an intervening reset except for responses to specific keys that explicitly allow repeated key declarations. If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above. Julo ------_=_NextPart_001_01C217EA.B32E5760 Content-Type: text/html; charset="iso-8859-1"
Sorry Pat, I read your response too quickly and misinterpreted the definition of "negotiation sequence".  I agree with you, the text you suggest is appropriate.
 
In addition, it would be nice if section 11 had an explicit "Use" indication distinguishing keys that can be repeated w/in a declaration sequence (targetAddress, targetAlias, targetName) and keys that cannot be repeated.
 
You mentioned that you couldn' t find text that says the SendTargets command can be repeated w/in a declaration sequence - in fact, Appendix D paragraph 6 says:
    
     "A SendTargets command consists of a single Text request PDU.
     This PDU contains exactly one text key and value.  The text key MUST
     be SendTargets.  The expected response depends upon the value, as
     well as whether the session is a discovery or operational session."
 
This seems OK to me, if an initiator wants information about another target, it can just initiate another SendTargets "negotiation sequence"??
 
Marj

 
 -----Original Message-----
From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie_krueger@hp.com]
Sent: Wednesday, June 19, 2002 11:32 AM
To: 'THALER,PAT (A-Roseville,ex1)'; Julo-Actcom; ips@ece.cmu.edu
Subject: RE: iSCSI: Negotiating a parameter more than once

In the context of the two keys that are valid during FFP, neither of these suggested edits to that paragraph make sense.  Currently, there is no "negotiation" key that's valid in FFP, and the "declarative" keys that are valid, - SendTargets and MaxPDUDataLength *can* validly be repeated.  If an initiator opens a discovery session, it may keep it open, and it may repeat SendTargets requests as it deems necessary to keep it's target information up to date.  In the course of a SendTargets response, the target validly repeats certain keys.  The MaxPDUDataLength key can be sent by the initiator as often as the PMTU changes.
 
Why not just delete this paragraph?  In the future if there are keys added that are valid during FFP, the RFC that specifies those keys can specify whether or not they can be "renegotiated".
 
Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
 
-----Original Message-----
From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@agilent.com]
Sent: Wednesday, June 19, 2002 10:19 AM
To: Julo-Actcom; ips@ece.cmu.edu
Subject: RE: iSCSI: Negotiating a parameter more than once

Julian,
 
If declarations should not be repeated (except for those where it is explicitly allowed), then it should be "negotiate or declare" because "negotiate" doesn't cover declarations. Alternatively, one could add an explicit definition that "Negotiate" includes both declarations and negotiations. Secondly, SendTargets is not a valid example for login as it is FFPO. I think the only parameter explicitly allowed to be duplicated during Login is TargetAddress (when returned as a result of a redirect). Furthermore, I can not find any explicit statement that SendTargets may be repeated during a FFP negotiation sequence. Only TargetName and TargetAddress have explicit text allowing them to be repeated (in Appendix B for both and in the description of redirection for LoginResponse for TargetAddress).
 
Therefore, I suggest:
For 4.3:
Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during login except for responses to specific keys that explicitly allow repeated key declarations (e.g. TargetAddress). If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection
 
For 4.4:
Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during any negotiation sequence without an intervening reset except for responses to specific keys that explicitly allow repeated key declarations (e.g. TargetAddress). If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above.
 
Pat
-----Original Message-----
From: Julo-Actcom [mailto:Julian_Satran@actcom.net.il]
Sent: Tuesday, June 18, 2002 10:12 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI: Negotiating a parameter more than once

Pat,
 
4.3 and 4.4 cover two diferent phases.
Parameters should not be negotiated or declared twice.
 
I think that you refer to the responses to SendTargets - those contain more than an instance of the declarations and have to outlined.
 
How about the following text in 4.4:
 

Neither the initiator nor the target should attempt to negotiate a parameter more than once during login except for responses to specific keys that explicitly allow repeated key declarations (e.g. SendTargets). If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection.

 

and in 4.4:

 

Neither the initiator nor the target should attempt to negotiate a parameter more than once during any negotiation sequence without an intervening reset except for responses to specific keys that explicitly allow repeated key declarations. If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above.
Julo
------_=_NextPart_001_01C217EA.B32E5760-- From owner-ips@ece.cmu.edu Wed Jun 19 22:30:26 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08964 for ; Wed, 19 Jun 2002 22:30:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5K1eEu26044 for ips-outgoing; Wed, 19 Jun 2002 21:40:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5K1eCw26038 for ; Wed, 19 Jun 2002 21:40:12 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Jun 2002 21:40:11 -0400 Message-ID: From: Eddy Quicksall To: Julian Satran Cc: ips@ece.cmu.edu, Bill Studenmund Subject: RE: Question regarding SNACK and bidi transfers Date: Wed, 19 Jun 2002 21:40:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C217FB.68BEA570" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C217FB.68BEA570 Content-Type: text/plain; charset="iso-8859-1" It wouldn't really have to be repeated but I don't think 9.8.1 and 9.7 should say something other than "(starting with 0"). I just didn't know the best way to suggest the clarification. Maybe something more light, like "except when used with bidirectional commands (see section 2.2.2.3)". The problem with a blanket statement like "(starting with 0)" is that one can easily miss the other section contradicting it. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 19, 2002 11:35 AM To: Eddy Quicksall Cc: ips@ece.cmu.edu; Bill Studenmund Subject: RE: Question regarding SNACK and bidi transfers Eddy, In fact 2.2.2.3 contains: For bidirectional commands, the target uses the DataSN/R2TSN to sequence Data-In and R2T PDUs in one continuous sequence (undifferentiated). Do you think I should repeat this in 9.8.1 and 9.7 ? Julo Eddy Quicksall 06/19/2002 01:11 PM Please respond to Eddy Quicksall To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, Bill Studenmund Subject: RE: Question regarding SNACK and bidi transfers Julo, Since the answer to the 2nd question is "yes" (see your EMAIL with subject "Emailing: msg10874.txt"), then I think the spec should make that more clear in sections 9.8.1 and 9.7. Perhaps in section 9.8.1, it should say something like "Except, when used with a bidirectional command and SNACK is being supported, the R2TSN must start with a number that couples the R2TSN and DataSN together as one continuous sequence". And a similar statement added to 9.7. Eddy -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Tuesday, June 18, 2002 7:56 PM To: ips@ece.cmu.edu Subject: Question regarding SNACK and bidi transfers I have a question about SNACK type 0 requests. In the text, they are described as being for Data-In PDUs or R2T PDUs. For a bidi command, how do you know which? Does this mean that for a bidi command, data-in and R2TSNs have to be mutually-unique (i.e. drawn from the same pool)? Take care, Bill ------_=_NextPart_001_01C217FB.68BEA570 Content-Type: text/html; charset="iso-8859-1"
It wouldn't really have to be repeated but I don't think 9.8.1 and 9.7 should say something other than "(starting with 0").
 
I just didn't know the best way to suggest the clarification.
 
Maybe something more light, like "except when used with bidirectional commands (see section 2.2.2.3)".
 
The problem with a blanket statement like "(starting with 0)" is that one can easily miss the other section contradicting it.
 
Eddy
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 19, 2002 11:35 AM
To: Eddy Quicksall
Cc: ips@ece.cmu.edu; Bill Studenmund
Subject: RE: Question regarding SNACK and bidi transfers


Eddy,

In fact 2.2.2.3 contains:

For bidirectional commands, the target uses the DataSN/R2TSN to sequence Data-In and R2T PDUs in one continuous sequence (undifferentiated).

Do you think I should repeat this in 9.8.1 and 9.7 ?

Julo


Eddy Quicksall <eddy_quicksall@ivivity.com>

06/19/2002 01:11 PM
Please respond to Eddy Quicksall

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu, Bill Studenmund <wrstuden@wasabisystems.com>
        Subject:        RE: Question regarding SNACK and bidi transfers

       


Julo,

Since the answer to the 2nd question is "yes" (see your EMAIL with subject
"Emailing: msg10874.txt"), then I think the spec should make that more clear
in sections 9.8.1 and 9.7.

Perhaps in section 9.8.1, it should say something like "Except, when used
with a bidirectional command and SNACK is being supported, the R2TSN must
start with a number that couples the R2TSN and DataSN together as one
continuous sequence". And a similar statement added to 9.7.

Eddy

-----Original Message-----
From: Bill Studenmund [mailto:wrstuden@wasabisystems.com]
Sent: Tuesday, June 18, 2002 7:56 PM
To: ips@ece.cmu.edu
Subject: Question regarding SNACK and bidi transfers


I have a question about SNACK type 0 requests. In the text, they are
described as being for Data-In PDUs or R2T PDUs.

For a bidi command, how do you know which? Does this mean that for a bidi
command, data-in and R2TSNs have to be mutually-unique (i.e. drawn from
the same pool)?

Take care,

Bill


------_=_NextPart_001_01C217FB.68BEA570-- From owner-ips@ece.cmu.edu Thu Jun 20 03:53:54 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21685 for ; Thu, 20 Jun 2002 03:53:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5K7WtA07090 for ips-outgoing; Thu, 20 Jun 2002 03:32:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5K7Wrw07082 for ; Thu, 20 Jun 2002 03:32:53 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5K7WhRD014494; Thu, 20 Jun 2002 09:32:44 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5K7WgL71740; Thu, 20 Jun 2002 09:32:43 +0200 Importance: Normal Subject: Re: iSCSI: TargetAuth To: "Lakshmi Ramasubramanian" Cc: X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Ofer Biran" Date: Thu, 20 Jun 2002 10:31:50 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 20/06/2002 10:32:42 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g5K7Wrw07083 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit lakshmi, In all authentication methods, initiator authentication is mandatory, and target authentication is dictated by the initiator (they are both mandatory to implement of course). In SRP, the initiator dictates it by the TargetAuth key. In CHAP, by sending the CHAP_I, CHAP_C keys in the right step (see 10.5). In Kerberos and SPKM it is by setting a mutual field in the initiator token (see 10.2, 10.3). Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 "Lakshmi Ramasubramanian" @ece.cmu.edu on 20/06/2002 02:52:22 Please respond to "Lakshmi Ramasubramanian" Sent by: owner-ips@ece.cmu.edu To: cc: Subject: iSCSI: TargetAuth In the Login phase examples given, the key TargetAuth is used ONLY with SRP. Does this mean that target authentication needs to be negotiated only for SRP? If so, what is the default behaviour for other authentication methods? Is there any way to negotiate this? It'll be good to have both sides authenticate each other (by default) for all authentication methods. thanks!  -lakshmi From owner-ips@ece.cmu.edu Thu Jun 20 03:55:12 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21712 for ; Thu, 20 Jun 2002 03:55:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5K6wbI06088 for ips-outgoing; Thu, 20 Jun 2002 02:58:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5K6waw06084 for ; Thu, 20 Jun 2002 02:58:36 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5K6wMKf051830; Thu, 20 Jun 2002 08:58:22 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5K6wKL109580; Thu, 20 Jun 2002 08:58:21 +0200 To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" Cc: ips@ece.cmu.edu, Julo-Actcom , owner-ips@ece.cmu.edu, "'THALER,PAT (A-Roseville,ex1)'" MIME-Version: 1.0 Subject: RE: iSCSI: Negotiating a parameter more than once X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 20 Jun 2002 09:58:19 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 20/06/2002 09:58:21, Serialize complete at 20/06/2002 09:58:21 Content-Type: multipart/alternative; boundary="=_alternative 0025647AC2256BDE_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0025647AC2256BDE_= Content-Type: text/plain; charset="us-ascii" Marjorie, We discussed this repeatedly in the past and I recall that except the dissenting voice of Mark Bakke the agreement was that long-lived discovery sessions are not considered useful. Julo "KRUEGER,MARJORIE (HP-Roseville,ex1)" Sent by: owner-ips@ece.cmu.edu 06/19/2002 09:31 PM Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'THALER,PAT (A-Roseville,ex1)'" , Julo-Actcom , ips@ece.cmu.edu cc: Subject: RE: iSCSI: Negotiating a parameter more than once In the context of the two keys that are valid during FFP, neither of these suggested edits to that paragraph make sense. Currently, there is no "negotiation" key that's valid in FFP, and the "declarative" keys that are valid, - SendTargets and MaxPDUDataLength *can* validly be repeated. If an initiator opens a discovery session, it may keep it open, and it may repeat SendTargets requests as it deems necessary to keep it's target information up to date. In the course of a SendTargets response, the target validly repeats certain keys. The MaxPDUDataLength key can be sent by the initiator as often as the PMTU changes. Why not just delete this paragraph? In the future if there are keys added that are valid during FFP, the RFC that specifies those keys can specify whether or not they can be "renegotiated". Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard -----Original Message----- From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@agilent.com] Sent: Wednesday, June 19, 2002 10:19 AM To: Julo-Actcom; ips@ece.cmu.edu Subject: RE: iSCSI: Negotiating a parameter more than once Julian, If declarations should not be repeated (except for those where it is explicitly allowed), then it should be "negotiate or declare" because "negotiate" doesn't cover declarations. Alternatively, one could add an explicit definition that "Negotiate" includes both declarations and negotiations. Secondly, SendTargets is not a valid example for login as it is FFPO. I think the only parameter explicitly allowed to be duplicated during Login is TargetAddress (when returned as a result of a redirect). Furthermore, I can not find any explicit statement that SendTargets may be repeated during a FFP negotiation sequence. Only TargetName and TargetAddress have explicit text allowing them to be repeated (in Appendix B for both and in the description of redirection for LoginResponse for TargetAddress). Therefore, I suggest: For 4.3: Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during login except for responses to specific keys that explicitly allow repeated key declarations (e.g. TargetAddress). If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection For 4.4: Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during any negotiation sequence without an intervening reset except for responses to specific keys that explicitly allow repeated key declarations (e.g. TargetAddress). If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above. Pat -----Original Message----- From: Julo-Actcom [mailto:Julian_Satran@actcom.net.il] Sent: Tuesday, June 18, 2002 10:12 PM To: ips@ece.cmu.edu Subject: RE: iSCSI: Negotiating a parameter more than once Pat, 4.3 and 4.4 cover two diferent phases. Parameters should not be negotiated or declared twice. I think that you refer to the responses to SendTargets - those contain more than an instance of the declarations and have to outlined. How about the following text in 4.4: Neither the initiator nor the target should attempt to negotiate a parameter more than once during login except for responses to specific keys that explicitly allow repeated key declarations (e.g. SendTargets). If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection. and in 4.4: Neither the initiator nor the target should attempt to negotiate a parameter more than once during any negotiation sequence without an intervening reset except for responses to specific keys that explicitly allow repeated key declarations. If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above. Julo To: Julian_Satran@il.ibm.com Subject: iSCSI: Negotiating a parameter more than once From: pat_thaler@agilent.com Date: Mon, 17 Jun 2002 16:18:43 -0600 Cc: ips@ece.cmu.edu Content-Type: text/plain;charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Julian, The following text appears in 4.3 (page 78 just before 4.3.1): Neither the initiator nor the target should attempt to negotiate a parameter more than once during login. If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection. and nearly the same text in 4.4 (page 85 near the end): Neither the initiator nor the target should attempt to negotiate a parameter more than once during any negotiation sequence without an intervening reset. If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above. This is confusing partly because "negotiate" seems to be generally used covering both negotiations and declarations and in some cases covering only negotiations. It isn't clear in which sense it is used. If the text above applies only to negotiated values, then it would be allowable to send parameters such as Initiator Name, SessionType, and MaxRecvDataSegmentLength over which doesn't seem to be a good idea. However, there are other declarative parameters which are sent multiple times - SendTargets where there are multiple targets or multiple addresses for a target requires sending the same parameter multiple times. Perhaps the text should be changed to: Neither the initiator nor the target should attempt to declare or negotiate a parameter other than TargetName, TargetAlias or TargetAddress more than once.... Regards, Pat Prev by Date: RE: iSCSI: use of Text/Login with no data segment Next by Date: RE: iSCSI: Negotiating a parameter more than once Prev by thread: iSCSI 0.13 vs. iSCSI Plugfest Next by thread: RE: iSCSI: Negotiating a parameter more than once Index(es): Date Thread --=_alternative 0025647AC2256BDE_= Content-Type: text/html; charset="us-ascii"
Marjorie,

We discussed this repeatedly in the past and I recall that except the dissenting voice of Mark Bakke the agreement was that long-lived discovery sessions are not considered useful.

Julo


"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
Sent by: owner-ips@ece.cmu.edu

06/19/2002 09:31 PM
Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"

       
        To:        "'THALER,PAT (A-Roseville,ex1)'" <pat_thaler@agilent.com>, Julo-Actcom <Julian_Satran@actcom.net.il>, ips@ece.cmu.edu
        cc:        
        Subject:        RE: iSCSI: Negotiating a parameter more than once

       


In the context of the two keys that are valid during FFP, neither of these suggested edits to that paragraph make sense.  Currently, there is no "negotiation" key that's valid in FFP, and the "declarative" keys that are valid, - SendTargets and MaxPDUDataLength *can* validly be repeated.  If an initiator opens a discovery session, it may keep it open, and it may repeat SendTargets requests as it deems necessary to keep it's target information up to date.  In the course of a SendTargets response, the target validly repeats certain keys.  The MaxPDUDataLength key can be sent by the initiator as often as the PMTU changes.
 
Why not just delete this paragraph?  In the future if there are keys added that are valid during FFP, the RFC that specifies those keys can specify whether or not they can be "renegotiated".
 
Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
-----Original Message-----
From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@agilent.com]
Sent: Wednesday, June 19, 2002 10:19 AM
To: Julo-Actcom; ips@ece.cmu.edu
Subject: RE: iSCSI: Negotiating a parameter more than once
Julian,
 
If declarations should not be repeated (except for those where it is explicitly allowed), then it should be "negotiate or declare" because "negotiate" doesn't cover declarations. Alternatively, one could add an explicit definition that "Negotiate" includes both declarations and negotiations. Secondly, SendTargets is not a valid example for login as it is FFPO. I think the only parameter explicitly allowed to be duplicated during Login is TargetAddress (when returned as a result of a redirect). Furthermore, I can not find any explicit statement that SendTargets may be repeated during a FFP negotiation sequence. Only TargetName and TargetAddress have explicit text allowing them to be repeated (in Appendix B for both and in the description of redirection for LoginResponse for TargetAddress).
 
Therefore, I suggest:
For 4.3:
Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during login except for responses to specific keys that explicitly allow repeated key declarations (e.g. TargetAddress). If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection
 
For 4.4:
Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during any negotiation sequence without an intervening reset except for responses to specific keys that explicitly allow repeated key declarations (e.g. TargetAddress). If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above.
 
Pat
-----Original Message-----
From: Julo-Actcom [mailto:Julian_Satran@actcom.net.il]
Sent: Tuesday, June 18, 2002 10:12 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI: Negotiating a parameter more than once
Pat,
 
4.3 and 4.4 cover two diferent phases.
Parameters should not be negotiated or declared twice.
 
I think that you refer to the responses to SendTargets - those contain more than an instance of the declarations and have to outlined.
 
How about the following text in 4.4:
 

Neither the initiator nor the target should attempt to negotiate a parameter more than once during login except for responses to specific keys that explicitly allow repeated key declarations (e.g. SendTargets). If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection.

 

and in 4.4:

 

Neither the initiator nor the target should attempt to negotiate a parameter more than once during any negotiation sequence without an intervening reset except for responses to specific keys that explicitly allow repeated key declarations. If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above.

Julo

  • To: Julian_Satran@il.ibm.com
  • Subject: iSCSI: Negotiating a parameter more than once
  • From: pat_thaler@agilent.com
  • Date: Mon, 17 Jun 2002 16:18:43 -0600
  • Cc: ips@ece.cmu.edu
  • Content-Type: text/plain;charset="ISO-8859-1"
  • Sender: owner-ips@ece.cmu.edu

    Julian,

    The following text appears in 4.3 (page 78 just before 4.3.1):

    Neither the initiator nor the target should attempt to negotiate a
    parameter more than once during login. If detected by the target this
    MUST result in a Login reject (initiator error). The initiator MUST
    drop the connection.

    and nearly the same text in 4.4 (page 85 near the end):

    Neither the initiator nor the target should attempt to negotiate a
    parameter more than once during any negotiation sequence without an
    intervening reset. If detected by the target this MUST result in a
    Reject with a reason of "protocol error". The initiator MUST reset
    the negotiation as outlined above.

    This is confusing partly because "negotiate" seems to be generally used covering both negotiations and declarations and in some cases covering only negotiations. It isn't clear in which sense it is used. If the text above applies only to negotiated values, then it would be allowable to send parameters such as Initiator Name, SessionType, and MaxRecvDataSegmentLength over which doesn't seem to be a good idea. However, there are other declarative parameters which are sent multiple times - SendTargets where there are multiple targets or multiple addresses for a target requires sending the same parameter multiple times.

    Perhaps the text should be changed to:

    Neither the initiator nor the target should attempt to declare or negotiate a
    parameter other than TargetName, TargetAlias or TargetAddress more than once....

    Regards,
    Pat
--=_alternative 0025647AC2256BDE_=-- From owner-ips@ece.cmu.edu Thu Jun 20 05:36:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22852 for ; Thu, 20 Jun 2002 05:36:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5K8wgw20501 for ips-outgoing; Thu, 20 Jun 2002 04:58:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5K8wew20497 for ; Thu, 20 Jun 2002 04:58:40 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5K8wWBL028830; Thu, 20 Jun 2002 10:58:32 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5K8wUL115086; Thu, 20 Jun 2002 10:58:31 +0200 To: Eddy Quicksall Cc: ips@ece.cmu.edu, Bill Studenmund MIME-Version: 1.0 Subject: RE: Question regarding SNACK and bidi transfers X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 20 Jun 2002 11:58:28 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 20/06/2002 11:58:32, Serialize complete at 20/06/2002 11:58:32 Content-Type: multipart/alternative; boundary="=_alternative 00310F4DC2256BDE_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00310F4DC2256BDE_= Content-Type: text/plain; charset="us-ascii" Eddy, I will add a reference. It was also brought to my attention that we should state that the total limit for R2T and Data is 2**32. I will add those to the text Thanks, Julo Eddy Quicksall 06/20/2002 04:40 AM Please respond to Eddy Quicksall To: Julian Satran cc: ips@ece.cmu.edu, Bill Studenmund Subject: RE: Question regarding SNACK and bidi transfers It wouldn't really have to be repeated but I don't think 9.8.1 and 9.7 should say something other than "(starting with 0"). I just didn't know the best way to suggest the clarification. Maybe something more light, like "except when used with bidirectional commands (see section 2.2.2.3)". The problem with a blanket statement like "(starting with 0)" is that one can easily miss the other section contradicting it. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 19, 2002 11:35 AM To: Eddy Quicksall Cc: ips@ece.cmu.edu; Bill Studenmund Subject: RE: Question regarding SNACK and bidi transfers Eddy, In fact 2.2.2.3 contains: For bidirectional commands, the target uses the DataSN/R2TSN to sequence Data-In and R2T PDUs in one continuous sequence (undifferentiated). Do you think I should repeat this in 9.8.1 and 9.7 ? Julo Eddy Quicksall 06/19/2002 01:11 PM Please respond to Eddy Quicksall To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, Bill Studenmund Subject: RE: Question regarding SNACK and bidi transfers Julo, Since the answer to the 2nd question is "yes" (see your EMAIL with subject "Emailing: msg10874.txt"), then I think the spec should make that more clear in sections 9.8.1 and 9.7. Perhaps in section 9.8.1, it should say something like "Except, when used with a bidirectional command and SNACK is being supported, the R2TSN must start with a number that couples the R2TSN and DataSN together as one continuous sequence". And a similar statement added to 9.7. Eddy -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Tuesday, June 18, 2002 7:56 PM To: ips@ece.cmu.edu Subject: Question regarding SNACK and bidi transfers I have a question about SNACK type 0 requests. In the text, they are described as being for Data-In PDUs or R2T PDUs. For a bidi command, how do you know which? Does this mean that for a bidi command, data-in and R2TSNs have to be mutually-unique (i.e. drawn from the same pool)? Take care, Bill --=_alternative 00310F4DC2256BDE_= Content-Type: text/html; charset="us-ascii"
Eddy,

I will add a reference.

It was also brought to my attention that we should state that the total limit for R2T and Data is 2**32.
I will add those to the text


Thanks,
Julo


Eddy Quicksall <eddy_quicksall@ivivity.com>

06/20/2002 04:40 AM
Please respond to Eddy Quicksall

       
        To:        Julian Satran <Julian_Satran@il.ibm.com>
        cc:        ips@ece.cmu.edu, Bill Studenmund <wrstuden@wasabisystems.com>
        Subject:        RE: Question regarding SNACK and bidi transfers

       


It wouldn't really have to be repeated but I don't think 9.8.1 and 9.7 should say something other than "(starting with 0").
 
I just didn't know the best way to suggest the clarification.
 
Maybe something more light, like "except when used with bidirectional commands (see section 2.2.2.3)".
 
The problem with a blanket statement like "(starting with 0)" is that one can easily miss the other section contradicting it.
 
Eddy
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 19, 2002 11:35 AM
To: Eddy Quicksall
Cc: ips@ece.cmu.edu; Bill Studenmund
Subject: RE: Question regarding SNACK and bidi transfers

Eddy,

In fact 2.2.2.3 contains:

For bidirectional commands, the target uses the DataSN/R2TSN to sequence Data-In and R2T PDUs in one continuous sequence (undifferentiated).

Do you think I should repeat this in 9.8.1 and 9.7 ?

Julo

Eddy Quicksall <eddy_quicksall@ivivity.com>

06/19/2002 01:11 PM
Please respond to Eddy Quicksall

       
       To:        Julian Satran/Haifa/IBM@IBMIL
       cc:        ips@ece.cmu.edu, Bill Studenmund <wrstuden@wasabisystems.com>
       Subject:        RE: Question regarding SNACK and bidi transfers

     



Julo,

Since the answer to the 2nd question is "yes" (see your EMAIL with subject
"Emailing: msg10874.txt"), then I think the spec should make that more clear
in sections 9.8.1 and 9.7.

Perhaps in section 9.8.1, it should say something like "Except, when used
with a bidirectional command and SNACK is being supported, the R2TSN must
start with a number that couples the R2TSN and DataSN together as one
continuous sequence". And a similar statement added to 9.7.

Eddy

-----Original Message-----
From: Bill Studenmund [mailto:wrstuden@wasabisystems.com]
Sent: Tuesday, June 18, 2002 7:56 PM
To: ips@ece.cmu.edu
Subject: Question regarding SNACK and bidi transfers


I have a question about SNACK type 0 requests. In the text, they are
described as being for Data-In PDUs or R2T PDUs.

For a bidi command, how do you know which? Does this mean that for a bidi
command, data-in and R2TSNs have to be mutually-unique (i.e. drawn from
the same pool)?

Take care,

Bill

--=_alternative 00310F4DC2256BDE_=-- From owner-ips@ece.cmu.edu Thu Jun 20 07:27:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25222 for ; Thu, 20 Jun 2002 07:27:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5KAl6D23309 for ips-outgoing; Thu, 20 Jun 2002 06:47:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5KAl5w23304 for ; Thu, 20 Jun 2002 06:47:05 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5KAkvrR068618; Thu, 20 Jun 2002 12:46:57 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5KAkvL115288; Thu, 20 Jun 2002 12:46:57 +0200 To: Ron Grinfeld Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSI - forcing no data X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 20 Jun 2002 13:46:55 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 20/06/2002 13:46:56, Serialize complete at 20/06/2002 13:46:56 Content-Type: multipart/alternative; boundary="=_alternative 003B298BC2256BDE_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 003B298BC2256BDE_= Content-Type: text/plain; charset="us-ascii" Ron, Thanks for pointing out the inconsistency. The text in 9.5: , and it is recommended to terminate all responses with no data "survived" the change we have made to mandate R2Ts to be fulfilled completely (a relative late addition) and is now incorrect. We will remove it. Julo --=_alternative 003B298BC2256BDE_= Content-Type: text/html; charset="us-ascii"
Ron,

Thanks for pointing out the inconsistency.
The text in 9.5:

, and it is recommended to terminate all responses with no data

"survived" the change we have made to mandate R2Ts to be fulfilled completely (a relative late addition) and is now incorrect.
We will remove it.

Julo --=_alternative 003B298BC2256BDE_=-- From owner-ips@ece.cmu.edu Thu Jun 20 10:11:10 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00752 for ; Thu, 20 Jun 2002 10:11:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5KDMHi28079 for ips-outgoing; Thu, 20 Jun 2002 09:22:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5KDMFw28074 for ; Thu, 20 Jun 2002 09:22:15 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Jun 2002 09:21:51 -0400 Message-ID: From: Eddy Quicksall To: Amir Shalit Cc: ips@ece.cmu.edu, Bill Studenmund Subject: RE: Question regarding SNACK and bidi transfers Date: Thu, 20 Jun 2002 09:21:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I'm running one counter that applies to both. Eddy -----Original Message----- From: Amir Shalit [mailto:amir@astutenetworks.com] Sent: Wednesday, June 19, 2002 11:44 AM To: Eddy Quicksall; julian_satran@il.ibm.com Cc: ips@ece.cmu.edu; Bill Studenmund Subject: RE: Question regarding SNACK and bidi transfers Eddy, How do you "couple" R2TSN and DataSN together? Would it be better using an option bit indicating what we are asking for? Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Eddy Quicksall Sent: Wednesday, June 19, 2002 3:12 AM To: julian_satran@il.ibm.com Cc: ips@ece.cmu.edu; Bill Studenmund Subject: RE: Question regarding SNACK and bidi transfers Julo, Since the answer to the 2nd question is "yes" (see your EMAIL with subject "Emailing: msg10874.txt"), then I think the spec should make that more clear in sections 9.8.1 and 9.7. Perhaps in section 9.8.1, it should say something like "Except, when used with a bidirectional command and SNACK is being supported, the R2TSN must start with a number that couples the R2TSN and DataSN together as one continuous sequence". And a similar statement added to 9.7. Eddy -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Tuesday, June 18, 2002 7:56 PM To: ips@ece.cmu.edu Subject: Question regarding SNACK and bidi transfers I have a question about SNACK type 0 requests. In the text, they are described as being for Data-In PDUs or R2T PDUs. For a bidi command, how do you know which? Does this mean that for a bidi command, data-in and R2TSNs have to be mutually-unique (i.e. drawn from the same pool)? Take care, Bill From owner-ips@ece.cmu.edu Thu Jun 20 11:27:44 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03361 for ; Thu, 20 Jun 2002 11:27:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5KEbuB01487 for ips-outgoing; Thu, 20 Jun 2002 10:37:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5KAxlw23591 for ; Thu, 20 Jun 2002 06:59:47 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24030; Thu, 20 Jun 2002 06:59:05 -0400 (EDT) Message-Id: <200206201059.GAA24030@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-fcovertcpip-11.txt,.pdf Date: Thu, 20 Jun 2002 06:59:05 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Fibre Channel Over TCP/IP (FCIP) Author(s) : M. Rajagopal, E. Rodriguez, R. Weber Filename : draft-ietf-ips-fcovertcpip-11.txt,.pdf Pages : 68 Date : 19-Jun-02 Fibre Channel Over TCP/IP (FCIP) describes mechanisms that allow the interconnection of islands of Fibre Channel storage area networks over IP-based networks to form a unified storage area network in a single Fibre Channel fabric. FCIP relies on IP-based network services to provide the connectivity between the storage area network islands over local area networks, metropolitan area networks, or wide area networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcovertcpip-11.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-fcovertcpip-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-fcovertcpip-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020619122630.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-fcovertcpip-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-fcovertcpip-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020619122630.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Thu Jun 20 13:50:35 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08136 for ; Thu, 20 Jun 2002 13:50:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5KGubS10300 for ips-outgoing; Thu, 20 Jun 2002 12:56:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5KGuZw10296 for ; Thu, 20 Jun 2002 12:56:35 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5KGuTQW056388 for ; Thu, 20 Jun 2002 18:56:29 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5KGuTL145318 for ; Thu, 20 Jun 2002 18:56:29 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: FirstBurstSize and unsolicited data X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 20 Jun 2002 19:56:27 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 20/06/2002 19:56:29, Serialize complete at 20/06/2002 19:56:29 Content-Type: multipart/alternative; boundary="=_alternative 005C9DEDC2256BDE_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005C9DEDC2256BDE_= Content-Type: text/plain; charset="us-ascii" Pat, That piece is a leftover (together with the piece found by Ron) from the time neither FirstBurstSize nor R2T where mandatory to fullfill. FirstBurstSize was particularly nasty because if not done properly a target starting to send R2T in advance to compensate for latency might end-up with less data than expected . Now the only condition we have to take care is "Incorrect amount of data" and I renamed the condition to that. The text reads also: The target reports the "Incorrect amount of data" condition if dur-ing data output the total data length to output is greater than First-BurstSize, but the initiator sent an amount different than FirstBurstSize of unsolicited non-immediate data or the amount of data sent as a reply to an R2T does not match the amount requested. Julo pat_thaler@agilent.com Sent by: owner-ips@ece.cmu.edu 06/15/2002 12:15 AM Please respond to pat_thaler To: ips@ece.cmu.edu cc: Subject: RE: iSCSI: FirstBurstSize and unsolicited data RE: > > The target reports the "Not enough unsolicited data" condition only > if it does not support output (write) operations in which the total > data length is greater than FirstBurstSize, but the initiator sent > less than FirstBurstSize amount of unsolicited data, and out-of-order > R2Ts cannot be used. > > This text does seem strange. Why does it say "only if it does not support output (write) operations in which" the initiator sent less data than the standard requires? Why would the target support that given that the initiator is required to send FirstBurstSize of unsolicited data if it sends non-immediate data PDUs (and total data length is greater than FirstBurstSize). Even out-of-order R2Ts are enabled, the target shouldn't be required to send an R2T for data that should have been sent unsolicited. This will complicate implementations. The text also doesn't deal with cases where the Initiator sent only Immediate data. Also it doesn't deal with cases where the transfer is less than First Burst size and the initiator sent non-immediate unsolicited data with a length less than the required amount. I think the text should be "The target reports the "Not enough unsolicited data" condition if the Initiator sent non-Immediate unsolicited data with a totla unsolicited data length less than the smaller of FirstBurstSize and Expected Data Transfer Length." It also isn't clear why this error has an iSCSI condition code while other similar errors do not. In particular, it is just as possible that an Initiator sends less data in response to an explicit R2T. When it sends less unsolicited data than it should, it is violating an implicit R2T. Why is violation of an implicit R2T different from violation of an explicit R2T? And why is sending less data than expected flagged with a Sense Data error but sending more data than expected is not? Regards, Pat --=_alternative 005C9DEDC2256BDE_= Content-Type: text/html; charset="us-ascii"
Pat,

That piece is a leftover (together with the piece found by Ron) from the time neither FirstBurstSize nor R2T where mandatory to fullfill.
FirstBurstSize was particularly nasty because if not done properly a target starting to send R2T in advance to compensate for latency
might end-up with less data than expected .

Now the only condition we have to take care is "Incorrect amount of data" and I renamed the condition to that.

The text reads also:

The target reports the "Incorrect amount of data" condition if dur-ing data output the total data length to output is greater than First-BurstSize, but the initiator sent an amount different than FirstBurstSize of unsolicited non-immediate data or the amount of data sent as a reply to an R2T does not match the amount requested.

Julo


pat_thaler@agilent.com
Sent by: owner-ips@ece.cmu.edu

06/15/2002 12:15 AM
Please respond to pat_thaler

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        RE: iSCSI: FirstBurstSize and unsolicited data

       



RE:
>
> The target reports the "Not enough unsolicited data" condition only
> if it does not support output (write) operations in which the total
> data length is greater than FirstBurstSize, but the initiator sent
> less than FirstBurstSize amount of unsolicited data, and out-of-order
> R2Ts cannot be used.
>
> </quote>

This text does seem strange. Why does it say "only if it does not support output (write) operations in which" the initiator sent less data than the standard requires?
Why would the target support that given that the initiator is required to send FirstBurstSize of unsolicited data if it sends non-immediate data PDUs (and total data length is greater than FirstBurstSize). Even out-of-order R2Ts are enabled, the target shouldn't be required to send an R2T for data that should have been sent unsolicited. This will complicate implementations.

The text also doesn't deal with cases where the Initiator sent only Immediate data.

Also it doesn't deal with cases where the transfer is less than First Burst size and the initiator sent non-immediate unsolicited data with a length less than the required amount.

I think the text should be

"The target reports the "Not enough unsolicited data" condition if the Initiator sent  non-Immediate unsolicited data with a totla unsolicited data length less than the smaller of FirstBurstSize and Expected Data Transfer Length."

It also isn't clear why this error has an iSCSI condition code while other similar errors do not. In particular, it is just as possible that an Initiator sends less data in response to an explicit R2T. When it sends less unsolicited data than it should, it is violating an implicit R2T. Why is violation of an implicit R2T different from violation of an explicit R2T? And why is sending less data than expected flagged with a Sense Data error but sending more data than expected is not?

Regards,
Pat

--=_alternative 005C9DEDC2256BDE_=-- From owner-ips@ece.cmu.edu Thu Jun 20 15:22:30 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11063 for ; Thu, 20 Jun 2002 15:22:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5KIJZU16221 for ips-outgoing; Thu, 20 Jun 2002 14:19:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5KIJWw16214; Thu, 20 Jun 2002 14:19:32 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 187C3184B; Thu, 20 Jun 2002 12:19:31 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 52294166; Thu, 20 Jun 2002 12:19:30 -0600 (MDT) Received: from 130.29.152.143 by axcsbh1.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 20 Jun 2002 12:19:29 -0600 Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Jun 2002 12:19:28 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C891B6C@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Julian Satran , "KRUEGER,MARJORIE (HP-Roseville,ex1)" Cc: ips@ece.cmu.edu, Julo-Actcom , owner-ips@ece.cmu.edu, "THALER,PAT (A-Roseville,ex1)" Subject: RE: iSCSI: Negotiating a parameter more than once Date: Thu, 20 Jun 2002 12:19:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-95a33ea6-8478-11d6-bae4-009027404a4a" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-95a33ea6-8478-11d6-bae4-009027404a4a Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21886.FE8860B0" ------_=_NextPart_001_01C21886.FE8860B0 Content-Type: text/plain; charset="ISO-8859-1" Julian, Whether the discovery session is long lived or not isn't really relevant to whether SendTargets can be offerred more than once per a negotiation _sequence_ since there can be multiple negotiation sequences during a discovery session. Keeping a discovery session open and sending SendTargets multiple times in a discovery session is specifically allowed (Appendix D page 249 just before the examples). The draft is silent on whether that is allowed within the same negotiation sequence. IMO, since it is simple for the initiator to start a new negotiation sequence by sending a Text Request after the last sequence finishes, there isn't any reason to complicate things by allowing multiple SendTargets within a sequence. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, June 19, 2002 11:58 PM To: KRUEGER,MARJORIE (HP-Roseville,ex1) Cc: ips@ece.cmu.edu; Julo-Actcom; owner-ips@ece.cmu.edu; 'THALER,PAT (A-Roseville,ex1)' Subject: RE: iSCSI: Negotiating a parameter more than once Marjorie, We discussed this repeatedly in the past and I recall that except the dissenting voice of Mark Bakke the agreement was that long-lived discovery sessions are not considered useful. Julo "KRUEGER,MARJORIE (HP-Roseville,ex1)" Sent by: owner-ips@ece.cmu.edu 06/19/2002 09:31 PM Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'THALER,PAT (A-Roseville,ex1)'" , Julo-Actcom , ips@ece.cmu.edu cc: Subject: RE: iSCSI: Negotiating a parameter more than once In the context of the two keys that are valid during FFP, neither of these suggested edits to that paragraph make sense. Currently, there is no "negotiation" key that's valid in FFP, and the "declarative" keys that are valid, - SendTargets and MaxPDUDataLength *can* validly be repeated. If an initiator opens a discovery session, it may keep it open, and it may repeat SendTargets requests as it deems necessary to keep it's target information up to date. In the course of a SendTargets response, the target validly repeats certain keys. The MaxPDUDataLength key can be sent by the initiator as often as the PMTU changes. Why not just delete this paragraph? In the future if there are keys added that are valid during FFP, the RFC that specifies those keys can specify whether or not they can be "renegotiated". Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard -----Original Message----- From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@agilent.com] Sent: Wednesday, June 19, 2002 10:19 AM To: Julo-Actcom; ips@ece.cmu.edu Subject: RE: iSCSI: Negotiating a parameter more than once Julian, If declarations should not be repeated (except for those where it is explicitly allowed), then it should be "negotiate or declare" because "negotiate" doesn't cover declarations. Alternatively, one could add an explicit definition that "Negotiate" includes both declarations and negotiations. Secondly, SendTargets is not a valid example for login as it is FFPO. I think the only parameter explicitly allowed to be duplicated during Login is TargetAddress (when returned as a result of a redirect). Furthermore, I can not find any explicit statement that SendTargets may be repeated during a FFP negotiation sequence. Only TargetName and TargetAddress have explicit text allowing them to be repeated (in Appendix B for both and in the description of redirection for LoginResponse for TargetAddress). Therefore, I suggest: For 4.3: Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during login except for responses to specific keys that explicitly allow repeated key declarations (e.g. TargetAddress). If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection For 4.4: Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during any negotiation sequence without an intervening reset except for responses to specific keys that explicitly allow repeated key declarations (e.g. TargetAddress). If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above. Pat -----Original Message----- From: Julo-Actcom [mailto:Julian_Satran@actcom.net.il] Sent: Tuesday, June 18, 2002 10:12 PM To: ips@ece.cmu.edu Subject: RE: iSCSI: Negotiating a parameter more than once Pat, 4.3 and 4.4 cover two diferent phases. Parameters should not be negotiated or declared twice. I think that you refer to the responses to SendTargets - those contain more than an instance of the declarations and have to outlined. How about the following text in 4.4: Neither the initiator nor the target should attempt to negotiate a parameter more than once during login except for responses to specific keys that explicitly allow repeated key declarations (e.g. SendTargets). If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection. and in 4.4: Neither the initiator nor the target should attempt to negotiate a parameter more than once during any negotiation sequence without an intervening reset except for responses to specific keys that explicitly allow repeated key declarations. If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above. Julo _____ * To: Julian_Satran@il.ibm.com * Subject: iSCSI: Negotiating a parameter more than once * From: pat_thaler@agilent.com * Date: Mon, 17 Jun 2002 16:18:43 -0600 * Cc: ips@ece.cmu.edu * Content-Type: text/plain;charset="ISO-8859-1" * Sender: owner-ips@ece.cmu.edu _____ Julian, The following text appears in 4.3 (page 78 just before 4.3.1): Neither the initiator nor the target should attempt to negotiate a parameter more than once during login. If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection. and nearly the same text in 4.4 (page 85 near the end): Neither the initiator nor the target should attempt to negotiate a parameter more than once during any negotiation sequence without an intervening reset. If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above. This is confusing partly because "negotiate" seems to be generally used covering both negotiations and declarations and in some cases covering only negotiations. It isn't clear in which sense it is used. If the text above applies only to negotiated values, then it would be allowable to send parameters such as Initiator Name, SessionType, and MaxRecvDataSegmentLength over which doesn't seem to be a good idea. However, there are other declarative parameters which are sent multiple times - SendTargets where there are multiple targets or multiple addresses for a target requires sending the same parameter multiple times. Perhaps the text should be changed to: Neither the initiator nor the target should attempt to declare or negotiate a parameter other than TargetName, TargetAlias or TargetAddress more than once.... Regards, Pat _____ * Prev by Date: RE: iSCSI: use of Text/Login with no data segment * Next by Date: RE: iSCSI: Negotiating a parameter more than once * Prev by thread: iSCSI 0.13 vs. iSCSI Plugfest * Next by thread: RE: iSCSI: Negotiating a parameter more than once * Index(es): * Date * Thread * * ------_=_NextPart_001_01C21886.FE8860B0 Content-Type: text/html; charset="ISO-8859-1"
Julian,
 
Whether the discovery session is long lived or not isn't really relevant to whether SendTargets can be offerred more than once per a negotiation _sequence_ since there can be multiple negotiation sequences during a discovery session. Keeping a discovery session open and sending SendTargets multiple times in a discovery session is specifically allowed (Appendix D page 249 just before the examples). The draft is silent on whether that is allowed within the same negotiation sequence.
 
IMO, since it is simple for the initiator to start a new negotiation sequence by sending a Text Request after the last sequence finishes, there isn't any reason to complicate things by allowing multiple SendTargets within a sequence.
 
Regards,
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 19, 2002 11:58 PM
To: KRUEGER,MARJORIE (HP-Roseville,ex1)
Cc: ips@ece.cmu.edu; Julo-Actcom; owner-ips@ece.cmu.edu; 'THALER,PAT (A-Roseville,ex1)'
Subject: RE: iSCSI: Negotiating a parameter more than once


Marjorie,

We discussed this repeatedly in the past and I recall that except the dissenting voice of Mark Bakke the agreement was that long-lived discovery sessions are not considered useful.

Julo


"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
Sent by: owner-ips@ece.cmu.edu

06/19/2002 09:31 PM
Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"

       
        To:        "'THALER,PAT (A-Roseville,ex1)'" <pat_thaler@agilent.com>, Julo-Actcom <Julian_Satran@actcom.net.il>, ips@ece.cmu.edu
        cc:        
        Subject:        RE: iSCSI: Negotiating a parameter more than once

       


In the context of the two keys that are valid during FFP, neither of these suggested edits to that paragraph make sense.  Currently, there is no "negotiation" key that's valid in FFP, and the "declarative" keys that are valid, - SendTargets and MaxPDUDataLength *can* validly be repeated.  If an initiator opens a discovery session, it may keep it open, and it may repeat SendTargets requests as it deems necessary to keep it's target information up to date.  In the course of a SendTargets response, the target validly repeats certain keys.  The MaxPDUDataLength key can be sent by the initiator as often as the PMTU changes.
 
Why not just delete this paragraph?  In the future if there are keys added that are valid during FFP, the RFC that specifies those keys can specify whether or not they can be "renegotiated".
 
Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard

-----Original Message-----
From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@agilent.com]
Sent: Wednesday, June 19, 2002 10:19 AM
To: Julo-Actcom; ips@ece.cmu.edu
Subject: RE: iSCSI: Negotiating a parameter more than once

Julian,
 
If declarations should not be repeated (except for those where it is explicitly allowed), then it should be "negotiate or declare" because "negotiate" doesn't cover declarations. Alternatively, one could add an explicit definition that "Negotiate" includes both declarations and negotiations. Secondly, SendTargets is not a valid example for login as it is FFPO. I think the only parameter explicitly allowed to be duplicated during Login is TargetAddress (when returned as a result of a redirect). Furthermore, I can not find any explicit statement that SendTargets may be repeated during a FFP negotiation sequence. Only TargetName and TargetAddress have explicit text allowing them to be repeated (in Appendix B for both and in the description of redirection for LoginResponse for TargetAddress).
 
Therefore, I suggest:
For 4.3:
Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during login except for responses to specific keys that explicitly allow repeated key declarations (e.g. TargetAddress). If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection
 
For 4.4:
Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during any negotiation sequence without an intervening reset except for responses to specific keys that explicitly allow repeated key declarations (e.g. TargetAddress). If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above.
 
Pat
-----Original Message-----
From: Julo-Actcom [mailto:Julian_Satran@actcom.net.il]
Sent: Tuesday, June 18, 2002 10:12 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI: Negotiating a parameter more than once

Pat,
 
4.3 and 4.4 cover two diferent phases.
Parameters should not be negotiated or declared twice.
 
I think that you refer to the responses to SendTargets - those contain more than an instance of the declarations and have to outlined.
 
How about the following text in 4.4:
 

Neither the initiator nor the target should attempt to negotiate a parameter more than once during login except for responses to specific keys that explicitly allow repeated key declarations (e.g. SendTargets). If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection.

and in 4.4:

Neither the initiator nor the target should attempt to negotiate a parameter more than once during any negotiation sequence without an intervening reset except for responses to specific keys that explicitly allow repeated key declarations. If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above.

Julo

  • To: Julian_Satran@il.ibm.com
  • Subject: iSCSI: Negotiating a parameter more than once
  • From: pat_thaler@agilent.com
  • Date: Mon, 17 Jun 2002 16:18:43 -0600
  • Cc: ips@ece.cmu.edu
  • Content-Type: text/plain;charset="ISO-8859-1"
  • Sender: owner-ips@ece.cmu.edu

    Julian,

    The following text appears in 4.3 (page 78 just before 4.3.1):

    Neither the initiator nor the target should attempt to negotiate a
    parameter more than once during login. If detected by the target this
    MUST result in a Login reject (initiator error). The initiator MUST
    drop the connection.

    and nearly the same text in 4.4 (page 85 near the end):

    Neither the initiator nor the target should attempt to negotiate a
    parameter more than once during any negotiation sequence without an
    intervening reset. If detected by the target this MUST result in a
    Reject with a reason of "protocol error". The initiator MUST reset
    the negotiation as outlined above.

    This is confusing partly because "negotiate" seems to be generally used covering both negotiations and declarations and in some cases covering only negotiations. It isn't clear in which sense it is used. If the text above applies only to negotiated values, then it would be allowable to send parameters such as Initiator Name, SessionType, and MaxRecvDataSegmentLength over which doesn't seem to be a good idea. However, there are other declarative parameters which are sent multiple times - SendTargets where there are multiple targets or multiple addresses for a target requires sending the same parameter multiple times.

    Perhaps the text should be changed to:

    Neither the initiator nor the target should attempt to declare or negotiate a
    parameter other than TargetName, TargetAlias or TargetAddress more than once....

    Regards,
    Pat

------_=_NextPart_001_01C21886.FE8860B0-- ------=_NextPartTM-000-95a33ea6-8478-11d6-bae4-009027404a4a-- From owner-ips@ece.cmu.edu Fri Jun 21 02:56:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02945 for ; Fri, 21 Jun 2002 02:56:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5L6Bob23538 for ips-outgoing; Fri, 21 Jun 2002 02:11:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5L6Bhw23528 for ; Fri, 21 Jun 2002 02:11:43 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5L6BaXj015308; Fri, 21 Jun 2002 08:11:36 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5L6Ba720436; Fri, 21 Jun 2002 08:11:36 +0200 To: "Eddy Quicksall" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: FirstBurstSize and unsolicited data X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 21 Jun 2002 09:11:33 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 21/06/2002 09:11:35, Serialize complete at 21/06/2002 09:11:35 Content-Type: multipart/alternative; boundary="=_alternative 0021AE17C2256BDF_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0021AE17C2256BDF_= Content-Type: text/plain; charset="us-ascii" Eddy, I assume you meant EDTL not DSL and then the answer is yes and I again forgot to subtract the immediate. A better formulation would be: The target reports the "Incorrect amount of data" condition if dur-ing data output the total data length to output is greater than First-BurstSize and the initiator sent unsolicited non-immediate data but the total amount of unsolicited data is different than FirstBurst-Size. The target reports the same error when the amount of data sent as a reply to an R2T does not match the amount requested. Julo "Eddy Quicksall" 06/21/2002 12:22 AM Please respond to "Eddy Quicksall" To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: iSCSI: FirstBurstSize and unsolicited data Isn't this saying that if DSL > FirstBurstSize, it would be incorrect to send non-immediate unsolicited which is not equal to FirstBurstSize? The target reports the "Incorrect amount of data" condition if dur-ing data output the total data length to output is greater than First-BurstSize, but the initiator sent an amount different than FirstBurstSize of unsolicited non-immediate data or the amount of data sent as a reply to an R2T does not match the amount requested. Eddy --=_alternative 0021AE17C2256BDF_= Content-Type: text/html; charset="us-ascii"
Eddy,

I assume you meant EDTL not DSL and then the answer is yes and I again forgot to subtract  the immediate. A better formulation would be:

The target reports the "Incorrect amount of data" condition if dur-ing data output the total data length to output is greater than First-BurstSize and the initiator sent unsolicited non-immediate data but the total amount of unsolicited data is different than FirstBurst-Size. The target reports the same error when the amount of data sent as a reply to an R2T does not match the amount requested.

Julo



"Eddy Quicksall" <Eddy@Quicksall.com>

06/21/2002 12:22 AM
Please respond to "Eddy Quicksall"

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        
        Subject:        RE: iSCSI: FirstBurstSize and unsolicited data

       


Isn't this saying that if DSL > FirstBurstSize, it would be incorrect to send non-immediate unsolicited which is not equal to FirstBurstSize?
 
The target reports the "Incorrect amount of data" condition if dur-ing data output the total data length to output is greater than First-BurstSize, but the initiator sent an amount different than FirstBurstSize of unsolicited non-immediate data or the amount of data sent as a reply to an R2T does not match the amount requested.
 
Eddy

--=_alternative 0021AE17C2256BDF_=-- From owner-ips@ece.cmu.edu Fri Jun 21 05:17:39 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05216 for ; Fri, 21 Jun 2002 05:17:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5L8YNV05987 for ips-outgoing; Fri, 21 Jun 2002 04:34:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hclnpd.hclt.co.in ([202.54.64.7]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5L8YKw05899 for ; Fri, 21 Jun 2002 04:34:20 -0400 (EDT) Received: from mailnpd.hclt-ntl.co.in ([192.168.19.36]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MR12XGKM; Fri, 21 Jun 2002 14:03:33 +0530 Received: from nramamurpc (nramamur-pc.hclt-ntl.co.in [192.168.19.98]) by mailnpd.hclt-ntl.co.in (8.11.0/8.11.0) with SMTP id g5L8PtL17243; Fri, 21 Jun 2002 13:55:56 +0530 Message-ID: <008901c218fe$a6b5b040$6213a8c0@hcltech.com> From: "Nandakumar Ramamurthy" To: "Julian Satran" Cc: References: Subject: Re: iSCSI: FirstBurstSize and unsolicited data Date: Fri, 21 Jun 2002 14:05:50 +0530 Organization: HCL Technologies Ltd. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0086_01C2192C.BFD30BD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0086_01C2192C.BFD30BD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have been following the discussion on this thread. I still have certain doubts regarding the conditions I specified in my original mail. The conditions are : FirstBurstSize =3D 64KB EDTL =3D 100KB ( EDTL > FirstBurstSize) MaxRecvDataSegmentLength =3D 8KB ImmediateData =3D Yes InitialR2T =3D Yes In the above case the initiator cannot send unsolicited Data-out PDUs. Here unsolicited data(ImmediateData) < FirstBurstSize. Will the target report any error in this case? The modified text for Section 9.4.6.2 only refers to the cases where unsolicited Data-outs can be sent. Please clarify if I am missing something very obvious. Thanks, Nandakumar Member Technical Staff HCL Technologies, Chennai, INDIA. http://san.hcltech.com ----- Original Message -----=20 From: Julian Satran=20 To: Eddy Quicksall=20 Cc: ips@ece.cmu.edu=20 Sent: Friday, June 21, 2002 11:41 AM Subject: RE: iSCSI: FirstBurstSize and unsolicited data Eddy,=20 I assume you meant EDTL not DSL and then the answer is yes and I again = forgot to subtract the immediate. A better formulation would be:=20 The target reports the "Incorrect amount of data" condition if dur-ing = data output the total data length to output is greater than = First-BurstSize and the initiator sent unsolicited non-immediate data = but the total amount of unsolicited data is different than = FirstBurst-Size. The target reports the same error when the amount of = data sent as a reply to an R2T does not match the amount requested.=20 Julo=20 "Eddy Quicksall" =20 06/21/2002 12:22 AM=20 Please respond to "Eddy Quicksall"=20 =20 To: Julian Satran/Haifa/IBM@IBMIL=20 cc: =20 Subject: RE: iSCSI: FirstBurstSize and = unsolicited data=20 =20 Isn't this saying that if DSL > FirstBurstSize, it would be incorrect = to send non-immediate unsolicited which is not equal to FirstBurstSize?=20 =20 The target reports the "Incorrect amount of data" condition if dur-ing = data output the total data length to output is greater than = First-BurstSize, but the initiator sent an amount different than = FirstBurstSize of unsolicited non-immediate data or the amount of data = sent as a reply to an R2T does not match the amount requested.=20 =20 Eddy=20 ------=_NextPart_000_0086_01C2192C.BFD30BD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I have been following the discussion on = this=20 thread.
 
I still have certain doubts regarding=20 the
conditions I specified in my original=20 mail.
 
The conditions are :
 
FirstBurstSize =3D 64KB
EDTL =3D 100KB ( EDTL >=20 FirstBurstSize)
MaxRecvDataSegmentLength =3D = 8KB
ImmediateData =3D Yes
InitialR2T =3D Yes
 
In the above case the initiator cannot = send=20 unsolicited Data-out PDUs.
Here unsolicited data(ImmediateData) < FirstBurstSize.
 
Will the target report any error in this case?
 
The modified=20 text for Section 9.4.6.2 only refers to the cases
where unsolicited Data-outs can be sent.
 
Please clarify if I am missing = something very=20 obvious.
 
 
Thanks,
Nandakumar
Member Technical = Staff
HCL=20 Technologies, Chennai, INDIA.
http://san.hcltech.com
 
 
----- Original Message -----
From:=20 Julian Satran
Sent: Friday, June 21, 2002 = 11:41=20 AM
Subject: RE: iSCSI: = FirstBurstSize and=20 unsolicited data


Eddy,

I=20 assume you meant EDTL not DSL and then the answer is yes and I again = forgot to=20 subtract  the immediate. A better formulation would be:=20

The target reports the = "Incorrect=20 amount of data" condition if dur-ing data output the total data length = to=20 output is greater than First-BurstSize and the initiator sent = unsolicited=20 non-immediate data but the total amount of unsolicited data is = different than=20 FirstBurst-Size. The target reports the same error when the amount of = data=20 sent as a reply to an R2T does not match the amount requested.=20

Julo



"Eddy Quicksall"=20 <Eddy@Quicksall.com>=20

06/21/2002 12:22 AM =
Please respond to "Eddy = Quicksall"=20

        =
        To: =    =20    Julian Satran/Haifa/IBM@IBMIL
        cc: =    =20    
  =  =20     Subject:        RE: iSCSI:=20 FirstBurstSize and unsolicited data

      =  


Isn't this saying that if DSL >=20 FirstBurstSize, it would be incorrect to send non-immediate = unsolicited which=20 is not equal to FirstBurstSize?
 
The = target reports=20 the "Incorrect amount of data" condition if dur-ing data output the = total data=20 length to output is greater than First-BurstSize, but the initiator = sent an=20 amount different than FirstBurstSize of unsolicited non-immediate data = or the=20 amount of data sent as a reply to an R2T does not match the amount=20 requested. =
 
Eddy

------=_NextPart_000_0086_01C2192C.BFD30BD0-- From owner-ips@ece.cmu.edu Fri Jun 21 06:34:25 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06523 for ; Fri, 21 Jun 2002 06:34:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5L9fUu12282 for ips-outgoing; Fri, 21 Jun 2002 05:41:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5L9egw12255 for ; Fri, 21 Jun 2002 05:40:51 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5L9eI3o035112; Fri, 21 Jun 2002 11:40:18 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5L9eHT64228; Fri, 21 Jun 2002 11:40:17 +0200 To: "Nandakumar Ramamurthy" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: FirstBurstSize and unsolicited data X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 21 Jun 2002 12:40:08 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 21/06/2002 12:40:17, Serialize complete at 21/06/2002 12:40:17 Content-Type: multipart/alternative; boundary="=_alternative 003420B1C2256BDF_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 003420B1C2256BDF_= Content-Type: text/plain; charset="us-ascii" I don't know what your original mail was :-) Julo "Nandakumar Ramamurthy" 06/21/2002 11:35 AM Please respond to "Nandakumar Ramamurthy" To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: Re: iSCSI: FirstBurstSize and unsolicited data Hi, I have been following the discussion on this thread. I still have certain doubts regarding the conditions I specified in my original mail. The conditions are : FirstBurstSize = 64KB EDTL = 100KB ( EDTL > FirstBurstSize) MaxRecvDataSegmentLength = 8KB ImmediateData = Yes InitialR2T = Yes In the above case the initiator cannot send unsolicited Data-out PDUs. Here unsolicited data(ImmediateData) < FirstBurstSize. Will the target report any error in this case? The modified text for Section 9.4.6.2 only refers to the cases where unsolicited Data-outs can be sent. Please clarify if I am missing something very obvious. Thanks, Nandakumar Member Technical Staff HCL Technologies, Chennai, INDIA. http://san.hcltech.com ----- Original Message ----- From: Julian Satran To: Eddy Quicksall Cc: ips@ece.cmu.edu Sent: Friday, June 21, 2002 11:41 AM Subject: RE: iSCSI: FirstBurstSize and unsolicited data Eddy, I assume you meant EDTL not DSL and then the answer is yes and I again forgot to subtract the immediate. A better formulation would be: The target reports the "Incorrect amount of data" condition if dur-ing data output the total data length to output is greater than First-BurstSize and the initiator sent unsolicited non-immediate data but the total amount of unsolicited data is different than FirstBurst-Size. The target reports the same error when the amount of data sent as a reply to an R2T does not match the amount requested. Julo "Eddy Quicksall" 06/21/2002 12:22 AM Please respond to "Eddy Quicksall" To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: iSCSI: FirstBurstSize and unsolicited data Isn't this saying that if DSL > FirstBurstSize, it would be incorrect to send non-immediate unsolicited which is not equal to FirstBurstSize? The target reports the "Incorrect amount of data" condition if dur-ing data output the total data length to output is greater than First-BurstSize, but the initiator sent an amount different than FirstBurstSize of unsolicited non-immediate data or the amount of data sent as a reply to an R2T does not match the amount requested. Eddy --=_alternative 003420B1C2256BDF_= Content-Type: text/html; charset="us-ascii"
I don't know what your original mail was :-) Julo


"Nandakumar Ramamurthy" <nramamur@npd.hcltech.com>

06/21/2002 11:35 AM
Please respond to "Nandakumar Ramamurthy"

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        <ips@ece.cmu.edu>
        Subject:        Re: iSCSI: FirstBurstSize and unsolicited data

       


Hi,
 
I have been following the discussion on this thread.
 
I still have certain doubts regarding the
conditions I specified in my original mail.
 
The conditions are :
 
FirstBurstSize = 64KB
EDTL = 100KB ( EDTL > FirstBurstSize)
MaxRecvDataSegmentLength = 8KB
ImmediateData = Yes
InitialR2T = Yes
 
In the above case the initiator cannot send unsolicited Data-out PDUs.
Here unsolicited data(ImmediateData) < FirstBurstSize.
 
Will the target report any error in this case?
 
The modified text for Section 9.4.6.2 only refers to the cases
where unsolicited Data-outs can be sent.
 
Please clarify if I am missing something very obvious.
 
 
Thanks,
Nandakumar
Member Technical Staff
HCL Technologies, Chennai, INDIA.
http://san.hcltech.com
 
 
----- Original Message -----
From: Julian Satran
To: Eddy Quicksall
Cc: ips@ece.cmu.edu
Sent: Friday, June 21, 2002 11:41 AM
Subject: RE: iSCSI: FirstBurstSize and unsolicited data


Eddy,

I assume you meant EDTL not DSL and then the answer is yes and I again forgot to subtract  the immediate. A better formulation would be:

The target reports the "Incorrect amount of data" condition if dur-ing data output the total data length to output is greater than First-BurstSize and the initiator sent unsolicited non-immediate data but the total amount of unsolicited data is different than FirstBurst-Size. The target reports the same error when the amount of data sent as a reply to an R2T does not match the amount requested.

Julo


"Eddy Quicksall" <Eddy@Quicksall.com>

06/21/2002 12:22 AM
Please respond to "Eddy Quicksall"

       
       To:        Julian Satran/Haifa/IBM@IBMIL
       cc:        
       Subject:        RE: iSCSI: FirstBurstSize and unsolicited data

     



Isn't this saying that if DSL > FirstBurstSize, it would be incorrect to send non-immediate unsolicited which is not equal to FirstBurstSize?
 
The target reports the "Incorrect amount of data" condition if dur-ing data output the total data length to output is greater than First-BurstSize, but the initiator sent an amount different than FirstBurstSize of unsolicited non-immediate data or the amount of data sent as a reply to an R2T does not match the amount requested.
 
Eddy


--=_alternative 003420B1C2256BDF_=-- From owner-ips@ece.cmu.edu Fri Jun 21 07:04:30 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07154 for ; Fri, 21 Jun 2002 07:04:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5LAOCV13904 for ips-outgoing; Fri, 21 Jun 2002 06:24:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5L4v2w20370 for ; Fri, 21 Jun 2002 00:57:02 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5KGWpPI014260; Thu, 20 Jun 2002 09:32:51 -0700 (PDT) Received: from SMOFFETT-W2K1.cisco.com (sjc-vpn3-450.cisco.com [10.21.65.194]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA03123; Thu, 20 Jun 2002 09:31:30 -0700 (PDT) Message-Id: <4.3.2.7.2.20020620092612.01a224d8@mira-sjc5-7.cisco.com> X-Sender: smoffett@mira-sjc5-7.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Jun 2002 09:31:30 -0700 To: From: Steve Moffett Subject: RE: FC Mgmt mib Cc: "'Keith McCloghrie'" , charissa.willard@sanvalley.com, arvindp@cisco.com, ips@ece.cmu.edu, sriramnj@cisco.com, nramesh@cisco.com, gklee@cisco.com, cshen@cisco.com, jcham@cisco.com In-Reply-To: <73DE11092C445F478CB3629910B2F494B8A4AF@webmail.sanvalley.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ips@ece.cmu.edu Precedence: bulk Charissa, Thanks for helping us move forward. Please keep us advise if there are any other issues with this mib we need to review and resolve on Eports and credits. Again,thanks for your response. Regards, Steve At 02:42 PM 6/19/2002 -0700, charissa.willard@sanvalley.com wrote: >Keith, > >That solution sounds good to me. > >Thanks, >Charissa > > > -----Original Message----- > > From: Keith McCloghrie [mailto:kzm@cisco.com] > > Sent: Wednesday, June 19, 2002 2:39 PM > > To: charissa.willard@sanvalley.com > > Cc: kzm@cisco.com; arvindp@cisco.com; ips@ece.cmu.edu; > > smoffett@cisco.com; sriramnj@cisco.com; nramesh@cisco.com; > > gklee@cisco.com > > Subject: Re: FC Mgmt mib > > > > > > Charissa, > > > > Sorry for the delay, but I have spoken with Arvind and he agrees > > that "encapsulates FC frames within another protocol" is a wide > > enough scope to cover his device, and thus, you're right that no > > change is needed for the FcUnitFunction TC. > > > > Further, the two objects within the current fcmEPortTable (i.e., > > fcmEPortClassFCredit and fcmEPortClassFDataFieldSize) can both be > > applied to Arvind's device. Now, you comment that > > fcmEPortClassFCredit > > applies to B_Ports, and I'm confident that fcmEPortClassFDataFieldSize > > does also. Thus, the fcmEPortTable actually applies to E_Ports and > > B_Ports. So, rather than have separate tables for B_Ports > > and E_Ports, > > with the same objects defined in both (i.e., a duplication), I'd like > > to use the existing table for both types. All that is required is to > > change the name to, say, the fcmInterSwitchPortTable (which is roughly > > what you suggested in your previous message), and update its > > definition > > to say it applies to E_Ports, B_Ports and any other type of port which > > interfaces to an inter-switch link. > > > > If you agree, I'll go ahead and update the MIB. > > > > Keith. > > > > > > > Keith, > > > > > > > > > > > 3. A new table for 'tunnel' ports > > > > > > > > - I'd rather not add a new table unless it's absolutely necessary. > > > > How about I just broaden the scope of the fcmEPortTable so that > > > > it applies not only to E_Ports but also to 'tunnel' ports ?? > > > > > > > > > > > The MIB will also need a new group for devices supporting 'tunnel' > > > > functionality, which will contain just fcmEPortClassFCredit > > > > and fcmEPortClassFDataFieldSize, right ?? > > > > > > For FC over IP a port can be either a B_port or an E_port. > > A B_port supports > > > Class F frames and thus could at least use the Class F > > BB_Credit object that > > > you specified in fcmEPortTable. > > > > > > The MIB defines the FcUnitFunction type of 'bridge' as > > "encapsulates FC > > > frames within another protocol". Doesn't this imply "tunneling"? > > > > > > Since a B_port is transparent to the Fabric, just providing > > a table for > > > B_Ports may provide a solution for other devices/ports that > > are transparent > > > to the Fabric and need an object for BB_Credit. > > > > > > Thanks, > > > Charissa > > > > > From owner-ips@ece.cmu.edu Fri Jun 21 07:12:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07391 for ; Fri, 21 Jun 2002 07:12:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5LAq4a15070 for ips-outgoing; Fri, 21 Jun 2002 06:52:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hclnpd.hclt.co.in ([202.54.64.7]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5LAq1w15065 for ; Fri, 21 Jun 2002 06:52:01 -0400 (EDT) Received: from mailnpd.hclt-ntl.co.in ([192.168.19.36]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MR12XH8S; Fri, 21 Jun 2002 16:21:14 +0530 Received: from nramamurpc (nramamur-pc.hclt-ntl.co.in [192.168.19.98]) by mailnpd.hclt-ntl.co.in (8.11.0/8.11.0) with SMTP id g5LAhbL21479 for ; Fri, 21 Jun 2002 16:13:37 +0530 Message-ID: <028801c21911$e2e6a520$6213a8c0@hcltech.com> From: "Nandakumar Ramamurthy" To: References: Subject: Re: iSCSI: FirstBurstSize and unsolicited data Date: Fri, 21 Jun 2002 16:23:33 +0530 Organization: HCL Technologies Ltd. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0285_01C2193F.FC8E3F50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0285_01C2193F.FC8E3F50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is my original mail. http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10803.html As the modified text (for 9.4.6.2) still specifies the case of unsolicited non-immediate data and is not clear how a target must respond to the case specified in my mail, further clarifications are sought. Thanks, Nandakumar. ----- Original Message -----=20 From: Julian Satran=20 To: Nandakumar Ramamurthy=20 Cc: ips@ece.cmu.edu=20 Sent: Friday, June 21, 2002 3:10 PM Subject: Re: iSCSI: FirstBurstSize and unsolicited data I don't know what your original mail was :-) Julo=20 "Nandakumar Ramamurthy" =20 06/21/2002 11:35 AM=20 Please respond to "Nandakumar Ramamurthy"=20 =20 To: Julian Satran/Haifa/IBM@IBMIL=20 cc: =20 Subject: Re: iSCSI: FirstBurstSize and = unsolicited data=20 =20 Hi,=20 =20 I have been following the discussion on this thread.=20 =20 I still have certain doubts regarding the=20 conditions I specified in my original mail.=20 =20 The conditions are :=20 =20 FirstBurstSize =3D 64KB=20 EDTL =3D 100KB ( EDTL > FirstBurstSize)=20 MaxRecvDataSegmentLength =3D 8KB=20 ImmediateData =3D Yes=20 InitialR2T =3D Yes=20 =20 In the above case the initiator cannot send unsolicited Data-out PDUs. = Here unsolicited data(ImmediateData) < FirstBurstSize.=20 =20 Will the target report any error in this case?=20 =20 The modified text for Section 9.4.6.2 only refers to the cases=20 where unsolicited Data-outs can be sent.=20 =20 Please clarify if I am missing something very obvious.=20 =20 =20 Thanks,=20 Nandakumar Member Technical Staff HCL Technologies, Chennai, INDIA. http://san.hcltech.com=20 =20 =20 ----- Original Message -----=20 From: Julian Satran=20 To: Eddy Quicksall=20 Cc: ips@ece.cmu.edu=20 Sent: Friday, June 21, 2002 11:41 AM=20 Subject: RE: iSCSI: FirstBurstSize and unsolicited data=20 Eddy,=20 I assume you meant EDTL not DSL and then the answer is yes and I again = forgot to subtract the immediate. A better formulation would be:=20 The target reports the "Incorrect amount of data" condition if dur-ing = data output the total data length to output is greater than = First-BurstSize and the initiator sent unsolicited non-immediate data = but the total amount of unsolicited data is different than = FirstBurst-Size. The target reports the same error when the amount of = data sent as a reply to an R2T does not match the amount requested.=20 Julo=20 "Eddy Quicksall" =20 06/21/2002 12:22 AM=20 Please respond to "Eddy Quicksall"=20 =20 To: Julian Satran/Haifa/IBM@IBMIL=20 cc: =20 Subject: RE: iSCSI: FirstBurstSize and unsolicited = data=20 =20 Isn't this saying that if DSL > FirstBurstSize, it would be incorrect = to send non-immediate unsolicited which is not equal to FirstBurstSize?=20 =20 The target reports the "Incorrect amount of data" condition if dur-ing = data output the total data length to output is greater than = First-BurstSize, but the initiator sent an amount different than = FirstBurstSize of unsolicited non-immediate data or the amount of data = sent as a reply to an R2T does not match the amount requested.=20 =20 Eddy=20 ------=_NextPart_000_0285_01C2193F.FC8E3F50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This is my original mail.
 
http:= //www.pdl.cmu.edu/mailinglists/ips/mail/msg10803.html
 
As the modified text (for 9.4.6.2) = still specifies=20 the case
of unsolicited non-immediate data and is not clear
how a target must=20 respond to the case specified in my mail,
further clarifications are = sought.
 
Thanks,
Nandakumar.
----- Original Message -----
From:=20 Julian Satran
Sent: Friday, June 21, 2002 = 3:10 PM
Subject: Re: iSCSI: = FirstBurstSize and=20 unsolicited data


I don't know what your original mail was = :-)=20 Julo


"Nandakumar Ramamurthy" = <nramamur@npd.hcltech.com>= =20

06/21/2002 11:35 AM =
Please respond to "Nandakumar = Ramamurthy"=20

        =
        To: =    =20    Julian Satran/Haifa/IBM@IBMIL =
        = cc:  =20      <ips@ece.cmu.edu> =
        Subject: =  =20      Re: iSCSI: FirstBurstSize and unsolicited=20 data

    =  =20  


Hi,=20
 
I have been following the discussion on this thread. =
 
I=20 still have certain doubts regarding the
conditions I specified in my original mail.
 
The=20 conditions are :
 =20
FirstBurstSize =3D 64KB =
EDTL =3D 100KB ( EDTL > FirstBurstSize)
MaxRecvDataSegmentLength =3D 8KB
ImmediateData =3D Yes
InitialR2T =3D=20 Yes
  =
In the above case the initiator cannot send = unsolicited=20 Data-out PDUs.
Here unsolicited = data(ImmediateData) < FirstBurstSize.
 
Will the target = report any=20 error in this case?
 
The modified text for Section 9.4.6.2 only = refers to the=20 cases
where unsolicited = Data-outs can be=20 sent.
  =
Please clarify if I am missing something very=20 obvious.
 =20
 
Thanks,
Nandakumar
Member=20 Technical Staff
HCL Technologies, Chennai, INDIA.
http://san.hcltech.com=20
 
 
----- Original Message -----
From: Julian = Satran
To: Eddy = Quicksall
Cc: ips@ece.cmu.edu=20
Sent: = Friday, June 21,=20 2002 11:41 AM
Subject:=20 RE: iSCSI: FirstBurstSize and unsolicited data


Eddy,=20

I assume you meant = EDTL not DSL=20 and then the answer is yes and I again forgot to subtract  the = immediate.=20 A better formulation would be:=20

The target reports = the=20 "Incorrect amount of data" condition if dur-ing data output the total = data=20 length to output is greater than First-BurstSize and the initiator = sent=20 unsolicited non-immediate data but the total amount of unsolicited = data is=20 different than FirstBurst-Size. The target reports the same error when = the=20 amount of data sent as a reply to an R2T does not match the amount=20 requested. =

Julo=20


"Eddy = Quicksall"=20 <Eddy@Quicksall.com>

06/21/2002 12:22 = AM
Please respond to "Eddy Quicksall"

      =  =20
      =  To:=20        Julian = Satran/Haifa/IBM@IBMIL
       cc:       =   =
      =  Subject:  =20      RE: iSCSI: FirstBurstSize and unsolicited=20 data =

     =20



Isn't = this saying=20 that if DSL > FirstBurstSize, it would be incorrect to send = non-immediate=20 unsolicited which is not equal to FirstBurstSize?
 
The target reports the "Incorrect amount of data" = condition if=20 dur-ing data output the total data length to output is greater than=20 First-BurstSize, but the initiator sent an amount different than=20 FirstBurstSize of unsolicited non-immediate data or the amount of data = sent as=20 a reply to an R2T does not match the amount requested.
 
Eddy=20


------=_NextPart_000_0285_01C2193F.FC8E3F50-- From owner-ips@ece.cmu.edu Fri Jun 21 08:16:53 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09378 for ; Fri, 21 Jun 2002 08:16:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5LBQ1E16317 for ips-outgoing; Fri, 21 Jun 2002 07:26:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5LBPxw16313 for ; Fri, 21 Jun 2002 07:25:59 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5LBPmcK038708; Fri, 21 Jun 2002 13:25:48 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5LBPm764284; Fri, 21 Jun 2002 13:25:48 +0200 To: "Nandakumar Ramamurthy" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: Fw: iSCSI: FirstBurstSize and unsolicited data X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 21 Jun 2002 14:25:43 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 21/06/2002 14:25:47, Serialize complete at 21/06/2002 14:25:47 Content-Type: multipart/alternative; boundary="=_alternative 003E5ECDC2256BDF_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 003E5ECDC2256BDF_= Content-Type: text/plain; charset="us-ascii" In your example (even before the correction) nothing bad would have happened (the behavior is correct). If you would have decided to send (and had InitialR2T=No) some amount of unsolicited data but not all the target could have answered with error. The error explanation is (was) a residue from when FirstBurtSize was only a limit (not also a mandated to send value). Julo "Nandakumar Ramamurthy" 06/21/2002 12:50 PM Please respond to "Nandakumar Ramamurthy" To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: Fw: iSCSI: FirstBurstSize and unsolicited data Julian, This was my mail to the IPS alias which started discussions on this thread. Thanks, Nandakumar. ----- Original Message ----- From: "Nandakumar Ramamurthy" To: Sent: Friday, June 14, 2002 4:45 PM Subject: iSCSI: FirstBurstSize and unsolicited data > Hi All, > > Consider the case where InitialR2T=yes and ImmediateData=yes. > All other values are the defaults. > > The expected data transfer length for a SCSI write > operation is a value exceeding FirstBurstSize (64KB). > > In the above case, the initiator will send immediate > unsolicited data (MaxRecvPDULength=8192 bytes). > After that it has to wait for an R2T from the target. > > In this scenario, FirstBurstSize of data will not be sent > to the target as unsolicited data-out's cannot be sent here. > > My understanding is that the remaining data can be > sent only through solicited Data-out PDUs, > and this is the expected way according to the draft. > > What does the following statement(in Section 9.4.6.2 Sense Data) mean in > this context ? > > > > The target reports the "Not enough unsolicited data" condition only > if it does not support output (write) operations in which the total > > data length is greater than FirstBurstSize, but the initiator sent > > less than FirstBurstSize amount of unsolicited data, and out-of-order > > R2Ts cannot be used. > > > > If this is specific to the SCSI layer at the target, > what is the dependency on FirstBurstSize? > > Please clarify. > > Thanks, > Nandakumar > Member Technical Staff > HCL Technologies, Chennai, INDIA. > http://san.hcltech.com > > --=_alternative 003E5ECDC2256BDF_= Content-Type: text/html; charset="us-ascii"
In your example (even before the correction) nothing bad would have happened (the behavior is correct).
If you would have decided to send (and had InitialR2T=No) some amount of unsolicited data but not all
the target could have answered with error.
The error explanation is (was) a residue from when FirstBurtSize was only a limit (not also a mandated to send value).

Julo



"Nandakumar Ramamurthy" <nramamur@npd.hcltech.com>

06/21/2002 12:50 PM
Please respond to "Nandakumar Ramamurthy"

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        
        Subject:        Fw: iSCSI: FirstBurstSize and unsolicited data

       


Julian,

This was my mail to the IPS alias which started discussions on this thread.

Thanks,
Nandakumar.


----- Original Message -----
From: "Nandakumar Ramamurthy" <nramamur@npd.hcltech.com>
To: <ips@ece.cmu.edu>
Sent: Friday, June 14, 2002 4:45 PM
Subject: iSCSI: FirstBurstSize and unsolicited data


> Hi All,
>
> Consider the case where InitialR2T=yes and ImmediateData=yes.
> All other values are the defaults.
>
> The expected data transfer length for a SCSI write
> operation is a value exceeding FirstBurstSize (64KB).
>
> In the above case, the initiator will send immediate
> unsolicited data (MaxRecvPDULength=8192 bytes).
> After that it has to wait for an R2T from the target.
>
> In this scenario, FirstBurstSize of data will not be sent
> to the target as unsolicited data-out's cannot be sent here.
>
> My understanding is that the remaining data can be
> sent only through solicited Data-out PDUs,
> and this is the expected way according to the draft.
>
> What does the following statement(in Section 9.4.6.2 Sense Data) mean in
> this context ?
>
> <quote>
>
> The target reports the "Not enough unsolicited data" condition only
> if it does not support output (write) operations in which the total
>
> data length is greater than FirstBurstSize, but the initiator sent
>
> less than FirstBurstSize amount of unsolicited data, and out-of-order
>
> R2Ts cannot be used.
>
> </quote>
>
> If this is specific to the SCSI layer at the target,
> what is the dependency on FirstBurstSize?
>
> Please clarify.
>
> Thanks,
> Nandakumar
> Member Technical Staff
> HCL Technologies, Chennai, INDIA.
> http://san.hcltech.com
>
>



--=_alternative 003E5ECDC2256BDF_=-- From owner-ips@ece.cmu.edu Fri Jun 21 12:20:15 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20467 for ; Fri, 21 Jun 2002 12:20:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5LFXLh29216 for ips-outgoing; Fri, 21 Jun 2002 11:33:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtp4.electric.net (smtp4.electric.net [216.129.90.17]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5LFXJw29212 for ; Fri, 21 Jun 2002 11:33:19 -0400 (EDT) Received: from hm1.electric.net ([216.129.90.33]) by smtp4.electric.net with smtp (Exim 4.04) id 17LQPW-000CDc-01 for ips@ece.cmu.edu; Fri, 21 Jun 2002 08:33:18 -0700 Received: from osmtp1.electric.net ([216.129.90.28]) by hm1.electric.net (NAVGW 2.5.2.9) with SMTP id M2002062108331720923 ; Fri, 21 Jun 2002 08:33:17 -0700 Received: from [216.192.227.37] (helo=EGRodriguez) by osmtp1.electric.net with esmtp (Exim 3.22 #1) id 17LQPT-0007em-04; Fri, 21 Jun 2002 08:33:16 -0700 From: "Elizabeth G. Rodriguez" To: Cc: Subject: IPS-ALL: WG Last Call on iSCSI Date: Fri, 21 Jun 2002 10:30:38 -0600 Message-ID: <012601c21940$fb948090$25e3c0d8@EGRodriguez> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0127_01C2190E.B0FA1090" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0127_01C2190E.B0FA1090 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All The IPS WG is announcing WG last call on the iSCSI document. The document is available at Document: iSCSI TXT Version: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-13.txt PDF Version: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-13.pdf Note: While the PDF and TXT version should be identical, the official draft is the TXT version. The working group last call will end at 5pm EST on SUNDAY, June 30. Editorial comments may be directed directly to the editor, Julian Satran (Julian_Satran@il.ibm.com) with copies to iSCSI Technical coordinator John Hufferd (John_Hufferd@il.ibm.com) and to your co-chairs Elizabeth Rodriguez(ElizabethRodriguez@ieee.org) and David Black (black_david@emc.com) All technical comments must be resolved directly on the reflector. NOTE: Since this draft was announced (informally last Friday and formally on Tuesday) there have been several comments/threads of discussion on the reflector. While none of these discussions are severe enough to prevent the working group from proceeding with WG last call, all these comments must be taken as WG Last Call comments and must be addressed in some manner (including rejection by the WG) during this last call period. Elizabeth Rodriguez & David Black, IPS WG co-chairs ------=_NextPart_000_0127_01C2190E.B0FA1090 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All

 

The IPS WG is announcing WG last call on the iSCSI = document.

The document is available at

 

Document: iSCSI

TXT Version: = http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-13.txt

PDF Version: = http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-13.pdf

 

Note:  While the PDF and TXT version should be identical, the official draft is the TXT version.

 

The working group last call will end at = 5pm EST on SUNDAY, June 30.

 

Editorial comments may be directed directly to the = editor, Julian Satran (Julian_Satran@il.ibm.com) with copies to iSCSI Technical coordinator John = Hufferd (John_Hufferd@il.ibm.com) and = to your co-chairs Elizabeth Rodriguez(ElizabethRodriguez@ieee.org) and David Black (black_david@emc.com)

 

All technical comments must be resolved directly on = the reflector.

 

NOTE:  Since this draft was announced = (informally last Friday and formally on Tuesday) there have been several comments/threads = of discussion on the reflector.  While none of these discussions are = severe enough to prevent the working group from proceeding with WG last call, = all these comments must be taken as WG Last Call comments and must be = addressed in some manner (including rejection by the WG) during this last call = period.

 

Elizabeth Rodriguez & David = Black,

IPS WG co-chairs

------=_NextPart_000_0127_01C2190E.B0FA1090-- From owner-ips@ece.cmu.edu Fri Jun 21 12:25:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20680 for ; Fri, 21 Jun 2002 12:25:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5LFrGC00506 for ips-outgoing; Fri, 21 Jun 2002 11:53:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtp1.electric.net (smtp1.electric.net [216.129.90.14]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5LFrDw00500 for ; Fri, 21 Jun 2002 11:53:13 -0400 (EDT) Received: from hm1.electric.net ([216.129.90.33]) by smtp1.electric.net with smtp (Exim 4.04) id 17LQil-000DC2-49 for ips@ece.cmu.edu; Fri, 21 Jun 2002 08:53:11 -0700 Received: from osmtp1.electric.net ([216.129.90.29]) by hm1.electric.net (NAVGW 2.5.2.9) with SMTP id M2002062108531005951 ; Fri, 21 Jun 2002 08:53:10 -0700 Received: from [216.192.227.37] (helo=EGRodriguez) by osmtp1.electric.net with esmtp (Exim 3.22 #1) id 17LQii-000Aos-04; Fri, 21 Jun 2002 08:53:08 -0700 From: "Elizabeth G. Rodriguez" To: Cc: , "'John Hufferd'" , "'David Black'" Subject: IPS-ALL: WG Last Call on iSCSI (Corrected -- last call cuttoff date Sunday, July 7!) Date: Fri, 21 Jun 2002 10:50:30 -0600 Message-ID: <015801c21943$c225b6f0$25e3c0d8@EGRodriguez> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0159_01C21911.778B46F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0159_01C21911.778B46F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Apologies - I need to get my head on straight this morning. Here is a corrected iSCSI last call announcement. The last call period needs to be a minimum of two weeks, and I messed up the date as well as John's email in the original announcement. -----Corrected annoucement----- All The IPS WG is announcing WG last call on the iSCSI document. The document is available at Document: iSCSI TXT Version: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-13.txt PDF Version: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-13.pdf Note: While the PDF and TXT version should be identical, the official draft is the TXT version. Last call period: 2 weeks The working group last call will end at 5pm EST on SUNDAY, July 7. Editorial comments may be directed directly to the editor, Julian Satran (Julian_Satran@il.ibm.com) with copies to iSCSI Technical coordinator John Hufferd (hufferd@us.ibm.com) and to your co-chairs Elizabeth Rodriguez(ElizabethRodriguez@ieee.org) and David Black (black_david@emc.com) All technical comments must be resolved directly on the reflector. NOTE: Since this draft was announced (informally last Friday and formally on Tuesday) there have been several comments/threads of discussion on the reflector. While none of these discussions are severe enough to prevent the working group from proceeding with WG last call, all these comments must be taken as WG Last Call comments and must be addressed in some manner (including rejection by the WG) during this last call period. Elizabeth Rodriguez & David Black, IPS WG co-chairs ------=_NextPart_000_0159_01C21911.778B46F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Apologies – I need to get my = head on straight this morning.

Here is a corrected iSCSI last call announcement.

The last call period needs to be a = minimum of two weeks, and I messed up the date as well as John’s email in = the original announcement.

 

-----Corrected annoucement-----

All

 

The IPS WG is announcing WG last call on the iSCSI = document.

The document is available at

 

Document: iSCSI

TXT Version: = http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-13.txt

PDF Version: = http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-13.pdf

 

Note: While the PDF and TXT version should be = identical, the official draft is the TXT version.

 

Last call period: 2 = weeks

The working group last call will end at = 5pm EST on SUNDAY, July = 7.

 

Editorial comments may be directed directly to the = editor, Julian Satran (Julian_Satran@il.ibm.com) with copies to iSCSI Technical coordinator John = Hufferd (hufferd@us.ibm.com) and to your = co-chairs Elizabeth Rodriguez(ElizabethRodriguez@ieee.org) and David Black (black_david@emc.com)

 

All technical comments must be resolved directly on = the reflector.

 

NOTE: Since this draft was announced (informally last = Friday and formally on Tuesday) there have been several comments/threads of = discussion on the reflector.  While none of these discussions are severe enough to prevent the working group = from proceeding with WG last call, all these comments must be taken as WG = Last Call comments and must be addressed in some manner (including rejection by = the WG) during this last call period.

 

Elizabeth Rodriguez & David = Black,

IPS WG co-chairs

------=_NextPart_000_0159_01C21911.778B46F0-- From owner-ips@ece.cmu.edu Fri Jun 21 12:25:27 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20732 for ; Fri, 21 Jun 2002 12:25:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5LFjn300022 for ips-outgoing; Fri, 21 Jun 2002 11:45:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtp4.electric.net (smtp4.electric.net [216.129.90.17]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5LFjlw00018 for ; Fri, 21 Jun 2002 11:45:47 -0400 (EDT) Received: from deckard.electric.net ([216.129.90.84]) by smtp4.electric.net with smtp (Exim 4.04) id 17LQba-000Fm2-49 for ips@ece.cmu.edu; Fri, 21 Jun 2002 08:45:46 -0700 Received: from osmtp1.electric.net ([216.129.90.29]) by deckard.electric.net (NAVGW 2.5.2.9) with SMTP id M2002062108454432157 ; Fri, 21 Jun 2002 08:45:44 -0700 Received: from [216.192.227.37] (helo=EGRodriguez) by osmtp1.electric.net with esmtp (Exim 3.22 #1) id 17LQbW-0009LR-04; Fri, 21 Jun 2002 08:45:42 -0700 From: "Elizabeth G. Rodriguez" To: Cc: , "'John Hufferd'" Subject: RE: IPS-ALL: WG Last Call on iSCSI Date: Fri, 21 Jun 2002 10:43:04 -0600 Message-ID: <013801c21942$b87b9d00$25e3c0d8@EGRodriguez> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0139_01C21910.6DE12D00" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0139_01C21910.6DE12D00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Correction: John Hufferd's email address is hufferd@us.ibm.com. Elizabeth Rodriguez -----Original Message----- From: Elizabeth G. Rodriguez [mailto:Elizabeth.G.Rodriguez@123mail.net] Sent: Friday, June 21, 2002 10:31 AM To: 'ips@ece.cmu.edu' Cc: 't10@t10.org' Subject: IPS-ALL: WG Last Call on iSCSI All The IPS WG is announcing WG last call on the iSCSI document. The document is available at Document: iSCSI TXT Version: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-13.txt PDF Version: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-13.pdf Note: While the PDF and TXT version should be identical, the official draft is the TXT version. The working group last call will end at 5pm EST on SUNDAY, June 30. Editorial comments may be directed directly to the editor, Julian Satran (Julian_Satran@il.ibm.com) with copies to iSCSI Technical coordinator John Hufferd (John_Hufferd@il.ibm.com) and to your co-chairs Elizabeth Rodriguez(ElizabethRodriguez@ieee.org) and David Black (black_david@emc.com) All technical comments must be resolved directly on the reflector. NOTE: Since this draft was announced (informally last Friday and formally on Tuesday) there have been several comments/threads of discussion on the reflector. While none of these discussions are severe enough to prevent the working group from proceeding with WG last call, all these comments must be taken as WG Last Call comments and must be addressed in some manner (including rejection by the WG) during this last call period. Elizabeth Rodriguez & David Black, IPS WG co-chairs ------=_NextPart_000_0139_01C21910.6DE12D00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Correction:  = John Hufferd’s email = address is hufferd@us.ibm.com.

 

Elizabeth = Rodriguez

 

-----Original = Message-----
From: Elizabeth G. = Rodriguez [mailto:Elizabeth.G.Rodriguez@123mail.net]
Sent: Friday, June 21, = 2002 10:31 AM
To: 'ips@ece.cmu.edu'
Cc: 't10@t10.org'
Subject: IPS-ALL: WG Last = Call on iSCSI

 

All

 

The IPS WG is announcing WG = last call on the iSCSI document.

The document is available = at

 

Document: = iSCSI

TXT Version: = http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-13.txt

PDF Version: = http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-13.pdf

 

Note:  While the PDF = and TXT version should be identical, the official draft is the TXT = version.

 

The working group last call = will end at 5pm EST on SUNDAY, June 30.

 

Editorial comments may be = directed directly to the editor, Julian Satran (Julian_Satran@il.ibm.com) with copies to iSCSI Technical coordinator John Hufferd (John_Hufferd@il.ibm.com) and = to your co-chairs Elizabeth Rodriguez(ElizabethRodriguez@ieee.org) and David Black (black_david@emc.com)

 

All technical comments must = be resolved directly on the reflector.

 

NOTE:  Since this = draft was announced (informally last Friday and formally on Tuesday) there have = been several comments/threads of discussion on the reflector.  While = none of these discussions are severe enough to prevent the working group from proceeding with WG last call, all these comments must be taken as WG = Last Call comments and must be addressed in some manner (including rejection by = the WG) during this last call period.

 

Elizabeth Rodriguez & = David Black,

IPS WG = co-chairs

------=_NextPart_000_0139_01C21910.6DE12D00-- From owner-ips@ece.cmu.edu Fri Jun 21 12:52:41 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21878 for ; Fri, 21 Jun 2002 12:52:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5LGDaZ01761 for ips-outgoing; Fri, 21 Jun 2002 12:13:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5LGDXw01754 for ; Fri, 21 Jun 2002 12:13:33 -0400 (EDT) Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id JAA28765; Fri, 21 Jun 2002 09:13:26 -0700 (PDT) From: Keith McCloghrie Message-Id: <200206211613.JAA28765@cisco.com> Subject: Re: FC Mgmt mib To: charissa.willard@sanvalley.com Date: Fri, 21 Jun 2002 09:13:26 -0700 (PDT) Cc: kzm@cisco.com ('Keith McCloghrie'), arvindp@cisco.com, ips@ece.cmu.edu, smoffett@cisco.com, sriramnj@cisco.com, nramesh@cisco.com, gklee@cisco.com In-Reply-To: <73DE11092C445F478CB3629910B2F494B8A4AF@webmail.sanvalley.com> from "charissa.willard@sanvalley.com" at Jun 19, 2002 02:42:12 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The updated MIB is at: ftp://ftp-eng.cisco.com/ftp/kzm/pub/draft-ietf-ips-fcmgmt-mib-02.txt I will submit it to be a new I-D in a few days if I don't recieve any comments. Hopefully, this is now ready for WG Last Call. Thanks, Keith. > Keith, > > That solution sounds good to me. > > Thanks, > Charissa > > > -----Original Message----- > > From: Keith McCloghrie [mailto:kzm@cisco.com] > > Sent: Wednesday, June 19, 2002 2:39 PM > > To: charissa.willard@sanvalley.com > > Cc: kzm@cisco.com; arvindp@cisco.com; ips@ece.cmu.edu; > > smoffett@cisco.com; sriramnj@cisco.com; nramesh@cisco.com; > > gklee@cisco.com > > Subject: Re: FC Mgmt mib > > > > > > Charissa, > > > > Sorry for the delay, but I have spoken with Arvind and he agrees > > that "encapsulates FC frames within another protocol" is a wide > > enough scope to cover his device, and thus, you're right that no > > change is needed for the FcUnitFunction TC. > > > > Further, the two objects within the current fcmEPortTable (i.e., > > fcmEPortClassFCredit and fcmEPortClassFDataFieldSize) can both be > > applied to Arvind's device. Now, you comment that > > fcmEPortClassFCredit > > applies to B_Ports, and I'm confident that fcmEPortClassFDataFieldSize > > does also. Thus, the fcmEPortTable actually applies to E_Ports and > > B_Ports. So, rather than have separate tables for B_Ports > > and E_Ports, > > with the same objects defined in both (i.e., a duplication), I'd like > > to use the existing table for both types. All that is required is to > > change the name to, say, the fcmInterSwitchPortTable (which is roughly > > what you suggested in your previous message), and update its > > definition > > to say it applies to E_Ports, B_Ports and any other type of port which > > interfaces to an inter-switch link. > > > > If you agree, I'll go ahead and update the MIB. > > > > Keith. > > > > > > > Keith, > > > > > > > > > > > 3. A new table for 'tunnel' ports > > > > > > > > - I'd rather not add a new table unless it's absolutely necessary. > > > > How about I just broaden the scope of the fcmEPortTable so that > > > > it applies not only to E_Ports but also to 'tunnel' ports ?? > > > > > > > > > > > The MIB will also need a new group for devices supporting 'tunnel' > > > > functionality, which will contain just fcmEPortClassFCredit > > > > and fcmEPortClassFDataFieldSize, right ?? > > > > > > For FC over IP a port can be either a B_port or an E_port. > > A B_port supports > > > Class F frames and thus could at least use the Class F > > BB_Credit object that > > > you specified in fcmEPortTable. > > > > > > The MIB defines the FcUnitFunction type of 'bridge' as > > "encapsulates FC > > > frames within another protocol". Doesn't this imply "tunneling"? > > > > > > Since a B_port is transparent to the Fabric, just providing > > a table for > > > B_Ports may provide a solution for other devices/ports that > > are transparent > > > to the Fabric and need an object for BB_Credit. > > > > > > Thanks, > > > Charissa > > > > > > From owner-ips@ece.cmu.edu Fri Jun 21 13:35:36 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23784 for ; Fri, 21 Jun 2002 13:35:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5LGkH903822 for ips-outgoing; Fri, 21 Jun 2002 12:46:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5LGkFw03815 for ; Fri, 21 Jun 2002 12:46:15 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id E6F9A9AB8; Fri, 21 Jun 2002 10:46:12 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 6AF453E5; Fri, 21 Jun 2002 10:46:10 -0600 (MDT) Received: from 130.29.152.143 by axcsbh1.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 21 Jun 2002 10:46:05 -0600 Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Jun 2002 10:46:03 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C891D73@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Nandakumar Ramamurthy , Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: FirstBurstSize and unsolicited data Date: Fri, 21 Jun 2002 10:46:02 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-4ca97886-8531-11d6-bae4-009027404a4a" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-4ca97886-8531-11d6-bae4-009027404a4a Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21943.209ABBF0" ------_=_NextPart_001_01C21943.209ABBF0 Content-Type: text/plain; charset="ISO-8859-1" Nandakumar, There are no restrictions on the amount of immediate data sent other than that it must be less than MaxRecvDataSegmentLength and less than FirstBurstSize. So in the conditions you have chosen, the initiator could send any amount of ImmediateData from 4 Bytes to 8 KB. Doing so should not cause an error at the target. The purpose of allowing an implicit InitialR2T is to gain efficiency by letting data start flowing without having to wait a round-trip delay for an R2T. Gaining this efficiency requires that the target know how much unsolicited data will be sent when it receives the SCSI Command PDU so that it can immediately send the first explicit R2T. The rule on sending the full FirstBurstSize (or all the data) when unsolicited data is sent in Data-out PDUs achieves this. When the target sees the SCSI Command PDU with the F bit set to 0, it knows that the first data it needs to request with an R2T starts after FirstBurstSize bytes. When the SCSI Command PDU has an F bit set to 1, then the target knows that DataSegmentLength is the amound of unsolicited data being sent and it can construct its first R2T. Therefore there is no reason to restrict the amount of unsolicited data sent when only immediate data is sent (other than that it not exceed the maximums). That is what is reflected in the rules. Pat -----Original Message----- From: Nandakumar Ramamurthy [mailto:nramamur@npd.hcltech.com] Sent: Friday, June 21, 2002 1:36 AM To: Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iSCSI: FirstBurstSize and unsolicited data Hi, I have been following the discussion on this thread. I still have certain doubts regarding the conditions I specified in my original mail. The conditions are : FirstBurstSize = 64KB EDTL = 100KB ( EDTL > FirstBurstSize) MaxRecvDataSegmentLength = 8KB ImmediateData = Yes InitialR2T = Yes In the above case the initiator cannot send unsolicited Data-out PDUs. Here unsolicited data(ImmediateData) < FirstBurstSize. Will the target report any error in this case? The modified text for Section 9.4.6.2 only refers to the cases where unsolicited Data-outs can be sent. Please clarify if I am missing something very obvious. Thanks, Nandakumar Member Technical Staff HCL Technologies, Chennai, INDIA. http://san.hcltech.com ----- Original Message ----- From: Julian Satran To: Eddy Quicksall Cc: ips@ece.cmu.edu Sent: Friday, June 21, 2002 11:41 AM Subject: RE: iSCSI: FirstBurstSize and unsolicited data Eddy, I assume you meant EDTL not DSL and then the answer is yes and I again forgot to subtract the immediate. A better formulation would be: The target reports the "Incorrect amount of data" condition if dur-ing data output the total data length to output is greater than First-BurstSize and the initiator sent unsolicited non-immediate data but the total amount of unsolicited data is different than FirstBurst-Size. The target reports the same error when the amount of data sent as a reply to an R2T does not match the amount requested. Julo "Eddy Quicksall" 06/21/2002 12:22 AM Please respond to "Eddy Quicksall" To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: iSCSI: FirstBurstSize and unsolicited data Isn't this saying that if DSL > FirstBurstSize, it would be incorrect to send non-immediate unsolicited which is not equal to FirstBurstSize? The target reports the "Incorrect amount of data" condition if dur-ing data output the total data length to output is greater than First-BurstSize, but the initiator sent an amount different than FirstBurstSize of unsolicited non-immediate data or the amount of data sent as a reply to an R2T does not match the amount requested. Eddy ------_=_NextPart_001_01C21943.209ABBF0 Content-Type: text/html; charset="ISO-8859-1"
Nandakumar,
 
There are no restrictions on the amount of immediate data sent other than that it must be less than MaxRecvDataSegmentLength and less than FirstBurstSize. So in the conditions you have chosen, the initiator could send any amount of ImmediateData from 4 Bytes to 8 KB. Doing so should not cause an error at the target.
 
The purpose of allowing an implicit InitialR2T is to gain efficiency by letting data start flowing without having to wait a round-trip delay for an R2T. Gaining this efficiency requires that the target know how much unsolicited data will be sent when it receives the SCSI Command PDU so that it can immediately send the first explicit R2T. The rule on sending the full FirstBurstSize (or all the data) when unsolicited data is sent in Data-out PDUs achieves this. When the target sees the SCSI Command PDU with the F bit set to 0, it knows that the first data it needs to request with an R2T starts after FirstBurstSize bytes.
 
When the SCSI Command PDU has an F bit set to 1, then the target knows that DataSegmentLength is the amound of unsolicited data being sent and it can construct its first R2T. Therefore there is no reason to restrict the amount of unsolicited data sent when only immediate data is sent (other than that it not exceed the maximums).
 
That is what is reflected in the rules.
 
Pat
 
-----Original Message-----
From: Nandakumar Ramamurthy [mailto:nramamur@npd.hcltech.com]
Sent: Friday, June 21, 2002 1:36 AM
To: Julian Satran
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI: FirstBurstSize and unsolicited data

Hi,
 
I have been following the discussion on this thread.
 
I still have certain doubts regarding the
conditions I specified in my original mail.
 
The conditions are :
 
FirstBurstSize = 64KB
EDTL = 100KB ( EDTL > FirstBurstSize)
MaxRecvDataSegmentLength = 8KB
ImmediateData = Yes
InitialR2T = Yes
 
In the above case the initiator cannot send unsolicited Data-out PDUs.
Here unsolicited data(ImmediateData) < FirstBurstSize.
 
Will the target report any error in this case?
 
The modified text for Section 9.4.6.2 only refers to the cases
where unsolicited Data-outs can be sent.
 
Please clarify if I am missing something very obvious.
 
 
Thanks,
Nandakumar
Member Technical Staff
HCL Technologies, Chennai, INDIA.
http://san.hcltech.com
 
 
----- Original Message -----
Sent: Friday, June 21, 2002 11:41 AM
Subject: RE: iSCSI: FirstBurstSize and unsolicited data


Eddy,

I assume you meant EDTL not DSL and then the answer is yes and I again forgot to subtract  the immediate. A better formulation would be:

The target reports the "Incorrect amount of data" condition if dur-ing data output the total data length to output is greater than First-BurstSize and the initiator sent unsolicited non-immediate data but the total amount of unsolicited data is different than FirstBurst-Size. The target reports the same error when the amount of data sent as a reply to an R2T does not match the amount requested.

Julo



"Eddy Quicksall" <Eddy@Quicksall.com>

06/21/2002 12:22 AM
Please respond to "Eddy Quicksall"

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        
        Subject:        RE: iSCSI: FirstBurstSize and unsolicited data

       


Isn't this saying that if DSL > FirstBurstSize, it would be incorrect to send non-immediate unsolicited which is not equal to FirstBurstSize?
 
The target reports the "Incorrect amount of data" condition if dur-ing data output the total data length to output is greater than First-BurstSize, but the initiator sent an amount different than FirstBurstSize of unsolicited non-immediate data or the amount of data sent as a reply to an R2T does not match the amount requested.
 
Eddy

------_=_NextPart_001_01C21943.209ABBF0-- ------=_NextPartTM-000-4ca97886-8531-11d6-bae4-009027404a4a-- From owner-ips@ece.cmu.edu Fri Jun 21 15:10:10 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27640 for ; Fri, 21 Jun 2002 15:10:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5LIRKb10317 for ips-outgoing; Fri, 21 Jun 2002 14:27:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5LIRGw10310 for ; Fri, 21 Jun 2002 14:27:16 -0400 (EDT) Received: from howe.windriver.com (howe [147.11.38.78]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA12964 for ; Fri, 21 Jun 2002 11:25:46 -0700 (PDT) Message-Id: <5.1.0.14.2.20020621111143.03780af0@mail.wrs.com> X-Sender: chiragw@mail.wrs.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 21 Jun 2002 11:29:22 -0700 To: ips@ece.cmu.edu From: Chirag Wighe Subject: Auth method negotiation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi In section 10.4 in Draft v13 it says "The AuthMethod selection is followed by an "authentication exchange" specific to the authentication method selected. " Should the "is" be replaced by a "MUST" for any AuthMethod selection other than "None"? As an example closely related to one in the Appendix. If the login begins as I- Login (CSG,NSG=0,1 T=1) InitiatorName=iqn.1999-07.com.os.hostid.77 TargetName=iqn.1999-07.com.acme.diskarray.sn.88 AuthMethod=KRB5,SRP,CHAP,None And the target chooses CHAP. One question that I have is whether choosing CHAP implies the statement in section 4.3 "Targets MUST NOT submit parameters that require an additional initiator login request in a login response with the T bit set to 1." So if the target chooses CHAP, does it imply that it expects a CHAP_A response and is not permitted to set the T bit to one even if the target is not interested in authenticating the initiator. So is the following reply illegal? T- Login-PR (CSG,NSG=1,0 T=1) AuthMethod=CHAP If the above is not illegal, then if the initiator is also not interested in authenticating the target, can the initiator transition to the next stage. I realize that the above problem might only be a syntactic one as the proper ordering of Auth Methods in the requests sent by the initiator not interested in Authentication would be for None to precede other options and the target will then choose None if it is also not interested in authentication either. Thanks Chirag Wighe Software Development Engineer Wind River Systems