From owner-ips@ece.cmu.edu Fri Feb 1 00: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 AAA23058 for ; Fri, 1 Feb 2002 00:16:45 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g114Vx022485 for ips-outgoing; Thu, 31 Jan 2002 23:31:59 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c003.snv.cp.net (c003-h000.c003.snv.cp.net [209.228.32.214]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g114Vtj22473 for ; Thu, 31 Jan 2002 23:31:55 -0500 (EST) Received: (cpmta 13225 invoked from network); 31 Jan 2002 20:31:45 -0800 Received: from 64.130.130.105 (HELO dougrmt) by smtp.telocity.com (209.228.32.214) with SMTP; 31 Jan 2002 20:31:45 -0800 X-Sent: 1 Feb 2002 04:31:45 GMT From: "Douglas Otis" To: Subject: RE: iSCSI: No Framing Date: Thu, 31 Jan 2002 20:33:15 -0800 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <277DD60FB639D511AC0400B0D068B71E029373F4@CORPMX14> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, As this was an interim measure as expressed by many, it would seem unlikely FIM would gain support in a stand alone draft at this time. There did seem to be several expressing a desire in finding a generic means. I am in favor of removing the section regarding FIM to reduce initial complexity and thereby offering a cleaner legacy moving forward. Doug > I would note that the most likely approach to "Rip the sucker out" > would be to declare framing to be experimental, allowing the framing > text to be moved to a draft that could become an experimental RFC - > it would not be necessary to bit-bucket the text and lose the > work invested in it. > > 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: Jim Pinkerton [mailto:jpink@microsoft.com] > > Sent: Thursday, January 31, 2002 6:22 PM > > To: Amir Shalit; Mark S. Edwards; ips@ece.cmu.edu > > Subject: RE: iSCSI: No Framing > > > > > > > > > > I also agree with this approach. Consensus is still a way out, > > significant work is being done on various fronts to solve some of the > > fundamental issues blocking consensus, and we should not > > block the iSCSI > > spec waiting for consensus. > > > > Rip the sucker out. > > > > > > Jim > > > > > > > > -----Original Message----- > > From: Amir Shalit [mailto:amir@astutenetworks.com] > > Sent: Thursday, January 31, 2002 12:29 PM > > To: Mark S. Edwards; ips@ece.cmu.edu > > Subject: RE: iSCSI: No Framing > > > > In second thought this is the preferred solution for now. Not > > selecting any type of framing until more progress at the transport > > level which may include running iSCSI on a modified TCP protocol etc. > > > > Amir > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Mark S. Edwards > > Sent: Thursday, January 31, 2002 9:49 AM > > To: ips@ece.cmu.edu > > Subject: Re: iSCSI: No Framing > > > > > > At 10:46 PM 1/29/2002 -0800, WENDT,JIM (HP-Roseville,ex1) wrote: > > >Perhaps we should discuss the possibility of not > > >specifying any framing mechanism (FIM or COWS) in the > > >first version of iSCSI. > > > > Nicely put Jim. My current opinion is that this issue has contributed > > to a > > delay in getting this spec out in to the wild. This issue MUST be > > closed > > next week and I don't see anything close to a consensus. My preferred > > approach is to drop this issue now and to look at it at a > > later date in > > terms of an IPS re-charter when we get to thinking about version 2 of > > iSCSI > > or have some good approaches proposed by the tsvwg or the RDMA WG. > > > > Mark. > > > From owner-ips@ece.cmu.edu Fri Feb 1 08:34: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 IAA21400 for ; Fri, 1 Feb 2002 08:34:00 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g11Cke528861 for ips-outgoing; Fri, 1 Feb 2002 07:46:40 -0500 (EST) 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 g11Ckcj28857 for ; Fri, 1 Feb 2002 07:46:38 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Feb 2002 07:46:38 -0500 Message-ID: <25369470B6F0D41194820002B328BDD2202607@ATLOPS> From: Eddy Quicksall To: Julian Satran Cc: "ips@ece. cmu. edu (E-mail)" Subject: RE: iSCSI: error text Date: Fri, 1 Feb 2002 07:46:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AB1E.77A73560" 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_01C1AB1E.77A73560 Content-Type: text/plain; charset="iso-8859-1" I forgot about the language thing :-). I guess this is already acceptable since there is not anything in the draft that says one can't send text with a Login Response with Status-Class non-zero. e.g. T->I Login Response, Status-Class=2, DataSegmentLength=30, DataSegment=X-CSG is incorrect Would that be acceptable under the specification? Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, January 29, 2002 3:52 PM To: Eddy Quicksall Cc: ips@ece. cmu. edu (E-mail) Subject: Re: iSCSI: error text Eddy - nice thought - there are vendor keys for that - If you ask me to add them as part of the standard - I will do it in HEBREW Julo Eddy Quicksall 29-01-02 21:04 To: Julian Satran/Haifa/IBM@IBMIL, "ips@ece. cmu. edu (E-mail)" cc: Subject: iSCSI: error text It would be nice if we could send some error text in the Login Response when the Status-Class is non zero. Since so many things fit into Initiator Error, that would allow anyone looking at an analyzer to see the actual reason. The text would not be defined by the spec but would be defined only by the target and would not be interpreted by anything other than a person trying to diagnose the problem. Eddy ------_=_NextPart_001_01C1AB1E.77A73560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I= forgot about the language thing J= .<= /font>

<= ![if = !supportEmptyParas]> 

=

I= guess this is already acceptable since there is not anything in the draft = that says one can’t send text with a Login Response with Status-Class = non-zero.

<= ![if = !supportEmptyParas]> 

=

e= .g. T->I Login Response, Status-Class=3D2, DataSegmentLength=3D30, = DataSegment=3DX-CSG is incorrect

<= ![if = !supportEmptyParas]> 

=

W= ould that be acceptable under the = specification?

<= ![if = !supportEmptyParas]> 

=

E= ddy

<= ![if = !supportEmptyParas]> 

=

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, January = 29, 2002 3:52 PM
To: Eddy Quicksall
Cc: ips@ece. cmu. edu = (E-mail)
Subject: Re: iSCSI: = error text

 


Eddy - nice thought - there = are vendor keys for that - If you ask me to add them as part of the = standard - I will do it in HEBREW Julo

 

Eddy Quicksall <Eddy_Quicksall@ivivity.com> =

29-01-02 21:04 =

    =    
  =       To:        Julian Satran/Haifa/IBM@IBMIL, "ips@ece. cmu. edu (E-mail)" = <ips@ece.cmu.edu>
  =       cc:        
  =       Subject:        iSCSI: error = text

      =  =



It would be nice if we could send some = error text in the Login Response when the Status-Class is non = zero. =

  =

Since so many = things fit into Initiator Error, that would allow anyone looking at an analyzer to = see the actual reason. =

  =

The text would = not be defined by the spec but would be defined only by the target and would = not be interpreted by anything other than a person trying to diagnose the = problem. =

  =

Eddy =

------_=_NextPart_001_01C1AB1E.77A73560-- From owner-ips@ece.cmu.edu Fri Feb 1 08:39: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 IAA21584 for ; Fri, 1 Feb 2002 08:38:57 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g11CboX28407 for ips-outgoing; Fri, 1 Feb 2002 07:37:50 -0500 (EST) 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 g11Cbmj28400 for ; Fri, 1 Feb 2002 07:37:48 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Feb 2002 07:37:28 -0500 Message-ID: <25369470B6F0D41194820002B328BDD2202606@ATLOPS> From: Eddy Quicksall To: Black_David@emc.com, Eddy Quicksall Cc: ips@ece.cmu.edu Subject: RE: iSCSI: not offering a key Date: Fri, 1 Feb 2002 07:37:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AB1D.2F50A4A0" 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_01C1AB1D.2F50A4A0 Content-Type: text/plain; charset="iso-8859-1" Maybe I misunderstood your note. What I was referring to is that you said: If for some reason the other party doesn't have the same default (bugs happen), negotiation should drive both parties to an agreed value ... Reading on I assumed you meant that we should add code to cope with that. If you take that to an extreme, we would be adding "lots of code" just to cover all possible bugs. An implementation should only have to cover the other ends bugs that could cause a crash or data corruption at our end. In this case, I don't think that means we should change the standard to do extra negotiations just to cover possible bugs. Again, maybe I misunderstood what you were trying to say. Eddy -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Tuesday, January 29, 2002 3:16 AM To: Eddy_Quicksall@ivivity.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: not offering a key I don't understand how this leads to "lots of code". The underlying principle is to negotiate anything you care about and not to complain about things that you didn't negotiate. Saying that there are no implicit offers is fine with me. Thanks, --David -----Original Message----- From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] Sent: Monday, January 28, 2002 12:42 PM To: julian_satran@il. ibm. com (E-mail) Cc: ips@ece.cmu.edu; Robert D. Russell Subject: RE: iSCSI: not offering a key I don't think we should be in the business of adding lots of code to cope with possible bugs at the other end ... there would be no end to what you would do and how you would do it. Couldn't we just strike the sentence and say what Dr. Russell said. I would suggest something like: "There is no such thing as implicit offers. If an explicit offer is not made then a reply cannot be expected." -- cut and past from his EMAIL -- I believe this sentence was added to the spec because at the last UNH plugfest, several people were interpreting "no explicit offer" of a key as an "implicit" offer of the default for the key, and were therefore expecting a reply. This sentence is intended to prevent that interpretation -- if you don't make an explict offer you cannot expect a reply -- there are no such things as implicit offers. Eddy -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Saturday, January 26, 2002 3:31 AM To: Eddy_Quicksall@ivivity.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: not offering a key > Maybe I don't understand the sentence. I interpret it to mean that if the > default value is acceptable to me then not offering it is somehow different > than the default ... and that confuses me (well, actually it makes me wonder > if the sentence is trying to say something else). Here are two examples of how it's different: (1) If for some reason the other party doesn't have the same default (bugs happen), negotiation should drive both parties to an agreed value, but in the absence of negotiation, the other party might do something different. Moral: if a key value is important, it MUST be negotiated. This is a little weaker than Luben's statement that all keys always have to be negotiated. That strength was never intended. (2) If the other party wants to negotiate the value and both offer the same default value, not offering the default results in an additional step before the negotiation can conclude, viz: -> Nothing -> Key=Default <- Key=Default <- Key=Default -> Key=Default --David ------_=_NextPart_001_01C1AB1D.2F50A4A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Maybe I misunderstood your = note.

 

=

What I was referring to is that you said: =

 

=

If for = some reason the other party doesn't have the

same = default (bugs happen), negotiation should drive

both parties to an agreed value ...

 

=

Reading on I assumed you meant that we should add code to cope = with that. If you take that to an extreme, we would be adding “lots of = code” just to cover all possible bugs.

 

=

An implementation should only have to cover the other ends bugs = that could cause a crash or data corruption at our end. In this case, I = don’t think that means we should change the standard to do extra negotiations just = to cover possible bugs.

 

Again, maybe I misunderstood what you were trying to = say.

 

=

Eddy

 

=

-----Original Message-----
From: = Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Tuesday, January = 29, 2002 3:16 AM
To: = Eddy_Quicksall@ivivity.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: not = offering a key

 

I don't understand how this leads to "lots of code".  The

underlying principle is to negotiate anything you care = about=

and not to complain about things that you didn't = negotiate.=

Saying that there are no implicit offers is fine with = me.=

 =

Thanks,

--David

-----Original Message-----
From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com]
Sent: Monday, January = 28, 2002 12:42 PM
To: julian_satran@il. = ibm. com (E-mail)
Cc: ips@ece.cmu.edu; = Robert D. Russell
Subject: RE: iSCSI: not = offering a key

I= don’t think we should be in the business of adding lots of code to cope with = possible bugs at the other end … there would be no end to what you would = do and how you would do it.

<= ![if = !supportEmptyParas]> 

=

C= ouldn’t we just strike the sentence and say what Dr. Russell said. I would = suggest something like:

<= ![if = !supportEmptyParas]> 

=

&= #8220;There is no such thing as implicit offers. If an explicit offer is not made then = a reply cannot be expected.”

<= ![if = !supportEmptyParas]> 

=

-- = cut and past from his EMAIL --

I = believe this sentence was added to the spec because at the

last = UNH plugfest, several people were interpreting "no = explicit

=

offer" of a key as an "implicit" offer of the default for the = key,

=

and = were therefore expecting a reply.  = This sentence is intended

to = prevent that interpretation -- if you don't make an explict = offer

=

you cannot expect a reply -- there are no = such things as implicit offers.

 

=

Eddy

<= ![if = !supportEmptyParas]> 

=

-----Original Message-----
From: = Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Saturday, January = 26, 2002 3:31 AM
To: = Eddy_Quicksall@ivivity.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: not = offering a key=

 =

> Maybe I = don’t understand the sentence. I interpret it to mean that if = the=

> default value = is acceptable to me then not offering it is somehow = different=

> than the = default … and that confuses me (well, actually it makes me = wonder=

> if the = sentence is trying to say something else).=

 =

Here are two examples of how it's = different:=

 =

(1) If for some reason the other party doesn't have = the=

    same default (bugs = happen), negotiation should drive

    both parties to an agreed value, = but in the absence of

    negotiation, the other party might = do something different.

    Moral: if a key value is = important, it MUST be negotiated.

    This is a little weaker than Luben's = statement that

    all keys always have to be = negotiated.  That strength

    was never intended.

 =

(2) If the other party wants to negotiate the value = and=

    both offer the same default value, not = offering the default

    results in an additional step before = the negotiation can

    conclude, viz:=

 =

    -> Nothing   = ;     -> Key=3DDefault

    <- Key=3DDefault    = <- Key=3DDefault

    -> Key=3DDefault=

 =

--David

 =

------_=_NextPart_001_01C1AB1D.2F50A4A0-- From owner-ips@ece.cmu.edu Fri Feb 1 09:35: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 JAA24174 for ; Fri, 1 Feb 2002 09:35:46 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g11DRnA01364 for ips-outgoing; Fri, 1 Feb 2002 08:27:49 -0500 (EST) 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 g11DRlj01354 for ; Fri, 1 Feb 2002 08:27:47 -0500 (EST) Received: from london ([10.95.10.3]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id FAA16852; Fri, 1 Feb 2002 05:26:01 -0800 (PST) From: "Rod Harrison" To: "Jeff Fellin" , , Subject: RE: iSCSI: No Framing Date: Fri, 1 Feb 2002 13:26:53 -0000 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: <200201312329.SAA20946@zydeco.research.bell-labs.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Wind River is in favour of this also. - Rod > -----Original Message----- > From: owner-ips@ece.cmu.edu > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Jeff Fellin > Sent: Thursday, January 31, 2002 11:30 PM > To: amir@astutenetworks.com; ips@ece.cmu.edu > Subject: RE: iSCSI: No Framing > > > > I agree with Amir's idea about removing the marking and > message sync and > recovery is no where near resolution. Removal should > allow the rest of the > iSCSI draft to reach consensus. > > Jeff Fellin From owner-ips@ece.cmu.edu Fri Feb 1 11:49: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 LAA02811 for ; Fri, 1 Feb 2002 11:49:44 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g11FoEr11138 for ips-outgoing; Fri, 1 Feb 2002 10:50:14 -0500 (EST) 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 g11FoAj11133 for ; Fri, 1 Feb 2002 10:50:11 -0500 (EST) 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 g11FnvJ15572; Fri, 1 Feb 2002 10:49:57 -0500 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with ESMTP id g11FnuP08637; Fri, 1 Feb 2002 10:49:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15450.47402.580000.349833@gargle.gargle.HOWL> Date: Fri, 1 Feb 2002 10:50:02 -0500 From: Paul Koning To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: IPsec Usage Question References: <277DD60FB639D511AC0400B0D068B71E029373F3@CORPMX14> 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 31 January 2002) by Black_David@emc.com: > In Salt Lake City, I asked folks to become familiar with > existing IPsec implementations that they plan to (re)use. I > now have a specific question about this that I need answers > to - send the answers to me directly to avoid inadvertently > revealing implementation plans (I promise to keep them > private). > > Q: Does the IPsec implementation you plan to use require > that the inner IP address be different from the outer > IP address for traffic that is to pass through IPsec > to the IP Storage (iSCSI, iFCP, FCIP) system? > Follow-up: If so, how do you plan to configure your system > to securely access a peer IP Storage system from > another vendor that also has this requirement? > > The underlying concern is that requiring that the inner > and outer IP addresses always be the same would visibly > simplify the configuration required to use IPsec with > the IP Storage protocols. I'm not sure if this is what you intended, but I'm reading this to say that IPsec as used with IP Storage would mandate the same IP addresses on inner and outer header. If so, that is equivalent to prohibiting external security gateways. This is not good. I understand that there are people who feel that an external security gateway is not necessarily the right way to address security concerns in IP Storage. But that's a long way from prohibiting their use entirely. If that wasn't your intent, could you clarify what you're after? If the goal is to *permit* inner == outer, that's fine. That's commonly supported because that situation occurs when you tunnel from a single host to a site protected by an IPsec gateway. And yes, allowing inner == outer in that case indeed makes things slightly easier. paul From owner-ips@ece.cmu.edu Fri Feb 1 11:50: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 LAA02843 for ; Fri, 1 Feb 2002 11:50:33 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g11FaOc10186 for ips-outgoing; Fri, 1 Feb 2002 10:36:24 -0500 (EST) 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 g11FaKj10174 for ; Fri, 1 Feb 2002 10:36:20 -0500 (EST) 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 g11Fa4J15499; Fri, 1 Feb 2002 10:36:04 -0500 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with ESMTP id g11Fa1207540; Fri, 1 Feb 2002 10:36:04 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15450.46567.369000.862275@gargle.gargle.HOWL> Date: Fri, 1 Feb 2002 10:36:07 -0500 From: Paul Koning To: Black_David@emc.com Cc: Michael_Fischer@adaptec.com, ips@ece.cmu.edu Subject: RE: iSCSI: not offering a key References: <277DD60FB639D511AC0400B0D068B71E029373F0@CORPMX14> 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 31 January 2002) by Black_David@emc.com: > > What I am reading from this discussion is that all iSCSI initiators must > > send _all_ keys. How else is behavior going to be stable? > > "_all_ keys" --> "_all_ important keys". If every key is important to > an implementation, then it should negotiate every one of them. I find this very strange. Certainly no use of "default" I have ever seen anywhere else takes this view -- that "default" exists for the purpose of assigning values to unimportant things. If that approach made sense, then we should have default only for parameters whose values don't matter much. (Which parameters are those?) > > It seems strange to complexify the algorithms on the grounds that > > people will implement things incorrectly, but it looks like I'm > > fighting a lost cause here so I'll stop now. > > IMHO, adding a notion of implicit offers of default values is more > complex, because in the case where the Initiator does not negotiate a > value and the Target replies with =, the following two > additional things happen to the negotiation algorithm: > - The Initiator must check whether is the default value, > and does not continue negotiation of this key if that value > is acceptable. > - The Target must check whether is the default value > in order to know that the Initiator may not respond if it > accepts the value. > Running the negotiation sequence until both sides have agreed > avoids these complications, and avoids some silly negotiation > protocol breakages ... > > Suppose someone overlooks the recent change in the default for > MaxRecvPDULength from 8191 to 8192, and suppose a Target who thinks > 8192 is the default offers MaxRecvPDULength=8191 to an Initiator who > thinks 8191 is the default. With the two changes above, the negotiation > fails because the Initiator doesn't send a response (it believes that > the Target sent an explicit response to its implicit offer of 8191), > but the Target won't receive the response required to complete the > negotiation (it believes it sent 8191 in response to an implicit offer > of 8192, and hence is waiting for an explicit reply), and hence no > iSCSI session is established. This negotiation failure is really > silly, as both parties have all the information needed to complete > the negotiation successfully (8191 is a likely result). That certainly would be silly, but you get that silly result because of the rule that you treat defaulted keys differently from keys explicitly specified. If you treat an omitted key the same as a supplied key, then you would answer either way, and things are fine (the session is established). > Just to make matters worse, if we change defaults in the future and > change the version number, we force an implementation that wants to > support multiple versions to keep a table of what default applies to > which version in order to comply with the two additional bullets above. That's no different from having to know the different state machines of the two versions, or the different parameter limits, or the different etc. etc... paul From owner-ips@ece.cmu.edu Fri Feb 1 11:53: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 LAA03165 for ; Fri, 1 Feb 2002 11:53:49 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g11FMDw09178 for ips-outgoing; Fri, 1 Feb 2002 10:22:13 -0500 (EST) 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 g11FMCj09173 for ; Fri, 1 Feb 2002 10:22:12 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id <1B5ZY5DM>; Fri, 1 Feb 2002 10:22:03 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029373F6@CORPMX14> From: Black_David@emc.com To: Eddy_Quicksall@ivivity.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: not offering a key Date: Fri, 1 Feb 2002 10:08:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AB32.4DEAC2F0" 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_01C1AB32.4DEAC2F0 Content-Type: text/plain; charset="iso-8859-1" Eddy, > What I was referring to is that you said: > > If for some reason the other party doesn't have the > same default (bugs happen), negotiation should drive > both parties to an agreed value ... > > Reading on I assumed you meant that we should add code to cope with that. > If you take that to an extreme, we would be adding "lots of code" just to cover all possible bugs. That was definitely not my intention. If either party chooses to negotiate a value, the negotiation code that has to be implemented anyway will drive both parties to agreement, but notice the *if*. I definitely do not want this taken to an extreme that would require all keys to be negotiated in all cases. As a consequence, there will be situations in which mistakes occur that cause the two parties to have different ideas of what the default value is for a key that wasn't negotiated (to err is human, most code is written by humans ... ). I am recommending an "if in doubt, negotiate" approach to implementation that will tend to limit such problems to relatively unimportant keys. Coverage of "all possible bugs" was not my intention. > An implementation should only have to cover the other ends bugs that could cause a crash > or data corruption at our end. In this case, I don't think that means we should change the > standard to do extra negotiations just to cover possible bugs. I think we have a serious difference in philosophy. The usual IETF dictum of being conservative in what is sent and liberal in what is accepted implies coverage of more than just bugs that could cause a crash or data corruption - see the recent example I sent to the list of how a notion of "implicit offers" could cause a silly breakdown in negotiation. OTOH, being liberal in what is accepted does not equate to covering all possible bugs - it means doing one's best to do something reasonable in the face of the unexpected as opposed to regarding the least little thing going wrong as a fatal error and reason to immediately give up. As to the standard, I'm not proposing any change. I'm recommending that implementers exercise good judgment by choosing to negotiate any parameters that are important to the behavior and performance of their implementation (which sounds like common sense - are you objecting to this?). The negotiation algorithm has been (and should be) specified in a way that is robust to minor things going wrong, and hence just using it provides some robustness against minor things going wrong. The overall principle is somewhat akin to the exhortation not to complain about the behavior of the government if you didn't bother to vote. I think we're close to violent agreement. 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: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] Sent: Friday, February 01, 2002 7:37 AM To: Black_David@emc.com; Eddy Quicksall Cc: ips@ece.cmu.edu Subject: RE: iSCSI: not offering a key Maybe I misunderstood your note. What I was referring to is that you said: If for some reason the other party doesn't have the same default (bugs happen), negotiation should drive both parties to an agreed value ... Reading on I assumed you meant that we should add code to cope with that. If you take that to an extreme, we would be adding "lots of code" just to cover all possible bugs. An implementation should only have to cover the other ends bugs that could cause a crash or data corruption at our end. In this case, I don't think that means we should change the standard to do extra negotiations just to cover possible bugs. Again, maybe I misunderstood what you were trying to say. Eddy -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Tuesday, January 29, 2002 3:16 AM To: Eddy_Quicksall@ivivity.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: not offering a key I don't understand how this leads to "lots of code". The underlying principle is to negotiate anything you care about and not to complain about things that you didn't negotiate. Saying that there are no implicit offers is fine with me. Thanks, --David -----Original Message----- From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] Sent: Monday, January 28, 2002 12:42 PM To: julian_satran@il. ibm. com (E-mail) Cc: ips@ece.cmu.edu; Robert D. Russell Subject: RE: iSCSI: not offering a key I don't think we should be in the business of adding lots of code to cope with possible bugs at the other end ... there would be no end to what you would do and how you would do it. Couldn't we just strike the sentence and say what Dr. Russell said. I would suggest something like: "There is no such thing as implicit offers. If an explicit offer is not made then a reply cannot be expected." -- cut and past from his EMAIL -- I believe this sentence was added to the spec because at the last UNH plugfest, several people were interpreting "no explicit offer" of a key as an "implicit" offer of the default for the key, and were therefore expecting a reply. This sentence is intended to prevent that interpretation -- if you don't make an explict offer you cannot expect a reply -- there are no such things as implicit offers. Eddy -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Saturday, January 26, 2002 3:31 AM To: Eddy_Quicksall@ivivity.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: not offering a key > Maybe I don't understand the sentence. I interpret it to mean that if the > default value is acceptable to me then not offering it is somehow different > than the default ... and that confuses me (well, actually it makes me wonder > if the sentence is trying to say something else). Here are two examples of how it's different: (1) If for some reason the other party doesn't have the same default (bugs happen), negotiation should drive both parties to an agreed value, but in the absence of negotiation, the other party might do something different. Moral: if a key value is important, it MUST be negotiated. This is a little weaker than Luben's statement that all keys always have to be negotiated. That strength was never intended. (2) If the other party wants to negotiate the value and both offer the same default value, not offering the default results in an additional step before the negotiation can conclude, viz: -> Nothing -> Key=Default <- Key=Default <- Key=Default -> Key=Default --David ------_=_NextPart_001_01C1AB32.4DEAC2F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Eddy,

 

> What I was referring to is that = you said:=20

>=20

> If for some reason the other = party doesn't=20 have the

> same default (bugs=20 happen), negotiation should drive

> both parties to an agreed = value=20 ...

>=20  

> Reading on I assumed you meant that = we should=20 add code to cope with that.

> If you take that to an extreme, = we would be=20 adding “lots of code” just to cover all possible = bugs.

 

That was definitely not my intention.  = If either=20 party chooses to negotiate a value, the negotiation

code that has to be implemented anyway=20 will drive both parties to agreement, but notice = the=20 *if*.

I definitely do not want this = taken to an=20 extreme that would require all keys to be negotiated = in

all cases. As a = consequence,=20 there will be situations in which mistakes occur = that cause=20 the

two parties to have different = ideas of what=20 the default value is for a key that wasn't negotiated

(to err is human, most code is = written by humans=20 ... ).  I am recommending an "if in = doubt,

negotiate" approach to = implementation that will=20 tend to limit such problems to relatively

unimportant keys.  Coverage=20 of "all possible bugs" was not my=20 intention.

 

> An implementation should only = have to cover=20 the other ends bugs that could cause a crash

> or data corruption at our end. = In this=20 case, I don’t think that means we should change = the

> standard to do extra = negotiations just to=20 cover possible bugs. 

=

 

=

I = think we have=20 a serious difference in philosophy.  The usual=20 IETF

dictum of being=20 conservative in what is sent and liberal in what=20 is

accepted implies=20 coverage of more than just bugs that could cause=20 a

crash or data=20 corruption - see the recent example I sent to the=20 list

of how a notion=20 of "implicit offers" could cause a silly=20 breakdown

in=20 negotiation.  OTOH, being liberal in what is accepted does=20 not

equate to covering all possible bugs - it = means=20 doing one's best to

do something reasonable in the face of the = unexpected=20 as opposed

to regarding the least little thing going = wrong as a=20 fatal error and

reason to immediately give = up.

 

As to the=20 standard, I'm not proposing any = change.  I'm=20 recommending that implementers

exercise good=20 judgment by choosing = to negotiate=20 any parameters that are important to the=20 behavior

and=20 performance=20 of their = implementation (which=20 sounds like common sense - are you objecting=20 to

this?).  The = negotiation=20 algorithm has been (and should be) = specified in a way = that=20 is robust=20 to

minor things going = wrong, and hence=20 just using it provides some robustness = against=20 minor

things going=20 wrong.

 

=

The overall = principle is=20 somewhat akin to the exhortation not to complain=20 about=20 the behavior=20 of

the government if you = didn't bother=20 to vote.  I think we're close to violent=20 agreement.=

 

=

Thanks,

--David

---------------------------------------------------
David = L.=20 Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, = MA =20 01748
+1 (508) 249-6449 *NEW*      FAX: +1 = (508)=20 497-8500
black_david@emc.com       = ; =20 Cell: +1 (978)=20 394-7754
---------------------------------------------------

 

 = -----Original Message-----
From: = Eddy=20 Quicksall [mailto:Eddy_Quicksall@ivivity.com]
Sent: Friday, = February=20 01, 2002 7:37 AM
To: Black_David@emc.com; Eddy = Quicksall
Cc:=20 ips@ece.cmu.edu
Subject: RE: iSCSI: not offering a=20 key

Maybe=20 I misunderstood your note.

 

=

What I=20 was referring to is that you said: =

 

=

If for some=20 reason the other party doesn't have the

same default=20 (bugs happen), negotiation should drive

both=20 parties to an agreed value ...

 

=

Reading=20 on I assumed you meant that we should add code to cope with that. If = you take=20 that to an extreme, we would be adding “lots of code” = just to cover all=20 possible bugs.

 

=

An=20 implementation should only have to cover the other ends bugs that = could cause=20 a crash or data corruption at our end. In this case, I don’t = think that means=20 we should change the standard to do extra negotiations just to cover = possible=20 bugs.

 

Again,=20 maybe I misunderstood what you were trying to=20 say.

 

=

Eddy

 

=

-----Original=20 Message-----
From: = Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Tuesday, January 29, = 2002 3:16=20 AM
To:=20 Eddy_Quicksall@ivivity.com
Cc: = ips@ece.cmu.edu
Subject: RE: iSCSI: not = offering a=20 key

 

I = don't=20 understand how this leads to "lots of code".  = The

underlying=20 principle is to negotiate anything you care about

and not to=20 complain about things that you didn't negotiate.

Saying that=20 there are no implicit offers is fine with me.

 

Thanks,

--David

-----Original=20 Message-----
From: = Eddy=20 Quicksall [mailto:Eddy_Quicksall@ivivity.com]
Sent: Monday, January 28, 2002 = 12:42=20 PM
To: = julian_satran@il. ibm.=20 com (E-mail)
Cc:=20 ips@ece.cmu.edu; Robert D. Russell
Subject: RE: iSCSI: not = offering a=20 key

I=20 don’t think we should be in the business of adding lots of code = to cope with=20 possible bugs at the other end … there would be no end to what = you would do=20 and how you would do it.

 

=

Couldn’t=20 we just strike the sentence and say what Dr. Russell said. I would = suggest=20 something like:

 

=

“There=20 is no such thing as implicit offers. If an explicit offer is not made = then a=20 reply cannot be expected.”

 

=

-- cut and=20 past from his EMAIL --

I believe=20 this sentence was added to the spec because at the

last UNH=20 plugfest, several people were interpreting "no = explicit

offer" of=20 a key as an "implicit" offer of the default for the = key,

and were=20 therefore expecting a reply.  = This=20 sentence is intended

to prevent=20 that interpretation -- if you don't make an explict = offer

you cannot=20 expect a reply -- there are no such things as implicit=20 offers.

 

Eddy

 

=

-----Original=20 Message-----
From: = Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Saturday, January 26, = 2002 3:31=20 AM
To:=20 Eddy_Quicksall@ivivity.com
Cc: = ips@ece.cmu.edu
Subject: RE: iSCSI: not = offering a=20 key

 

>=20 Maybe I don’t understand the sentence. I interpret it to mean = that if=20 the

>=20 default value is acceptable to me then not offering it is somehow=20 different

>=20 than the default … and that confuses me (well, actually it = makes me=20 wonder

>=20 if the sentence is trying to say something = else).

 

Here are two=20 examples of how it's different:

 

(1) If for=20 some reason the other party doesn't have the

   =20 same default (bugs happen), negotiation should = drive

   =20 both parties to an agreed value, but in the absence = of

   =20 negotiation, the other party might do something=20 different.

   =20 Moral: if a key value is important, it MUST be=20 negotiated.

   =20 This is a little weaker than Luben's statement = that

   =20 all keys always have to be negotiated.  That = strength

   =20 was never intended.

 

(2) If the=20 other party wants to negotiate the value and

   =20 both offer the same default value, not offering the = default

   =20 results in an additional step before the negotiation = can

   =20 conclude, viz:

 

    -> Nothing    =    =20 -> Key=3DDefault

   =20 <- Key=3DDefault    <- = Key=3DDefault

   =20 -> Key=3DDefault

 

--David

 

------_=_NextPart_001_01C1AB32.4DEAC2F0-- From owner-ips@ece.cmu.edu Fri Feb 1 12:34: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 MAA05202 for ; Fri, 1 Feb 2002 12:34:45 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g11GeEW15255 for ips-outgoing; Fri, 1 Feb 2002 11:40:14 -0500 (EST) 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 g11GeDj15249 for ; Fri, 1 Feb 2002 11:40:13 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id <1B5ZZB42>; Fri, 1 Feb 2002 11:40:05 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029373F8@CORPMX14> From: Black_David@emc.com To: ni1d@arrl.net Cc: ips@ece.cmu.edu Subject: RE: iSCSI: not offering a key Date: Fri, 1 Feb 2002 11:26:25 -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 > Excerpt of message (sent 31 January 2002) by Black_David@emc.com: > > > What I am reading from this discussion is that all iSCSI > initiators must > > > send _all_ keys. How else is behavior going to be stable? > > > > "_all_ keys" --> "_all_ important keys". If every key is important to > > an implementation, then it should negotiate every one of them. > > I find this very strange. Certainly no use of "default" I have ever > seen anywhere else takes this view -- that "default" exists for the > purpose of assigning values to unimportant things. If that approach > made sense, then we should have default only for parameters whose > values don't matter much. (Which parameters are those?) I'd leave that decision to implementers, who understand far more about what matters to their implementation than WG members who aren't familiar with the details of that specific implementation. As indicated in a previous message, I believe that this approach to defaults and negotiation is in line with the IETF dictum of being conservative in what is sent and liberal in what is accepted - disallowing "implicit offers" is conservative, because it results in less state having to be inferred from a message, IMHO. > > > It seems strange to complexify the algorithms on the grounds that > > > people will implement things incorrectly, but it looks like I'm > > > fighting a lost cause here so I'll stop now. > > > > IMHO, adding a notion of implicit offers of default values is more > > complex, because in the case where the Initiator does not negotiate a > > value and the Target replies with =, the following two > > additional things happen to the negotiation algorithm: > > - The Initiator must check whether is the default value, > > and does not continue negotiation of this key if that value > > is acceptable. > > - The Target must check whether is the default value > > in order to know that the Initiator may not respond if it > > accepts the value. > > Running the negotiation sequence until both sides have agreed > > avoids these complications, and avoids some silly negotiation > > protocol breakages ... > > > > Suppose someone overlooks the recent change in the default for > > MaxRecvPDULength from 8191 to 8192, and suppose a Target who thinks > > 8192 is the default offers MaxRecvPDULength=8191 to an Initiator who > > thinks 8191 is the default. With the two changes above, the negotiation > > fails because the Initiator doesn't send a response (it believes that > > the Target sent an explicit response to its implicit offer of 8191), > > but the Target won't receive the response required to complete the > > negotiation (it believes it sent 8191 in response to an implicit offer > > of 8192, and hence is waiting for an explicit reply), and hence no > > iSCSI session is established. This negotiation failure is really > > silly, as both parties have all the information needed to complete > > the negotiation successfully (8191 is a likely result). > > That certainly would be silly, but you get that silly result because > of the rule that you treat defaulted keys differently from keys > explicitly specified. If you treat an omitted key the same as a > supplied key, then you would answer either way, and things are fine > (the session is established). That's not correct. The problem occurs in the above scenario because the Initiator *is* treating the = supplied by the Target identically to an omitted (and hence defaulted) key. Recall that the problem is caused by Initiator and Target having different views of what the default value is, so that while the Target believes it has offered a non-default value, the Initiator believes that the Target has agreed to the default value offered by omission in the initial message, hence the Initiator does not respond to the Target, and the negotiation fails. > > Just to make matters worse, if we change defaults in the future and > > change the version number, we force an implementation that wants to > > support multiple versions to keep a table of what default applies to > > which version in order to comply with the two additional > bullets above. > > That's no different from having to know the different state machines > of the two versions, or the different parameter limits, or the > different etc. etc... But it's more complexity ... why force this on implementers? 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 Fri Feb 1 12:34: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 MAA05214 for ; Fri, 1 Feb 2002 12:34:57 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g11GRPa14095 for ips-outgoing; Fri, 1 Feb 2002 11:27:25 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g11GRJj14085 for ; Fri, 1 Feb 2002 11:27:19 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Feb 2002 11:21:40 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029373F7@CORPMX14> From: Black_David@emc.com To: ni1d@arrl.net Cc: ips@ece.cmu.edu Subject: RE: IPsec Usage Question Date: Fri, 1 Feb 2002 11:13:05 -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 > Excerpt of message (sent 31 January 2002) by Black_David@emc.com: > > In Salt Lake City, I asked folks to become familiar with > > existing IPsec implementations that they plan to (re)use. I > > now have a specific question about this that I need answers > > to - send the answers to me directly to avoid inadvertently > > revealing implementation plans (I promise to keep them > > private). > > > > Q: Does the IPsec implementation you plan to use require > > that the inner IP address be different from the outer > > IP address for traffic that is to pass through IPsec > > to the IP Storage (iSCSI, iFCP, FCIP) system? > > Follow-up: If so, how do you plan to configure your system > > to securely access a peer IP Storage system from > > another vendor that also has this requirement? > > > > The underlying concern is that requiring that the inner > > and outer IP addresses always be the same would visibly > > simplify the configuration required to use IPsec with > > the IP Storage protocols. > > I'm not sure if this is what you intended, but I'm reading this to say > that IPsec as used with IP Storage would mandate the same IP addresses > on inner and outer header. > > If so, that is equivalent to prohibiting external security gateways. > This is not good. I understand that there are people who feel that an > external security gateway is not necessarily the right way to address > security concerns in IP Storage. But that's a long way from > prohibiting their use entirely. > > If that wasn't your intent, could you clarify what you're after? If > the goal is to *permit* inner == outer, that's fine. That's commonly > supported because that situation occurs when you tunnel from a single > host to a site protected by an IPsec gateway. And yes, allowing inner > == outer in that case indeed makes things slightly easier. Mandating the same addresses in the inner and outer header is a "big hammer" that may not be the right course of action. OTOH, if one needs to know both the inner and outer IP addresses in order to contact a target, that has implications for the functionality/usage of Send Targets, iSNS, and SLP. My underlying goal is to figure out whether we need to put support for two IP addresses per target into those configuration mechanisms (this would apply to FCIP, iFCP, and iSCSI). I intended to raise the possibility of mandating the same addresses in the inner and outer header as a possibility as opposed to proposing it as a course of action as I don't have enough info about what folks intend to do/think is important to make any proposal in this space. Paul's input that this would be a bad idea because it would implicitly ban the use of security gateways is a fine response to that possibility - and to his credit, Paul was right about the last IPsec-related issue he brought up (dangling SAs). 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 Fri Feb 1 13:30: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 NAA06874 for ; Fri, 1 Feb 2002 13:30:35 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g11HNRD18939 for ips-outgoing; Fri, 1 Feb 2002 12:23:27 -0500 (EST) 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 g11HNQj18931 for ; Fri, 1 Feb 2002 12:23:26 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id <1B5ZZF6F>; Fri, 1 Feb 2002 12:23:20 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029373F9@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: RE: Edited Minutes of the 1/29/02 IPS Security Conference call Date: Fri, 1 Feb 2002 12:09:43 -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 Answering a private question to the list due to general interest: > When would an initiators IPsec implementation would be > an IPsec gateway one (or is there a scenario where > an initiator would be acting as an IPsec gateway?) When it functions as a security gateway as defined by RFC 2401. The IP Storage specifications would not set down any rules for determining this - there would be a reference to RFC 2401 and implementers would make their own determinations. In general, if there's a private network link (physical or virtual) over which packets are forwarded between the IPsec implementation and the IP Storage implementation (e.g., iSCSI Initiator), then the IPsec implementation is most probably a security gateway. This need not always be the case (e.g., in the presence of sufficient architectural "cleverness"), and there are other situations in which the IPsec implementation may be a security gateway even in the absence of such a private link. Also, please note that Transport mode is not forbidden for security gateways, it is just not required. To understand this topic, there is really no substitute for the relevant portions of RFC 2401 - I would recommend that anyone who is interested in this topic read RFC 2401 from its beginning through at least the end of Section 4.3. 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 Fri Feb 1 13:44: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 NAA07461 for ; Fri, 1 Feb 2002 13:44:28 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g11HSDA19319 for ips-outgoing; Fri, 1 Feb 2002 12:28:13 -0500 (EST) 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 g11HSBj19312 for ; Fri, 1 Feb 2002 12:28:11 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id SAA84030 for ; Fri, 1 Feb 2002 18:28:04 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g11HTQE68144 for ; Fri, 1 Feb 2002 18:29:26 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: error text X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 1 Feb 2002 19:29:24 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 01/02/2002 19:29:26, Serialize complete at 01/02/2002 19:29:26 Content-Type: multipart/alternative; boundary="=_alternative 005F5DDAC2256B53_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005F5DDAC2256B53_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Eddy, Certainly correct and better than to force everybody to prduce the=20 message. Julo Eddy Quicksall Sent by: owner-ips@ece.cmu.edu 01-02-02 14:46 =20 To: Julian Satran/Haifa/IBM@IBMIL cc: "ips@ece. cmu. edu (E-mail)" Subject: RE: iSCSI: error text =20 I forgot about the language thing J. =20 I guess this is already acceptable since there is not anything in the=20 draft that says one can't send text with a Login Response with=20 Status-Class non-zero. =20 e.g. T->I Login Response, Status-Class=3D2, DataSegmentLength=3D30,=20 DataSegment=3DX-CSG is incorrect =20 Would that be acceptable under the specification? =20 Eddy =20 -----Original Message----- From: Julian Satran [mailto:Julian=5FSatran@il.ibm.com] Sent: Tuesday, January 29, 2002 3:52 PM To: Eddy Quicksall Cc: ips@ece. cmu. edu (E-mail) Subject: Re: iSCSI: error text =20 Eddy - nice thought - there are vendor keys for that - If you ask me to=20 add them as part of the standard - I will do it in HEBREW Julo=20 =20 Eddy Quicksall =20 29-01-02 21:04=20 =20 To: Julian Satran/Haifa/IBM@IBMIL, "ips@ece. cmu. edu=20 (E-mail)" =20 cc: =20 Subject: iSCSI: error text=20 =20 It would be nice if we could send some error text in the Login Response=20 when the Status-Class is non zero.=20 =20 Since so many things fit into Initiator Error, that would allow anyone=20 looking at an analyzer to see the actual reason.=20 =20 The text would not be defined by the spec but would be defined only by the = target and would not be interpreted by anything other than a person trying = to diagnose the problem.=20 =20 Eddy=20 --=_alternative 005F5DDAC2256B53_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Eddy,

Certainly correct and better than to= force everybody to prduce the message.

Julo


Eddy Quicksall <Eddy=5FQuicksa= ll@ivivity.com>
Sent by: owner-ips@ece.cmu.edu

01-02-02 14:46

       
        To: &nbs= p;      Julian Satran/Haifa/IBM@IBMIL
        cc: &nbs= p;      "ips@ece. cmu. edu (E-mail)" <ips@ece.c= mu.edu>
        Subject:=        RE: iSCSI: error text

       


I forgot about the langua= ge thing J<= font size=3D2 color=3D#000080 face=3D"Arial">.

 

I guess this is already ac= ceptable since there is not anything in the draft that says one can't send = text with a Login Response with Status-Class non-zero.

 

e.g. T->I Login Respons= e, Status-Class=3D2, DataSegmentLength=3D30, DataSegment=3DX-CSG is incorre= ct

 

Would that be acceptable u= nder the specification?

 

Eddy

 

-----Original Message-----
From: Julian Satran [mailto:Julian=5FSatran@il.ibm.com]
Sent: Tuesday, January 29, 2002 3:52 PM
To: Eddy Quicksall
Cc: ips@ece. cmu. edu (E-mail)
Subject: Re: iSCSI: error text

 


Eddy - nice thought - there are vendor keys for that - If you ask me to add= them as part of the standard - I will do it in HEBREW Julo

  Eddy Quicksall <Ed= dy=5FQuicksall@ivivity.com>

29-01-02 21:04

        <= /font>
       To:        Julian Satran/Ha= ifa/IBM@IBMIL, "ips@ece. cmu. edu (E-mail)" <ips@ece.cmu.edu&g= t;
       cc:         <= br>        Subject:        iSCSI: erro= r text

     



It would be nice if we could send some error text in the Login Response whe= n the Status-Class is non zero.

 

Since so many things fit into Initiator Er= ror, that would allow anyone looking at an analyzer to see the actual reaso= n.

 

The text would not be defined by the spec = but would be defined only by the target and would not be interpreted by any= thing other than a person trying to diagnose the problem.

 

Eddy

--=_alternative 005F5DDAC2256B53_=-- From owner-ips@ece.cmu.edu Fri Feb 1 14:59: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 OAA10415 for ; Fri, 1 Feb 2002 14:59:04 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g11IEiI22779 for ips-outgoing; Fri, 1 Feb 2002 13:14:44 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from imo-r06.mx.aol.com (imo-r06.mx.aol.com [152.163.225.102]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g11IEcj22766 for ; Fri, 1 Feb 2002 13:14:39 -0500 (EST) Received: from VAHUJA@aol.com by imo-r06.mx.aol.com (mail_out_v31_r1.26.) id 3.b2.5d8b5a0 (3314) for ; Fri, 1 Feb 2002 13:14:25 -0500 (EST) From: VAHUJA@aol.com Message-ID: Date: Fri, 1 Feb 2002 13:14:25 EST Subject: Fwd: IPsec Usage Question To: ips@ece.cmu.edu MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="part1_b2.5d8b5a0.298c3501_boundary" X-Mailer: AOL 7.0 for Windows US sub 121 Sender: owner-ips@ece.cmu.edu Precedence: bulk --part1_b2.5d8b5a0.298c3501_boundary Content-Type: multipart/alternative; boundary="part1_b2.5d8b5a0.298c3501_alt_boundary" --part1_b2.5d8b5a0.298c3501_alt_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I can see the existence of an external security gateway as critical to make these protocols viable and support real configs. So, I agree that we should not mandate the inner and outer IP address to be same...it can be an option, and that would be fine. I can see the external security gateways to be necessary even for the FCiP and iFCP environments - unless I am missing something here... --part1_b2.5d8b5a0.298c3501_alt_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit I can see the existence of an external security gateway as critical to make these protocols viable and support real configs. So, I agree that we should not mandate the inner and outer IP address to be same...it can be an option, and that would be fine. I can see the external security gateways to be necessary even for the FCiP and iFCP environments - unless I am missing something here... --part1_b2.5d8b5a0.298c3501_alt_boundary-- --part1_b2.5d8b5a0.298c3501_boundary Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from rly-yb03.mx.aol.com (rly-yb03.mail.aol.com [172.18.146.3]) by air-yb05.mail.aol.com (v83.35) with ESMTP id MAILINYB51-0201121510; Fri, 01 Feb 2002 12:15:10 -0500 Received: from ece.cmu.edu (ece.cmu.edu [128.2.136.200]) by rly-yb03.mx.aol.com (v83.35) with ESMTP id MAILRELAYINYB38-0201121459; Fri, 01 Feb 2002 12:14:59 -0500 Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g11GRPa14095 for ips-outgoing; Fri, 1 Feb 2002 11:27:25 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g11GRJj14085 for ; Fri, 1 Feb 2002 11:27:19 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Feb 2002 11:21:40 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029373F7@CORPMX14> From: Black_David@emc.com To: ni1d@arrl.net Cc: ips@ece.cmu.edu Subject: RE: IPsec Usage Question Date: Fri, 1 Feb 2002 11:13:05 -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 > Excerpt of message (sent 31 January 2002) by Black_David@emc.com: > > In Salt Lake City, I asked folks to become familiar with > > existing IPsec implementations that they plan to (re)use. I > > now have a specific question about this that I need answers > > to - send the answers to me directly to avoid inadvertently > > revealing implementation plans (I promise to keep them > > private). > > > > Q: Does the IPsec implementation you plan to use require > > that the inner IP address be different from the outer > > IP address for traffic that is to pass through IPsec > > to the IP Storage (iSCSI, iFCP, FCIP) system? > > Follow-up: If so, how do you plan to configure your system > > to securely access a peer IP Storage system from > > another vendor that also has this requirement? > > > > The underlying concern is that requiring that the inner > > and outer IP addresses always be the same would visibly > > simplify the configuration required to use IPsec with > > the IP Storage protocols. > > I'm not sure if this is what you intended, but I'm reading this to say > that IPsec as used with IP Storage would mandate the same IP addresses > on inner and outer header. > > If so, that is equivalent to prohibiting external security gateways. > This is not good. I understand that there are people who feel that an > external security gateway is not necessarily the right way to address > security concerns in IP Storage. But that's a long way from > prohibiting their use entirely. > > If that wasn't your intent, could you clarify what you're after? If > the goal is to *permit* inner == outer, that's fine. That's commonly > supported because that situation occurs when you tunnel from a single > host to a site protected by an IPsec gateway. And yes, allowing inner > == outer in that case indeed makes things slightly easier. Mandating the same addresses in the inner and outer header is a "big hammer" that may not be the right course of action. OTOH, if one needs to know both the inner and outer IP addresses in order to contact a target, that has implications for the functionality/usage of Send Targets, iSNS, and SLP. My underlying goal is to figure out whether we need to put support for two IP addresses per target into those configuration mechanisms (this would apply to FCIP, iFCP, and iSCSI). I intended to raise the possibility of mandating the same addresses in the inner and outer header as a possibility as opposed to proposing it as a course of action as I don't have enough info about what folks intend to do/think is important to make any proposal in this space. Paul's input that this would be a bad idea because it would implicitly ban the use of security gateways is a fine response to that possibility - and to his credit, Paul was right about the last IPsec-related issue he brought up (dangling SAs). 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 --------------------------------------------------- --part1_b2.5d8b5a0.298c3501_boundary-- From owner-ips@ece.cmu.edu Fri Feb 1 17:02: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 RAA12966 for ; Fri, 1 Feb 2002 17:02:55 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g11Ks8C05939 for ips-outgoing; Fri, 1 Feb 2002 15:54:08 -0500 (EST) 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 g11Ks1j05931 for ; Fri, 1 Feb 2002 15:54:04 -0500 (EST) 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 g11KrlJ17880; Fri, 1 Feb 2002 15:53:47 -0500 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with ESMTP id g11KrkJ23398; Fri, 1 Feb 2002 15:53:47 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15451.96.621000.636478@gargle.gargle.HOWL> Date: Fri, 1 Feb 2002 15:53:52 -0500 From: Paul Koning To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: IPsec Usage Question References: <277DD60FB639D511AC0400B0D068B71E029373F7@CORPMX14> 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 1 February 2002) by Black_David@emc.com: > Mandating the same addresses in the inner and outer header is a "big > hammer" that may not be the right course of action. OTOH, if one > needs to know both the inner and outer IP addresses in order to contact > a target, that has implications for the functionality/usage of Send > Targets, iSNS, and SLP. My underlying goal is to figure out whether > we need to put support for two IP addresses per target into those > configuration mechanisms (this would apply to FCIP, iFCP, and iSCSI). Managing the mapping from the inner address to the outer address is a function of IPsec management -- that's the policy database which defines which host traffic is protected by what tunnel. It's tempting to try to avoid IPsec management by addressing restrictions such as you mentioned here, but that does not help. There are about a dozen parameters for an IPsec SA, and you can't hardware all of them in the standard. Trying to attack this by the restriction you proposed, even if feasible, only takes care of a fraction of the IPsec management you need. I would think that IP Storage mechanisms such as Send Targets or iSNS should concern themselves with storage, not with other components like IPsec. So yes, you need IPsec management (including tunnel addressing) but no, it's not the job of IP Storage mechanisms to administer those parameters. paul From owner-ips@ece.cmu.edu Fri Feb 1 17:03: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 RAA12978 for ; Fri, 1 Feb 2002 17:03:39 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g11LL3Y07912 for ips-outgoing; Fri, 1 Feb 2002 16:21:03 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls16.mediaone.net (chmls16.ne.ipsvc.net [24.147.1.151]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0VNTNj04062 for ; Thu, 31 Jan 2002 18:29:23 -0500 (EST) Received: from breinhold ([140.186.40.85]) by chmls16.mediaone.net (8.11.1/8.11.1) with SMTP id g0VNTIP26373 for ; Thu, 31 Jan 2002 18:29:18 -0500 (EST) From: "Reinholds" To: "ISCSI" Subject: FCIP: Loss of connection in multi-connection LEP Date: Thu, 31 Jan 2002 18:29:16 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I am having a hard time understanding how we are supposed to deal with TCP connections that become unresponsive when there are multiple TCP connections between a LEP. How is recovery supposed to work? Clause 15.5.4.1 (Rev 5.3 - Jan 22) appears to require that all FC flows continue to be sent on the connection for all time. When a connection is deemed unresponsive by one end, when can the effected flows be moved to another connection (if ever)? If a new connection is established and a special frame not sent, is this considered to be the "same DE" allowing continued transmission of frames of the impacted flows? Is appears to be possible to use an already existing connection (see 16.3.1) but if this is the case there is a possibility of delivering out of order frames, especially if one can not gracefully close a TCP connection (no FIN ACK is received). Barry Reinhold Principal Architect Trebia Networks barry.reinhold@trebia.com 603-868-5144/603-659-0885/978-929-0830 x138 From owner-ips@ece.cmu.edu Fri Feb 1 18:19: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 SAA13979 for ; Fri, 1 Feb 2002 18:19:20 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g11MHmU12053 for ips-outgoing; Fri, 1 Feb 2002 17:17:48 -0500 (EST) 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 g11MHij12035 for ; Fri, 1 Feb 2002 17:17:44 -0500 (EST) Received: from sponge.cisco.com (sponge.cisco.com [64.101.128.87]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g11MHc604408 for ; Fri, 1 Feb 2002 14:17:38 -0800 (PST) Received: from DAPW2K3 (dhcp-161-44-68-223.cisco.com [161.44.68.223]) by sponge.cisco.com (Mirapoint) with SMTP id AAK03227; Fri, 1 Feb 2002 16:12:52 -0600 (CST) From: "Dave Peterson" To: "Ips@Ece. Cmu. Edu" Subject: iSCSI ACA requirement Date: Fri, 1 Feb 2002 16:17:36 -0600 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 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I'm having heartburn with the statement in iSCSI rev 10 clause 9.2: "As iSCSI can have many commands in-flight between initiator and target, iSCSI mandates support for ACA." My understanding of the above statement is that iSCSI target must indicate support for NACA=1. Requiring ACA is problematic and normally not necessary for implementations for a variety of reasons. Examples: a. A small number of devices actually support NACA=1. b. In practice FC applications do not require command ordering (i.e., use of the Simple Queue Tag). If ordering is a consideration the application will issue the command and wait for the response. c. The FC/FCP standards do not require NACA=1. d. Complicates bridging implementations - bridge must proxy NACA=1 for a device that does not support NACA=1 - bridge must maintain NACA behavior when the end device does not support NACA=1 I do understand the benefits to requiring NACA=1 especially when command ordering and stateful operations are desired, but its not realistic at this time, IMHO. As such this use of ACA should be a SHOULD, not a must or mandate. Dave From owner-ips@ece.cmu.edu Fri Feb 1 20: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 UAA16078 for ; Fri, 1 Feb 2002 20:58:37 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g120rBb21670 for ips-outgoing; Fri, 1 Feb 2002 19:53:11 -0500 (EST) 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 g120r8j21659 for ; Fri, 1 Feb 2002 19:53:08 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 7728435E9; Fri, 1 Feb 2002 17:53:07 -0700 (MST) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 31C45246; Fri, 1 Feb 2002 17:53:07 -0700 (MST) Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Feb 2002 17:53:07 -0700 Message-ID: <01A7DAF31F93D511AEE300D0B706ED9201BF46F1@axcs13.cos.agilent.com> From: "CAVANNA,VICENTE V (A-Roseville,ex1)" To: "'Black_David@emc.com'" , "'Paul Koning'" Cc: ips@ece.cmu.edu, "THALER,PAT (A-Roseville,ex1)" Subject: RE: IPsec Usage Question Date: Fri, 1 Feb 2002 17:53:06 -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 agree with Paul Koning's comments on this topic; in particular his observation that forcing the inner and outer IP addresses to be the same forces the security tunnel endpoint to be the same as the communication endpoint and thus precludes implementing security in an entity other that that which originated the packet. I am one of those who think an IPSEC tunnel to a gateway and then an unsecured path to the storage device is not enough security for storage traffic but the reality is that this may be the only security available initially. In fact it is possible that we have nested tunnels and we may be dealing with more than two IP addresses. I therefore do not agree with mandating both IPs to be the same. It seems inevitable to me that if security is implemented by a gateway in the path to a storage server, that the clients need to be aware of its IP address as well as the IP of the storage server and as Paul has pointed out this is a function of Security Policy management. Vince Cavanna Agilent Technologies |-----Original Message----- |From: Black_David@emc.com [mailto:Black_David@emc.com] |Sent: Friday, February 01, 2002 8:13 AM |To: ni1d@arrl.net |Cc: ips@ece.cmu.edu |Subject: RE: IPsec Usage Question | | |> Excerpt of message (sent 31 January 2002) by Black_David@emc.com: |> > In Salt Lake City, I asked folks to become familiar with |> > existing IPsec implementations that they plan to (re)use. I |> > now have a specific question about this that I need answers |> > to - send the answers to me directly to avoid inadvertently |> > revealing implementation plans (I promise to keep them |> > private). |> > |> > Q: Does the IPsec implementation you plan to use require |> > that the inner IP address be different from the outer |> > IP address for traffic that is to pass through IPsec |> > to the IP Storage (iSCSI, iFCP, FCIP) system? |> > Follow-up: If so, how do you plan to configure your system |> > to securely access a peer IP Storage system from |> > another vendor that also has this requirement? |> > |> > The underlying concern is that requiring that the inner |> > and outer IP addresses always be the same would visibly |> > simplify the configuration required to use IPsec with |> > the IP Storage protocols. |> |> I'm not sure if this is what you intended, but I'm reading |this to say |> that IPsec as used with IP Storage would mandate the same IP |addresses |> on inner and outer header. |> |> If so, that is equivalent to prohibiting external security gateways. |> This is not good. I understand that there are people who |feel that an |> external security gateway is not necessarily the right way to address |> security concerns in IP Storage. But that's a long way from |> prohibiting their use entirely. |> |> If that wasn't your intent, could you clarify what you're after? If |> the goal is to *permit* inner == outer, that's fine. That's commonly |> supported because that situation occurs when you tunnel from a single |> host to a site protected by an IPsec gateway. And yes, |allowing inner |> == outer in that case indeed makes things slightly easier. | |Mandating the same addresses in the inner and outer header is a "big |hammer" that may not be the right course of action. OTOH, if one |needs to know both the inner and outer IP addresses in order to contact |a target, that has implications for the functionality/usage of Send |Targets, iSNS, and SLP. My underlying goal is to figure out whether |we need to put support for two IP addresses per target into those |configuration mechanisms (this would apply to FCIP, iFCP, and iSCSI). | |I intended to raise the possibility of mandating the same addresses |in the inner and outer header as a possibility as opposed to proposing |it as a course of action as I don't have enough info about what folks |intend to do/think is important to make any proposal in this space. |Paul's input that this would be a bad idea because it would implicitly |ban the use of security gateways is a fine response to that possibility |- and to his credit, Paul was right about the last IPsec-related issue |he brought up (dangling SAs). | |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 Fri Feb 1 21:00: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 VAA16101 for ; Fri, 1 Feb 2002 21:00:32 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g121Pla23089 for ips-outgoing; Fri, 1 Feb 2002 20:25:47 -0500 (EST) 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 g121Pjj23083 for ; Fri, 1 Feb 2002 20:25:45 -0500 (EST) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id RAA19163; Fri, 1 Feb 2002 17:25:31 -0800 (PST) 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 RAA11828; Fri, 1 Feb 2002 17:08:43 -0800 (PST) Received: by aimexc07.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Feb 2002 17:24:20 -0800 Message-ID: From: "Mukund, Shridhar" To: "'WENDT,JIM (HP-Roseville,ex1)'" , ips@ece.cmu.edu Subject: RE: iSCSI: No Framing Date: Fri, 1 Feb 2002 17:24:18 -0800 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 Dear Colleagues, PART 1 of 3 : The pertinent points that "I" see in Jim's email are: A. Need to hear from iSCSI chip implementers ... The issues that you raise for e.g. in #2 are simply circumstantial( See PART 2 ). Answers to those questions unnecessarily call for data flows and implementation details that silicon vendors are not allowed to share in public. While I do not know of many silicon vendors in the multi gig space, clearly one of the competitions I respect, namely Trebia, point to FIM as well. Granted, no matter what, we are going to see several trebia-on-the-other-end and adaptec-on-the-other-end type of cost optimizations. B. The iWARP/TUF/SCTP under-current ... The "only" message of significance in Jim's email is #5. It seems like the iWARP/SCTP/TUF enthusiasts somehow feel threatened that FIM-iSCSI will dilute the perceived value proposition of iWARP :-) I for one am an enthusiast of iWARP ideals myself, barring the proposed mechanics. I would love to make a buck or two along with you in building iWARP NICs, "at the right time". In the meanwhile, iSCSI is the flag ship effort that has the unique opportunity to make a dent in enabling IP Storage visions. ( See PART 3 ) My assertions are : i) TUF/SCTP/iWARP is ruled out in the near term. The mechanics are unclear as hell. ii) FIM is the least intrusive, TCP transparent, means for enabling low-cost(power,b/w,latency,memory,space,CPU) RDMA transport of bulk data. iii) I do not see significant technical reasons that merit major changes to the iSCSI draft at this late date. iii) Making it OPTIONAL to use, and SHOULD only on send provides a graceful and incremental deployment path for "real":-) providers and users to succeed. I have personally contributed nothing to the iSCSI effort and do applaud the pains that several of you are taking to pull it all together. In that very same spirit, I respect David's decision w.r.t. consensus, whatever that turns out to be. Thanks. -Shridhar Mukund + Todd Sperry, Siva Munnangi, Dev ... ------------------------------------------------------------ PART 2 of 3 : MUST delete, SHOULD read Dear Jim, Congratulations Jim! Seems like when you bowl, pins roll, unintentional as they may be. You make a "seemingly" well balanced set of arguments and "tactfully" tilt the balance towards your chosen side. I would love to be on your side ... maybe in another effort :-) I would like to introduce you to my respectable friend, who "vehemently" contradicts you on all accounts. One of his numerous quotes goes as follows: http://groups.yahoo.com/group/rdma/message/486 "Much of today's usage of the Internet and IP networks is for buffer-to-buffer data transfers, often in the form of bulk data ... Gigabit and faster network transfers incur 'heavy' system resource costs, including both CPU use and system bus bandwidth, particularly on the receiving side ... The costs incurred on hosts for protocol processing and management has 'inhibited' the use of IP in the high speed bulk data domain. ... Bulk data transfer is dominated by the costs of copying and validating incoming data in order to place it at its ultimate destination." The good friend I quote above is none other than Jim Wendt himself!!! I REST MY CASE. Thanks. -Shridhar Mukund ---------------------------------------------------------------- PART 3 of 3: MUST delete, OPTIONAL read On the lighter side ... since the opponents have "no" technical arguments whatsoever against FIM and it is all turning out to be a pure political gimmick, I will put on my rusting tin politician hat :-) My dear fellow iSCSI country (wo)men: If our goals are anything short of enabling the HP's, Cisco's, uSoft's, IBM's and EMC's of the world in globalization of storage for McDonald's and Macy's from Kabul to Somalia, via iSCSI, we have lost our identity! ( \insert APPLAUSE for 13 seconds )We are no more protected by the vast oceans between us and other Storage efforts. The freedom of iSCSI America is threatened from within by elements who will not blink twice when it comes to using the world's most potent BOO-bombs ... and grinnn while we end up sifting through the rubbles for iSCSI, youSCSI and theySCSI. ( \insert APPLAUSE for 11 seconds ) Beware of the elements that sleep with "our" very ideals in their privacy(burkha clad though) and yet attempt to destabilize us, only to accomplish their mutated agenda.( \insert APPLAUSE for 57 seconds ) No offense folks. I respect each and every one of you and especially Jim. I think that he was only attempting to question, "are we sure ... should we commit ...". I disagree with him anyway! - the running(actually limping) mate :-) :-) :-) -----Original Message----- From: WENDT,JIM (HP-Roseville,ex1) [mailto:jim_wendt@hp.com] Sent: Tuesday, January 29, 2002 10:47 PM To: ips@ece.cmu.edu Subject: iSCSI: No Framing Perhaps we should discuss the possibility of not specifying any framing mechanism (FIM or COWS) in the first version of iSCSI. The arguments for not specifying framing include (there may be others as well): 1) The brute force approach of putting TCP receiver reassembly memory on the iSCSI NIC will work for both 1Gbps and 10Gbps. Cost is incurred for memory chips, ASIC pins, power, and board space. But, it is a feasible approach. 2) I/O bus latency (or bandwidth limitations) could mandate inbound buffering (as a 'smoothing' buffer) from the iSCSI NIC to the host system. If this buffer memory is large enough to have to be off-chip, then it will require some minimum number of memory chips to provide the necessary bandwidth, and the memory/pins/power/space costs will be incurred anyway. 3) Very large receive buffering on the NIC is only required for high-bandwidth links traversing large geographic distances (which may not be the predominate case). These specialized implementations can cost more (e.g. more memory/power/pins/etc) and customers will likely be willing to pay accordingly. 4) Many NICs will likely aspire to be combo iSCSI+TOE+Ethernet NICs allowing the host system to use a single Ethernet port for all of its network communications. The TOE function on this combo NIC will already require TCP receive buffering and off- chip buffer memory to support the existing sockets interface receive model. More importantly, to allow senders to assume ownership of the buffer upon return from a socket send call, the TOE NIC would need to copy application send buffers into NIC memory as well. 5) The framing/marker mechanism will be an iSCSI-only solution. It is quite possible that the problem will be solved via a different, and hopefully more general, mechanism for other ULPs. 6) Both FIM and COWS are poor solutions for software implementation. COWS requires, at a minimum, the sender to read every word in the buffer. FIM either imposes additional sender gather processing (iovecs) or requires a data buffer copy (on systems that don't support HW gather on sends). 7) Unless all senders thoroughly test framing/markers now (i.e. unless the framing method is a MUST implement), there is potential for future interoperability problems as framing/marker receivers are deployed in the future. 8) Neither FIM nor COWS is an elegant solution. Are we comfortable with the legacy we are creating under the umbrella of state-of-the-art IP networked storage? 9) Is it essential to build in forward compatibility now, or will there be a different solution in the 10Gbps or 40Gbps timeframe - perhaps involving iSCSI- 2? Will it be reasonable to update or bridge initial 1Gbps deployments? So, it would be good to hear from several iSCSI NIC/chip implementors who: - have or plan to implement FIM or COWS (or some other framing mechanism) and take advantage of it to minimize demands on on-NIC buffer memory bandwidth/quantity. - believe that all-buffers-on-chip solutions are feasible and valid (wrt the points above, including #2) - can quantify the memory/pin/power/space cost savings for all-buffers-on-chip solutions Jim From owner-ips@ece.cmu.edu Fri Feb 1 21:01: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 VAA16137 for ; Fri, 1 Feb 2002 21:01:59 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g121Bt822444 for ips-outgoing; Fri, 1 Feb 2002 20:11:55 -0500 (EST) 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 g121Brj22437 for ; Fri, 1 Feb 2002 20:11:53 -0500 (EST) Received: from xparelay1.corp.hp.com (xparelay1.corp.hp.com [15.58.136.173]) by palrel10.hp.com (Postfix) with ESMTP id 0952EC0104A; Fri, 1 Feb 2002 16:28:06 -0800 (PST) Received: from xpabh4.corp.hp.com (xpabh4.corp.hp.com [15.58.136.1]) by xparelay1.corp.hp.com (Postfix) with ESMTP id C4DB4E000A6; Fri, 1 Feb 2002 16:28:05 -0800 (PST) Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2653.19) id <1DJCK4DW>; Fri, 1 Feb 2002 16:28:05 -0800 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF38F@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: IPsec Usage Question Date: Fri, 1 Feb 2002 16:28:04 -0800 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 agree with Paul, the association of *any* internal network address to any external mapping is an IPSec configuration concern! To state that another way, that is a generic IPSec security gateway configuration detail. I can't speak for iSNS, but this information does *not* belong in the SendTargets command or the iSCSI portion of SLP! That very notion violates architectural layering principals - iSCSI has no need to know about IPSec headers which will be stripped off before the iSCSI processing layer receives the packet. It is true that security gateways in general have implications to the accessability of *every* service behind that gateway. But the solution does not lie in sprinkling pieces of the IPSec configuration into all of those service configuration mechanisms! As Paul suggests, this should be handled by the IPSec configuration management tools. We've already agreed that sendTargets should contain only information directly related to iSCSI configuration (knowledge within the iSCSI "entity") - see this thread http://www.pdl.cmu.edu/mailinglists/ips/mail/msg04944.html Just say No! to feature creep... :-) Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard tel: +1 916 785 2656 fax: +1 916 785 0391 email: marjorie_krueger@hp.com > -----Original Message----- > From: Paul Koning [mailto:ni1d@arrl.net] > Sent: Friday, February 01, 2002 12:54 PM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: RE: IPsec Usage Question > > > Excerpt of message (sent 1 February 2002) by Black_David@emc.com: > > Mandating the same addresses in the inner and outer header is a "big > > hammer" that may not be the right course of action. OTOH, if one > > needs to know both the inner and outer IP addresses in > order to contact > > a target, that has implications for the functionality/usage of Send > > Targets, iSNS, and SLP. My underlying goal is to figure out whether > > we need to put support for two IP addresses per target into those > > configuration mechanisms (this would apply to FCIP, iFCP, > and iSCSI). > > Managing the mapping from the inner address to the outer address is > a function of IPsec management -- that's the policy database which > defines which host traffic is protected by what tunnel. > > It's tempting to try to avoid IPsec management by addressing > restrictions such as you mentioned here, but that does not help. > There are about a dozen parameters for an IPsec SA, and you can't > hardware all of them in the standard. Trying to attack this by the > restriction you proposed, even if feasible, only takes care of a > fraction of the IPsec management you need. > > I would think that IP Storage mechanisms such as Send Targets or iSNS > should concern themselves with storage, not with other components like > IPsec. So yes, you need IPsec management (including tunnel > addressing) but no, it's not the job of IP Storage mechanisms to > administer those parameters. > > paul > From owner-ips@ece.cmu.edu Fri Feb 1 21:54: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 VAA17832 for ; Fri, 1 Feb 2002 21:54:33 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g121vBb24527 for ips-outgoing; Fri, 1 Feb 2002 20:57:11 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ariel.nishansystems.com (goretex.nishansystems.com [216.217.36.167]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g121v9j24519 for ; Fri, 1 Feb 2002 20:57:09 -0500 (EST) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Feb 2002 17:56:42 -0800 Message-ID: From: Joshua Tseng To: "'CAVANNA,VICENTE V (A-Roseville,ex1)'" , "'Black_David@emc.com'" , "'Paul Koning'" Cc: ips@ece.cmu.edu, "THALER,PAT (A-Roseville,ex1)" Subject: RE: IPsec Usage Question Date: Fri, 1 Feb 2002 17:56:39 -0800 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 Knowledge of the gateway IP address (first-hop address) is a common requirement for all IP hosts, not just iSCSI hosts. In fact, this is information relevant only to the IP layer below iSCSI. If a security gateway were front-ending an iSCSI device in a single box, I would imagine the gateway's IP address would be the first-hop address for the IP configuration. But once again, this is below iSCSI and doesn't need to be known to iSCSI. I therefore don't see why iSCSI needs to be conscious of the security gateway's address. And I agree it's best to keep this out of sendtargets, iSNS, and SLP. Josh > -----Original Message----- > From: CAVANNA,VICENTE V (A-Roseville,ex1) > [mailto:vince_cavanna@agilent.com] > Sent: Friday, February 01, 2002 4:53 PM > To: 'Black_David@emc.com'; 'Paul Koning' > Cc: ips@ece.cmu.edu; THALER,PAT (A-Roseville,ex1) > Subject: RE: IPsec Usage Question > > > I agree with Paul Koning's comments on this topic; in particular his > observation that forcing the inner and outer IP addresses to > be the same > forces the security tunnel endpoint to be the same as the > communication > endpoint and thus precludes implementing security in an > entity other that > that which originated the packet. I am one of those who think an IPSEC > tunnel to a gateway and then an unsecured path to the storage > device is not > enough security for storage traffic but the reality is that > this may be the > only security available initially. > > In fact it is possible that we have nested tunnels and we may > be dealing > with more than two IP addresses. > > I therefore do not agree with mandating both IPs to be the same. > > It seems inevitable to me that if security is implemented by > a gateway in > the path to a storage server, that the clients need to be > aware of its IP > address as well as the IP of the storage server and as Paul > has pointed out > this is a function of Security Policy management. > > Vince Cavanna > Agilent Technologies > > |-----Original Message----- > |From: Black_David@emc.com [mailto:Black_David@emc.com] > |Sent: Friday, February 01, 2002 8:13 AM > |To: ni1d@arrl.net > |Cc: ips@ece.cmu.edu > |Subject: RE: IPsec Usage Question > | > | > |> Excerpt of message (sent 31 January 2002) by Black_David@emc.com: > |> > In Salt Lake City, I asked folks to become familiar with > |> > existing IPsec implementations that they plan to (re)use. I > |> > now have a specific question about this that I need answers > |> > to - send the answers to me directly to avoid inadvertently > |> > revealing implementation plans (I promise to keep them > |> > private). > |> > > |> > Q: Does the IPsec implementation you plan to use require > |> > that the inner IP address be different from the outer > |> > IP address for traffic that is to pass through IPsec > |> > to the IP Storage (iSCSI, iFCP, FCIP) system? > |> > Follow-up: If so, how do you plan to configure your system > |> > to securely access a peer IP Storage system from > |> > another vendor that also has this requirement? > |> > > |> > The underlying concern is that requiring that the inner > |> > and outer IP addresses always be the same would visibly > |> > simplify the configuration required to use IPsec with > |> > the IP Storage protocols. > |> > |> I'm not sure if this is what you intended, but I'm reading > |this to say > |> that IPsec as used with IP Storage would mandate the same IP > |addresses > |> on inner and outer header. > |> > |> If so, that is equivalent to prohibiting external security > gateways. > |> This is not good. I understand that there are people who > |feel that an > |> external security gateway is not necessarily the right way > to address > |> security concerns in IP Storage. But that's a long way from > |> prohibiting their use entirely. > |> > |> If that wasn't your intent, could you clarify what you're > after? If > |> the goal is to *permit* inner == outer, that's fine. > That's commonly > |> supported because that situation occurs when you tunnel > from a single > |> host to a site protected by an IPsec gateway. And yes, > |allowing inner > |> == outer in that case indeed makes things slightly easier. > | > |Mandating the same addresses in the inner and outer header is a "big > |hammer" that may not be the right course of action. OTOH, if one > |needs to know both the inner and outer IP addresses in order > to contact > |a target, that has implications for the functionality/usage of Send > |Targets, iSNS, and SLP. My underlying goal is to figure out whether > |we need to put support for two IP addresses per target into those > |configuration mechanisms (this would apply to FCIP, iFCP, and iSCSI). > | > |I intended to raise the possibility of mandating the same addresses > |in the inner and outer header as a possibility as opposed to > proposing > |it as a course of action as I don't have enough info about what folks > |intend to do/think is important to make any proposal in this space. > |Paul's input that this would be a bad idea because it would > implicitly > |ban the use of security gateways is a fine response to that > possibility > |- and to his credit, Paul was right about the last > IPsec-related issue > |he brought up (dangling SAs). > | > |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 Fri Feb 1 22:56: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 WAA19428 for ; Fri, 1 Feb 2002 22:56:09 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g123F8q27817 for ips-outgoing; Fri, 1 Feb 2002 22:15:08 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from demetrius.hosting.pacbell.net (demetrius.hosting.pacbell.net [216.100.99.31]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g123F6j27812 for ; Fri, 1 Feb 2002 22:15:06 -0500 (EST) Received: from somesh ([65.172.158.93]) by demetrius.hosting.pacbell.net id WAA08707; Fri, 1 Feb 2002 22:12:36 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Reply-To: From: "Somesh Gupta" To: "Mukund, Shridhar" , "'WENDT,JIM \(HP-Roseville,ex1\)'" , Subject: RE: iSCSI: No Framing Date: Fri, 1 Feb 2002 19:10:13 -0800 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mukund, With all due respect, taking on the mantle of the noble engineer being denied by politically motivated people, belittles the technical expertise and strengths of the people who have expressed an opinion against having any of the proposed schemes at this time in the spec. I would be very happy to work alongside a number of the people on both sides of the issue (and that does include you). None of your arguments below refutes the technical and some non-technical opinions expressed against FIM. Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Mukund, Shridhar > Sent: Friday, February 01, 2002 5:24 PM > To: 'WENDT,JIM (HP-Roseville,ex1)'; ips@ece.cmu.edu > Subject: RE: iSCSI: No Framing > > > Dear Colleagues, > > PART 1 of 3 : > > The pertinent points that "I" see in Jim's email are: > > A. Need to hear from iSCSI chip implementers ... > The issues that you raise for e.g. in #2 are simply > circumstantial( See PART 2 ). Answers to those questions > unnecessarily call for data flows and implementation > details that silicon vendors are not allowed to share > in public. While I do not know of many silicon vendors > in the multi gig space, clearly one of the competitions > I respect, namely Trebia, point to FIM as well. Granted, > no matter what, we are going to see several > trebia-on-the-other-end and adaptec-on-the-other-end > type of cost optimizations. > > B. The iWARP/TUF/SCTP under-current ... > The "only" message of significance in Jim's email is #5. > It seems like the iWARP/SCTP/TUF enthusiasts somehow feel > threatened that FIM-iSCSI will dilute the perceived value > proposition of iWARP :-) I for one am an enthusiast of > iWARP ideals myself, barring the proposed mechanics. I > would love to make a buck or two along with you in > building iWARP NICs, "at the right time". In the > meanwhile, iSCSI is the flag ship effort that has the > unique opportunity to make a dent in enabling IP Storage > visions. ( See PART 3 ) > > My assertions are : > i) TUF/SCTP/iWARP is ruled out in the near term. The > mechanics are unclear as hell. > ii) FIM is the least intrusive, TCP transparent, means for > enabling low-cost(power,b/w,latency,memory,space,CPU) > RDMA transport of bulk data. > iii) I do not see significant technical reasons that > merit major changes to the iSCSI draft at this late > date. > iii) Making it OPTIONAL to use, and SHOULD only on send > provides a graceful and incremental deployment path > for "real":-) providers and users to succeed. > > I have personally contributed nothing to the iSCSI effort > and do applaud the pains that several of you are taking to > pull it all together. In that very same spirit, I respect > David's decision w.r.t. consensus, whatever that turns out > to be. > > Thanks. > > -Shridhar Mukund + Todd Sperry, Siva Munnangi, Dev ... > > ------------------------------------------------------------ > PART 2 of 3 : MUST delete, SHOULD read > > Dear Jim, > > Congratulations Jim! Seems like when you bowl, pins > roll, unintentional as they may be. You make a "seemingly" > well balanced set of arguments and "tactfully" tilt the > balance towards your chosen side. I would love to be on > your side ... maybe in another effort :-) > > I would like to introduce you to my respectable friend, > who "vehemently" contradicts you on all accounts. One of > his numerous quotes goes as follows: > http://groups.yahoo.com/group/rdma/message/486 > "Much of today's usage of the Internet and IP networks > is for buffer-to-buffer data transfers, often in the > form of bulk data ... Gigabit and faster network transfers > incur 'heavy' system resource costs, including both CPU > use and system bus bandwidth, particularly on the > receiving side ... The costs incurred on hosts for protocol > processing and management has 'inhibited' the use of IP > in the high speed bulk data domain. ... Bulk data transfer > is dominated by the costs of copying and validating > incoming data in order to place it at its ultimate > destination." > > The good friend I quote above is none other than Jim > Wendt himself!!! I REST MY CASE. > > Thanks. > > -Shridhar Mukund > > ---------------------------------------------------------------- > PART 3 of 3: MUST delete, OPTIONAL read > > On the lighter side ... since the opponents have "no" technical > arguments whatsoever against FIM and it is all turning out to > be a pure political gimmick, I will put on my rusting tin > politician hat :-) > > My dear fellow iSCSI country (wo)men: If our goals are anything > short of enabling the HP's, Cisco's, uSoft's, IBM's and EMC's of > the world in globalization of storage for McDonald's and Macy's > from Kabul to Somalia, via iSCSI, we have lost our identity! > ( \insert APPLAUSE for 13 seconds )We are no more protected by > the vast oceans between us and other Storage efforts. The > freedom of iSCSI America is threatened from within by elements > who will not blink twice when it comes to using the world's most > potent BOO-bombs ... and grinnn while we end up sifting through > the rubbles for iSCSI, youSCSI and theySCSI. > ( \insert APPLAUSE for 11 seconds ) Beware of the elements that > sleep with "our" very ideals in their privacy(burkha clad > though) and yet attempt to destabilize us, only to accomplish > their mutated agenda.( \insert APPLAUSE for 57 seconds ) > > No offense folks. I respect each and every one of you and > especially Jim. I think that he was only attempting to > question, "are we sure ... should we commit ...". > I disagree with him anyway! > > - the running(actually limping) mate :-) :-) :-) > > -----Original Message----- > From: WENDT,JIM (HP-Roseville,ex1) [mailto:jim_wendt@hp.com] > Sent: Tuesday, January 29, 2002 10:47 PM > To: ips@ece.cmu.edu > Subject: iSCSI: No Framing > > > Perhaps we should discuss the possibility of not > specifying any framing mechanism (FIM or COWS) in the > first version of iSCSI. > > The arguments for not specifying framing include > (there may be others as well): > 1) The brute force approach of putting TCP receiver > reassembly memory on the iSCSI NIC will work for both > 1Gbps and 10Gbps. Cost is incurred for memory chips, > ASIC pins, power, and board space. But, it is a > feasible approach. > > 2) I/O bus latency (or bandwidth limitations) could > mandate inbound buffering (as a 'smoothing' buffer) > from the iSCSI NIC to the host system. If this buffer > memory is large enough to have to be off-chip, then > it will require some minimum number of memory chips > to provide the necessary bandwidth, and the > memory/pins/power/space costs will be incurred > anyway. > > 3) Very large receive buffering on the NIC is only > required for high-bandwidth links traversing large > geographic distances (which may not be the > predominate case). These specialized implementations > can cost more (e.g. more memory/power/pins/etc) and > customers will likely be willing to pay accordingly. > > 4) Many NICs will likely aspire to be combo > iSCSI+TOE+Ethernet NICs allowing the host system to > use a single Ethernet port for all of its network > communications. The TOE function on this combo NIC > will already require TCP receive buffering and off- > chip buffer memory to support the existing sockets > interface receive model. More importantly, to allow > senders to assume ownership of the buffer upon return > from a socket send call, the TOE NIC would need to > copy application send buffers into NIC memory as > well. > > 5) The framing/marker mechanism will be an iSCSI-only > solution. It is quite possible that the problem will > be solved via a different, and hopefully more > general, mechanism for other ULPs. > > 6) Both FIM and COWS are poor solutions for software > implementation. COWS requires, at a minimum, the > sender to read every word in the buffer. FIM either > imposes additional sender gather processing (iovecs) > or requires a data buffer copy (on systems that don't > support HW gather on sends). > > 7) Unless all senders thoroughly test framing/markers > now (i.e. unless the framing method is a MUST > implement), there is potential for future > interoperability problems as framing/marker receivers > are deployed in the future. > > 8) Neither FIM nor COWS is an elegant solution. Are > we comfortable with the legacy we are creating under > the umbrella of state-of-the-art IP networked > storage? > > 9) Is it essential to build in forward compatibility > now, or will there be a different solution in the > 10Gbps or 40Gbps timeframe - perhaps involving iSCSI- > 2? Will it be reasonable to update or bridge initial > 1Gbps deployments? > > > So, it would be good to hear from several iSCSI > NIC/chip implementors who: > - have or plan to implement FIM or COWS (or some > other framing mechanism) and take advantage of it to > minimize demands on on-NIC buffer memory > bandwidth/quantity. > - believe that all-buffers-on-chip solutions are > feasible and valid (wrt the points above, including > #2) > - can quantify the memory/pin/power/space cost > savings for all-buffers-on-chip solutions > > Jim > From owner-ips@ece.cmu.edu Fri Feb 1 22: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 WAA19442 for ; Fri, 1 Feb 2002 22:59:13 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g122rQM26866 for ips-outgoing; Fri, 1 Feb 2002 21:53:26 -0500 (EST) 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 g122rOj26861 for ; Fri, 1 Feb 2002 21:53:24 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Feb 2002 21:53:18 -0500 Message-ID: <25369470B6F0D41194820002B328BDD2202622@ATLOPS> From: Eddy Quicksall To: Black_David@emc.com Cc: "ips@ece. cmu. edu (E-mail)" Subject: RE: iSCSI: not offering a key Date: Fri, 1 Feb 2002 21:53:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AB94.C2A33570" 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_01C1AB94.C2A33570 Content-Type: text/plain; charset="iso-8859-1" > I'm recommending that implementers exercise good judgment ... are you objecting to this? No > I think we're close to violent agreement. Yes Actually, I started this thread because I was wondering what was meant by the sentence: Not offering a key for negotiation is not equivalent to offering the current (or default) value. And I think that was answered. Thanks Eddy -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Friday, February 01, 2002 10:08 AM To: Eddy_Quicksall@ivivity.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: not offering a key Eddy, > What I was referring to is that you said: > > If for some reason the other party doesn't have the > same default (bugs happen), negotiation should drive > both parties to an agreed value ... > > Reading on I assumed you meant that we should add code to cope with that. > If you take that to an extreme, we would be adding "lots of code" just to cover all possible bugs. That was definitely not my intention. If either party chooses to negotiate a value, the negotiation code that has to be implemented anyway will drive both parties to agreement, but notice the *if*. I definitely do not want this taken to an extreme that would require all keys to be negotiated in all cases. As a consequence, there will be situations in which mistakes occur that cause the two parties to have different ideas of what the default value is for a key that wasn't negotiated (to err is human, most code is written by humans ... ). I am recommending an "if in doubt, negotiate" approach to implementation that will tend to limit such problems to relatively unimportant keys. Coverage of "all possible bugs" was not my intention. > An implementation should only have to cover the other ends bugs that could cause a crash > or data corruption at our end. In this case, I don't think that means we should change the > standard to do extra negotiations just to cover possible bugs. I think we have a serious difference in philosophy. The usual IETF dictum of being conservative in what is sent and liberal in what is accepted implies coverage of more than just bugs that could cause a crash or data corruption - see the recent example I sent to the list of how a notion of "implicit offers" could cause a silly breakdown in negotiation. OTOH, being liberal in what is accepted does not equate to covering all possible bugs - it means doing one's best to do something reasonable in the face of the unexpected as opposed to regarding the least little thing going wrong as a fatal error and reason to immediately give up. As to the standard, I'm not proposing any change. I'm recommending that implementers exercise good judgment by choosing to negotiate any parameters that are important to the behavior and performance of their implementation (which sounds like common sense - are you objecting to this?). The negotiation algorithm has been (and should be) specified in a way that is robust to minor things going wrong, and hence just using it provides some robustness against minor things going wrong. The overall principle is somewhat akin to the exhortation not to complain about the behavior of the government if you didn't bother to vote. I think we're close to violent agreement. 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: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] Sent: Friday, February 01, 2002 7:37 AM To: Black_David@emc.com; Eddy Quicksall Cc: ips@ece.cmu.edu Subject: RE: iSCSI: not offering a key Maybe I misunderstood your note. What I was referring to is that you said: If for some reason the other party doesn't have the same default (bugs happen), negotiation should drive both parties to an agreed value ... Reading on I assumed you meant that we should add code to cope with that. If you take that to an extreme, we would be adding "lots of code" just to cover all possible bugs. An implementation should only have to cover the other ends bugs that could cause a crash or data corruption at our end. In this case, I don't think that means we should change the standard to do extra negotiations just to cover possible bugs. Again, maybe I misunderstood what you were trying to say. Eddy -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Tuesday, January 29, 2002 3:16 AM To: Eddy_Quicksall@ivivity.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: not offering a key I don't understand how this leads to "lots of code". The underlying principle is to negotiate anything you care about and not to complain about things that you didn't negotiate. Saying that there are no implicit offers is fine with me. Thanks, --David -----Original Message----- From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] Sent: Monday, January 28, 2002 12:42 PM To: julian_satran@il. ibm. com (E-mail) Cc: ips@ece.cmu.edu; Robert D. Russell Subject: RE: iSCSI: not offering a key I don't think we should be in the business of adding lots of code to cope with possible bugs at the other end ... there would be no end to what you would do and how you would do it. Couldn't we just strike the sentence and say what Dr. Russell said. I would suggest something like: "There is no such thing as implicit offers. If an explicit offer is not made then a reply cannot be expected." -- cut and past from his EMAIL -- I believe this sentence was added to the spec because at the last UNH plugfest, several people were interpreting "no explicit offer" of a key as an "implicit" offer of the default for the key, and were therefore expecting a reply. This sentence is intended to prevent that interpretation -- if you don't make an explict offer you cannot expect a reply -- there are no such things as implicit offers. Eddy -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Saturday, January 26, 2002 3:31 AM To: Eddy_Quicksall@ivivity.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: not offering a key > Maybe I don't understand the sentence. I interpret it to mean that if the > default value is acceptable to me then not offering it is somehow different > than the default ... and that confuses me (well, actually it makes me wonder > if the sentence is trying to say something else). Here are two examples of how it's different: (1) If for some reason the other party doesn't have the same default (bugs happen), negotiation should drive both parties to an agreed value, but in the absence of negotiation, the other party might do something different. Moral: if a key value is important, it MUST be negotiated. This is a little weaker than Luben's statement that all keys always have to be negotiated. That strength was never intended. (2) If the other party wants to negotiate the value and both offer the same default value, not offering the default results in an additional step before the negotiation can conclude, viz: -> Nothing -> Key=Default <- Key=Default <- Key=Default -> Key=Default --David ------_=_NextPart_001_01C1AB94.C2A33570 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

> I'm recommending that = implementers exercise good judgment … are you objecting to = this?

 =

No=

 =

> I think = we're close to violent agreement.

 =

Yes=

 =

Actually, I started this thread because I was wondering what was meant by the = sentence:=

 =

Not offering a key for negotiation is not <= /p>

equivalent to offering the current (or default) = value.

 =

And I think that was answered.

 =

Thanks=

 =

Eddy=

 

=

 

=

-----Original Message-----
From: = Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Friday, February = 01, 2002 10:08 AM
To: = Eddy_Quicksall@ivivity.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: not = offering a key

 

Eddy,=

 =

> What I was referring to is that you = said:

> = =

> If for some reason the other party doesn't have = the

> same default (bugs happen), negotiation should = drive=

> both parties to an agreed value = ...<= o:p>

> = &= nbsp;

> Reading on I assumed you meant that = we should add code to cope with that.=

> If you take that to an extreme, we would = be adding “lots of code” just to cover all possible = bugs.=

 =

That was definitely not my intention.  If either party chooses to = negotiate a value, the negotiation

code tha= t has to be implemented anyway will drive both parties to agreement, = but notice the *if*.

I definitely do not want this taken to an extreme that would require all = keys to be negotiated in

all cases. As a consequence, there will be situations in which = mistakes occur that cause the

two parties to have different ideas of what the default value is for a key = that wasn't negotiated

(to err is human, most code is written by humans ... ).  I am = recommending an "if in doubt,

negotiate&quo= t; approach to implementation that will tend to limit such problems to = relatively=

unimportant keys.  Coverage of "all possible bugs" was not my = intention.=

 

> An implementation should only have to = cover the other ends bugs that could cause a crash=

> or data corruption at our end. In this = case, I don’t think that means we should change = the=

> standard to do extra negotiations just = to cover possible bugs. =

 =

I think we have a serious difference in philosophy.  The usual = IETF=

dictum of being = conservative in what is sent and liberal in what is=

accepted implies coverage = of more than just bugs that could cause a=

crash or data corruption = - see the recent example I sent to the list=

of how a notion of = "implicit offers" could cause a silly breakdown=

in negotiation.  = OTOH, being liberal in what is accepted does not=

equate to covering all possible bugs - it means = doing one's best to

do something reasonable in the face of the unexpected as = opposed=

to regarding the least little thing going wrong as a fatal = error and=

reason to immediately give up.=

 =

As to the standard, = I'm not = proposing any change.  I'm recommending that = implementers=

exercise good judgment by = choosing to negotiate any parameters that are important to the = behavior=

and performance of their = implementation (which sounds like common sense - are you objecting = to=

this?).  The negotiation = algorithm has been (and should be) specified in a way that is robust = to=

minor things going wrong, and = hence just using it provides some robustness against = minor=

things going = wrong.=

 =

The overall principle is = somewhat akin to the exhortation not to complain about the behavior = of=

the government if you didn't = bother to vote.  I think we're close to violent = agreement.=

 =

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: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com]
Sent: Friday, February = 01, 2002 7:37 AM
To: Black_David@emc.com; = Eddy Quicksall
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: not = offering a key

M= aybe I misunderstood your note.

<= ![if = !supportEmptyParas]> 

=

W= hat I was referring to is that you said:

<= ![if = !supportEmptyParas]> 

=

If for some reason the other party doesn't have = the

same default (bugs happen), negotiation should = drive=

both parties to an agreed value = ...<= o:p>

<= ![if = !supportEmptyParas]> 

=

R= eading on I assumed you meant that we should add code to cope with that. If you = take that to an extreme, we would be adding “lots of code” just to = cover all possible bugs.

<= ![if = !supportEmptyParas]> 

=

A= n implementation should only have to cover the other ends bugs that could = cause a crash or data corruption at our end. In this case, I don’t think = that means we should change the standard to do extra negotiations just to cover = possible bugs.

<= span style=3D"mso-spacerun: = yes"> 

A= gain, maybe I misunderstood what you were trying to = say.

<= ![if = !supportEmptyParas]> 

=

E= ddy

<= ![if = !supportEmptyParas]> 

=

-----Original Message-----
From: = Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Tuesday, January = 29, 2002 3:16 AM
To: = Eddy_Quicksall@ivivity.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: not = offering a key=

 =

I don't understand how this leads to "lots of code".  The

underlying principle is to negotiate anything you care = about=

and not to complain about things that you didn't = negotiate.=

Saying that there are no implicit offers is fine with = me.=

 =

Thanks,

--David

-----Original Message-----
From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com]
Sent: Monday, January = 28, 2002 12:42 PM
To: julian_satran@il. = ibm. com (E-mail)
Cc: ips@ece.cmu.edu; = Robert D. Russell
Subject: RE: iSCSI: not = offering a key

I= don’t think we should be in the business of adding lots of code to cope with = possible bugs at the other end … there would be no end to what you would = do and how you would do it.

<= ![if = !supportEmptyParas]> 

=

C= ouldn’t we just strike the sentence and say what Dr. Russell said. I would suggest something like:

<= ![if = !supportEmptyParas]> 

=

&= #8220;There is no such thing as implicit offers. If an explicit offer is not made then = a reply cannot be expected.”

<= ![if = !supportEmptyParas]> 

=

-- = cut and past from his EMAIL --

I = believe this sentence was added to the spec because at the

last = UNH plugfest, several people were interpreting "no = explicit

=

offer" of a key as an "implicit" offer of the default for the = key,

=

and = were therefore expecting a reply.  = This sentence is intended

to = prevent that interpretation -- if you don't make an explict = offer

=

you cannot expect a reply -- there are no = such things as implicit offers.

 

=

Eddy

<= ![if = !supportEmptyParas]> 

=

-----Original Message-----
From: = Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Saturday, January = 26, 2002 3:31 AM
To: = Eddy_Quicksall@ivivity.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: not = offering a key=

 =

> Maybe I = don’t understand the sentence. I interpret it to mean that if = the=

> default value = is acceptable to me then not offering it is somehow = different=

> than the = default … and that confuses me (well, actually it makes me = wonder=

> if the = sentence is trying to say something else).=

 =

Here are two examples of how it's = different:=

 =

(1) If for some reason the other party doesn't have = the=

    same default (bugs = happen), negotiation should drive

    both parties to an agreed value, = but in the absence of

    negotiation, the other party might = do something different.

    Moral: if a key value is = important, it MUST be negotiated.

    This is a little weaker than Luben's = statement that

    all keys always have to be = negotiated.  That strength

    was never intended.

 =

(2) If the other party wants to negotiate the value = and=

    both offer the same default value, not = offering the default

    results in an additional step before = the negotiation can

    conclude, viz:=

 =

    -> Nothing   = ;     -> Key=3DDefault

    <- Key=3DDefault    = <- Key=3DDefault

    -> Key=3DDefault=

 =

--David

 =

------_=_NextPart_001_01C1AB94.C2A33570-- From owner-ips@ece.cmu.edu Sat Feb 2 03:17: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 DAA00354 for ; Sat, 2 Feb 2002 03:17:20 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g127LCD07270 for ips-outgoing; Sat, 2 Feb 2002 02:21:12 -0500 (EST) 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 g127LAj07265 for ; Sat, 2 Feb 2002 02:21:10 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id IAA63852 for ; Sat, 2 Feb 2002 08:21:04 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g127MTE41152 for ; Sat, 2 Feb 2002 08:22:29 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI ACA requirement X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 2 Feb 2002 09:22:25 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 02/02/2002 09:22:27, Serialize complete at 02/02/2002 09:22:27 Content-Type: multipart/alternative; boundary="=_alternative 002852E8C2256B54_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 002852E8C2256B54_= Content-Type: text/plain; charset="us-ascii" Dave, In fact we could make it SHOULD as ACA support is not anymore critical provided that the right exception mechanism for busy etc. is in place and it is now and does not use ACA(!). However the effect on performance could be more taxing than in the case of FCP - the network diameter supported is far larger and the need to support commands in fly is more important than in the case of FCP. Julo "Dave Peterson" Sent by: owner-ips@ece.cmu.edu 02-02-02 00:17 To: "Ips@Ece. Cmu. Edu" cc: Subject: iSCSI ACA requirement I'm having heartburn with the statement in iSCSI rev 10 clause 9.2: "As iSCSI can have many commands in-flight between initiator and target, iSCSI mandates support for ACA." My understanding of the above statement is that iSCSI target must indicate support for NACA=1. Requiring ACA is problematic and normally not necessary for implementations for a variety of reasons. Examples: a. A small number of devices actually support NACA=1. b. In practice FC applications do not require command ordering (i.e., use of the Simple Queue Tag). If ordering is a consideration the application will issue the command and wait for the response. c. The FC/FCP standards do not require NACA=1. d. Complicates bridging implementations - bridge must proxy NACA=1 for a device that does not support NACA=1 - bridge must maintain NACA behavior when the end device does not support NACA=1 I do understand the benefits to requiring NACA=1 especially when command ordering and stateful operations are desired, but its not realistic at this time, IMHO. As such this use of ACA should be a SHOULD, not a must or mandate. Dave --=_alternative 002852E8C2256B54_= Content-Type: text/html; charset="us-ascii"
Dave,

In fact we could make it SHOULD as ACA support is not anymore critical provided that the right exception mechanism for busy etc. is in place and it is now and does not use ACA(!).  However the effect on performance could be more taxing than in the case of FCP - the network diameter supported is far larger and the need to support commands in fly is more important than in the case of FCP.

Julo




"Dave Peterson" <dap@cisco.com>
Sent by: owner-ips@ece.cmu.edu

02-02-02 00:17

       
        To:        "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
        cc:        
        Subject:        iSCSI ACA requirement

       


I'm having heartburn with the statement in iSCSI rev 10 clause 9.2:
"As iSCSI can have many commands in-flight between initiator and target,
iSCSI mandates support for ACA."

My understanding of the above statement is that iSCSI target must indicate
support for NACA=1.

Requiring ACA is problematic and normally not necessary for implementations
for a variety of reasons.
Examples:
a. A small number of devices actually support NACA=1.
b. In practice FC applications do not require command ordering (i.e., use of
the Simple Queue Tag). If ordering is a consideration the application will
issue the command and wait for the response.
c. The FC/FCP standards do not require NACA=1.
d. Complicates bridging implementations
                - bridge must proxy NACA=1 for a device that does not support NACA=1
                - bridge must maintain NACA behavior when the end device does not support
NACA=1

I do understand the benefits to requiring NACA=1 especially when command
ordering and stateful operations are desired, but its not realistic at this
time, IMHO.
As such this use of ACA should be a SHOULD, not a must or mandate.

Dave

--=_alternative 002852E8C2256B54_=-- From owner-ips@ece.cmu.edu Sat Feb 2 03:17: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 DAA00369 for ; Sat, 2 Feb 2002 03:17:52 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g127XYA07757 for ips-outgoing; Sat, 2 Feb 2002 02:33:34 -0500 (EST) 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 g127XWj07753 for ; Sat, 2 Feb 2002 02:33:32 -0500 (EST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.99.140.24]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id CAA85394; Sat, 2 Feb 2002 02:30:24 -0500 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay03.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g127XUR22428; Sat, 2 Feb 2002 00:33:30 -0700 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: No Framing To: Cc: "Mukund, Shridhar" , X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Fri, 1 Feb 2002 23:30:56 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 02/02/2002 12:33:30 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Somesh, This is not fair, we asked for Chip Vendors that were planning on using it, to make themselves known and to tell us why. Without exposing internal designs, he has tried to do that, likewise Trebia, and some others have said they want FIMs. You may not want FIMs for your design, but you should respect these folks that have been following our spec and found it to be valuable in their designs. They are putting their money on it not just talk, so we should at least give them the credit which their position deserves. Yes, of course they are disappointed with the rhetoric around this issue, since they and others have been following the spec, and can not understand why others haven't, since they have determined it to be of significant value. His note does speak to the issues. (And clearly has some silly parts :-) In fact he has found it of enough value to use now, since he believes they can not wait for iWARP to happen before the issue is addressed (and he really wants iWARP). It should be useful to listen to folks that are willing to put their money where their mouth is. OK, that said: don't you think we can find a way to address both your position and their position, since they both seem strong and heart felt. I would think that the "Should Implement" or at least "May Implement" would give both sides enough reasonable room to meet on an even business plane. . . . 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 "Somesh Gupta" @ece.cmu.edu on 02/01/2002 07:10:13 PM Please respond to Sent by: owner-ips@ece.cmu.edu To: "Mukund, Shridhar" , "'WENDT,JIM \(HP-Roseville,ex1\)'" , cc: Subject: RE: iSCSI: No Framing Mukund, With all due respect, taking on the mantle of the noble engineer being denied by politically motivated people, belittles the technical expertise and strengths of the people who have expressed an opinion against having any of the proposed schemes at this time in the spec. I would be very happy to work alongside a number of the people on both sides of the issue (and that does include you). None of your arguments below refutes the technical and some non-technical opinions expressed against FIM. Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Mukund, Shridhar > Sent: Friday, February 01, 2002 5:24 PM > To: 'WENDT,JIM (HP-Roseville,ex1)'; ips@ece.cmu.edu > Subject: RE: iSCSI: No Framing > > > Dear Colleagues, > > PART 1 of 3 : > > The pertinent points that "I" see in Jim's email are: > > A. Need to hear from iSCSI chip implementers ... > The issues that you raise for e.g. in #2 are simply > circumstantial( See PART 2 ). Answers to those questions > unnecessarily call for data flows and implementation > details that silicon vendors are not allowed to share > in public. While I do not know of many silicon vendors > in the multi gig space, clearly one of the competitions > I respect, namely Trebia, point to FIM as well. Granted, > no matter what, we are going to see several > trebia-on-the-other-end and adaptec-on-the-other-end > type of cost optimizations. > > B. The iWARP/TUF/SCTP under-current ... > The "only" message of significance in Jim's email is #5. > It seems like the iWARP/SCTP/TUF enthusiasts somehow feel > threatened that FIM-iSCSI will dilute the perceived value > proposition of iWARP :-) I for one am an enthusiast of > iWARP ideals myself, barring the proposed mechanics. I > would love to make a buck or two along with you in > building iWARP NICs, "at the right time". In the > meanwhile, iSCSI is the flag ship effort that has the > unique opportunity to make a dent in enabling IP Storage > visions. ( See PART 3 ) > > My assertions are : > i) TUF/SCTP/iWARP is ruled out in the near term. The > mechanics are unclear as hell. > ii) FIM is the least intrusive, TCP transparent, means for > enabling low-cost(power,b/w,latency,memory,space,CPU) > RDMA transport of bulk data. > iii) I do not see significant technical reasons that > merit major changes to the iSCSI draft at this late > date. > iii) Making it OPTIONAL to use, and SHOULD only on send > provides a graceful and incremental deployment path > for "real":-) providers and users to succeed. > > I have personally contributed nothing to the iSCSI effort > and do applaud the pains that several of you are taking to > pull it all together. In that very same spirit, I respect > David's decision w.r.t. consensus, whatever that turns out > to be. > > Thanks. > > -Shridhar Mukund + Todd Sperry, Siva Munnangi, Dev ... > > ------------------------------------------------------------ > PART 2 of 3 : MUST delete, SHOULD read > > Dear Jim, > > Congratulations Jim! Seems like when you bowl, pins > roll, unintentional as they may be. You make a "seemingly" > well balanced set of arguments and "tactfully" tilt the > balance towards your chosen side. I would love to be on > your side ... maybe in another effort :-) > > I would like to introduce you to my respectable friend, > who "vehemently" contradicts you on all accounts. One of > his numerous quotes goes as follows: > http://groups.yahoo.com/group/rdma/message/486 > "Much of today's usage of the Internet and IP networks > is for buffer-to-buffer data transfers, often in the > form of bulk data ... Gigabit and faster network transfers > incur 'heavy' system resource costs, including both CPU > use and system bus bandwidth, particularly on the > receiving side ... The costs incurred on hosts for protocol > processing and management has 'inhibited' the use of IP > in the high speed bulk data domain. ... Bulk data transfer > is dominated by the costs of copying and validating > incoming data in order to place it at its ultimate > destination." > > The good friend I quote above is none other than Jim > Wendt himself!!! I REST MY CASE. > > Thanks. > > -Shridhar Mukund > > ---------------------------------------------------------------- > PART 3 of 3: MUST delete, OPTIONAL read > > On the lighter side ... since the opponents have "no" technical > arguments whatsoever against FIM and it is all turning out to > be a pure political gimmick, I will put on my rusting tin > politician hat :-) > > My dear fellow iSCSI country (wo)men: If our goals are anything > short of enabling the HP's, Cisco's, uSoft's, IBM's and EMC's of > the world in globalization of storage for McDonald's and Macy's > from Kabul to Somalia, via iSCSI, we have lost our identity! > ( \insert APPLAUSE for 13 seconds )We are no more protected by > the vast oceans between us and other Storage efforts. The > freedom of iSCSI America is threatened from within by elements > who will not blink twice when it comes to using the world's most > potent BOO-bombs ... and grinnn while we end up sifting through > the rubbles for iSCSI, youSCSI and theySCSI. > ( \insert APPLAUSE for 11 seconds ) Beware of the elements that > sleep with "our" very ideals in their privacy(burkha clad > though) and yet attempt to destabilize us, only to accomplish > their mutated agenda.( \insert APPLAUSE for 57 seconds ) > > No offense folks. I respect each and every one of you and > especially Jim. I think that he was only attempting to > question, "are we sure ... should we commit ...". > I disagree with him anyway! > > - the running(actually limping) mate :-) :-) :-) > > -----Original Message----- > From: WENDT,JIM (HP-Roseville,ex1) [mailto:jim_wendt@hp.com] > Sent: Tuesday, January 29, 2002 10:47 PM > To: ips@ece.cmu.edu > Subject: iSCSI: No Framing > > > Perhaps we should discuss the possibility of not > specifying any framing mechanism (FIM or COWS) in the > first version of iSCSI. > > The arguments for not specifying framing include > (there may be others as well): > 1) The brute force approach of putting TCP receiver > reassembly memory on the iSCSI NIC will work for both > 1Gbps and 10Gbps. Cost is incurred for memory chips, > ASIC pins, power, and board space. But, it is a > feasible approach. > > 2) I/O bus latency (or bandwidth limitations) could > mandate inbound buffering (as a 'smoothing' buffer) > from the iSCSI NIC to the host system. If this buffer > memory is large enough to have to be off-chip, then > it will require some minimum number of memory chips > to provide the necessary bandwidth, and the > memory/pins/power/space costs will be incurred > anyway. > > 3) Very large receive buffering on the NIC is only > required for high-bandwidth links traversing large > geographic distances (which may not be the > predominate case). These specialized implementations > can cost more (e.g. more memory/power/pins/etc) and > customers will likely be willing to pay accordingly. > > 4) Many NICs will likely aspire to be combo > iSCSI+TOE+Ethernet NICs allowing the host system to > use a single Ethernet port for all of its network > communications. The TOE function on this combo NIC > will already require TCP receive buffering and off- > chip buffer memory to support the existing sockets > interface receive model. More importantly, to allow > senders to assume ownership of the buffer upon return > from a socket send call, the TOE NIC would need to > copy application send buffers into NIC memory as > well. > > 5) The framing/marker mechanism will be an iSCSI-only > solution. It is quite possible that the problem will > be solved via a different, and hopefully more > general, mechanism for other ULPs. > > 6) Both FIM and COWS are poor solutions for software > implementation. COWS requires, at a minimum, the > sender to read every word in the buffer. FIM either > imposes additional sender gather processing (iovecs) > or requires a data buffer copy (on systems that don't > support HW gather on sends). > > 7) Unless all senders thoroughly test framing/markers > now (i.e. unless the framing method is a MUST > implement), there is potential for future > interoperability problems as framing/marker receivers > are deployed in the future. > > 8) Neither FIM nor COWS is an elegant solution. Are > we comfortable with the legacy we are creating under > the umbrella of state-of-the-art IP networked > storage? > > 9) Is it essential to build in forward compatibility > now, or will there be a different solution in the > 10Gbps or 40Gbps timeframe - perhaps involving iSCSI- > 2? Will it be reasonable to update or bridge initial > 1Gbps deployments? > > > So, it would be good to hear from several iSCSI > NIC/chip implementors who: > - have or plan to implement FIM or COWS (or some > other framing mechanism) and take advantage of it to > minimize demands on on-NIC buffer memory > bandwidth/quantity. > - believe that all-buffers-on-chip solutions are > feasible and valid (wrt the points above, including > #2) > - can quantify the memory/pin/power/space cost > savings for all-buffers-on-chip solutions > > Jim > From owner-ips@ece.cmu.edu Sat Feb 2 05:43: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 FAA01761 for ; Sat, 2 Feb 2002 05:43:31 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g129W4911987 for ips-outgoing; Sat, 2 Feb 2002 04:32:04 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c003.snv.cp.net (c003-h004.c003.snv.cp.net [209.228.32.218]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g129W2j11983 for ; Sat, 2 Feb 2002 04:32:02 -0500 (EST) Received: (cpmta 8873 invoked from network); 2 Feb 2002 01:31:56 -0800 Received: from 64.130.130.105 (HELO dougrmt) by smtp.telocity.com (209.228.32.218) with SMTP; 2 Feb 2002 01:31:56 -0800 X-Sent: 2 Feb 2002 09:31:56 GMT From: "Douglas Otis" To: Subject: RE: iSCSI: No Framing Date: Sat, 2 Feb 2002 01:33:30 -0800 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit John, I understand your desire to push through an interim measure despite short-comings. With a solution available using an existing IP protocol for framing, there is no need to alter network layering to implement such a solution. Network equipment vendors will only find success supporting a reasonable number of applications. Any generic solution (hallmark of the IETF protocols) will quickly obsolete an application specific FIM leaving only difficulty for future support. Especially a generic, buffer friendly, framing solution that overcomes DoS, spoofing, router failure, head of queue blocking, while introducing increased SACK, bundling, object acknowledgement, and CRC32c error checking. Those advocating a portion of the iSCSI application be in hardware below the TCP transport should be willing to document information exchanged between layers, and the states held within this layer. You wish the IETF to endorse a scheme within a standards draft and yet not be allowed to understand its implementation. This scheme so modifies the application attempting FIM utilization, it would be impractical to describe this as not altering TCP. TCP is not just a wire specification. Changing the receive packet into a memory array needs additional clarification beyond a claim this does not change TCP. Doug > Somesh, > > This is not fair, we asked for Chip Vendors that were planning on > using it, to make themselves known and to tell us why. Without exposing > internal designs, he has tried to do that, likewise Trebia, and some > others have said they want FIMs. You may not want FIMs for your design, > but you should respect these folks that have been following our spec and > found it to be valuable in their designs. They are putting their money > on it not just talk, so we should at least give them the credit which > their position deserves. Yes, of course they are disappointed with the > rhetoric around this issue, since they and others have been following the > spec, and can not understand why others haven't, since they have > determined it to be of significant value. > > His note does speak to the issues. (And clearly has some silly parts :-) > > In fact he has found it of enough value to use now, since he believes they > can not wait for iWARP to happen before the issue is addressed (and he > really wants iWARP). It should be useful to listen to folks that are > willing to put their money where their mouth is. > > OK, that said: don't you think we can find a way to address both your > position and their position, since they both seem strong and > heart felt. I would think that the "Should Implement" or at least "May > Implement" would give both sides enough reasonable room to meet on an > even business plane. > . > . > . > 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 Feb 2 16:25: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 QAA07775 for ; Sat, 2 Feb 2002 16:25:12 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g12KCs014802 for ips-outgoing; Sat, 2 Feb 2002 15:12:54 -0500 (EST) 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 g12KCqj14797 for ; Sat, 2 Feb 2002 15:12:52 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Sat, 2 Feb 2002 15:12:51 -0500 Message-ID: <25369470B6F0D41194820002B328BDD2202627@ATLOPS> From: Eddy Quicksall To: Julian Satran , ips@ece.cmu.edu Subject: RE: iSCSI: error text Date: Sat, 2 Feb 2002 15:12:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AC25.FC66FDA0" 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_01C1AC25.FC66FDA0 Content-Type: text/plain; charset="iso-8859-1" Actually, I didn't mean to mandate it. I just don't want it to be illegal. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, February 01, 2002 12:29 PM To: ips@ece.cmu.edu Subject: RE: iSCSI: error text Eddy, Certainly correct and better than to force everybody to prduce the message. Julo Eddy Quicksall Sent by: owner-ips@ece.cmu.edu 01-02-02 14:46 To: Julian Satran/Haifa/IBM@IBMIL cc: "ips@ece. cmu. edu (E-mail)" Subject: RE: iSCSI: error text I forgot about the language thing :-). I guess this is already acceptable since there is not anything in the draft that says one can't send text with a Login Response with Status-Class non-zero. e.g. T->I Login Response, Status-Class=2, DataSegmentLength=30, DataSegment=X-CSG is incorrect Would that be acceptable under the specification? Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, January 29, 2002 3:52 PM To: Eddy Quicksall Cc: ips@ece. cmu. edu (E-mail) Subject: Re: iSCSI: error text Eddy - nice thought - there are vendor keys for that - If you ask me to add them as part of the standard - I will do it in HEBREW Julo Eddy Quicksall 29-01-02 21:04 To: Julian Satran/Haifa/IBM@IBMIL, "ips@ece. cmu. edu (E-mail)" cc: Subject: iSCSI: error text It would be nice if we could send some error text in the Login Response when the Status-Class is non zero. Since so many things fit into Initiator Error, that would allow anyone looking at an analyzer to see the actual reason. The text would not be defined by the spec but would be defined only by the target and would not be interpreted by anything other than a person trying to diagnose the problem. Eddy ------_=_NextPart_001_01C1AC25.FC66FDA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

A= ctually, I didn’t mean to mandate it. I just don’t want it to be = illegal.

<= ![if = !supportEmptyParas]> 

=

E= ddy

<= ![if = !supportEmptyParas]> 

=

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, February = 01, 2002 12:29 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI: = error text

 


Eddy,

Certainly correct and better = than to force everybody to prduce the message.

Julo

 

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

01-02-02 14:46 =

    =    
  =       To:        Julian = Satran/Haifa/IBM@IBMIL
  =       cc:        "ips@ece. cmu. edu = (E-mail)" <ips@ece.cmu.edu>
  =       Subject:        RE: iSCSI: error = text

      =  =



I forgot about the language thing = J.<= font color=3Dblack> =

  =

I guess this is = already acceptable since there is not anything in the draft that says one can't = send text with a Login Response with Status-Class = non-zero. =

  =

e.g. T->I = Login Response, Status-Class=3D2, DataSegmentLength=3D30, DataSegment=3DX-CSG = is incorrect =

  =

Would that be = acceptable under the specification?

  =

Eddy =

  =

-----Original Message-----
From: Julian Satran = [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, January 29, 2002 3:52 PM
To: Eddy Quicksall
Cc: ips@ece. cmu. edu (E-mail)
Subject: Re: iSCSI: error text

  =


Eddy - nice thought - there are vendor keys for that - If you ask me to = add them as part of the standard - I will do it in HEBREW = Julo =

  =

Eddy Quicksall <Eddy_Quicksall@ivivity.com> =

29-01-02 21:04 =

    =    
       To:        Julian Satran/Haifa/IBM@IBMIL, "ips@ece. cmu. edu (E-mail)" <ips@ece.cmu.edu>
       cc:       =  
       Subject:        iSCSI: = error text =

     



It would be nice if we could send some error text in the Login Response = when the Status-Class is non zero.

  =

Since so many = things fit into Initiator Error, that would allow anyone looking at an analyzer to = see the actual reason. =

  =

The text would = not be defined by the spec but would be defined only by the target and would = not be interpreted by anything other than a person trying to diagnose the = problem. =

  =

Eddy =

------_=_NextPart_001_01C1AC25.FC66FDA0-- From owner-ips@ece.cmu.edu Sat Feb 2 17:22: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 RAA08250 for ; Sat, 2 Feb 2002 17:22:39 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g12LKpc17245 for ips-outgoing; Sat, 2 Feb 2002 16:20:51 -0500 (EST) 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 g12LKoj17241 for ; Sat, 2 Feb 2002 16:20:50 -0500 (EST) 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 g12LKNJ22550; Sat, 2 Feb 2002 16:20:23 -0500 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with ESMTP id g12LKDx26015; Sat, 2 Feb 2002 16:20:22 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15452.22548.666000.100130@gargle.gargle.HOWL> Date: Sat, 2 Feb 2002 16:20:20 -0500 From: Paul Koning To: vince_cavanna@agilent.com Cc: ips@ece.cmu.edu Subject: RE: IPsec Usage Question References: <01A7DAF31F93D511AEE300D0B706ED9201BF46F1@axcs13.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 1 February 2002) by CAVANNA,VICENTE V (A-Roseville,ex1): > I am one of those who think an IPSEC > tunnel to a gateway and then an unsecured path to the storage device is not > enough security for storage traffic but the reality is that this may be the > only security available initially. > > In fact it is possible that we have nested tunnels and we may be dealing > with more than two IP addresses. Nested tunnels is certainly one example. But there are other reasons: 1. You mention a preference for having end to end (rather than gateway to somewhere) security. That's one valid preference. But in general the choice of what is required is driven, among other things, by a threat analysis. Threats differ for different installations; one size does not fit all. There will be plenty of sites where the threat analysis says that a security gateway (protecting traffic going beyond a security boundary) is the correct solution. 2. One reason why practical IPsec installations show a preference for security gateways is that it reduces the number of places where security must be managed. Security management is one of the hardest management jobs. (This is one of the serious problems with mandating security everywhere!) So network adminstrators generally put a security gateway in a suitable spot, and lavish a lot of attention on configuriging that correctly and carefully. The resulting secure channel then protects lots of other nodes at little or no extra cost. paul From owner-ips@ece.cmu.edu Sun Feb 3 19: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 TAA01359 for ; Sun, 3 Feb 2002 19:10:10 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g13N1Mq24080 for ips-outgoing; Sun, 3 Feb 2002 18:01:22 -0500 (EST) 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 g13N1Lj24076 for ; Sun, 3 Feb 2002 18:01:21 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 495456AB for ; Sun, 3 Feb 2002 16:01:20 -0700 (MST) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 1B2C3331 for ; Sun, 3 Feb 2002 16:01:20 -0700 (MST) Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Sun, 3 Feb 2002 16:01:20 -0700 Message-ID: <1BEBA5E8600DD4119A50009027AF54A009F87A6B@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: "WENDT,JIM (HP-Roseville,ex1)" , ips@ece.cmu.edu Subject: RE: iSCSI: No Framing Date: Sun, 3 Feb 2002 16:01:12 -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 Jim, In answer to your questions: Agilent is planning to implement framing. We view both FIM and COWS as having about the same utility so we would implement whichever one went into the standard. A smoothing buffer on the chip is feasible wrt your point 2. There are some configurations that would use external memory. Also, one concern is that the very situation where one would need large window size for efficiency - high bandwidth long distance communication - is where out of order receipt becomes increasingly likely so the amount of memory for this situation could push up cost to an excessive extent. Reducing the amount of traffic that has to be shunted to an external memory affects the bandwidth that needs to be provided for that memory. If we can handle most PDUs internally then the external memory doesn't have to be as wide and as fast. For instance, if a drop means that the iSCSI PDU with the drop is put into external memory then that takes less memory bandwidth than if a drop means the whole data stream for that session will be going into the buffer until the hole is filled. This decision also effects latency after a drop and required backplane bandwidth. Let's say one is on a 10 Gbit/s extreme long distance WAN connection and that there is a drop. If the round trip delay for getting the whole filled is 100 ms, then without framing, one could have about 1 Gbit stored in the local buffer memory by the time the hole is filled. One will have to process all of this through iSCSI and across the backplane before one can deal with the new traffic coming in. If the backplane data rate is closely sized to the external data rate, an extra 100 ms latency has just been inserted into the path until traffic slacks off. (Congestion control might mitigate this to the extent that one is talking to just one source, but with multiple sessions, one will still have to keep up.) To get the buffer emptied to make space for further drops and to get the latency back down, one will have to size the backplane bandwidth wider and have the iSCSI engine process at a higher data rate. With FIM or COWS, one can end the incident with much less data in the buffer as one processes PDUs after the hole while waiting for it to be filled. Then, when the hole is filled one just has to process a small amount of data to catch up. Regards, Pat Thaler -----Original Message----- From: WENDT,JIM (HP-Roseville,ex1) [mailto:jim_wendt@hp.com] Sent: Tuesday, January 29, 2002 10:47 PM To: ips@ece.cmu.edu Subject: iSCSI: No Framing So, it would be good to hear from several iSCSI NIC/chip implementors who: - have or plan to implement FIM or COWS (or some other framing mechanism) and take advantage of it to minimize demands on on-NIC buffer memory bandwidth/quantity. - believe that all-buffers-on-chip solutions are feasible and valid (wrt the points above, including #2) - can quantify the memory/pin/power/space cost savings for all-buffers-on-chip solutions Jim From owner-ips@ece.cmu.edu Sun Feb 3 21:50: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 VAA03503 for ; Sun, 3 Feb 2002 21:50:09 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g141f9k00375 for ips-outgoing; Sun, 3 Feb 2002 20:41:09 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c003.snv.cp.net (c003-h004.c003.snv.cp.net [209.228.32.218]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g141f7j00371 for ; Sun, 3 Feb 2002 20:41:08 -0500 (EST) Received: (cpmta 17305 invoked from network); 3 Feb 2002 17:41:01 -0800 Received: from 64.130.130.105 (HELO dougrmt) by smtp.telocity.com (209.228.32.218) with SMTP; 3 Feb 2002 17:41:01 -0800 X-Sent: 4 Feb 2002 01:41:01 GMT From: "Douglas Otis" To: Subject: RE: iSCSI: No Framing Date: Sun, 3 Feb 2002 17:42:41 -0800 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.2910.0) Importance: Normal In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A009F87A6B@axcs04.cos.agilent.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat, The macroscopic behavior of the TCP congestion avoidance algorithm by Mathis, Semke, Mahdavi & Ott in Computer Communication Review, July 97, provides a simple formula for an upper bound on the TCP transfer rate: Rate <= (MSS/RTT)*(1/sqrt{p}) A .004% loss rate with 1460 MSS, and 100 ms RTT would be less than 2.3 MB/s or 18 Mb/s. In your senario, there would be a requirement to buffer 230 KB. The system will also see a reduction in send traffic accommodating receiver side recovery following 157 packets after a loss seen about every 25,000 packets. There should be little concern about dealing with a single connection across great distances working at phenomenal data rates unless packet loss becomes diminishingly small. The cost for such a connection will also make related memory concerns diminishingly small as well. Reliability and security should easily override benefits seen by placing the application below TCP as advocated. If you wish to implement framing, then may I suggest such a scheme is possible using SCTP without placing the application beneath the transport. SCTP offers may other benefits needed in any mission critical application. You would save your customer grief by not introducing obsolete equipment as there is already this emerging standard that provides many improvements over such a kludge. Doug > Jim, > > In answer to your questions: > > Agilent is planning to implement framing. We view both FIM and > COWS as having about the same utility so we would implement > whichever one went into the standard. > > A smoothing buffer on the chip is feasible wrt your point 2. > There are some configurations that would use external memory. > > Also, one concern is that the very situation where one would > need large window size for efficiency - high bandwidth long > distance communication - is where out of order receipt becomes > increasingly likely so the amount of memory for this situation > could push up cost to an excessive extent. > > Reducing the amount of traffic that has to be shunted to an > external memory affects the bandwidth that needs to be provided > for that memory. If we can handle most PDUs internally then the > external memory doesn't have to be as wide and as fast. For > instance, if a drop means that the iSCSI PDU with the drop > is put into external memory then that takes less memory bandwidth > than if a drop means the whole data stream for that session will > be going into the buffer until the hole is filled. > > This decision also effects latency after a drop and required > backplane bandwidth. > > Let's say one is on a 10 Gbit/s extreme long distance WAN > connection and that there is a drop. If the round trip delay > for getting the whole filled is 100 ms, then without framing, > one could have about 1 Gbit stored in the local buffer memory > by the time the hole is filled. One will have to process all > of this through iSCSI and across the backplane before one can > deal with the new traffic coming in. If the backplane data rate > is closely sized to the external data rate, an extra 100 ms latency > has just been inserted into the path until traffic slacks off. > (Congestion control might mitigate this to the extent that one > is talking to just one source, but with multiple sessions, one > will still have to keep up.) To get the buffer emptied to make > space for further drops and to get the latency back down, one > will have to size the backplane bandwidth wider and have the > iSCSI engine process at a higher data rate. > > With FIM or COWS, one can end the incident with much less data > in the buffer as one processes PDUs after the hole while waiting > for it to be filled. Then, when the hole is filled one just has > to process a small amount of data to catch up. > > Regards, > Pat Thaler > > -----Original Message----- > From: WENDT,JIM (HP-Roseville,ex1) [mailto:jim_wendt@hp.com] > Sent: Tuesday, January 29, 2002 10:47 PM > To: ips@ece.cmu.edu > Subject: iSCSI: No Framing > > > > So, it would be good to hear from several iSCSI > NIC/chip implementors who: > - have or plan to implement FIM or COWS (or some > other framing mechanism) and take advantage of it to > minimize demands on on-NIC buffer memory > bandwidth/quantity. > - believe that all-buffers-on-chip solutions are > feasible and valid (wrt the points above, including > #2) > - can quantify the memory/pin/power/space cost > savings for all-buffers-on-chip solutions > > Jim > From owner-ips@ece.cmu.edu Sun Feb 3 23:33: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 XAA05574 for ; Sun, 3 Feb 2002 23:33:05 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g143NZc04433 for ips-outgoing; Sun, 3 Feb 2002 22:23:35 -0500 (EST) 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 g143NUj04425; Sun, 3 Feb 2002 22:23:30 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id WAA66472; Sun, 3 Feb 2002 22:20:17 -0500 Received: from d03nm041.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g143NOP136746; Sun, 3 Feb 2002 20:23:24 -0700 Subject: RE: iSCSI: No Framing To: "THALER,PAT (A-Roseville,ex1)" Cc: ips@ece.cmu.edu, "WENDT,JIM (HP-Roseville,ex1)" , owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Prasenjit Sarkar" Date: Sun, 3 Feb 2002 19:22:55 -0800 X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.9 |November 16, 2001) at 02/03/2002 07:23:23 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Pat, I had a few questions about your 10 Gbps example. If we assume that this is a single TCP stream, I would like to know which application in the near and forseeable future can sustain a 10 Gbps data rate for a reasonable amount of time? Or if they are multiple TCP streams, are you assuming packet drops in all streams simultaneously? Thanks, Prasenjit Sarkar Research Staff Member IBM Almaden Research San Jose "THALER,PAT (A-Roseville,ex1) To: "WENDT,JIM (HP-Roseville,ex1)" " , ips@ece.cmu.edu Subject: RE: iSCSI: No Framing Sent by: owner-ips@ece.cmu .edu 02/03/2002 03:01 PM Jim, In answer to your questions: Agilent is planning to implement framing. We view both FIM and COWS as having about the same utility so we would implement whichever one went into the standard. A smoothing buffer on the chip is feasible wrt your point 2. There are some configurations that would use external memory. Also, one concern is that the very situation where one would need large window size for efficiency - high bandwidth long distance communication - is where out of order receipt becomes increasingly likely so the amount of memory for this situation could push up cost to an excessive extent. Reducing the amount of traffic that has to be shunted to an external memory affects the bandwidth that needs to be provided for that memory. If we can handle most PDUs internally then the external memory doesn't have to be as wide and as fast. For instance, if a drop means that the iSCSI PDU with the drop is put into external memory then that takes less memory bandwidth than if a drop means the whole data stream for that session will be going into the buffer until the hole is filled. This decision also effects latency after a drop and required backplane bandwidth. Let's say one is on a 10 Gbit/s extreme long distance WAN connection and that there is a drop. If the round trip delay for getting the whole filled is 100 ms, then without framing, one could have about 1 Gbit stored in the local buffer memory by the time the hole is filled. One will have to process all of this through iSCSI and across the backplane before one can deal with the new traffic coming in. If the backplane data rate is closely sized to the external data rate, an extra 100 ms latency has just been inserted into the path until traffic slacks off. (Congestion control might mitigate this to the extent that one is talking to just one source, but with multiple sessions, one will still have to keep up.) To get the buffer emptied to make space for further drops and to get the latency back down, one will have to size the backplane bandwidth wider and have the iSCSI engine process at a higher data rate. With FIM or COWS, one can end the incident with much less data in the buffer as one processes PDUs after the hole while waiting for it to be filled. Then, when the hole is filled one just has to process a small amount of data to catch up. Regards, Pat Thaler -----Original Message----- From: WENDT,JIM (HP-Roseville,ex1) [mailto:jim_wendt@hp.com] Sent: Tuesday, January 29, 2002 10:47 PM To: ips@ece.cmu.edu Subject: iSCSI: No Framing So, it would be good to hear from several iSCSI NIC/chip implementors who: - have or plan to implement FIM or COWS (or some other framing mechanism) and take advantage of it to minimize demands on on-NIC buffer memory bandwidth/quantity. - believe that all-buffers-on-chip solutions are feasible and valid (wrt the points above, including #2) - can quantify the memory/pin/power/space cost savings for all-buffers-on-chip solutions Jim From owner-ips@ece.cmu.edu Mon Feb 4 10:50: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 KAA26318 for ; Mon, 4 Feb 2002 10:50:05 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g14ETet10772 for ips-outgoing; Mon, 4 Feb 2002 09:29:40 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from packer.xiotech.com (mail.xiotech.com [209.46.118.18]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g14ETbj10766; Mon, 4 Feb 2002 09:29:37 -0500 (EST) Message-ID: From: "Peglar, Robert" To: "'Prasenjit Sarkar'" , "THALER,PAT (A-Roseville,ex1)" Cc: ips@ece.cmu.edu, "WENDT,JIM (HP-Roseville,ex1)" , owner-ips@ece.cmu.edu Subject: RE: iSCSI: No Framing Date: Mon, 4 Feb 2002 08:29:32 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk De-lurking... Right now, I'd say disk-disk backup/restore and mirroring. The individual disk devices of today can perform at ~70 MB/s. One need only gang 14 of these together, streaming, to reach nearly 1000 MB/s, or 1 GB/s, or 8 Gb/s. The disk devices of tomorrow are going to perform at rates approaching 100 MB/s per spindle. Only ten devices are then necessary. This would be a single TCP stream (one initiator, one target, many LUs). If one has to mirror (/move) 10 TB in a reasonable amount of time, say, then a stream of 1 GB/s is not only necessary, but paramount. Even at that rate, it would still take nearly three hours to move just 10 TB. In a business-critical recovery situation, three hours is an eon. Don't think application (CPU/memory in a server) to storage. Think storage to storage. Rob Rob Peglar Corporate Architect XIOtech Corporation, a Seagate Company (314) 308-6983 >-----Original Message----- >From: Prasenjit Sarkar [mailto:psarkar@almaden.ibm.com] >Sent: Sunday, February 03, 2002 9:23 PM >To: THALER,PAT (A-Roseville,ex1) >Cc: ips@ece.cmu.edu; WENDT,JIM (HP-Roseville,ex1); >owner-ips@ece.cmu.edu >Subject: RE: iSCSI: No Framing > > > >Hi Pat, > >I had a few questions about your 10 Gbps example. If we assume >that this is >a single TCP stream, I would like to know which application in >the near and >forseeable future can sustain a 10 Gbps data rate for a >reasonable amount >of time? Or if they are multiple TCP streams, are you assuming >packet drops >in all streams simultaneously? > >Thanks, > > > Prasenjit Sarkar > Research Staff Member > IBM Almaden Research > San Jose > > > > > > "THALER,PAT > > (A-Roseville,ex1) To: >"WENDT,JIM (HP-Roseville,ex1)" > " >, ips@ece.cmu.edu > > nt.com> Subject: RE: >iSCSI: No Framing > Sent by: > > owner-ips@ece.cmu > > .edu > > > > > > 02/03/2002 03:01 > > PM > > > > > > > > >Jim, > >In answer to your questions: > >Agilent is planning to implement framing. We view both FIM and >COWS as having about the same utility so we would implement >whichever one went into the standard. > >A smoothing buffer on the chip is feasible wrt your point 2. >There are some configurations that would use external memory. > >Also, one concern is that the very situation where one would >need large window size for efficiency - high bandwidth long >distance communication - is where out of order receipt becomes >increasingly likely so the amount of memory for this situation >could push up cost to an excessive extent. > >Reducing the amount of traffic that has to be shunted to an >external memory affects the bandwidth that needs to be provided >for that memory. If we can handle most PDUs internally then the >external memory doesn't have to be as wide and as fast. For >instance, if a drop means that the iSCSI PDU with the drop >is put into external memory then that takes less memory bandwidth >than if a drop means the whole data stream for that session will >be going into the buffer until the hole is filled. > >This decision also effects latency after a drop and required >backplane bandwidth. > >Let's say one is on a 10 Gbit/s extreme long distance WAN >connection and that there is a drop. If the round trip delay >for getting the whole filled is 100 ms, then without framing, >one could have about 1 Gbit stored in the local buffer memory >by the time the hole is filled. One will have to process all >of this through iSCSI and across the backplane before one can >deal with the new traffic coming in. If the backplane data rate >is closely sized to the external data rate, an extra 100 ms latency >has just been inserted into the path until traffic slacks off. >(Congestion control might mitigate this to the extent that one >is talking to just one source, but with multiple sessions, one >will still have to keep up.) To get the buffer emptied to make >space for further drops and to get the latency back down, one >will have to size the backplane bandwidth wider and have the >iSCSI engine process at a higher data rate. > >With FIM or COWS, one can end the incident with much less data >in the buffer as one processes PDUs after the hole while waiting >for it to be filled. Then, when the hole is filled one just has >to process a small amount of data to catch up. > >Regards, >Pat Thaler > >-----Original Message----- >From: WENDT,JIM (HP-Roseville,ex1) [mailto:jim_wendt@hp.com] >Sent: Tuesday, January 29, 2002 10:47 PM >To: ips@ece.cmu.edu >Subject: iSCSI: No Framing > > > >So, it would be good to hear from several iSCSI >NIC/chip implementors who: >- have or plan to implement FIM or COWS (or some >other framing mechanism) and take advantage of it to >minimize demands on on-NIC buffer memory >bandwidth/quantity. >- believe that all-buffers-on-chip solutions are >feasible and valid (wrt the points above, including >#2) >- can quantify the memory/pin/power/space cost >savings for all-buffers-on-chip solutions > >Jim > > > > From owner-ips@ece.cmu.edu Mon Feb 4 12:02: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 MAA29287 for ; Mon, 4 Feb 2002 12:02:15 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g14FgJ415272 for ips-outgoing; Mon, 4 Feb 2002 10:42:19 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from duteinh.et.tudelft.nl (root@duteinh.et.tudelft.nl [130.161.42.1]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g12DXRj00643 for ; Sat, 2 Feb 2002 08:33:27 -0500 (EST) Received: from arthur.home (erik.et.tudelft.nl [130.161.48.56]) by duteinh.et.tudelft.nl (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id OAA24924; Sat, 2 Feb 2002 14:33:23 +0100 X-Authentication-Warning: duteinh.et.tudelft.nl: Host erik.et.tudelft.nl [130.161.48.56] claimed to be arthur.home Received: from arthur.home (erik@localhost [127.0.0.1]) by arthur.home (8.12.1/8.12.1/Debian -5) with ESMTP id g12DXM7s003697; Sat, 2 Feb 2002 14:33:22 +0100 Received: (from erik@localhost) by arthur.home (8.12.1/8.12.1/Debian -5) id g12DXLxC003694; Sat, 2 Feb 2002 14:33:21 +0100 Date: Sat, 2 Feb 2002 14:33:21 +0100 From: Erik Mouw To: Sarah Wright Cc: ips@ece.cmu.edu, kernelnewbies@nl.linux.org Subject: Re: SNMP usage Message-ID: <20020202133321.GE2363@arthur.ubicom.tudelft.nl> References: <20020202122650.11393.qmail@web14006.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020202122650.11393.qmail@web14006.mail.yahoo.com> User-Agent: Mutt/1.3.25i Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy! Sender: owner-ips@ece.cmu.edu Precedence: bulk On Sat, Feb 02, 2002 at 04:26:50AM -0800, Sarah Wright wrote: > I need to download a new firmware on to the hardware > from a remote location. The device only supports SNMP > at the moment. Is it necessary to add the FTP feature > on to it. The usual way to download new firmware is TFTP: it's a simple protocol and the implemention can be made very small. > If this is not the right place to ask, Can someone > please point me out the right place. I think linux-embedded@waste.org is the correct list for this. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: J.A.K.Mouw@its.tudelft.nl WWW: http://www-ict.its.tudelft.nl/~erik/ From owner-ips@ece.cmu.edu Mon Feb 4 13:16: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 NAA01940 for ; Mon, 4 Feb 2002 13:16:34 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g14Gab619635 for ips-outgoing; Mon, 4 Feb 2002 11:36:37 -0500 (EST) 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 g14GaXj19626 for ; Mon, 4 Feb 2002 11:36:34 -0500 (EST) Received: from london ([10.95.10.3]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id IAA29100; Mon, 4 Feb 2002 08:34:52 -0800 (PST) From: "Rod Harrison" To: "THALER,PAT (A-Roseville,ex1)" , "WENDT,JIM (HP-Roseville,ex1)" , Subject: RE: iSCSI: No Framing Date: Mon, 4 Feb 2002 16:35:46 -0000 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 In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A009F87A6B@axcs04.cos.agilent.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Framing of any kind is not a panacea allowing for almost buffering free target implementations, it can only move the buffering from the transport layer up to the iSCSI layer. Remember that the target MUST guarantee commands are delivered to SCSI in the command sequence number order. This means if a dropped packet contains an iSCSI command PDU you are going to have to buffer until the CmdSN hole is plugged. Consider the example of an initiator filling the command window, perhaps sending CmdSNs 1 through 100, possibly along with immediate or unsolicited data for some of the commands. If the packet dropped contained the command PDU for CmdSN 50 then the target iSCSI layer must buffer CmdSNs 51 through 100 and their associated DATA_OUT PDUs. Since you can continue to process any DATA_OUT PDUs for CmdSNs 1 through 49 the buffering required is reduced, but not eliminated, Only if the packet dropped contains DATA_OUTs and no command PDUs can you continue processing past the hole while waiting for it to be filled. You can R2T for data associated with commands after the hole but that serves only to potentially decrease recovery time, not reduce buffer requirements. Don't get me wrong, I'm not saying framing isn't a good thing but it is only one piece of the puzzle. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of THALER,PAT (A-Roseville,ex1) Sent: Sunday, February 03, 2002 11:01 PM To: WENDT,JIM (HP-Roseville,ex1); ips@ece.cmu.edu Subject: RE: iSCSI: No Framing Jim, In answer to your questions: Agilent is planning to implement framing. We view both FIM and COWS as having about the same utility so we would implement whichever one went into the standard. A smoothing buffer on the chip is feasible wrt your point 2. There are some configurations that would use external memory. Also, one concern is that the very situation where one would need large window size for efficiency - high bandwidth long distance communication - is where out of order receipt becomes increasingly likely so the amount of memory for this situation could push up cost to an excessive extent. Reducing the amount of traffic that has to be shunted to an external memory affects the bandwidth that needs to be provided for that memory. If we can handle most PDUs internally then the external memory doesn't have to be as wide and as fast. For instance, if a drop means that the iSCSI PDU with the drop is put into external memory then that takes less memory bandwidth than if a drop means the whole data stream for that session will be going into the buffer until the hole is filled. This decision also effects latency after a drop and required backplane bandwidth. Let's say one is on a 10 Gbit/s extreme long distance WAN connection and that there is a drop. If the round trip delay for getting the whole filled is 100 ms, then without framing, one could have about 1 Gbit stored in the local buffer memory by the time the hole is filled. One will have to process all of this through iSCSI and across the backplane before one can deal with the new traffic coming in. If the backplane data rate is closely sized to the external data rate, an extra 100 ms latency has just been inserted into the path until traffic slacks off. (Congestion control might mitigate this to the extent that one is talking to just one source, but with multiple sessions, one will still have to keep up.) To get the buffer emptied to make space for further drops and to get the latency back down, one will have to size the backplane bandwidth wider and have the iSCSI engine process at a higher data rate. With FIM or COWS, one can end the incident with much less data in the buffer as one processes PDUs after the hole while waiting for it to be filled. Then, when the hole is filled one just has to process a small amount of data to catch up. Regards, Pat Thaler -----Original Message----- From: WENDT,JIM (HP-Roseville,ex1) [mailto:jim_wendt@hp.com] Sent: Tuesday, January 29, 2002 10:47 PM To: ips@ece.cmu.edu Subject: iSCSI: No Framing So, it would be good to hear from several iSCSI NIC/chip implementors who: - have or plan to implement FIM or COWS (or some other framing mechanism) and take advantage of it to minimize demands on on-NIC buffer memory bandwidth/quantity. - believe that all-buffers-on-chip solutions are feasible and valid (wrt the points above, including #2) - can quantify the memory/pin/power/space cost savings for all-buffers-on-chip solutions Jim From owner-ips@ece.cmu.edu Mon Feb 4 13:48: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 NAA02706 for ; Mon, 4 Feb 2002 13:48:38 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g14HZZl24377 for ips-outgoing; Mon, 4 Feb 2002 12:35:35 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c003.snv.cp.net (c003-h016.c003.snv.cp.net [209.228.32.230]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g14HZXj24373 for ; Mon, 4 Feb 2002 12:35:33 -0500 (EST) Received: (cpmta 579 invoked from network); 4 Feb 2002 09:35:26 -0800 Received: from 64.130.130.105 (HELO dougrmt) by smtp.telocity.com (209.228.32.230) with SMTP; 4 Feb 2002 09:35:26 -0800 X-Sent: 4 Feb 2002 17:35:26 GMT From: "Douglas Otis" To: Subject: RE: iSCSI: No Framing Date: Mon, 4 Feb 2002 09:37:09 -0800 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Rob, Although it will be true large amounts of bandwidth will be exchanged between the typical SAN, such systems also use cache due to mechanical limitations with respect to rotation and linear access. If it were just storage to storage, Fibre-Channel or FC encapsulation would be preferable. At least with that scheme, there are direct placement interfaces available. Direct placement is needed with low latency high bandwidth to reduce overhead lost during a subsequent memory copy. SCTP offers a means of implementing direct placement without kludging a portion of the application beneath the transport. In addition, this direct placement scheme can be done in an general fashion to support thousands of higher level protocols. As with most SAN, network related failures are not well tolerated, so the added robustness of SCTP becomes highly beneficial. In establishing a large remote mirror, the highest bandwidth means of initialization would be physical transport of the image. Once initialized, only differential information is exchanged largely limited by the bandwidth and error rate of the interconnect. Doug > De-lurking... > > Right now, I'd say disk-disk backup/restore and mirroring. The individual > disk devices of today can perform at ~70 MB/s. One need only gang 14 of > these together, streaming, to reach nearly 1000 MB/s, or 1 GB/s, > or 8 Gb/s. > The disk devices of tomorrow are going to perform at rates approaching 100 > MB/s per spindle. Only ten devices are then necessary. > > This would be a single TCP stream (one initiator, one target, many LUs). > > If one has to mirror (/move) 10 TB in a reasonable amount of > time, say, then > a stream of 1 GB/s is not only necessary, but paramount. Even at > that rate, > it would still take nearly three hours to move just 10 TB. In a > business-critical recovery situation, three hours is an eon. > > Don't think application (CPU/memory in a server) to storage. > Think storage > to storage. > > Rob > > Rob Peglar > Corporate Architect > XIOtech Corporation, a Seagate Company > (314) 308-6983 From owner-ips@ece.cmu.edu Mon Feb 4 15:10: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 PAA04785 for ; Mon, 4 Feb 2002 15:10:13 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g14J3At01691 for ips-outgoing; Mon, 4 Feb 2002 14:03:10 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g14J39j01687 for ; Mon, 4 Feb 2002 14:03:09 -0500 (EST) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Feb 2002 14:05:45 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937411@CORPMX14> From: Black_David@emc.com To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI ACA requirement Date: Mon, 4 Feb 2002 13:49:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1ADAC.A3726D50" 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_01C1ADAC.A3726D50 Content-Type: text/plain; charset="iso-8859-1" I thought the outcome of the previous lengthy discussion on ACA was to make it a SHOULD. That is also the right requirement level for Julian's concern that failure to use ACA may have performance consequences. I agree with Dave Peterson that requiring ACA behavior from devices that have no intention of supporting it other than a possible need for compliance with the iSCSI spec is pointless. Let's make ACA a SHOULD. 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: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, February 02, 2002 2:22 AM To: ips@ece.cmu.edu Subject: Re: iSCSI ACA requirement Dave, In fact we could make it SHOULD as ACA support is not anymore critical provided that the right exception mechanism for busy etc. is in place and it is now and does not use ACA(!). However the effect on performance could be more taxing than in the case of FCP - the network diameter supported is far larger and the need to support commands in fly is more important than in the case of FCP. Julo "Dave Peterson" Sent by: owner-ips@ece.cmu.edu 02-02-02 00:17 To: "Ips@Ece. Cmu. Edu" cc: Subject: iSCSI ACA requirement I'm having heartburn with the statement in iSCSI rev 10 clause 9.2: "As iSCSI can have many commands in-flight between initiator and target, iSCSI mandates support for ACA." My understanding of the above statement is that iSCSI target must indicate support for NACA=1. Requiring ACA is problematic and normally not necessary for implementations for a variety of reasons. Examples: a. A small number of devices actually support NACA=1. b. In practice FC applications do not require command ordering (i.e., use of the Simple Queue Tag). If ordering is a consideration the application will issue the command and wait for the response. c. The FC/FCP standards do not require NACA=1. d. Complicates bridging implementations - bridge must proxy NACA=1 for a device that does not support NACA=1 - bridge must maintain NACA behavior when the end device does not support NACA=1 I do understand the benefits to requiring NACA=1 especially when command ordering and stateful operations are desired, but its not realistic at this time, IMHO. As such this use of ACA should be a SHOULD, not a must or mandate. Dave ------_=_NextPart_001_01C1ADAC.A3726D50 Content-Type: text/html; charset="iso-8859-1"
I thought the outcome of the previous lengthy discussion on
ACA was to make it a SHOULD.  That is also the right requirement
level for Julian's concern that failure to use ACA may have
performance consequences.  I agree with Dave Peterson that
requiring ACA behavior from devices that have no intention
of supporting it other than a possible need for compliance
with the iSCSI spec is pointless.  Let's make ACA a SHOULD.
 
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: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, February 02, 2002 2:22 AM
To: ips@ece.cmu.edu
Subject: Re: iSCSI ACA requirement


Dave,

In fact we could make it SHOULD as ACA support is not anymore critical provided that the right exception mechanism for busy etc. is in place and it is now and does not use ACA(!).  However the effect on performance could be more taxing than in the case of FCP - the network diameter supported is far larger and the need to support commands in fly is more important than in the case of FCP.

Julo




"Dave Peterson" <dap@cisco.com>
Sent by: owner-ips@ece.cmu.edu

02-02-02 00:17

       
        To:        "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
        cc:        
        Subject:        iSCSI ACA requirement

       


I'm having heartburn with the statement in iSCSI rev 10 clause 9.2:
"As iSCSI can have many commands in-flight between initiator and target,
iSCSI mandates support for ACA."

My understanding of the above statement is that iSCSI target must indicate
support for NACA=1.

Requiring ACA is problematic and normally not necessary for implementations
for a variety of reasons.
Examples:
a. A small number of devices actually support NACA=1.
b. In practice FC applications do not require command ordering (i.e., use of
the Simple Queue Tag). If ordering is a consideration the application will
issue the command and wait for the response.
c. The FC/FCP standards do not require NACA=1.
d. Complicates bridging implementations
                - bridge must proxy NACA=1 for a device that does not support NACA=1
                - bridge must maintain NACA behavior when the end device does not support
NACA=1

I do understand the benefits to requiring NACA=1 especially when command
ordering and stateful operations are desired, but its not realistic at this
time, IMHO.
As such this use of ACA should be a SHOULD, not a must or mandate.

Dave



------_=_NextPart_001_01C1ADAC.A3726D50-- From owner-ips@ece.cmu.edu Mon Feb 4 15:12: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 PAA04813 for ; Mon, 4 Feb 2002 15:12:17 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g14JM2003238 for ips-outgoing; Mon, 4 Feb 2002 14:22:02 -0500 (EST) 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 g14JM1j03233 for ; Mon, 4 Feb 2002 14:22:01 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id <1B5Z9JVS>; Mon, 4 Feb 2002 14:21:54 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937412@CORPMX14> From: Black_David@emc.com To: marjorie_krueger@hp.com Cc: ips@ece.cmu.edu Subject: RE: IPsec Usage Question Date: Mon, 4 Feb 2002 14:08:01 -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 > I agree with Paul, the association of *any* internal network address > to any external mapping is an IPSec configuration concern! On the one hand, I like this, because it's the simplest way to close this issue, and I have a strong preference for simple approaches that allow us to declare victory sooner. OTOH, I want to make sure that people understand what the issue is: AFAIK, IPsec has no standard or widely deployed mechanism for handling gateway discovery or address association dynamically. This has concrete consequences. Suppose that: - An IPsec implementation operating only in tunnel mode and requiring different inner and outer IP addresses is used to provide the IPsec security required by an IP Storage protocol. AND - A dynamic discovery mechanism (e.g., Send Targets, SLP, and iSNS) is used to discover IP Storage peers. Then the dynamic discovery mechanism only discovers the IP address of the IP Storage peer, and does not provide information about the IP address of the security gateway that must be contacted in order to talk to that peer. The current state of the art is to statically pre-configure the gateway address information (i.e., every peer that wants to communicate with a specific implementation will have to know that implementation's security gateway IP address in advance, even though the IP Storage IP address can be discovered dynamically). This approach works, but it makes dynamic discovery much more difficult to use with security gateways. To the extent that this biases IP storage against the use of security gateways, it will make my life easier in dealing with the folks who want to make absolutely sure that IP Storage uses end-to-end security, but I wanted to make sure that the practical configuration consequences of this approach were understood. 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 Feb 4 15:14: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 PAA04848 for ; Mon, 4 Feb 2002 15:14:38 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g14J2Mq01608 for ips-outgoing; Mon, 4 Feb 2002 14:02:22 -0500 (EST) 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 g14J2Ij01601 for ; Mon, 4 Feb 2002 14:02:19 -0500 (EST) Received: by med.corp.rhapsodynetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Feb 2002 11:02:06 -0800 Message-ID: <45BEF1D68145D51186C100B0D0AABE6506D178@med.corp.rhapsodynetworks.com> From: Dennis Young To: "'Rod Harrison'" , "THALER,PAT (A-Roseville,ex1)" , "WENDT,JIM (HP-Roseville,ex1)" , ips@ece.cmu.edu Subject: RE: iSCSI: No Framing Date: Mon, 4 Feb 2002 11:02:05 -0800 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 Rod, Your are correct for the situation where there is only one iSCSI session. One of the benefits of framing is that when there are multiple sessions, a hole in one session won't hold up the other sessions. Dennis >-----Original Message----- >From: Rod Harrison [mailto:rod.harrison@windriver.com] >Sent: Monday, February 04, 2002 8:36 AM >To: THALER,PAT (A-Roseville,ex1); WENDT,JIM (HP-Roseville,ex1); >ips@ece.cmu.edu >Subject: RE: iSCSI: No Framing > > > > Framing of any kind is not a panacea allowing for >almost buffering >free target implementations, it can only move the buffering from the >transport layer up to the iSCSI layer. Remember that the target MUST >guarantee commands are delivered to SCSI in the command sequence >number order. This means if a dropped packet contains an iSCSI command >PDU you are going to have to buffer until the CmdSN hole is plugged. > > Consider the example of an initiator filling the command window, >perhaps sending CmdSNs 1 through 100, possibly along with immediate or >unsolicited data for some of the commands. If the packet dropped >contained the command PDU for CmdSN 50 then the target iSCSI layer >must buffer CmdSNs 51 through 100 and their associated DATA_OUT PDUs. >Since you can continue to process any DATA_OUT PDUs for CmdSNs 1 >through 49 the buffering required is reduced, but not eliminated, > > Only if the packet dropped contains DATA_OUTs and no >command PDUs can >you continue processing past the hole while waiting for it to be >filled. You can R2T for data associated with commands after the hole >but that serves only to potentially decrease recovery time, not reduce >buffer requirements. > > Don't get me wrong, I'm not saying framing isn't a good >thing but it >is only one piece of the puzzle. > > - Rod > >-----Original Message----- >From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of >THALER,PAT (A-Roseville,ex1) >Sent: Sunday, February 03, 2002 11:01 PM >To: WENDT,JIM (HP-Roseville,ex1); ips@ece.cmu.edu >Subject: RE: iSCSI: No Framing > > >Jim, > >In answer to your questions: > >Agilent is planning to implement framing. We view both FIM and >COWS as having about the same utility so we would implement >whichever one went into the standard. > >A smoothing buffer on the chip is feasible wrt your point 2. >There are some configurations that would use external memory. > >Also, one concern is that the very situation where one would >need large window size for efficiency - high bandwidth long >distance communication - is where out of order receipt becomes >increasingly likely so the amount of memory for this situation >could push up cost to an excessive extent. > >Reducing the amount of traffic that has to be shunted to an >external memory affects the bandwidth that needs to be provided >for that memory. If we can handle most PDUs internally then the >external memory doesn't have to be as wide and as fast. For >instance, if a drop means that the iSCSI PDU with the drop >is put into external memory then that takes less memory bandwidth >than if a drop means the whole data stream for that session will >be going into the buffer until the hole is filled. > >This decision also effects latency after a drop and required >backplane bandwidth. > >Let's say one is on a 10 Gbit/s extreme long distance WAN >connection and that there is a drop. If the round trip delay >for getting the whole filled is 100 ms, then without framing, >one could have about 1 Gbit stored in the local buffer memory >by the time the hole is filled. One will have to process all >of this through iSCSI and across the backplane before one can >deal with the new traffic coming in. If the backplane data rate >is closely sized to the external data rate, an extra 100 ms latency >has just been inserted into the path until traffic slacks off. >(Congestion control might mitigate this to the extent that one >is talking to just one source, but with multiple sessions, one >will still have to keep up.) To get the buffer emptied to make >space for further drops and to get the latency back down, one >will have to size the backplane bandwidth wider and have the >iSCSI engine process at a higher data rate. > >With FIM or COWS, one can end the incident with much less data >in the buffer as one processes PDUs after the hole while waiting >for it to be filled. Then, when the hole is filled one just has >to process a small amount of data to catch up. > >Regards, >Pat Thaler > >-----Original Message----- >From: WENDT,JIM (HP-Roseville,ex1) [mailto:jim_wendt@hp.com] >Sent: Tuesday, January 29, 2002 10:47 PM >To: ips@ece.cmu.edu >Subject: iSCSI: No Framing > > > >So, it would be good to hear from several iSCSI >NIC/chip implementors who: >- have or plan to implement FIM or COWS (or some >other framing mechanism) and take advantage of it to >minimize demands on on-NIC buffer memory >bandwidth/quantity. >- believe that all-buffers-on-chip solutions are >feasible and valid (wrt the points above, including >#2) >- can quantify the memory/pin/power/space cost >savings for all-buffers-on-chip solutions > >Jim > From owner-ips@ece.cmu.edu Mon Feb 4 15:21: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 PAA05006 for ; Mon, 4 Feb 2002 15:21:04 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g14JVrf04131 for ips-outgoing; Mon, 4 Feb 2002 14:31:53 -0500 (EST) 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 SMTP id g14JVpj04123 for ; Mon, 4 Feb 2002 14:31:51 -0500 (EST) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Mon Feb 4 14:30:06 EST 2002 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 g14JTjc03770; Mon, 4 Feb 2002 14:29:46 -0500 (EST) Received: (from jkf@localhost) by zydeco.research.bell-labs.com (8.9.1/8.9.1) id OAA16852; Mon, 4 Feb 2002 14:29:45 -0500 (EST) Date: Mon, 4 Feb 2002 14:29:45 -0500 (EST) From: Jeff Fellin Message-Id: <200202041929.OAA16852@zydeco.research.bell-labs.com> To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu, Black_David@emc.com Subject: RE: iSCSI ACA requirement X-Sun-Charset: US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk I don't understand all the concern about the ACA being a MUST, because this is only in the iSCSI PDU's and not in the SCSI INQUIRY DATA. The iSCSI target can emulate the local device supporting ACA. This is easily done by checking the status code on the returned command (something that must alreadly be done), and if it indicates a SCSI error issuing a SCSI REQUEST SENSE command. When the response for the SCSI REQUEST SENSE is returned, the target iSCSI implementation returns all the information in the iSCSI SCSI CMD Response message. This eliminates another round trip to retrieve the information. On the iSCSI initiator side the local SCSI layer receives the Check condition with valid request and sense data without the need of issuing the REQUEST SENSE with the round trip delay. Jeff Fellin > From owner-ips@ece.cmu.edu Mon Feb 4 14:09 EST 2002 > X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f > From: Black_David@emc.com > To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu > Subject: RE: iSCSI ACA requirement > Date: Mon, 4 Feb 2002 13:49:13 -0500 > Sender: owner-ips@ece.cmu.edu > Precedence: bulk > Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1ADAC.A3726D50" > Content-Length: 8875 > X-Lines: 195 > > I thought the outcome of the previous lengthy discussion on > ACA was to make it a SHOULD. That is also the right requirement > level for Julian's concern that failure to use ACA may have > performance consequences. I agree with Dave Peterson that > requiring ACA behavior from devices that have no intention > of supporting it other than a possible need for compliance > with the iSCSI spec is pointless. Let's make ACA a SHOULD. > > 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: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Saturday, February 02, 2002 2:22 AM > To: ips@ece.cmu.edu > Subject: Re: iSCSI ACA requirement > > > > Dave, > > In fact we could make it SHOULD as ACA support is not anymore critical > provided that the right exception mechanism for busy etc. is in place and it > is now and does not use ACA(!). However the effect on performance could be > more taxing than in the case of FCP - the network diameter supported is far > larger and the need to support commands in fly is more important than in the > case of FCP. > > Julo > > > > > > "Dave Peterson" > Sent by: owner-ips@ece.cmu.edu > > > 02-02-02 00:17 > > > > To: "Ips@Ece. Cmu. Edu" > cc: > Subject: iSCSI ACA requirement > > > > > I'm having heartburn with the statement in iSCSI rev 10 clause 9.2: > "As iSCSI can have many commands in-flight between initiator and target, > iSCSI mandates support for ACA." > > My understanding of the above statement is that iSCSI target must indicate > support for NACA=1. > > Requiring ACA is problematic and normally not necessary for implementations > for a variety of reasons. > Examples: > a. A small number of devices actually support NACA=1. > b. In practice FC applications do not require command ordering (i.e., use of > the Simple Queue Tag). If ordering is a consideration the application will > issue the command and wait for the response. > c. The FC/FCP standards do not require NACA=1. > d. Complicates bridging implementations > - bridge must proxy NACA=1 for a device that does not > support NACA=1 > - bridge must maintain NACA behavior when the end device > does not support > NACA=1 > > I do understand the benefits to requiring NACA=1 especially when command > ordering and stateful operations are desired, but its not realistic at this > time, IMHO. > As such this use of ACA should be a SHOULD, not a must or mandate. > > Dave > > > > > From owner-ips@ece.cmu.edu Mon Feb 4 16:03: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 QAA05932 for ; Mon, 4 Feb 2002 16:03:33 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g14JkK805354 for ips-outgoing; Mon, 4 Feb 2002 14:46:20 -0500 (EST) 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 g14JkIj05348 for ; Mon, 4 Feb 2002 14:46:18 -0500 (EST) Received: from cceexg13.americas.cpqcorp.net (cceexg13.americas.cpqcorp.net [16.110.250.119]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id CBB3839D3 for ; Mon, 4 Feb 2002 13:46:12 -0600 (CST) Received: from cceexc17.americas.cpqcorp.net ([16.110.250.84]) by cceexg13.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 4 Feb 2002 13:46:12 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: iSCSI ACA requirement Date: Mon, 4 Feb 2002 13:46:12 -0600 Message-ID: <78AF3C342AEAEF4BA33B35A8A15668C60296DA73@cceexc17.americas.cpqcorp.net> Thread-Topic: iSCSI ACA requirement Thread-Index: AcGtst8SzjxKaSdiTymA6PvmLngcgAAAOTvw From: "Elliott, Robert" To: X-OriginalArrivalTime: 04 Feb 2002 19:46:12.0538 (UTC) FILETIME=[999371A0:01C1ADB4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g14JkJj05350 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit You're confusing autosense with ACA. Refer to Ralph Weber's article on them excerpted from the ENDL letter: http://www.pdl.cmu.edu/mailinglists/ips/mail/msg03427.html Short summaries: autosense = returning sense data with the response PDU (rather than requiring REQUEST SENSE) ACA = special state the logical unit enters after returning a CHECK CONDITION (and autosense data) It would be a huge burden to have an iSCSI target layer try to implement ACA on behalf of a SCSI logical unit layer which does not do so. --- Rob Elliott, Compaq Server Storage Robert.Elliott@compaq.com > -----Original Message----- > From: Jeff Fellin [mailto:jkf@research.bell-labs.com] > Sent: Monday, February 04, 2002 1:30 PM > To: Julian_Satran@il.ibm.com; ips@ece.cmu.edu; Black_David@emc.com > Subject: RE: iSCSI ACA requirement > > > I don't understand all the concern about the ACA being a MUST, because > this is only in the iSCSI PDU's and not in the SCSI INQUIRY DATA. The > iSCSI target can emulate the local device supporting ACA. > This is easily > done by checking the status code on the returned command > (something that > must alreadly be done), and if it indicates a SCSI error issuing a > SCSI REQUEST SENSE command. When the response for the SCSI > REQUEST SENSE > is returned, the target iSCSI implementation returns all the > information > in the iSCSI SCSI CMD Response message. This eliminates > another round trip > to retrieve the information. On the iSCSI initiator side the > local SCSI > layer receives the Check condition with valid request and > sense data without > the need of issuing the REQUEST SENSE with the round trip delay. > > Jeff Fellin > > > From owner-ips@ece.cmu.edu Mon Feb 4 14:09 EST 2002 > > X-Authentication-Warning: ece.cmu.edu: majordom set sender > to owner-ips@ece.cmu.edu using -f > > From: Black_David@emc.com > > To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu > > Subject: RE: iSCSI ACA requirement > > Date: Mon, 4 Feb 2002 13:49:13 -0500 > > Sender: owner-ips@ece.cmu.edu > > Precedence: bulk > > Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C1ADAC.A3726D50" > > Content-Length: 8875 > > X-Lines: 195 > > > > I thought the outcome of the previous lengthy discussion on > > ACA was to make it a SHOULD. That is also the right requirement > > level for Julian's concern that failure to use ACA may have > > performance consequences. I agree with Dave Peterson that > > requiring ACA behavior from devices that have no intention > > of supporting it other than a possible need for compliance > > with the iSCSI spec is pointless. Let's make ACA a SHOULD. > > > > 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: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Saturday, February 02, 2002 2:22 AM > > To: ips@ece.cmu.edu > > Subject: Re: iSCSI ACA requirement > > > > > > > > Dave, > > > > In fact we could make it SHOULD as ACA support is not > anymore critical > > provided that the right exception mechanism for busy etc. > is in place and it > > is now and does not use ACA(!). However the effect on > performance could be > > more taxing than in the case of FCP - the network diameter > supported is far > > larger and the need to support commands in fly is more > important than in the > > case of FCP. > > > > Julo > > > > > > > > > > > > "Dave Peterson" > > Sent by: owner-ips@ece.cmu.edu > > > > > > 02-02-02 00:17 > > > > > > > > To: "Ips@Ece. Cmu. Edu" > > cc: > > Subject: iSCSI ACA requirement > > > > > > > > > > I'm having heartburn with the statement in iSCSI rev 10 clause 9.2: > > "As iSCSI can have many commands in-flight between > initiator and target, > > iSCSI mandates support for ACA." > > > > My understanding of the above statement is that iSCSI > target must indicate > > support for NACA=1. > > > > Requiring ACA is problematic and normally not necessary for > implementations > > for a variety of reasons. > > Examples: > > a. A small number of devices actually support NACA=1. > > b. In practice FC applications do not require command > ordering (i.e., use of > > the Simple Queue Tag). If ordering is a consideration the > application will > > issue the command and wait for the response. > > c. The FC/FCP standards do not require NACA=1. > > d. Complicates bridging implementations > > - bridge must proxy NACA=1 for a device > that does not > > support NACA=1 > > - bridge must maintain NACA behavior when > the end device > > does not support > > NACA=1 > > > > I do understand the benefits to requiring NACA=1 especially > when command > > ordering and stateful operations are desired, but its not > realistic at this > > time, IMHO. > > As such this use of ACA should be a SHOULD, not a must or mandate. > > > > Dave > > > > > > > > > > > From owner-ips@ece.cmu.edu Mon Feb 4 16:04: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 QAA05947 for ; Mon, 4 Feb 2002 16:04:12 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g14JecX04899 for ips-outgoing; Mon, 4 Feb 2002 14:40:38 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g14Jebj04893 for ; Mon, 4 Feb 2002 14:40:37 -0500 (EST) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Feb 2002 14:43:20 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937413@CORPMX14> From: Black_David@emc.com To: dotis@sanlight.net, ips@ece.cmu.edu Subject: RE: iSCSI: No Framing Date: Mon, 4 Feb 2002 14:26:46 -0500 Importance: high X-Priority: 1 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 > Those advocating a portion of the iSCSI application be in hardware below the > TCP transport should be willing to document information exchanged between > layers, and the states held within this layer. You wish the IETF to endorse > a scheme within a standards draft and yet not be allowed to understand its > implementation. That is a level of implementation detail that the IETF has historically not demanded the exposure of, and it would certainly be inappropriate to standardize. To the extent that there are open source implementations of this form, the information will be disclosed in due course, other implementers will make their own decisions about what to make available. > This scheme so modifies the application attempting FIM > utilization, it would be impractical to describe this as not altering TCP. > TCP is not just a wire specification. Changing the receive packet into a > memory array needs additional clarification beyond a claim this does not > change TCP. That is unfortunately a waste of list bandwidth. With my WG chair hat firmly on, it is my conclusion that Doug Otis has failed to provide sufficient technical support for his argument that FIM alters TCP, and hence I hereby reject the procedural request that FIM be removed from the iSCSI draft as being a modification of TCP that would be outside the IPS WG's charter. Discussion of the merits of FIM is fine, and FIM may yet be removed from the iSCSI draft for good technical reasons (or may not) but debating whether FIM alters TCP is a waste of list bandwidth at this point. I also state that it is the rough consensus of the IPS WG that TCP will be used for the first version of iSCSI, and this is stated over Doug Otis's continuing objections. Doug would be better advised to work on using SCTP for iSCSI rather than complaining about the fact that others are not doing so. These decisions are appealable in accordance with RFC 2026, but should not be further discussed on this list. 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 Feb 4 16:06: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 QAA06004 for ; Mon, 4 Feb 2002 16:06:33 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g14KLTo08014 for ips-outgoing; Mon, 4 Feb 2002 15:21:29 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from packer.xiotech.com (mail.xiotech.com [209.46.118.18]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g14KLQj08009 for ; Mon, 4 Feb 2002 15:21:26 -0500 (EST) Message-ID: From: "Peglar, Robert" To: ips@ece.cmu.edu Subject: RE: iSCSI: No Framing Date: Mon, 4 Feb 2002 14:21:22 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk >-----Original Message----- >From: Douglas Otis [mailto:dotis@sanlight.net] >Sent: Monday, February 04, 2002 11:37 AM >To: ips@ece.cmu.edu >Subject: RE: iSCSI: No Framing > > >Rob, > >Although it will be true large amounts of bandwidth will be exchanged >between the typical SAN, such systems also use cache due to mechanical >limitations with respect to rotation and linear access. If it >were just >storage to storage, Fibre-Channel or FC encapsulation would be >preferable. >At least with that scheme, there are direct placement >interfaces available. Without bogging down the list in a debate about storage subsystems, I must say that there are examples to the contrary w.r.t. the usage of subsystem cache. iSCSI is, of course, more than just storage-to-storage. But we should not limit iSCSI to just host-to-storage. Remember, storage subsystems can (and are, in some cases) both initiator and target at the same time. The original thread began with a question (paraphrased) about '...what applications could consume a 10G pipe for long periods of time'. I answered that question - disk-disk backup and subsystem replication. FC is not sufficient. Storage-to-storage needs all the advantages as well as that which iSCSI has to offer the host-storage model. > >Direct placement is needed with low latency high bandwidth to reduce >overhead lost during a subsequent memory copy. This assumes a subsequent memory copy. >SCTP offers a means of >implementing direct placement without kludging a portion of >the application >beneath the transport. In addition, this direct placement >scheme can be >done in an general fashion to support thousands of higher >level protocols. >As with most SAN, network related failures are not well >tolerated, so the >added robustness of SCTP becomes highly beneficial. Having read this list since its creation, I choose to not participate in the SCTP/TCP religious war. >In establishing a large remote mirror, the highest bandwidth means of >initialization would be physical transport of the image. Once >initialized, >only differential information is exchanged largely limited by >the bandwidth >and error rate of the interconnect. Well put. Consider 3-10 TB of differential per day as a start. Consider images of 100s to 1,000s of TB, spread across 100s to 1,000s of 15KRPM (or more, stay tuned) spindles. Now, we're talking. Rob Rob Peglar Corporate Architect XIOtech Corporation, a Seagate Company (314) 308-6983 > >Doug > >> De-lurking... >> >> Right now, I'd say disk-disk backup/restore and mirroring. >The individual >> disk devices of today can perform at ~70 MB/s. One need >only gang 14 of >> these together, streaming, to reach nearly 1000 MB/s, or 1 GB/s, >> or 8 Gb/s. >> The disk devices of tomorrow are going to perform at rates >approaching 100 >> MB/s per spindle. Only ten devices are then necessary. >> >> This would be a single TCP stream (one initiator, one >target, many LUs). >> >> If one has to mirror (/move) 10 TB in a reasonable amount of >> time, say, then >> a stream of 1 GB/s is not only necessary, but paramount. Even at >> that rate, >> it would still take nearly three hours to move just 10 TB. In a >> business-critical recovery situation, three hours is an eon. >> >> Don't think application (CPU/memory in a server) to storage. >> Think storage >> to storage. >> >> Rob >> >> Rob Peglar >> Corporate Architect >> XIOtech Corporation, a Seagate Company >> (314) 308-6983 > From owner-ips@ece.cmu.edu Mon Feb 4 17:15: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 RAA07035 for ; Mon, 4 Feb 2002 17:15:18 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g14LYxL13723 for ips-outgoing; Mon, 4 Feb 2002 16:34:59 -0500 (EST) 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 g14LYwj13719 for ; Mon, 4 Feb 2002 16:34:58 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel7.hp.com (Postfix) with ESMTP id 616E3805063 for ; Mon, 4 Feb 2002 16:34:52 -0500 (EST) 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 NAA27102 for ; Mon, 4 Feb 2002 13:36:29 -0800 (PST) Message-ID: <005601c1adc3$c692c520$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: References: <1BEBA5E8600DD4119A50009027AF54A009F87A6B@axcs04.cos.agilent.com> Subject: Re: iSCSI: No Framing Date: Mon, 4 Feb 2002 13:34:49 -0800 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I share the concern about iSCSI embracing a framing mechanism that is not a MUST implement. For all the reasons that Jim pointed out, OTOH, I am not recommending a MUST framing either. I suspect not many will implement framing if it's a MAY, so it appears that we're talking about a potential SHOULD. Given that SHOULD is a fairly strong requirement, one "significant justification" for not doing framing could be (even while the NIC *may be* on the expensive side) - - has less design complexity since no OOO placement. - can have quicker TTM since less design, testing, debugging etc. I think ultimately it boils down to: how many vendors would use a "significant justfication" to not implement a SHOULD-requirement? If that's a majority: let's say vendor X is implementing (whatever) framing for optimizing the memory requirements, it essentially means that X's product will perform poorly with (the majority) no-framing senders. I don't think X would like that, nor the customer. IOW, this situation doesn't seem to be long-lasting. OTOH, the situation of an almost equal number of "framing" and "no-framing" products in the market (perhaps at different price points) could be unfortunately long-lasting.... To summarize, it is a troubling prospect that a framing technique (if adopted as SHOULD) has the potential to somewhat fracture the market and in effect create "interoperability problems" (of performance sort) similar to that affect FC.... -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 > > -----Original Message----- > From: WENDT,JIM (HP-Roseville,ex1) [mailto:jim_wendt@hp.com] > Sent: Tuesday, January 29, 2002 10:47 PM > To: ips@ece.cmu.edu > Subject: iSCSI: No Framing > > > > So, it would be good to hear from several iSCSI > NIC/chip implementors who: > - have or plan to implement FIM or COWS (or some > other framing mechanism) and take advantage of it to > minimize demands on on-NIC buffer memory > bandwidth/quantity. > - believe that all-buffers-on-chip solutions are > feasible and valid (wrt the points above, including > #2) > - can quantify the memory/pin/power/space cost > savings for all-buffers-on-chip solutions > > Jim > From owner-ips@ece.cmu.edu Mon Feb 4 17:16: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 RAA07048 for ; Mon, 4 Feb 2002 17:16:12 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g14KsJS10504 for ips-outgoing; Mon, 4 Feb 2002 15:54:19 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c003.snv.cp.net (c003-h016.c003.snv.cp.net [209.228.32.230]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g14KsCj10493 for ; Mon, 4 Feb 2002 15:54:12 -0500 (EST) Received: (cpmta 17570 invoked from network); 4 Feb 2002 12:54:05 -0800 Received: from 64.130.130.105 (HELO dougrmt) by smtp.telocity.com (209.228.32.230) with SMTP; 4 Feb 2002 12:54:05 -0800 X-Sent: 4 Feb 2002 20:54:05 GMT From: "Douglas Otis" To: "Tsvwg" Cc: "Ips" Subject: RE: iSCSI: No Framing Date: Mon, 4 Feb 2002 12:55:47 -0800 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <277DD60FB639D511AC0400B0D068B71E02937413@CORPMX14> Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, > > Those advocating a portion of the iSCSI application be in hardware > > below the TCP transport should be willing to document information > > exchanged between layers, and the states held within this layer. > > You wish the IETF to endorse a scheme within a standards draft and > > yet not be allowed to understand its implementation. > > That is a level of implementation detail that the IETF has historically > not demanded the exposure of, and it would certainly be inappropriate to > standardize. To the extent that there are open source implementations of > this form, the information will be disclosed in due course, other > implementers will make their own decisions about what to make available. I am not requesting a detailed API, but rather essential information exchanged between this layer beneath TCP supporting framing and the application. An essential aspect of any application interchange is the information exchanged with network related layers. Keeping this information proprietary does not allow a review. I suspect the reason for keeping this information private is to prevent an understanding of the scope of change being advocated or to ensure proprietary solutions. > > This scheme so modifies the application attempting FIM utilization, it > > would be impractical to describe this as not altering TCP. TCP is not > > just a wire specification. Changing the receive packet into a memory > > array needs additional clarification beyond a claim this does not > > change TCP. > > That is unfortunately a waste of list bandwidth. With my WG chair hat > firmly on, it is my conclusion that Doug Otis has failed to provide > sufficient technical support for his argument that FIM alters TCP, and > hence I hereby reject the procedural request that FIM be removed from the > iSCSI draft as being a modification of TCP that would be outside the IPS > WG's charter. Discussion of the merits of FIM is fine, and FIM may yet be > removed from the iSCSI draft for good technical reasons (or may not) but > debating whether FIM alters TCP is a waste of list bandwidth at this point. Any scheme that introduces a new network layer that directly or indirectly interfaces with the application would be a modification of any transport. I do not feel I am obligated to offer technical details of this scheme, but rather those that advocate its use should feel such obligations. > I also state that it is the rough consensus of the IPS WG that TCP will be > used for the first version of iSCSI, and this is stated over Doug Otis's > continuing objections. Doug would be better advised to work on using SCTP > for iSCSI rather than complaining about the fact that others are not doing > so. I have had no objections to the use of TCP. I have steadfastly rejected alteration of TCP to accommodate various schemes designed to introduce framing within or below TCP however, especially those that introduce application specific layers below the transport. My principle objection is that such a scheme is possible using SCTP without alteration of network layering. Your continued endorsement of such a scheme is troubling. If one is allowed to create a new layer below and above the transport, then any alteration of the transport becomes possible. Granting this abuse in principle makes any attempt by the IETF to regulate a transport meaningless. Here you are advocating that this new layer does not require any details offered and yet you have concluded it does not alter TCP in the absence of public information. > These decisions are appealable in accordance with RFC 2026, but should not > be further discussed on this list. My objections to this framing scheme remains unchanged. Your endorsement of an undocumented scheme is in violation of several principles expressed within RFC 2026. One being clear and concise documentation, and the other openness and fairness. The IPS wg has made an incorrect technical choice through the addition of this new layer below TCP which places the integrity of the iSCSI draft in jeopardy. I am willing to continue this through an appeals process, but my hope would be that this aspect of the draft is struck prior to that exercise. Doug > 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 Feb 4 17:18: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 RAA07062 for ; Mon, 4 Feb 2002 17:18:44 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g14LLje12604 for ips-outgoing; Mon, 4 Feb 2002 16:21:45 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c003.snv.cp.net (c003-h000.c003.snv.cp.net [209.228.32.214]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g14LLhj12598 for ; Mon, 4 Feb 2002 16:21:43 -0500 (EST) Received: (cpmta 18950 invoked from network); 4 Feb 2002 13:21:37 -0800 Received: from 64.130.130.105 (HELO dougrmt) by smtp.telocity.com (209.228.32.214) with SMTP; 4 Feb 2002 13:21:37 -0800 X-Sent: 4 Feb 2002 21:21:37 GMT From: "Douglas Otis" To: Subject: RE: iSCSI: No Framing Date: Mon, 4 Feb 2002 13:23:19 -0800 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Rob, I agree with your conclusions. 10 TB/day would represent an average of about 1 Gb/sec. This would be possible within a MAN environment. Indeed, within that environment and through the use of specialized memory handling, the need for any framing technique quickly vanishes. Doug > >Rob, > > > >Although it will be true large amounts of bandwidth will be exchanged > >between the typical SAN, such systems also use cache due to mechanical > >limitations with respect to rotation and linear access. If it were > >just storage to storage, Fibre-Channel or FC encapsulation would be > >preferable. At least with that scheme, there are direct placement > >interfaces available. > > Without bogging down the list in a debate about storage subsystems, I must > say that there are examples to the contrary w.r.t. the usage of subsystem > cache. > > iSCSI is, of course, more than just storage-to-storage. But we should not > limit iSCSI to just host-to-storage. Remember, storage subsystems can > (and are, in some cases) both initiator and target at the same time. > > The original thread began with a question (paraphrased) about '...what > applications could consume a 10G pipe for long periods of time'. > I answered that question - disk-disk backup and subsystem replication. > > FC is not sufficient. Storage-to-storage needs all the advantages as well > as that which iSCSI has to offer the host-storage model. > > > Direct placement is needed with low latency high bandwidth to reduce > > overhead loss during a subsequent memory copy. > > This assumes a subsequent memory copy. > > >SCTP offers a means of implementing direct placement without kludging > >a portion of the application beneath the transport. In addition, > >this direct placement scheme can be done in an general fashion to > >support thousands of higher level protocols. As with most SAN, > >network related failures are not well tolerated, so the added > >robustness of SCTP becomes highly beneficial. > > Having read this list since its creation, I choose to not > participate in the SCTP/TCP religious war. > > >In establishing a large remote mirror, the highest bandwidth means of > >initialization would be physical transport of the image. Once > >initialized, only differential information is exchanged largely > >limited by the bandwidth and error rate of the interconnect. > > Well put. Consider 3-10 TB of differential per day as a start. Consider > images of 100s to 1,000s of TB, spread across 100s to 1,000s of 15KRPM (or > more, stay tuned) spindles. Now, we're talking. > > Rob > > Rob Peglar > Corporate Architect > XIOtech Corporation, a Seagate Company > (314) 308-6983 From owner-ips@ece.cmu.edu Mon Feb 4 18:53: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 SAA08528 for ; Mon, 4 Feb 2002 18:53:06 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g14MIDr16937 for ips-outgoing; Mon, 4 Feb 2002 17:18:13 -0500 (EST) 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 g14MI9j16917 for ; Mon, 4 Feb 2002 17:18:09 -0500 (EST) 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 g14MHs608823; Mon, 4 Feb 2002 17:17:54 -0500 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with SMTP id g14MHsE14360; Mon, 4 Feb 2002 17:17:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15455.2194.2566.737855@pkoning.dev.equallogic.com> Date: Mon, 4 Feb 2002 17:17:54 -0500 (EST) From: Paul Koning To: Black_David@emc.com Cc: marjorie_krueger@hp.com, ips@ece.cmu.edu Subject: RE: IPsec Usage Question References: <277DD60FB639D511AC0400B0D068B71E02937412@CORPMX14> X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "BlackG" == Black David writes: BlackG> AFAIK, IPsec has no standard or widely deployed mechanism for BlackG> handling gateway discovery or address association BlackG> dynamically. True. But let's consider a very common IPsec deployment scenario. I think this is actually the predominant one, but let's not argue about that; it certainly is quite common. Scenario: two sites, each with an IPsec gateway, and an IPsec tunnel set up between the two sites. All traffic between the two sites goes through the tunnel. (This is the classic IPsec based VPN scenario.) The way this is handled is simply by configuring the routing tables on the two IPsec gateways to forward to the other site through the tunnel. As far as the other nodes on the two sites is concerned, the other site is simply reachable via ordinary IP mechanisms, and the existence of the tunnel, or the addresses used in the outer headers, are none of its concern. And of course the IP addresses of the inner header cannot possibly equal those of the outer header in this example. This example MUST work. So you cannot require inner == outer address, because that translates into saying that IP Storage cannot be protected by a site to site IPsec tunnel. Now for a different case: if you use tunnel mode to protect traffic for a single node (a common case for laptops, so this is often called the "road warrior" case) then it may well be useful to allow inner == outer. Some road warrior OS types will want that, others don't care so much, so it can be a simplifying approach. I have no objection at all to saying that inner == outer is useful, and for that matter I can go along with saying inner == outer should be supported. But, either way, inner != outer must be supported. paul From owner-ips@ece.cmu.edu Mon Feb 4 21:02: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 VAA10046 for ; Mon, 4 Feb 2002 21:02:00 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g150xLt28146 for ips-outgoing; Mon, 4 Feb 2002 19:59:21 -0500 (EST) 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 g150xIj28142 for ; Mon, 4 Feb 2002 19:59:19 -0500 (EST) 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 g150x3609564; Mon, 4 Feb 2002 19:59:03 -0500 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with ESMTP id g150x1r19154; Mon, 4 Feb 2002 19:59:02 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15455.11861.929000.83530@gargle.gargle.HOWL> Date: Mon, 4 Feb 2002 19:59:01 -0500 From: Paul Koning To: Black_David@emc.com, marjorie_krueger@hp.com, ips@ece.cmu.edu Subject: RE: IPsec Usage Question References: <277DD60FB639D511AC0400B0D068B71E02937412@CORPMX14> <15455.2194.2566.737855@pkoning.dev.equallogic.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 Addendum to my previous note about tunnels and IPsec gateways, because the examples I gave don't make the issue clear. The issue is: given how security gateways are used, is the inner address == outer address restriction acceptable? Consider a situation where a set of initiators are protected by a (separate) IPsec gateway. There are plenty of reasons for using that setup: (1) lower cost than per-HBA high speed crypto, (2) centralized security management is easier, (3) centralized security management is required by organization policy, (n) etc. On the other hand, the target is an iSCSI node whose built-in IPsec is used. (Perhaps it's managed separately; perhaps since there is only one node is it considered more sensible not to stick an IPsec gateway in front of it.) Let's assume that node doesn't need a separate outer IPsec address. In that setting, the I->T packets will have innerDA == outerDA and innerSA != outerSA, while the T->I packets will have innerSA == outerSA and innerDA != outerDA. Note also that in this scenario it doesn't matter to the initiators whether the target uses inner == outer. The initiators talk to the inner address of the target; only the IPsec gateway needs to know that that traffic goes into the tunnel to the target, and what the outer address for the tunnel is. (And that has to be IPsec management, not IPS management, since the IPsec gateway doesn't participate in any IPS mechanisms.) So in summary: since it's not acceptable to rule out the use of separate IPsec security gateways at one end of an IPS connection, it follows that you must allow inner != outer address. paul From owner-ips@ece.cmu.edu Tue Feb 5 00:57: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 AAA15224 for ; Tue, 5 Feb 2002 00:57:59 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g154vNm12552 for ips-outgoing; Mon, 4 Feb 2002 23:57:23 -0500 (EST) 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 g154vLj12548 for ; Mon, 4 Feb 2002 23:57:21 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id DBB3B84C; Mon, 4 Feb 2002 21:57:20 -0700 (MST) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id C2A23120; Mon, 4 Feb 2002 21:57:20 -0700 (MST) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 04 Feb 2002 21:57:20 -0700 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Feb 2002 21:57:20 -0700 Message-ID: <01A7DAF31F93D511AEE300D0B706ED9201BF4702@axcs13.cos.agilent.com> From: "CAVANNA,VICENTE V (A-Roseville,ex1)" To: "'Black_David@emc.com'" Cc: ips@ece.cmu.edu, "CAVANNA,VICENTE V (A-Roseville,ex1)" , "'marjorie_krueger@hp.com'" Subject: RE: IPsec Usage Question Date: Mon, 4 Feb 2002 21:55:21 -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, A few comments below as I thought about what you pointed out and, for the first time, about the implications of peer discovery mechanisms to IPsec. Vince |-----Original Message----- |From: Black_David@emc.com [mailto:Black_David@emc.com] |Sent: Monday, February 04, 2002 11:08 AM |To: marjorie_krueger@hp.com |Cc: ips@ece.cmu.edu |Subject: RE: IPsec Usage Question | | |> I agree with Paul, the association of *any* internal network address |> to any external mapping is an IPSec configuration concern! | |On the one hand, I like this, because it's the simplest way to close |this issue, and I have a strong preference for simple approaches that |allow us to declare victory sooner. OTOH, I want to make sure |that people |understand what the issue is: | | AFAIK, IPsec has no standard or widely deployed mechanism for | handling gateway discovery or address association dynamically. | |This has concrete consequences. Suppose that: |- An IPsec implementation operating only in tunnel mode and requiring | different inner and outer IP addresses is used to provide the | IPsec security required by an IP Storage protocol. AND |- A dynamic discovery mechanism (e.g., Send Targets, SLP, and iSNS) is | used to discover IP Storage peers. |Then the dynamic discovery mechanism only discovers the IP address |of the IP Storage peer, and does not provide information about the |IP address of the security gateway that must be contacted in order |to talk to that peer. | |The current state of the art is to statically pre-configure the gateway |address information (i.e., every peer that wants to communicate with a |specific implementation will have to know that |implementation's security |gateway IP address in advance, even though the IP Storage IP address |can be discovered dynamically). It is my understanding that this knowlege of security peers is an essential aspect of IPSec. IPSec is a point-to-point protocol and each entity has to know every other entity with which it needs to communicate securely. The security policy database MUST have the information required to reach any peer. If it is not known beforehand (until they are discovered) who the peers are, then it is possible that the required policy has not been setup and it may not be possible to reach that peer. What appears to mitigate this is that the policy may be described with coarse granularity and say something like "to reach any IP in subnet x use gateway y". This way targets in subnet x can be explored or discovered. I suppose if the discovery traffic can be identified (I have not studied the discovery mechanisms) the security policy could be set such as to allow such traffic to pass without security. I don't know if this a safe thing for a VPN gateway to allow. |This approach works, but it |makes dynamic |discovery much more difficult to use with security gateways. To the |extent that this biases IP storage against the use of security |gateways, |it will make my life easier in dealing with the folks who want to make |absolutely sure that IP Storage uses end-to-end security, but I wanted |to make sure that the practical configuration consequences of this |approach were understood. Even if the granularity of the security policy permits discovery (allows a target to be reached for discovery purposes) the process will be slow. Discovery cannot occur until an SA has been established between any security endpoints that may exist in the path between the iSCSI initiator and target. I don't know how directed the dynamic discovery mechanisms are but it seems as if this is going to be a very slow process even in simple cases where there are no nested tunnels. Consider a simple case of a target in some remote protected subnet and the initiator in a local protected subnet. Each subnet has a security gateway to the internet and both gateways secure all traffic between themselves by means of an IPsec tunnel. The first packet sent by the initiator to some target's IP will trigger an IKE exchange to the remote security gateway (whose IP is in the Security Policy database of the local security gateway) to establish the IPSec SAs. Depending on how the policy is setup, packets from the initiator to a different target IP may require a different IPSec SA to be setup. Imagine when there are nested tunnels because there is, in the path between initiator and target, a company security gateway followed by a department security gateway! In this case a security association must first be established with the corporate security gateway before a security association can be established with the department security gateway. Yes, it appears that the combination of IPSec and peer discovery is ugly indeed! | |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 Feb 5 01:33: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 BAA15559 for ; Tue, 5 Feb 2002 01:33:14 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g155QQ014166 for ips-outgoing; Tue, 5 Feb 2002 00:26:26 -0500 (EST) 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 g155QOj14161 for ; Tue, 5 Feb 2002 00:26:24 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id GAA51568; Tue, 5 Feb 2002 06:26:07 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g155RZY23968; Tue, 5 Feb 2002 06:27:35 +0100 Importance: Normal Subject: RE: IPsec Usage Question To: Paul Koning Cc: Black_David@emc.com, marjorie_krueger@hp.com, ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Ofer Biran" Date: Tue, 5 Feb 2002 07:29:34 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 05/02/2002 07:27:34 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Paul, >This example MUST work. So you cannot require inner == outer >address, because that translates into saying that IP Storage cannot be >protected by a site to site IPsec tunnel. This is not Kansas any more... The iSCSI devices on both sites (assuming that's their only IPsec protection) are not iSCSI compliant. This definitely doesn't cover the IPsec protection mandated by iSCSI. Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 Paul Koning @ece.cmu.edu on 05/02/2002 00:17:54 Sent by: owner-ips@ece.cmu.edu To: Black_David@emc.com cc: marjorie_krueger@hp.com, ips@ece.cmu.edu Subject: RE: IPsec Usage Question >>>>> "BlackG" == Black David writes: BlackG> AFAIK, IPsec has no standard or widely deployed mechanism for BlackG> handling gateway discovery or address association BlackG> dynamically. True. But let's consider a very common IPsec deployment scenario. I think this is actually the predominant one, but let's not argue about that; it certainly is quite common. Scenario: two sites, each with an IPsec gateway, and an IPsec tunnel set up between the two sites. All traffic between the two sites goes through the tunnel. (This is the classic IPsec based VPN scenario.) The way this is handled is simply by configuring the routing tables on the two IPsec gateways to forward to the other site through the tunnel. As far as the other nodes on the two sites is concerned, the other site is simply reachable via ordinary IP mechanisms, and the existence of the tunnel, or the addresses used in the outer headers, are none of its concern. And of course the IP addresses of the inner header cannot possibly equal those of the outer header in this example. This example MUST work. So you cannot require inner == outer address, because that translates into saying that IP Storage cannot be protected by a site to site IPsec tunnel. Now for a different case: if you use tunnel mode to protect traffic for a single node (a common case for laptops, so this is often called the "road warrior" case) then it may well be useful to allow inner == outer. Some road warrior OS types will want that, others don't care so much, so it can be a simplifying approach. I have no objection at all to saying that inner == outer is useful, and for that matter I can go along with saying inner == outer should be supported. But, either way, inner != outer must be supported. paul From owner-ips@ece.cmu.edu Tue Feb 5 01:43: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 BAA15797 for ; Tue, 5 Feb 2002 01:43:27 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g155unV15827 for ips-outgoing; Tue, 5 Feb 2002 00:56:49 -0500 (EST) 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 g155ulj15821 for ; Tue, 5 Feb 2002 00:56:47 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id GAA55722 for ; Tue, 5 Feb 2002 06:56:40 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g155w8Z80606 for ; Tue, 5 Feb 2002 06:58:08 +0100 Subject: Re: iSCSI: No Framing To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Tue, 5 Feb 2002 03:09:39 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 05/02/2002 07:58:06 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mallikarjun, I doubt that FIM (or COWS) will fracture the market. Hardware and software vendors will gain experience in what it takes to use framing. a specialized DDP and that could be useful later. The first generation although not imperiously needing any framing (I have proposed not less than 3 solutions!) will enable us to get a better second generation if we do something in this area. Julo "Mallikarjun C." To: Subject: Re: iSCSI: No Framing Sent by: owner-ips@ece. cmu.edu 04-02-02 23:34 I share the concern about iSCSI embracing a framing mechanism that is not a MUST implement. For all the reasons that Jim pointed out, OTOH, I am not recommending a MUST framing either. I suspect not many will implement framing if it's a MAY, so it appears that we're talking about a potential SHOULD. Given that SHOULD is a fairly strong requirement, one "significant justification" for not doing framing could be (even while the NIC *may be* on the expensive side) - - has less design complexity since no OOO placement. - can have quicker TTM since less design, testing, debugging etc. I think ultimately it boils down to: how many vendors would use a "significant justfication" to not implement a SHOULD-requirement? If that's a majority: let's say vendor X is implementing (whatever) framing for optimizing the memory requirements, it essentially means that X's product will perform poorly with (the majority) no-framing senders. I don't think X would like that, nor the customer. IOW, this situation doesn't seem to be long-lasting. OTOH, the situation of an almost equal number of "framing" and "no-framing" products in the market (perhaps at different price points) could be unfortunately long-lasting.... To summarize, it is a troubling prospect that a framing technique (if adopted as SHOULD) has the potential to somewhat fracture the market and in effect create "interoperability problems" (of performance sort) similar to that affect FC.... -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 > > -----Original Message----- > From: WENDT,JIM (HP-Roseville,ex1) [mailto:jim_wendt@hp.com] > Sent: Tuesday, January 29, 2002 10:47 PM > To: ips@ece.cmu.edu > Subject: iSCSI: No Framing > > > > So, it would be good to hear from several iSCSI > NIC/chip implementors who: > - have or plan to implement FIM or COWS (or some > other framing mechanism) and take advantage of it to > minimize demands on on-NIC buffer memory > bandwidth/quantity. > - believe that all-buffers-on-chip solutions are > feasible and valid (wrt the points above, including > #2) > - can quantify the memory/pin/power/space cost > savings for all-buffers-on-chip solutions > > Jim > From owner-ips@ece.cmu.edu Tue Feb 5 05:27: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 FAA26568 for ; Tue, 5 Feb 2002 05:27:36 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g158ef124316 for ips-outgoing; Tue, 5 Feb 2002 03:40:41 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c003.snv.cp.net (c003-h013.c003.snv.cp.net [209.228.32.227]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g158eej24312 for ; Tue, 5 Feb 2002 03:40:40 -0500 (EST) Received: (cpmta 14315 invoked from network); 5 Feb 2002 00:40:33 -0800 Received: from 64.130.130.105 (HELO dougrmt) by smtp.telocity.com (209.228.32.227) with SMTP; 5 Feb 2002 00:40:33 -0800 X-Sent: 5 Feb 2002 08:40:33 GMT From: "Douglas Otis" To: Cc: "Tsvwg" Subject: RE: iSCSI: No Framing Date: Tue, 5 Feb 2002 00:42:18 -0800 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, Implementing a scheme for doing direct data placement by means of an application specific, undocumented or proprietary layer below TCP will fracture the market. This will result in an unacceptable outcome having hardware created for each application, limited by various vendors making as yet unknown claims, if implementing the DDP feature using TCP. In the future, should this feature become desired, iSCSI can adopt a generic method that is possible through the use of SCTP. An eventual adoption of SCTP would also simplify much of the existing complexity found with the multi-connection TCP standard now proposed for iSCSI. Use of SCTP would allow common hardware for many protocols desiring Direct Data Placement without modification of the SCTP transport as it can deliver objects unordered. A shim providing the DDP feature could ensure objects are disclosed in the order sent if desired, independent of the reception at the shim while not modifying SCTP or adding layers beneath this transport as would be required for TCP. Only when constrained to conventional memory allocation, does DDP become beneficial. The concept of placing a layer beneath TCP that structures an array to hold each individual packet based on application specific structures is fundamentally flawed. This presumes the layer beneath TCP knows before hand the content of the byte stream prior to TCP composing the stream. This lower layer will also need to create exceptions for handling duplicates, for placement information not aligned with the TCP segment, and for application informational errors. SCTP can easily avoid these exceptional cases making such development less disruptive. In addition, an SCTP stack that does not offer DDP in hardware need not change the API behavior to the application nor modify any layer functionality. The ability of SCTP to support many different higher level protocols comes from the capability of SCTP to deliver objects unordered. TCP's restriction on ordered delivery mandates that any direct data placement is done prior to TCP through the addition of a new and application unique layer between IP and TCP. The saving caveat has been that disclosure to TCP of these packets are sequential but the application interface to TCP will change as a result of this modification in some undefined way to associate the steering information with the desired buffers. This change impacts the interface between this new layer, as well as the application and TCP. The desire to keep this DDP scheme for TCP proprietary will ensure a fractured market in terms of hardware, OS services, and perhaps interchange not to mention that each application then also needs unique hardware. The security risks involved in creating this new and highly complex layer below TCP is yet unknown as details are lacking. In essence, an attempt to implement DDP by creating a new layer beneath TCP in a proprietary fashion is in direct competition with the far better practice of using SCTP to implement DDP. Doug > Mallikarjun, > > I doubt that FIM (or COWS) will fracture the market. > Hardware and software vendors will gain experience in what it takes to use > framing. > a specialized DDP and that could be useful later. The first generation > although not imperiously needing any framing (I have proposed not > less than > 3 solutions!) will enable us to get a better second generation if we do > something in this area. > > Julo > > I share the concern about iSCSI embracing a framing mechanism that is > not a MUST implement. For all the reasons that Jim pointed out, OTOH, > I am not recommending a MUST framing either. I suspect not many will > implement framing if it's a MAY, so it appears that we're talking about > a potential SHOULD. > > Given that SHOULD is a fairly strong requirement, one "significant > justification" > for not doing framing could be (even while the NIC *may be* on the > expensive side) - > - has less design complexity since no OOO placement. > - can have quicker TTM since less design, testing, debugging etc. > > I think ultimately it boils down to: how many vendors would use a > "significant > justfication" to not implement a SHOULD-requirement? > > If that's a majority: let's say vendor X is implementing > (whatever) framing > for > optimizing the memory requirements, it essentially means that X's product > will > perform poorly with (the majority) no-framing senders. I don't think X > would > like that, nor the customer. IOW, this situation doesn't seem to be > long-lasting. > OTOH, the situation of an almost equal number of "framing" and > "no-framing" > products in the market (perhaps at different price points) could be > unfortunately > long-lasting.... > > To summarize, it is a troubling prospect that a framing technique (if > adopted as > SHOULD) has the potential to somewhat fracture the market and in effect > create "interoperability problems" (of performance sort) similar to that > affect > FC.... > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 From owner-ips@ece.cmu.edu Tue Feb 5 07: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 HAA28056 for ; Tue, 5 Feb 2002 07:17:57 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g15BHk715126 for ips-outgoing; Tue, 5 Feb 2002 06:17:46 -0500 (EST) 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 g15BHij15121 for ; Tue, 5 Feb 2002 06:17:44 -0500 (EST) 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 657B9151 for ; Tue, 5 Feb 2002 12:17:40 +0100 (MET) Received: from 15.145.8.166 by loddon.br.itc.hp.com (InterScan E-Mail VirusWall NT); Tue, 05 Feb 2002 11:17:40 -0000 (GMT Standard Time) Received: by loddon.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Feb 2002 11:17:40 -0000 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC104FF1D9E@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: ips@ece.cmu.edu Subject: Small Editorial Change Date: Tue, 5 Feb 2002 11:17:38 -0000 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, In section 12.14 of draft 10, the last sentence refers to MaximumBurstSize. I presume this should read MaxBurstSize to tie it up with 12.13. Matthew From owner-ips@ece.cmu.edu Tue Feb 5 11:24: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 LAA06654 for ; Tue, 5 Feb 2002 11:24:13 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g15Eqxq28208 for ips-outgoing; Tue, 5 Feb 2002 09:52:59 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g15Eqqj28199 for ; Tue, 5 Feb 2002 09:52:52 -0500 (EST) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.154]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4617); Tue, 5 Feb 2002 06:52:33 -0800 Received: from 157.54.6.150 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 05 Feb 2002 06:52:33 -0800 Received: from red-msg-02.redmond.corp.microsoft.com ([157.54.12.70]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 5 Feb 2002 06:52:33 -0800 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: No Framing Date: Tue, 5 Feb 2002 06:52:32 -0800 Message-ID: <24A715275661C8428C00432EFCA5CB7C055F9B61@red-msg-02.redmond.corp.microsoft.com> Thread-Topic: iSCSI: No Framing Thread-Index: AcGrv9XTWsFSDDZGQECp7Cc3J9bNcQCkwoyw From: "Jim Pinkerton" To: "John Hufferd" , Cc: "Mukund, Shridhar" , X-OriginalArrivalTime: 05 Feb 2002 14:52:33.0270 (UTC) FILETIME=[BE164160:01C1AE54] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g15Eqrj28200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit In reviewing the mail alias, and after having many conversations with various folks, I would like to retract my prior opinion on ripping out markers. It appears to me as though _every_ NIC vendor is in support of markers. To me the evidence in support of keeping in "Sync and Steering with Fixed Interval Markers" is pretty compelling (now that I've been re-educated). Without going into proprietary issues - how often do NIC vendors agree unanimously on something? Also, a software implementation of markers is tractable. I have not heard a single NIC vendor in support of COWS, and I personally don't support COWS either. Thus I would recommend that COWS be "ripped out". Jim -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Friday, February 01, 2002 11:31 PM To: somesh_gupta@silverbacksystems.com Cc: Mukund, Shridhar; ips@ece.cmu.edu Subject: RE: iSCSI: No Framing Somesh, This is not fair, we asked for Chip Vendors that were planning on using it, to make themselves known and to tell us why. Without exposing internal designs, he has tried to do that, likewise Trebia, and some others have said they want FIMs. You may not want FIMs for your design, but you should respect these folks that have been following our spec and found it to be valuable in their designs. They are putting their money on it not just talk, so we should at least give them the credit which their position deserves. Yes, of course they are disappointed with the rhetoric around this issue, since they and others have been following the spec, and can not understand why others haven't, since they have determined it to be of significant value. His note does speak to the issues. (And clearly has some silly parts :-) In fact he has found it of enough value to use now, since he believes they can not wait for iWARP to happen before the issue is addressed (and he really wants iWARP). It should be useful to listen to folks that are willing to put their money where their mouth is. OK, that said: don't you think we can find a way to address both your position and their position, since they both seem strong and heart felt. I would think that the "Should Implement" or at least "May Implement" would give both sides enough reasonable room to meet on an even business plane. . . . 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 "Somesh Gupta" @ece.cmu.edu on 02/01/2002 07:10:13 PM Please respond to Sent by: owner-ips@ece.cmu.edu To: "Mukund, Shridhar" , "'WENDT,JIM \(HP-Roseville,ex1\)'" , cc: Subject: RE: iSCSI: No Framing Mukund, With all due respect, taking on the mantle of the noble engineer being denied by politically motivated people, belittles the technical expertise and strengths of the people who have expressed an opinion against having any of the proposed schemes at this time in the spec. I would be very happy to work alongside a number of the people on both sides of the issue (and that does include you). None of your arguments below refutes the technical and some non-technical opinions expressed against FIM. Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Mukund, Shridhar > Sent: Friday, February 01, 2002 5:24 PM > To: 'WENDT,JIM (HP-Roseville,ex1)'; ips@ece.cmu.edu > Subject: RE: iSCSI: No Framing > > > Dear Colleagues, > > PART 1 of 3 : > > The pertinent points that "I" see in Jim's email are: > > A. Need to hear from iSCSI chip implementers ... > The issues that you raise for e.g. in #2 are simply > circumstantial( See PART 2 ). Answers to those questions > unnecessarily call for data flows and implementation > details that silicon vendors are not allowed to share > in public. While I do not know of many silicon vendors > in the multi gig space, clearly one of the competitions > I respect, namely Trebia, point to FIM as well. Granted, > no matter what, we are going to see several > trebia-on-the-other-end and adaptec-on-the-other-end > type of cost optimizations. > > B. The iWARP/TUF/SCTP under-current ... > The "only" message of significance in Jim's email is #5. > It seems like the iWARP/SCTP/TUF enthusiasts somehow feel > threatened that FIM-iSCSI will dilute the perceived value > proposition of iWARP :-) I for one am an enthusiast of > iWARP ideals myself, barring the proposed mechanics. I > would love to make a buck or two along with you in > building iWARP NICs, "at the right time". In the > meanwhile, iSCSI is the flag ship effort that has the > unique opportunity to make a dent in enabling IP Storage > visions. ( See PART 3 ) > > My assertions are : > i) TUF/SCTP/iWARP is ruled out in the near term. The > mechanics are unclear as hell. > ii) FIM is the least intrusive, TCP transparent, means for > enabling low-cost(power,b/w,latency,memory,space,CPU) > RDMA transport of bulk data. > iii) I do not see significant technical reasons that > merit major changes to the iSCSI draft at this late > date. > iii) Making it OPTIONAL to use, and SHOULD only on send > provides a graceful and incremental deployment path > for "real":-) providers and users to succeed. > > I have personally contributed nothing to the iSCSI effort > and do applaud the pains that several of you are taking to > pull it all together. In that very same spirit, I respect > David's decision w.r.t. consensus, whatever that turns out > to be. > > Thanks. > > -Shridhar Mukund + Todd Sperry, Siva Munnangi, Dev ... > > ------------------------------------------------------------ > PART 2 of 3 : MUST delete, SHOULD read > > Dear Jim, > > Congratulations Jim! Seems like when you bowl, pins > roll, unintentional as they may be. You make a "seemingly" > well balanced set of arguments and "tactfully" tilt the > balance towards your chosen side. I would love to be on > your side ... maybe in another effort :-) > > I would like to introduce you to my respectable friend, > who "vehemently" contradicts you on all accounts. One of > his numerous quotes goes as follows: > http://groups.yahoo.com/group/rdma/message/486 > "Much of today's usage of the Internet and IP networks > is for buffer-to-buffer data transfers, often in the > form of bulk data ... Gigabit and faster network transfers > incur 'heavy' system resource costs, including both CPU > use and system bus bandwidth, particularly on the > receiving side ... The costs incurred on hosts for protocol > processing and management has 'inhibited' the use of IP > in the high speed bulk data domain. ... Bulk data transfer > is dominated by the costs of copying and validating > incoming data in order to place it at its ultimate > destination." > > The good friend I quote above is none other than Jim > Wendt himself!!! I REST MY CASE. > > Thanks. > > -Shridhar Mukund > > ---------------------------------------------------------------- > PART 3 of 3: MUST delete, OPTIONAL read > > On the lighter side ... since the opponents have "no" technical > arguments whatsoever against FIM and it is all turning out to > be a pure political gimmick, I will put on my rusting tin > politician hat :-) > > My dear fellow iSCSI country (wo)men: If our goals are anything > short of enabling the HP's, Cisco's, uSoft's, IBM's and EMC's of > the world in globalization of storage for McDonald's and Macy's > from Kabul to Somalia, via iSCSI, we have lost our identity! > ( \insert APPLAUSE for 13 seconds )We are no more protected by > the vast oceans between us and other Storage efforts. The > freedom of iSCSI America is threatened from within by elements > who will not blink twice when it comes to using the world's most > potent BOO-bombs ... and grinnn while we end up sifting through > the rubbles for iSCSI, youSCSI and theySCSI. > ( \insert APPLAUSE for 11 seconds ) Beware of the elements that > sleep with "our" very ideals in their privacy(burkha clad > though) and yet attempt to destabilize us, only to accomplish > their mutated agenda.( \insert APPLAUSE for 57 seconds ) > > No offense folks. I respect each and every one of you and > especially Jim. I think that he was only attempting to > question, "are we sure ... should we commit ...". > I disagree with him anyway! > > - the running(actually limping) mate :-) :-) :-) > > -----Original Message----- > From: WENDT,JIM (HP-Roseville,ex1) [mailto:jim_wendt@hp.com] > Sent: Tuesday, January 29, 2002 10:47 PM > To: ips@ece.cmu.edu > Subject: iSCSI: No Framing > > > Perhaps we should discuss the possibility of not > specifying any framing mechanism (FIM or COWS) in the > first version of iSCSI. > > The arguments for not specifying framing include > (there may be others as well): > 1) The brute force approach of putting TCP receiver > reassembly memory on the iSCSI NIC will work for both > 1Gbps and 10Gbps. Cost is incurred for memory chips, > ASIC pins, power, and board space. But, it is a > feasible approach. > > 2) I/O bus latency (or bandwidth limitations) could > mandate inbound buffering (as a 'smoothing' buffer) > from the iSCSI NIC to the host system. If this buffer > memory is large enough to have to be off-chip, then > it will require some minimum number of memory chips > to provide the necessary bandwidth, and the > memory/pins/power/space costs will be incurred > anyway. > > 3) Very large receive buffering on the NIC is only > required for high-bandwidth links traversing large > geographic distances (which may not be the > predominate case). These specialized implementations > can cost more (e.g. more memory/power/pins/etc) and > customers will likely be willing to pay accordingly. > > 4) Many NICs will likely aspire to be combo > iSCSI+TOE+Ethernet NICs allowing the host system to > use a single Ethernet port for all of its network > communications. The TOE function on this combo NIC > will already require TCP receive buffering and off- > chip buffer memory to support the existing sockets > interface receive model. More importantly, to allow > senders to assume ownership of the buffer upon return > from a socket send call, the TOE NIC would need to > copy application send buffers into NIC memory as > well. > > 5) The framing/marker mechanism will be an iSCSI-only > solution. It is quite possible that the problem will > be solved via a different, and hopefully more > general, mechanism for other ULPs. > > 6) Both FIM and COWS are poor solutions for software > implementation. COWS requires, at a minimum, the > sender to read every word in the buffer. FIM either > imposes additional sender gather processing (iovecs) > or requires a data buffer copy (on systems that don't > support HW gather on sends). > > 7) Unless all senders thoroughly test framing/markers > now (i.e. unless the framing method is a MUST > implement), there is potential for future > interoperability problems as framing/marker receivers > are deployed in the future. > > 8) Neither FIM nor COWS is an elegant solution. Are > we comfortable with the legacy we are creating under > the umbrella of state-of-the-art IP networked > storage? > > 9) Is it essential to build in forward compatibility > now, or will there be a different solution in the > 10Gbps or 40Gbps timeframe - perhaps involving iSCSI- > 2? Will it be reasonable to update or bridge initial > 1Gbps deployments? > > > So, it would be good to hear from several iSCSI > NIC/chip implementors who: > - have or plan to implement FIM or COWS (or some > other framing mechanism) and take advantage of it to > minimize demands on on-NIC buffer memory > bandwidth/quantity. > - believe that all-buffers-on-chip solutions are > feasible and valid (wrt the points above, including > #2) > - can quantify the memory/pin/power/space cost > savings for all-buffers-on-chip solutions > > Jim > From owner-ips@ece.cmu.edu Tue Feb 5 12:22: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 MAA09424 for ; Tue, 5 Feb 2002 12:22:17 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g15GJMd05598 for ips-outgoing; Tue, 5 Feb 2002 11:19:22 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail15a.boca15-verio.com (mail15a.boca15-verio.com [208.55.91.57]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g15GJIj05580 for ; Tue, 5 Feb 2002 11:19:19 -0500 (EST) Received: from www1509.boca15-verio.com (208.55.91.90) by mail15a.boca15-verio.com (RS ver 1.0.60s) with SMTP id 020592864; Tue, 5 Feb 2002 11:18:02 -0500 (EST) From: "Joseph D. Harwood" To: "CAVANNA,VICENTE V \(A-Roseville,ex1\)" , Cc: , Subject: RE: IPsec Usage Question Date: Tue, 5 Feb 2002 08:19:20 -0800 Message-ID: <002401c1ae60$ddebdc00$c7d0fea9@vesta> 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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-reply-to: <01A7DAF31F93D511AEE300D0B706ED9201BF4702@axcs13.cos.agilent.com> Importance: Normal X-Loop-Detect: 1 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello, An SA only needs to be set up if it isn't in place already. How often this happens can be controlled through configuration: - Does the discovery traffic use the same SA as other traffic, or does it require a unique SA? - How often is discovery performed? - How long does an SA stay in place when there is no traffic? It should be possible to choose these parameters so that IPsec doesn't unduly burden discovery, perhaps suggestions for the above could be included in the standard. Best Regards, Joseph D. Harwood (408) 838-9434 jharwood@vesta-corp.com www.vesta-corp.com > > |This approach works, but it > |makes dynamic > |discovery much more difficult to use with security gateways. To the > |extent that this biases IP storage against the use of security > |gateways, > |it will make my life easier in dealing with the folks who want to make > |absolutely sure that IP Storage uses end-to-end security, but I wanted > |to make sure that the practical configuration consequences of this > |approach were understood. > > Even if the granularity of the security policy permits discovery (allows a > target to be reached for discovery purposes) the process will be slow. > Discovery cannot occur until an SA has been established between > any security > endpoints that may exist in the path between the iSCSI initiator > and target. > I don't know how directed the dynamic discovery mechanisms are > but it seems > as if this is going to be a very slow process even in simple cases where > there are no nested tunnels. > > Consider a simple case of a target in some remote protected subnet and the > initiator in a local protected subnet. Each subnet has a security > gateway to > the internet and both gateways secure all traffic between themselves by > means of an IPsec tunnel. > > The first packet sent by the initiator to some target's IP will trigger an > IKE exchange to the remote security gateway (whose IP is in the Security > Policy database of the local security gateway) to establish the IPSec SAs. > Depending on how the policy is setup, packets from the initiator to a > different target IP may require a different IPSec SA to be setup. > > Imagine when there are nested tunnels because there is, in the > path between > initiator and target, a company security gateway followed by a > department > security gateway! In this case a security association must first be > established with the corporate security gateway before a security > association can be established with the department security gateway. > > Yes, it appears that the combination of IPSec and peer discovery is ugly > indeed! > > From owner-ips@ece.cmu.edu Tue Feb 5 12:24: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 MAA09526 for ; Tue, 5 Feb 2002 12:24:32 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g15G0iJ03871 for ips-outgoing; Tue, 5 Feb 2002 11:00:44 -0500 (EST) 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 g15G0fj03859 for ; Tue, 5 Feb 2002 11:00:41 -0500 (EST) Received: from xparelay1.corp.hp.com (xparelay1.corp.hp.com [15.58.136.173]) by palrel12.hp.com (Postfix) with ESMTP id 23BA960084E for ; Tue, 5 Feb 2002 08:00:32 -0800 (PST) Received: from xpabh2.corp.hp.com (xpabh2.corp.hp.com [15.58.136.192]) by xparelay1.corp.hp.com (Postfix) with ESMTP id 044E6E000A2 for ; Tue, 5 Feb 2002 08:00:32 -0800 (PST) Received: by xpabh2.corp.hp.com with Internet Mail Service (5.5.2653.19) id <1FZ2HLQ1>; Tue, 5 Feb 2002 08:00:31 -0800 Message-ID: <499DC368E25AD411B3F100902740AD6508E99F13@xrose03.rose.hp.com> From: "ERICKSON,SHAWN (HP-Roseville,ex1)" To: ips@ece.cmu.edu Subject: RE: iSCSI: No Framing Date: Tue, 5 Feb 2002 08:00:31 -0800 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 trying to be obtuse but how does it help if only the NIC vendors implement it? (I know you didn't precisely say that) It sounds like we may end up with NIC vendors implementing it and storage vendors ignoring it or some mix. In the end we will have a fracture in the market place and/or all vendors will be forced to implement FIM to satisfy customer demands ("my NIC supports FIMs, you don't, things are SLOW, you must be at fault", etc.). To me it sounds like FIMs needs to be SHOULD/MUST or not in the standard at all (moved to a secondary document). I personally would like to see FIM (and COWS) moved from the standard to a secondary document but that is just my gut level opinion on this issue. I do think FIM blurs the layering of TCP/IP, which is not normally desirable. Regardless it would be worthwhile for a document describing how to fire iSCSI over SCTP or other IP backed transports that are better suited for iSCSI style data and high speed/long distance links. (Please excuse my ignorance is such drafts already exist) -Shawn ------------------------------------------------------- Shawn Carl Erickson > -----Original Message----- > From: Jim Pinkerton [mailto:jpink@microsoft.com] > Sent: Tuesday, February 05, 2002 6:53 AM > To: John Hufferd; somesh_gupta@silverbacksystems.com > Cc: Mukund, Shridhar; ips@ece.cmu.edu > Subject: RE: iSCSI: No Framing > > > > In reviewing the mail alias, and after having many conversations with > various folks, I would like to retract my prior opinion on ripping out > markers. It appears to me as though _every_ NIC vendor is in > support of > markers. > > To me the evidence in support of keeping in "Sync and Steering with > Fixed Interval Markers" is pretty compelling (now that I've been > re-educated). Without going into proprietary issues - how often do NIC > vendors agree unanimously on something? Also, a software > implementation > of markers is tractable. > > I have not heard a single NIC vendor in support of COWS, and I > personally don't support COWS either. Thus I would recommend that COWS > be "ripped out". > > > Jim From owner-ips@ece.cmu.edu Tue Feb 5 13:02: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 NAA11135 for ; Tue, 5 Feb 2002 13:02:38 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g15H3JD09277 for ips-outgoing; Tue, 5 Feb 2002 12:03:19 -0500 (EST) 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 g15H3Hj09271; Tue, 5 Feb 2002 12:03:17 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id SAA68026; Tue, 5 Feb 2002 18:03:11 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g15H4a292558; Tue, 5 Feb 2002 18:04:36 +0100 To: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: Small Editorial Change X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 5 Feb 2002 19:04:33 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 05/02/2002 19:04:38, Serialize complete at 05/02/2002 19:04:38 Content-Type: multipart/alternative; boundary="=_alternative 005B5508C2256B57_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005B5508C2256B57_= Content-Type: text/plain; charset="us-ascii" thanks - julo "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" Sent by: owner-ips@ece.cmu.edu 05-02-02 13:17 To: ips@ece.cmu.edu cc: Subject: Small Editorial Change Julian, In section 12.14 of draft 10, the last sentence refers to MaximumBurstSize. I presume this should read MaxBurstSize to tie it up with 12.13. Matthew --=_alternative 005B5508C2256B57_= 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

05-02-02 13:17

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        Small Editorial Change

       


Julian,

In section 12.14 of draft 10, the last sentence refers to MaximumBurstSize.
I presume this should read MaxBurstSize to tie it up with 12.13.

Matthew

--=_alternative 005B5508C2256B57_=-- From owner-ips@ece.cmu.edu Tue Feb 5 13:10: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 NAA11513 for ; Tue, 5 Feb 2002 13:10:06 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g15Gr7r08499 for ips-outgoing; Tue, 5 Feb 2002 11:53:07 -0500 (EST) 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 g15Gr0j08480 for ; Tue, 5 Feb 2002 11:53:01 -0500 (EST) 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 g15GqY613689; Tue, 5 Feb 2002 11:52:34 -0500 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with ESMTP id g15GqSX18848; Tue, 5 Feb 2002 11:52:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15456.3532.484000.503186@gargle.gargle.HOWL> Date: Tue, 5 Feb 2002 11:52:28 -0500 From: Paul Koning To: BIRAN@il.ibm.com Cc: Black_David@emc.com, marjorie_krueger@hp.com, ips@ece.cmu.edu Subject: RE: IPsec Usage Question References: 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 5 February 2002) by Ofer Biran: > > Paul, > > >This example MUST work. So you cannot require inner == outer > >address, because that translates into saying that IP Storage cannot be > >protected by a site to site IPsec tunnel. > > This is not Kansas any more... The iSCSI devices on both sites (assuming > that's their only IPsec protection) are not iSCSI compliant. This > definitely > doesn't cover the IPsec protection mandated by iSCSI. No, you're mistaken. I said nothing about what the iSCSI devices IMPLEMENT. I only talked about what was IN USE by the customer. In the example, the customer chose to USE a different security mechanism for reasons of cost, convenience, site policy, or whatever. Remember that the proposed requirement is "required to implement" and NOT "required to use". My interpretation of having "use" be optional is that you also have the option of securing your traffic via other means. Am I right? Or is it the intent of the WG to say that no other security mechanisms are allowed -- if you want security you MUST use the one that is mandated in iSCSI nodes? If so, for what reason? paul From owner-ips@ece.cmu.edu Tue Feb 5 13:11: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 NAA11585 for ; Tue, 5 Feb 2002 13:11:10 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g15HGwh10321 for ips-outgoing; Tue, 5 Feb 2002 12:16:58 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ausxc10.us.dell.com (ausxc10.us.dell.com [143.166.98.229]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g15HGuj10316 for ; Tue, 5 Feb 2002 12:16:56 -0500 (EST) Received: by ausxc10.us.dell.com with Internet Mail Service (5.5.2650.21) id <1B1JYHL8>; Tue, 5 Feb 2002 11:13:48 -0600 Message-ID: <71714C04806CD511935200902728921703AC3117@ausxmrr502.us.dell.com> From: Dan_McConnell@Dell.com To: ips@ece.cmu.edu Subject: iSCSI: iSNS Sever Reference implementation Date: Tue, 5 Feb 2002 11:15:12 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AE68.ABFDE6E0" 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_01C1AE68.ABFDE6E0 Content-Type: text/plain I am curious what everyone's current thoughts are concerning a common reference implementation for the iSNS Server. Those that are implementing iSNS clients in their iSCSI HBAs, initiators, and targets, is there a "reference implementation" of the iSNS server that you have been testing with to ensure interoperability? Have you been developing your own? Are people using the Nishan iSNS implementations as reference implementations? Thanks, Dan ------_=_NextPart_001_01C1AE68.ABFDE6E0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable iSCSI: iSNS Sever Reference implementation

I am curious = what everyone's current thoughts = are concerning a common reference implementation for = the iSNS Server.  = Those that are implementing iSNS clients in their iSCSI = HBAs, initiators, and targets, is there a "reference = implementation" of the iSNS server that you have been testing with to = ensure interoperability?  Have you = been developing your own?  Are people using the Nishan iSNS implementations as = reference implementations?

Thanks,

Dan

------_=_NextPart_001_01C1AE68.ABFDE6E0-- From owner-ips@ece.cmu.edu Tue Feb 5 13:20: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 NAA11989 for ; Tue, 5 Feb 2002 13:20:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g15HJkt10571 for ips-outgoing; Tue, 5 Feb 2002 12:19:46 -0500 (EST) 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 g15HJij10563 for ; Tue, 5 Feb 2002 12:19:44 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id SAA160596; Tue, 5 Feb 2002 18:19:31 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g15HKv269948; Tue, 5 Feb 2002 18:20:57 +0100 To: ips@ece.cmu.edu Cc: Black_David@emc.com MIME-Version: 1.0 Subject: RE: iSCSI: No Framing X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 5 Feb 2002 19:20:49 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 05/02/2002 19:20:58, Serialize complete at 05/02/2002 19:20:58 Content-Type: multipart/alternative; boundary="=_alternative 005DC6D5C2256B57_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005DC6D5C2256B57_= Content-Type: text/plain; charset="us-ascii" David, Dough is continuing his rumblings - whether they are relevant to us or not. I wonder if there is some administrative measure you can take to save us some bandwidth or we should install our own "Otis filters". Julo "Douglas Otis" Sent by: owner-ips@ece.cmu.edu 05-02-02 10:42 To: cc: "Tsvwg" Subject: RE: iSCSI: No Framing Julian, Implementing a scheme for doing direct data placement by means of an application specific, undocumented or proprietary layer below TCP will fracture the market. This will result in an unacceptable outcome having hardware created for each application, limited by various vendors making as yet unknown claims, if implementing the DDP feature using TCP. In the future, should this feature become desired, iSCSI can adopt a generic method that is possible through the use of SCTP. An eventual adoption of SCTP would also simplify much of the existing complexity found with the multi-connection TCP standard now proposed for iSCSI. Use of SCTP would allow common hardware for many protocols desiring Direct Data Placement without modification of the SCTP transport as it can deliver objects unordered. A shim providing the DDP feature could ensure objects are disclosed in the order sent if desired, independent of the reception at the shim while not modifying SCTP or adding layers beneath this transport as would be required for TCP. Only when constrained to conventional memory allocation, does DDP become beneficial. The concept of placing a layer beneath TCP that structures an array to hold each individual packet based on application specific structures is fundamentally flawed. This presumes the layer beneath TCP knows before hand the content of the byte stream prior to TCP composing the stream. This lower layer will also need to create exceptions for handling duplicates, for placement information not aligned with the TCP segment, and for application informational errors. SCTP can easily avoid these exceptional cases making such development less disruptive. In addition, an SCTP stack that does not offer DDP in hardware need not change the API behavior to the application nor modify any layer functionality. The ability of SCTP to support many different higher level protocols comes from the capability of SCTP to deliver objects unordered. TCP's restriction on ordered delivery mandates that any direct data placement is done prior to TCP through the addition of a new and application unique layer between IP and TCP. The saving caveat has been that disclosure to TCP of these packets are sequential but the application interface to TCP will change as a result of this modification in some undefined way to associate the steering information with the desired buffers. This change impacts the interface between this new layer, as well as the application and TCP. The desire to keep this DDP scheme for TCP proprietary will ensure a fractured market in terms of hardware, OS services, and perhaps interchange not to mention that each application then also needs unique hardware. The security risks involved in creating this new and highly complex layer below TCP is yet unknown as details are lacking. In essence, an attempt to implement DDP by creating a new layer beneath TCP in a proprietary fashion is in direct competition with the far better practice of using SCTP to implement DDP. Doug > Mallikarjun, > > I doubt that FIM (or COWS) will fracture the market. > Hardware and software vendors will gain experience in what it takes to use > framing. > a specialized DDP and that could be useful later. The first generation > although not imperiously needing any framing (I have proposed not > less than > 3 solutions!) will enable us to get a better second generation if we do > something in this area. > > Julo > > I share the concern about iSCSI embracing a framing mechanism that is > not a MUST implement. For all the reasons that Jim pointed out, OTOH, > I am not recommending a MUST framing either. I suspect not many will > implement framing if it's a MAY, so it appears that we're talking about > a potential SHOULD. > > Given that SHOULD is a fairly strong requirement, one "significant > justification" > for not doing framing could be (even while the NIC *may be* on the > expensive side) - > - has less design complexity since no OOO placement. > - can have quicker TTM since less design, testing, debugging etc. > > I think ultimately it boils down to: how many vendors would use a > "significant > justfication" to not implement a SHOULD-requirement? > > If that's a majority: let's say vendor X is implementing > (whatever) framing > for > optimizing the memory requirements, it essentially means that X's product > will > perform poorly with (the majority) no-framing senders. I don't think X > would > like that, nor the customer. IOW, this situation doesn't seem to be > long-lasting. > OTOH, the situation of an almost equal number of "framing" and > "no-framing" > products in the market (perhaps at different price points) could be > unfortunately > long-lasting.... > > To summarize, it is a troubling prospect that a framing technique (if > adopted as > SHOULD) has the potential to somewhat fracture the market and in effect > create "interoperability problems" (of performance sort) similar to that > affect > FC.... > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 --=_alternative 005DC6D5C2256B57_= Content-Type: text/html; charset="us-ascii"
David,

Dough is continuing his rumblings - whether they are relevant to us or not.
I wonder if there is some administrative measure you can take to save us some bandwidth or we should install our own
"Otis filters".

Julo




"Douglas Otis" <dotis@sanlight.net>
Sent by: owner-ips@ece.cmu.edu

05-02-02 10:42

       
        To:        <ips@ece.cmu.edu>
        cc:        "Tsvwg" <tsvwg@ietf.org>
        Subject:        RE: iSCSI: No Framing

       


Julian,

Implementing a scheme for doing direct data placement by means of an
application specific, undocumented or proprietary layer below TCP will
fracture the market.  This will result in an unacceptable outcome having
hardware created for each application, limited by various vendors making as
yet unknown claims, if implementing the DDP feature using TCP.  In the
future, should this feature become desired, iSCSI can adopt a generic method
that is possible through the use of SCTP.  An eventual adoption of SCTP
would also simplify much of the existing complexity found with the
multi-connection TCP standard now proposed for iSCSI.  Use of SCTP would
allow common hardware for many protocols desiring Direct Data Placement
without modification of the SCTP transport as it can deliver objects
unordered.  A shim providing the DDP feature could ensure objects are
disclosed in the order sent if desired, independent of the reception at the
shim while not modifying SCTP or adding layers beneath this transport as
would be required for TCP.

Only when constrained to conventional memory allocation, does DDP become
beneficial.  The concept of placing a layer beneath TCP that structures an
array to hold each individual packet based on application specific
structures is fundamentally flawed.  This presumes the layer beneath TCP
knows before hand the content of the byte stream prior to TCP composing the
stream.  This lower layer will also need to create exceptions for handling
duplicates, for placement information not aligned with the TCP segment, and
for application informational errors.  SCTP can easily avoid these
exceptional cases making such development less disruptive.  In addition, an
SCTP stack that does not offer DDP in hardware need not change the API
behavior to the application nor modify any layer functionality.

The ability of SCTP to support many different higher level protocols comes
from the capability of SCTP to deliver objects unordered.  TCP's restriction
on ordered delivery mandates that any direct data placement is done prior to
TCP through the addition of a new and application unique layer between IP
and TCP.  The saving caveat has been that disclosure to TCP of these packets
are sequential but the application interface to TCP will change as a result
of this modification in some undefined way to associate the steering
information with the desired buffers.  This change impacts the interface
between this new layer, as well as the application and TCP.  The desire to
keep this DDP scheme for TCP proprietary will ensure a fractured market in
terms of hardware, OS services, and perhaps interchange not to mention that
each application then also needs unique hardware.  The security risks
involved in creating this new and highly complex layer below TCP is yet
unknown as details are lacking.  In essence, an attempt to implement DDP by
creating a new layer beneath TCP in a proprietary fashion is in direct
competition with the far better practice of using SCTP to implement DDP.

Doug

> Mallikarjun,
>
> I doubt that FIM (or COWS) will fracture the market.
> Hardware and software vendors will gain experience in what it takes to use
> framing.
> a specialized DDP and that could be useful later.  The first generation
> although not imperiously needing any framing (I have proposed not
> less than
> 3 solutions!) will enable us to get a better second generation if we do
> something in this area.
>
> Julo
>
> I share the concern about iSCSI embracing a framing mechanism that is
> not a MUST implement.  For all the reasons that Jim pointed out, OTOH,
> I am not recommending a MUST framing either.  I suspect not many will
> implement framing if it's a MAY, so it appears that we're talking about
> a potential SHOULD.
>
> Given that SHOULD is a fairly strong requirement, one "significant
> justification"
> for not doing framing could be (even while the NIC *may be* on the
> expensive side) -
>  - has less design complexity since no OOO placement.
>  - can have quicker TTM since less design, testing, debugging etc.
>
> I think ultimately it boils down to: how many vendors would use a
> "significant
> justfication" to not implement a SHOULD-requirement?
>
> If that's a majority: let's say vendor X is implementing
> (whatever) framing
> for
> optimizing the memory requirements, it essentially means that X's product
> will
> perform poorly with (the majority) no-framing senders.  I don't think X
> would
> like that, nor the customer.  IOW, this situation doesn't seem to be
> long-lasting.
> OTOH, the situation of an almost equal number of  "framing" and
> "no-framing"
> products in the market (perhaps at different price points) could be
> unfortunately
> long-lasting....
>
> To summarize, it is a troubling prospect that a framing technique (if
> adopted as
> SHOULD) has the potential to somewhat fracture the market and in effect
> create "interoperability problems" (of performance sort) similar to that
> affect
> FC....
> --
> Mallikarjun
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> Hewlett-Packard MS 5668
> Roseville CA 95747

--=_alternative 005DC6D5C2256B57_=-- From owner-ips@ece.cmu.edu Tue Feb 5 13:28: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 NAA12462 for ; Tue, 5 Feb 2002 13:28:59 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g15HoXK13014 for ips-outgoing; Tue, 5 Feb 2002 12:50:33 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from rdgxch01.nsmg.veritas.com (brooklyn-bridge.emea.veritas.com [62.172.234.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g15HoVj13010 for ; Tue, 5 Feb 2002 12:50:31 -0500 (EST) Received: by RDGXCH01 with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Feb 2002 17:50:27 -0000 Message-ID: <99794BDDB8F5D311A95000508B6B881D049096F2@RDGXCH01> From: Stuart Naisbitt To: "'Dan_McConnell@Dell.com'" , ips@ece.cmu.edu Subject: RE: iSCSI: iSNS Sever Reference implementation Date: Tue, 5 Feb 2002 17:50:17 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AE6D.92BBE420" 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_01C1AE6D.92BBE420 Content-Type: text/plain; charset="iso-8859-1" Hi Dan, I have been using their OpenSource reference implementation for the time being, it is available from Source Forge or the Nishan Website Stuart -----Original Message----- From: Dan_McConnell@Dell.com [mailto:Dan_McConnell@Dell.com] Sent: 05 February 2002 17:15 To: ips@ece.cmu.edu Subject: iSCSI: iSNS Sever Reference implementation I am curious what everyone's current thoughts are concerning a common reference implementation for the iSNS Server. Those that are implementing iSNS clients in their iSCSI HBAs, initiators, and targets, is there a "reference implementation" of the iSNS server that you have been testing with to ensure interoperability? Have you been developing your own? Are people using the Nishan iSNS implementations as reference implementations? BM__MailAutoSigThanks, Dan ------_=_NextPart_001_01C1AE6D.92BBE420 Content-Type: text/html; charset="iso-8859-1" iSCSI: iSNS Sever Reference implementation
Hi Dan,
 
I have been using their OpenSource reference implementation for the time being,
it is available from Source Forge or the Nishan Website
 
Stuart
-----Original Message-----
From: Dan_McConnell@Dell.com [mailto:Dan_McConnell@Dell.com]
Sent: 05 February 2002 17:15
To: ips@ece.cmu.edu
Subject: iSCSI: iSNS Sever Reference implementation

I am curious what everyone's current thoughts are concerning a common reference implementation for the iSNS Server.  Those that are implementing iSNS clients in their iSCSI HBAs, initiators, and targets, is there a "reference implementation" of the iSNS server that you have been testing with to ensure interoperability?  Have you been developing your own?  Are people using the Nishan iSNS implementations as reference implementations?

Thanks,

Dan

------_=_NextPart_001_01C1AE6D.92BBE420-- From owner-ips@ece.cmu.edu Tue Feb 5 13:32: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 NAA12701 for ; Tue, 5 Feb 2002 13:32:15 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g15HeCF12212 for ips-outgoing; Tue, 5 Feb 2002 12:40:12 -0500 (EST) 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 g15He9j12206 for ; Tue, 5 Feb 2002 12:40:10 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id E58C72E12; Tue, 5 Feb 2002 10:40:08 -0700 (MST) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id CAB1D170; Tue, 5 Feb 2002 10:40:08 -0700 (MST) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 05 Feb 2002 10:40:08 -0700 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Feb 2002 10:40:08 -0700 Message-ID: <01A7DAF31F93D511AEE300D0B706ED9201BF4704@axcs13.cos.agilent.com> From: "CAVANNA,VICENTE V (A-Roseville,ex1)" To: "'Ofer Biran'" Cc: Black_David@emc.com, marjorie_krueger@hp.com, ips@ece.cmu.edu, Paul Koning Subject: RE: IPsec Usage Question Date: Tue, 5 Feb 2002 10:40:07 -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 Ofer | |>This example MUST work. So you cannot require inner == outer |>address, because that translates into saying that IP Storage cannot be |>protected by a site to site IPsec tunnel. | |This is not Kansas any more... The iSCSI devices on both sites |(assuming |that's their only IPsec protection) are not iSCSI compliant. This |definitely |doesn't cover the IPsec protection mandated by iSCSI. | | Regards, | Ofer Could you elaborate on this. Why would such devices be in violation of the iSCSI spec? Thanks. Vince |-----Original Message----- |From: Ofer Biran [mailto:BIRAN@il.ibm.com] |Sent: Monday, February 04, 2002 9:30 PM |To: Paul Koning |Cc: Black_David@emc.com; marjorie_krueger@hp.com; ips@ece.cmu.edu |Subject: RE: IPsec Usage Question | | | |Paul, | |>This example MUST work. So you cannot require inner == outer |>address, because that translates into saying that IP Storage cannot be |>protected by a site to site IPsec tunnel. | |This is not Kansas any more... The iSCSI devices on both sites |(assuming |that's their only IPsec protection) are not iSCSI compliant. This |definitely |doesn't cover the IPsec protection mandated by iSCSI. | | Regards, | Ofer | | |Ofer Biran |Storage and Systems Technology |IBM Research Lab in Haifa |biran@il.ibm.com 972-4-8296253 | | |Paul Koning @ece.cmu.edu on 05/02/2002 00:17:54 | |Sent by: owner-ips@ece.cmu.edu | | |To: Black_David@emc.com |cc: marjorie_krueger@hp.com, ips@ece.cmu.edu |Subject: RE: IPsec Usage Question | | | |>>>>> "BlackG" == Black David writes: | | BlackG> AFAIK, IPsec has no standard or widely deployed mechanism for | BlackG> handling gateway discovery or address association | BlackG> dynamically. | |True. | |But let's consider a very common IPsec deployment scenario. I think |this is actually the predominant one, but let's not argue about that; |it certainly is quite common. | |Scenario: two sites, each with an IPsec gateway, and an IPsec tunnel |set up between the two sites. All traffic between the two sites goes |through the tunnel. (This is the classic IPsec based VPN scenario.) | |The way this is handled is simply by configuring the routing tables on |the two IPsec gateways to forward to the other site through the |tunnel. As far as the other nodes on the two sites is concerned, the |other site is simply reachable via ordinary IP mechanisms, and the |existence of the tunnel, or the addresses used in the outer headers, |are none of its concern. And of course the IP addresses of the inner |header cannot possibly equal those of the outer header in this |example. | |This example MUST work. So you cannot require inner == outer |address, because that translates into saying that IP Storage cannot be |protected by a site to site IPsec tunnel. | |Now for a different case: if you use tunnel mode to protect traffic |for a single node (a common case for laptops, so this is often called |the "road warrior" case) then it may well be useful to allow inner == |outer. Some road warrior OS types will want that, others don't care |so much, so it can be a simplifying approach. I have no objection at |all to saying that inner == outer is useful, and for that matter I can |go along with saying inner == outer should be supported. But, either |way, inner != outer must be supported. | | paul | | | | From owner-ips@ece.cmu.edu Tue Feb 5 13:40: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 NAA13059 for ; Tue, 5 Feb 2002 13:40:57 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g15HksF12689 for ips-outgoing; Tue, 5 Feb 2002 12:46:54 -0500 (EST) 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 g15Hkqj12683 for ; Tue, 5 Feb 2002 12:46:52 -0500 (EST) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id JAA21063; Tue, 5 Feb 2002 09:43:59 -0800 (PST) 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 JAA18779; Tue, 5 Feb 2002 09:27:05 -0800 (PST) Received: by aimexc07.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Feb 2002 09:42:45 -0800 Message-ID: From: "Mukund, Shridhar" To: "'ERICKSON,SHAWN (HP-Roseville,ex1)'" , ips@ece.cmu.edu Subject: RE: iSCSI: No Framing Date: Tue, 5 Feb 2002 09:42:37 -0800 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 Shawn, We would love to sell FIM enabled HBA's to you :-) -Shridhar Mukund -----Original Message----- From: ERICKSON,SHAWN (HP-Roseville,ex1) [mailto:shawn_erickson@hp.com] Sent: Tuesday, February 05, 2002 8:01 AM To: ips@ece.cmu.edu Subject: RE: iSCSI: No Framing Not trying to be obtuse but how does it help if only the NIC vendors implement it? (I know you didn't precisely say that) It sounds like we may end up with NIC vendors implementing it and storage vendors ignoring it or some mix. In the end we will have a fracture in the market place and/or all vendors will be forced to implement FIM to satisfy customer demands ("my NIC supports FIMs, you don't, things are SLOW, you must be at fault", etc.). To me it sounds like FIMs needs to be SHOULD/MUST or not in the standard at all (moved to a secondary document). I personally would like to see FIM (and COWS) moved from the standard to a secondary document but that is just my gut level opinion on this issue. I do think FIM blurs the layering of TCP/IP, which is not normally desirable. Regardless it would be worthwhile for a document describing how to fire iSCSI over SCTP or other IP backed transports that are better suited for iSCSI style data and high speed/long distance links. (Please excuse my ignorance is such drafts already exist) -Shawn ------------------------------------------------------- Shawn Carl Erickson > -----Original Message----- > From: Jim Pinkerton [mailto:jpink@microsoft.com] > Sent: Tuesday, February 05, 2002 6:53 AM > To: John Hufferd; somesh_gupta@silverbacksystems.com > Cc: Mukund, Shridhar; ips@ece.cmu.edu > Subject: RE: iSCSI: No Framing > > > > In reviewing the mail alias, and after having many conversations with > various folks, I would like to retract my prior opinion on ripping out > markers. It appears to me as though _every_ NIC vendor is in > support of > markers. > > To me the evidence in support of keeping in "Sync and Steering with > Fixed Interval Markers" is pretty compelling (now that I've been > re-educated). Without going into proprietary issues - how often do NIC > vendors agree unanimously on something? Also, a software > implementation > of markers is tractable. > > I have not heard a single NIC vendor in support of COWS, and I > personally don't support COWS either. Thus I would recommend that COWS > be "ripped out". > > > Jim From owner-ips@ece.cmu.edu Tue Feb 5 14:50: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 OAA16293 for ; Tue, 5 Feb 2002 14:50:12 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g15IxiG18662 for ips-outgoing; Tue, 5 Feb 2002 13:59:44 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c003.snv.cp.net (c003-h015.c003.snv.cp.net [209.228.32.229]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g15Ixgj18658 for ; Tue, 5 Feb 2002 13:59:42 -0500 (EST) Received: (cpmta 12302 invoked from network); 5 Feb 2002 10:59:35 -0800 Received: from 64.130.130.105 (HELO dougrmt) by smtp.telocity.com (209.228.32.229) with SMTP; 5 Feb 2002 10:59:35 -0800 X-Sent: 5 Feb 2002 18:59:35 GMT From: "Douglas Otis" To: Cc: "Tsvwg" Subject: RE: iSCSI: No Framing Date: Tue, 5 Feb 2002 11:01:22 -0800 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, Discussion regarding the concept of framing using FIM within iSCSI is a valid topic at this time. I disagree strongly with your statement about the market not becoming fractured. With this topic to be decided shortly, now is my opportunity to speak. A generalized scheme for implementing DDP is relevant as opposed to one that is proprietary and application specific. Yes, I know it is using the four letter word SCTP. There is about to be a document released illustrating DDP using SCTP. It removes the application specific nature of this endeavor and does not impact existing TCP implementations or network layering. SCTP provides a far superior solution when attempting Direct Data Placement, the rational for FIM within iSCSI. iSCSI APIs need not change to introduce SCTP as an alternative transport if implementing this DDP feature in the future. To prevent fracturing of the market and creating standards competition within IETF, FIM should be removed from the iSCSI draft. Transition to SCTP for this feature and do not add layers to TCP. Doug David, Dough is continuing his rumblings - whether they are relevant to us or not. I wonder if there is some administrative measure you can take to save us some bandwidth or we should install our own "Otis filters". Julo Julian, Implementing a scheme for doing direct data placement by means of an application specific, undocumented or proprietary layer below TCP will fracture the market. This will result in an unacceptable outcome having hardware created for each application, limited by various vendors making as yet unknown claims, if implementing the DDP feature using TCP. In the future, should this feature become desired, iSCSI can adopt a generic method that is possible through the use of SCTP. An eventual adoption of SCTP would also simplify much of the existing complexity found with the multi-connection TCP standard now proposed for iSCSI. Use of SCTP would allow common hardware for many protocols desiring Direct Data Placement without modification of the SCTP transport as it can deliver objects unordered. A shim providing the DDP feature could ensure objects are disclosed in the order sent if desired, independent of the reception at the shim while not modifying SCTP or adding layers beneath this transport as would be required for TCP. Only when constrained to conventional memory allocation, does DDP become beneficial. The concept of placing a layer beneath TCP that structures an array to hold each individual packet based on application specific structures is fundamentally flawed. This presumes the layer beneath TCP knows before hand the content of the byte stream prior to TCP composing the stream. This lower layer will also need to create exceptions for handling duplicates, for placement information not aligned with the TCP segment, and for application informational errors. SCTP can easily avoid these exceptional cases making such development less disruptive. In addition, an SCTP stack that does not offer DDP in hardware need not change the API behavior to the application nor modify any layer functionality. The ability of SCTP to support many different higher level protocols comes from the capability of SCTP to deliver objects unordered. TCP's restriction on ordered delivery mandates that any direct data placement is done prior to TCP through the addition of a new and application unique layer between IP and TCP. The saving caveat has been that disclosure to TCP of these packets are sequential but the application interface to TCP will change as a result of this modification in some undefined way to associate the steering information with the desired buffers. This change impacts the interface between this new layer, as well as the application and TCP. The desire to keep this DDP scheme for TCP proprietary will ensure a fractured market in terms of hardware, OS services, and perhaps interchange not to mention that each application then also needs unique hardware. The security risks involved in creating this new and highly complex layer below TCP is yet unknown as details are lacking. In essence, an attempt to implement DDP by creating a new layer beneath TCP in a proprietary fashion is in direct competition with the far better practice of using SCTP to implement DDP. Doug From owner-ips@ece.cmu.edu Tue Feb 5 14: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 OAA16351 for ; Tue, 5 Feb 2002 14:51:14 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g15IQXc15977 for ips-outgoing; Tue, 5 Feb 2002 13:26:33 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from demetrius.hosting.pacbell.net (demetrius.hosting.pacbell.net [216.100.99.31]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g15IQUj15971 for ; Tue, 5 Feb 2002 13:26:31 -0500 (EST) Received: from somesh ([65.172.158.93]) by demetrius.hosting.pacbell.net id NAA23249; Tue, 5 Feb 2002 13:25:45 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Reply-To: From: "Somesh Gupta" To: "Jim Pinkerton" , "John Hufferd" Cc: "Mukund, Shridhar" , Subject: RE: iSCSI: No Framing Date: Tue, 5 Feb 2002 10:25:45 -0800 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <24A715275661C8428C00432EFCA5CB7C055F9B61@red-msg-02.redmond.corp.microsoft.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jim, > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Jim Pinkerton > Sent: Tuesday, February 05, 2002 6:53 AM > To: John Hufferd; somesh_gupta@silverbacksystems.com > Cc: Mukund, Shridhar; ips@ece.cmu.edu > Subject: RE: iSCSI: No Framing > > > > In reviewing the mail alias, and after having many conversations with > various folks, I would like to retract my prior opinion on ripping out > markers. It appears to me as though _every_ NIC vendor is in support of > markers. Every NIC vendor may implement markers (or as is obvious from interoperability results, may have the capability to implement markers). On whether every (person who works at a) NIC/Chip vendor supports it from a technical perspective (i.e. whether it solves anything, or is a useful solution, or whether the analysis people are using is correct) supports it, I think the count seems to be evenly split. > > To me the evidence in support of keeping in "Sync and Steering with > Fixed Interval Markers" is pretty compelling (now that I've been > re-educated). Without going into proprietary issues - how often do NIC > vendors agree unanimously on something? Also, a software implementation > of markers is tractable. > > I have not heard a single NIC vendor in support of COWS, and I > personally don't support COWS either. Thus I would recommend that COWS > be "ripped out". > > > Jim > Julian indicates in his message that we are not really sure what a good solution is and if we put something in, we are likely to get to a better one in the second draft. I also concur that the whole problem/solution space is experimental in nature, and ought to be treated as such. I think it is meaningless to assume that one person or another has a magic solution here. The problems are fairly well understood. One can talk about it from an algorithmic perspective (like error recovery) which will expose some of the assumptions/compromises behind this. Of course, whether that will pass muster with the community at large is another issue. > > > > -----Original Message----- > From: John Hufferd [mailto:hufferd@us.ibm.com] > Sent: Friday, February 01, 2002 11:31 PM > To: somesh_gupta@silverbacksystems.com > Cc: Mukund, Shridhar; ips@ece.cmu.edu > Subject: RE: iSCSI: No Framing > > > Somesh, > This is not fair, we asked for Chip Vendors that were planning on using > it, > to make themselves known and to tell us why. Without exposing internal > designs, he has tried to do that, likewise Trebia, and some others have > said they want FIMs. You may not want FIMs for your design, but you > should > respect these folks that have been following our spec and found it to be > valuable in their designs. They are putting their money on it not just > talk, so we should at least give them the credit which their position > deserves. Yes, of course they are disappointed with the rhetoric around > this issue, since they and others have been following the spec, and can > not > understand why others haven't, since they have determined it to be of > significant value. > > His note does speak to the issues. (And clearly has some silly parts :-) > > In fact he has found it of enough value to use now, since he believes > they > can not wait for iWARP to happen before the issue is addressed (and he > really wants iWARP). It should be useful to listen to folks that are > willing to put their money where their mouth is. > > OK, that said: don't you think we can find a way to address both your > position and their position, since they both seem strong and heart felt. > I > would think that the "Should Implement" or at least "May Implement" > would > give both sides enough reasonable room to meet on an even business > plane. > > > . > . > . > 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 > > > "Somesh Gupta" @ece.cmu.edu on > 02/01/2002 07:10:13 PM > > Please respond to > > Sent by: owner-ips@ece.cmu.edu > > > To: "Mukund, Shridhar" , "'WENDT,JIM > \(HP-Roseville,ex1\)'" , > cc: > Subject: RE: iSCSI: No Framing > > > > Mukund, > > With all due respect, taking on the mantle of > the noble engineer being denied by politically > motivated people, belittles the technical expertise > and strengths of the people who have expressed an > opinion against having any of the proposed schemes > at this time in the spec. > > I would be very happy to work alongside a number of > the people on both sides of the issue (and that does > include you). > > None of your arguments below refutes the technical > and some non-technical opinions expressed against > FIM. > > Somesh > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Mukund, Shridhar > > Sent: Friday, February 01, 2002 5:24 PM > > To: 'WENDT,JIM (HP-Roseville,ex1)'; ips@ece.cmu.edu > > Subject: RE: iSCSI: No Framing > > > > > > Dear Colleagues, > > > > PART 1 of 3 : > > > > The pertinent points that "I" see in Jim's email are: > > > > A. Need to hear from iSCSI chip implementers ... > > The issues that you raise for e.g. in #2 are simply > > circumstantial( See PART 2 ). Answers to those questions > > unnecessarily call for data flows and implementation > > details that silicon vendors are not allowed to share > > in public. While I do not know of many silicon vendors > > in the multi gig space, clearly one of the competitions > > I respect, namely Trebia, point to FIM as well. Granted, > > no matter what, we are going to see several > > trebia-on-the-other-end and adaptec-on-the-other-end > > type of cost optimizations. > > > > B. The iWARP/TUF/SCTP under-current ... > > The "only" message of significance in Jim's email is #5. > > It seems like the iWARP/SCTP/TUF enthusiasts somehow feel > > threatened that FIM-iSCSI will dilute the perceived value > > proposition of iWARP :-) I for one am an enthusiast of > > iWARP ideals myself, barring the proposed mechanics. I > > would love to make a buck or two along with you in > > building iWARP NICs, "at the right time". In the > > meanwhile, iSCSI is the flag ship effort that has the > > unique opportunity to make a dent in enabling IP Storage > > visions. ( See PART 3 ) > > > > My assertions are : > > i) TUF/SCTP/iWARP is ruled out in the near term. The > > mechanics are unclear as hell. > > ii) FIM is the least intrusive, TCP transparent, means for > > enabling low-cost(power,b/w,latency,memory,space,CPU) > > RDMA transport of bulk data. > > iii) I do not see significant technical reasons that > > merit major changes to the iSCSI draft at this late > > date. > > iii) Making it OPTIONAL to use, and SHOULD only on send > > provides a graceful and incremental deployment path > > for "real":-) providers and users to succeed. > > > > I have personally contributed nothing to the iSCSI effort > > and do applaud the pains that several of you are taking to > > pull it all together. In that very same spirit, I respect > > David's decision w.r.t. consensus, whatever that turns out > > to be. > > > > Thanks. > > > > -Shridhar Mukund + Todd Sperry, Siva Munnangi, Dev ... > > > > ------------------------------------------------------------ > > PART 2 of 3 : MUST delete, SHOULD read > > > > Dear Jim, > > > > Congratulations Jim! Seems like when you bowl, pins > > roll, unintentional as they may be. You make a "seemingly" > > well balanced set of arguments and "tactfully" tilt the > > balance towards your chosen side. I would love to be on > > your side ... maybe in another effort :-) > > > > I would like to introduce you to my respectable friend, > > who "vehemently" contradicts you on all accounts. One of > > his numerous quotes goes as follows: > > http://groups.yahoo.com/group/rdma/message/486 > > "Much of today's usage of the Internet and IP networks > > is for buffer-to-buffer data transfers, often in the > > form of bulk data ... Gigabit and faster network transfers > > incur 'heavy' system resource costs, including both CPU > > use and system bus bandwidth, particularly on the > > receiving side ... The costs incurred on hosts for protocol > > processing and management has 'inhibited' the use of IP > > in the high speed bulk data domain. ... Bulk data transfer > > is dominated by the costs of copying and validating > > incoming data in order to place it at its ultimate > > destination." > > > > The good friend I quote above is none other than Jim > > Wendt himself!!! I REST MY CASE. > > > > Thanks. > > > > -Shridhar Mukund > > > > ---------------------------------------------------------------- > > PART 3 of 3: MUST delete, OPTIONAL read > > > > On the lighter side ... since the opponents have "no" technical > > arguments whatsoever against FIM and it is all turning out to > > be a pure political gimmick, I will put on my rusting tin > > politician hat :-) > > > > My dear fellow iSCSI country (wo)men: If our goals are anything > > short of enabling the HP's, Cisco's, uSoft's, IBM's and EMC's of > > the world in globalization of storage for McDonald's and Macy's > > from Kabul to Somalia, via iSCSI, we have lost our identity! > > ( \insert APPLAUSE for 13 seconds )We are no more protected by > > the vast oceans between us and other Storage efforts. The > > freedom of iSCSI America is threatened from within by elements > > who will not blink twice when it comes to using the world's most > > potent BOO-bombs ... and grinnn while we end up sifting through > > the rubbles for iSCSI, youSCSI and theySCSI. > > ( \insert APPLAUSE for 11 seconds ) Beware of the elements that > > sleep with "our" very ideals in their privacy(burkha clad > > though) and yet attempt to destabilize us, only to accomplish > > their mutated agenda.( \insert APPLAUSE for 57 seconds ) > > > > No offense folks. I respect each and every one of you and > > especially Jim. I think that he was only attempting to > > question, "are we sure ... should we commit ...". > > I disagree with him anyway! > > > > - the running(actually limping) mate :-) :-) :-) > > > > -----Original Message----- > > From: WENDT,JIM (HP-Roseville,ex1) [mailto:jim_wendt@hp.com] > > Sent: Tuesday, January 29, 2002 10:47 PM > > To: ips@ece.cmu.edu > > Subject: iSCSI: No Framing > > > > > > Perhaps we should discuss the possibility of not > > specifying any framing mechanism (FIM or COWS) in the > > first version of iSCSI. > > > > The arguments for not specifying framing include > > (there may be others as well): > > 1) The brute force approach of putting TCP receiver > > reassembly memory on the iSCSI NIC will work for both > > 1Gbps and 10Gbps. Cost is incurred for memory chips, > > ASIC pins, power, and board space. But, it is a > > feasible approach. > > > > 2) I/O bus latency (or bandwidth limitations) could > > mandate inbound buffering (as a 'smoothing' buffer) > > from the iSCSI NIC to the host system. If this buffer > > memory is large enough to have to be off-chip, then > > it will require some minimum number of memory chips > > to provide the necessary bandwidth, and the > > memory/pins/power/space costs will be incurred > > anyway. > > > > 3) Very large receive buffering on the NIC is only > > required for high-bandwidth links traversing large > > geographic distances (which may not be the > > predominate case). These specialized implementations > > can cost more (e.g. more memory/power/pins/etc) and > > customers will likely be willing to pay accordingly. > > > > 4) Many NICs will likely aspire to be combo > > iSCSI+TOE+Ethernet NICs allowing the host system to > > use a single Ethernet port for all of its network > > communications. The TOE function on this combo NIC > > will already require TCP receive buffering and off- > > chip buffer memory to support the existing sockets > > interface receive model. More importantly, to allow > > senders to assume ownership of the buffer upon return > > from a socket send call, the TOE NIC would need to > > copy application send buffers into NIC memory as > > well. > > > > 5) The framing/marker mechanism will be an iSCSI-only > > solution. It is quite possible that the problem will > > be solved via a different, and hopefully more > > general, mechanism for other ULPs. > > > > 6) Both FIM and COWS are poor solutions for software > > implementation. COWS requires, at a minimum, the > > sender to read every word in the buffer. FIM either > > imposes additional sender gather processing (iovecs) > > or requires a data buffer copy (on systems that don't > > support HW gather on sends). > > > > 7) Unless all senders thoroughly test framing/markers > > now (i.e. unless the framing method is a MUST > > implement), there is potential for future > > interoperability problems as framing/marker receivers > > are deployed in the future. > > > > 8) Neither FIM nor COWS is an elegant solution. Are > > we comfortable with the legacy we are creating under > > the umbrella of state-of-the-art IP networked > > storage? > > > > 9) Is it essential to build in forward compatibility > > now, or will there be a different solution in the > > 10Gbps or 40Gbps timeframe - perhaps involving iSCSI- > > 2? Will it be reasonable to update or bridge initial > > 1Gbps deployments? > > > > > > So, it would be good to hear from several iSCSI > > NIC/chip implementors who: > > - have or plan to implement FIM or COWS (or some > > other framing mechanism) and take advantage of it to > > minimize demands on on-NIC buffer memory > > bandwidth/quantity. > > - believe that all-buffers-on-chip solutions are > > feasible and valid (wrt the points above, including > > #2) > > - can quantify the memory/pin/power/space cost > > savings for all-buffers-on-chip solutions > > > > Jim > > > > > > From owner-ips@ece.cmu.edu Tue Feb 5 15:01: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 PAA16912 for ; Tue, 5 Feb 2002 15:01:53 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g15J1SP18830 for ips-outgoing; Tue, 5 Feb 2002 14:01:28 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ariel.nishansystems.com (goretex.nishansystems.com [216.217.36.167]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g15J1Qj18823 for ; Tue, 5 Feb 2002 14:01:26 -0500 (EST) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Feb 2002 11:00:43 -0800 Message-ID: From: Kevin Gibbons To: "'Dan_McConnell@Dell.com'" Cc: ips@ece.cmu.edu Subject: RE: iSCSI: iSNS Sever Reference implementation Date: Tue, 5 Feb 2002 11:00:33 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AE77.634E6D70" 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_01C1AE77.634E6D70 Content-Type: text/plain; charset="iso-8859-1" Dan, there is an open source reference implementation at Source Forge, and at the Nishan Systems web site. However, some companies are developing/testing with their own iSNS server implementation and not using the one developed at Nishan Systems. Longer term I would assume that the server would be available from multiple sources. Regards, Kevin -----Original Message----- From: Dan_McConnell@Dell.com [mailto:Dan_McConnell@Dell.com] Sent: Tuesday, February 05, 2002 9:15 AM To: ips@ece.cmu.edu Subject: iSCSI: iSNS Sever Reference implementation I am curious what everyone's current thoughts are concerning a common reference implementation for the iSNS Server. Those that are implementing iSNS clients in their iSCSI HBAs, initiators, and targets, is there a "reference implementation" of the iSNS server that you have been testing with to ensure interoperability? Have you been developing your own? Are people using the Nishan iSNS implementations as reference implementations? BM__MailAutoSigThanks, Dan ------_=_NextPart_001_01C1AE77.634E6D70 Content-Type: text/html; charset="iso-8859-1" iSCSI: iSNS Sever Reference implementation
Dan,
    there is an open source reference implementation at Source Forge, and at the Nishan Systems web site.  However, some companies are developing/testing with their own iSNS server implementation and not using the one developed at Nishan Systems.  Longer term I would assume that the server would be available from multiple sources.
    Regards, Kevin
-----Original Message-----
From: Dan_McConnell@Dell.com [mailto:Dan_McConnell@Dell.com]
Sent: Tuesday, February 05, 2002 9:15 AM
To: ips@ece.cmu.edu
Subject: iSCSI: iSNS Sever Reference implementation

I am curious what everyone's current thoughts are concerning a common reference implementation for the iSNS Server.  Those that are implementing iSNS clients in their iSCSI HBAs, initiators, and targets, is there a "reference implementation" of the iSNS server that you have been testing with to ensure interoperability?  Have you been developing your own?  Are people using the Nishan iSNS implementations as reference implementations?

Thanks,

Dan

------_=_NextPart_001_01C1AE77.634E6D70-- From owner-ips@ece.cmu.edu Tue Feb 5 15:06: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 PAA17127 for ; Tue, 5 Feb 2002 15:06:27 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g15IxjG18665 for ips-outgoing; Tue, 5 Feb 2002 13:59:45 -0500 (EST) 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 g15Ixcj18653 for ; Tue, 5 Feb 2002 13:59:38 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.99.140.22]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA27058; Tue, 5 Feb 2002 13:56:25 -0500 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay01.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g15IxVI78100; Tue, 5 Feb 2002 11:59:31 -0700 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: No Framing To: Cc: "Jim Pinkerton" , "Mukund, Shridhar" , X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Tue, 5 Feb 2002 10:55:18 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 02/05/2002 11:59:30 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Somesh, I usually give higher weight to the opinions of folks that take their opinions and put their money on it, than the folks that do not. So I am not sure you can so easily dismiss the ideas of folks that are committed with actual money. . . . 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 "Somesh Gupta" on 02/05/2002 10:25:45 AM Please respond to To: "Jim Pinkerton" , John Hufferd/San Jose/IBM@IBMUS cc: "Mukund, Shridhar" , Subject: RE: iSCSI: No Framing Jim, > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Jim Pinkerton > Sent: Tuesday, February 05, 2002 6:53 AM > To: John Hufferd; somesh_gupta@silverbacksystems.com > Cc: Mukund, Shridhar; ips@ece.cmu.edu > Subject: RE: iSCSI: No Framing > > > > In reviewing the mail alias, and after having many conversations with > various folks, I would like to retract my prior opinion on ripping out > markers. It appears to me as though _every_ NIC vendor is in support of > markers. Every NIC vendor may implement markers (or as is obvious from interoperability results, may have the capability to implement markers). On whether every (person who works at a) NIC/Chip vendor supports it from a technical perspective (i.e. whether it solves anything, or is a useful solution, or whether the analysis people are using is correct) supports it, I think the count seems to be evenly split. > > To me the evidence in support of keeping in "Sync and Steering with > Fixed Interval Markers" is pretty compelling (now that I've been > re-educated). Without going into proprietary issues - how often do NIC > vendors agree unanimously on something? Also, a software implementation > of markers is tractable. > > I have not heard a single NIC vendor in support of COWS, and I > personally don't support COWS either. Thus I would recommend that COWS > be "ripped out". > > > Jim > Julian indicates in his message that we are not really sure what a good solution is and if we put something in, we are likely to get to a better one in the second draft. I also concur that the whole problem/solution space is experimental in nature, and ought to be treated as such. I think it is meaningless to assume that one person or another has a magic solution here. The problems are fairly well understood. One can talk about it from an algorithmic perspective (like error recovery) which will expose some of the assumptions/compromises behind this. Of course, whether that will pass muster with the community at large is another issue. > > > > -----Original Message----- > From: John Hufferd [mailto:hufferd@us.ibm.com] > Sent: Friday, February 01, 2002 11:31 PM > To: somesh_gupta@silverbacksystems.com > Cc: Mukund, Shridhar; ips@ece.cmu.edu > Subject: RE: iSCSI: No Framing > > > Somesh, > This is not fair, we asked for Chip Vendors that were planning on using > it, > to make themselves known and to tell us why. Without exposing internal > designs, he has tried to do that, likewise Trebia, and some others have > said they want FIMs. You may not want FIMs for your design, but you > should > respect these folks that have been following our spec and found it to be > valuable in their designs. They are putting their money on it not just > talk, so we should at least give them the credit which their position > deserves. Yes, of course they are disappointed with the rhetoric around > this issue, since they and others have been following the spec, and can > not > understand why others haven't, since they have determined it to be of > significant value. > > His note does speak to the issues. (And clearly has some silly parts :-) > > In fact he has found it of enough value to use now, since he believes > they > can not wait for iWARP to happen before the issue is addressed (and he > really wants iWARP). It should be useful to listen to folks that are > willing to put their money where their mouth is. > > OK, that said: don't you think we can find a way to address both your > position and their position, since they both seem strong and heart felt. > I > would think that the "Should Implement" or at least "May Implement" > would > give both sides enough reasonable room to meet on an even business > plane. > > > . > . > . > 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 > > > "Somesh Gupta" @ece.cmu.edu on > 02/01/2002 07:10:13 PM > > Please respond to > > Sent by: owner-ips@ece.cmu.edu > > > To: "Mukund, Shridhar" , "'WENDT,JIM > \(HP-Roseville,ex1\)'" , > cc: > Subject: RE: iSCSI: No Framing > > > > Mukund, > > With all due respect, taking on the mantle of > the noble engineer being denied by politically > motivated people, belittles the technical expertise > and strengths of the people who have expressed an > opinion against having any of the proposed schemes > at this time in the spec. > > I would be very happy to work alongside a number of > the people on both sides of the issue (and that does > include you). > > None of your arguments below refutes the technical > and some non-technical opinions expressed against > FIM. > > Somesh > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Mukund, Shridhar > > Sent: Friday, February 01, 2002 5:24 PM > > To: 'WENDT,JIM (HP-Roseville,ex1)'; ips@ece.cmu.edu > > Subject: RE: iSCSI: No Framing > > > > > > Dear Colleagues, > > > > PART 1 of 3 : > > > > The pertinent points that "I" see in Jim's email are: > > > > A. Need to hear from iSCSI chip implementers ... > > The issues that you raise for e.g. in #2 are simply > > circumstantial( See PART 2 ). Answers to those questions > > unnecessarily call for data flows and implementation > > details that silicon vendors are not allowed to share > > in public. While I do not know of many silicon vendors > > in the multi gig space, clearly one of the competitions > > I respect, namely Trebia, point to FIM as well. Granted, > > no matter what, we are going to see several > > trebia-on-the-other-end and adaptec-on-the-other-end > > type of cost optimizations. > > > > B. The iWARP/TUF/SCTP under-current ... > > The "only" message of significance in Jim's email is #5. > > It seems like the iWARP/SCTP/TUF enthusiasts somehow feel > > threatened that FIM-iSCSI will dilute the perceived value > > proposition of iWARP :-) I for one am an enthusiast of > > iWARP ideals myself, barring the proposed mechanics. I > > would love to make a buck or two along with you in > > building iWARP NICs, "at the right time". In the > > meanwhile, iSCSI is the flag ship effort that has the > > unique opportunity to make a dent in enabling IP Storage > > visions. ( See PART 3 ) > > > > My assertions are : > > i) TUF/SCTP/iWARP is ruled out in the near term. The > > mechanics are unclear as hell. > > ii) FIM is the least intrusive, TCP transparent, means for > > enabling low-cost(power,b/w,latency,memory,space,CPU) > > RDMA transport of bulk data. > > iii) I do not see significant technical reasons that > > merit major changes to the iSCSI draft at this late > > date. > > iii) Making it OPTIONAL to use, and SHOULD only on send > > provides a graceful and incremental deployment path > > for "real":-) providers and users to succeed. > > > > I have personally contributed nothing to the iSCSI effort > > and do applaud the pains that several of you are taking to > > pull it all together. In that very same spirit, I respect > > David's decision w.r.t. consensus, whatever that turns out > > to be. > > > > Thanks. > > > > -Shridhar Mukund + Todd Sperry, Siva Munnangi, Dev ... > > > > ------------------------------------------------------------ > > PART 2 of 3 : MUST delete, SHOULD read > > > > Dear Jim, > > > > Congratulations Jim! Seems like when you bowl, pins > > roll, unintentional as they may be. You make a "seemingly" > > well balanced set of arguments and "tactfully" tilt the > > balance towards your chosen side. I would love to be on > > your side ... maybe in another effort :-) > > > > I would like to introduce you to my respectable friend, > > who "vehemently" contradicts you on all accounts. One of > > his numerous quotes goes as follows: > > http://groups.yahoo.com/group/rdma/message/486 > > "Much of today's usage of the Internet and IP networks > > is for buffer-to-buffer data transfers, often in the > > form of bulk data ... Gigabit and faster network transfers > > incur 'heavy' system resource costs, including both CPU > > use and system bus bandwidth, particularly on the > > receiving side ... The costs incurred on hosts for protocol > > processing and management has 'inhibited' the use of IP > > in the high speed bulk data domain. ... Bulk data transfer > > is dominated by the costs of copying and validating > > incoming data in order to place it at its ultimate > > destination." > > > > The good friend I quote above is none other than Jim > > Wendt himself!!! I REST MY CASE. > > > > Thanks. > > > > -Shridhar Mukund > > > > ---------------------------------------------------------------- > > PART 3 of 3: MUST delete, OPTIONAL read > > > > On the lighter side ... since the opponents have "no" technical > > arguments whatsoever against FIM and it is all turning out to > > be a pure political gimmick, I will put on my rusting tin > > politician hat :-) > > > > My dear fellow iSCSI country (wo)men: If our goals are anything > > short of enabling the HP's, Cisco's, uSoft's, IBM's and EMC's of > > the world in globalization of storage for McDonald's and Macy's > > from Kabul to Somalia, via iSCSI, we have lost our identity! > > ( \insert APPLAUSE for 13 seconds )We are no more protected by > > the vast oceans between us and other Storage efforts. The > > freedom of iSCSI America is threatened from within by elements > > who will not blink twice when it comes to using the world's most > > potent BOO-bombs ... and grinnn while we end up sifting through > > the rubbles for iSCSI, youSCSI and theySCSI. > > ( \insert APPLAUSE for 11 seconds ) Beware of the elements that > > sleep with "our" very ideals in their privacy(burkha clad > > though) and yet attempt to destabilize us, only to accomplish > > their mutated agenda.( \insert APPLAUSE for 57 seconds ) > > > > No offense folks. I respect each and every one of you and > > especially Jim. I think that he was only attempting to > > question, "are we sure ... should we commit ...". > > I disagree with him anyway! > > > > - the running(actually limping) mate :-) :-) :-) > > > > -----Original Message----- > > From: WENDT,JIM (HP-Roseville,ex1) [mailto:jim_wendt@hp.com] > > Sent: Tuesday, January 29, 2002 10:47 PM > > To: ips@ece.cmu.edu > > Subject: iSCSI: No Framing > > > > > > Perhaps we should discuss the possibility of not > > specifying any framing mechanism (FIM or COWS) in the > > first version of iSCSI. > > > > The arguments for not specifying framing include > > (there may be others as well): > > 1) The brute force approach of putting TCP receiver > > reassembly memory on the iSCSI NIC will work for both > > 1Gbps and 10Gbps. Cost is incurred for memory chips, > > ASIC pins, power, and board space. But, it is a > > feasible approach. > > > > 2) I/O bus latency (or bandwidth limitations) could > > mandate inbound buffering (as a 'smoothing' buffer) > > from the iSCSI NIC to the host system. If this buffer > > memory is large enough to have to be off-chip, then > > it will require some minimum number of memory chips > > to provide the necessary bandwidth, and the > > memory/pins/power/space costs will be incurred > > anyway. > > > > 3) Very large receive buffering on the NIC is only > > required for high-bandwidth links traversing large > > geographic distances (which may not be the > > predominate case). These specialized implementations > > can cost more (e.g. more memory/power/pins/etc) and > > customers will likely be willing to pay accordingly. > > > > 4) Many NICs will likely aspire to be combo > > iSCSI+TOE+Ethernet NICs allowing the host system to > > use a single Ethernet port for all of its network > > communications. The TOE function on this combo NIC > > will already require TCP receive buffering and off- > > chip buffer memory to support the existing sockets > > interface receive model. More importantly, to allow > > senders to assume ownership of the buffer upon return > > from a socket send call, the TOE NIC would need to > > copy application send buffers into NIC memory as > > well. > > > > 5) The framing/marker mechanism will be an iSCSI-only > > solution. It is quite possible that the problem will > > be solved via a different, and hopefully more > > general, mechanism for other ULPs. > > > > 6) Both FIM and COWS are poor solutions for software > > implementation. COWS requires, at a minimum, the > > sender to read every word in the buffer. FIM either > > imposes additional sender gather processing (iovecs) > > or requires a data buffer copy (on systems that don't > > support HW gather on sends). > > > > 7) Unless all senders thoroughly test framing/markers > > now (i.e. unless the framing method is a MUST > > implement), there is potential for future > > interoperability problems as framing/marker receivers > > are deployed in the future. > > > > 8) Neither FIM nor COWS is an elegant solution. Are > > we comfortable with the legacy we are creating under > > the umbrella of state-of-the-art IP networked > > storage? > > > > 9) Is it essential to build in forward compatibility > > now, or will there be a different solution in the > > 10Gbps or 40Gbps timeframe - perhaps involving iSCSI- > > 2? Will it be reasonable to update or bridge initial > > 1Gbps deployments? > > > > > > So, it would be good to hear from several iSCSI > > NIC/chip implementors who: > > - have or plan to implement FIM or COWS (or some > > other framing mechanism) and take advantage of it to > > minimize demands on on-NIC buffer memory > > bandwidth/quantity. > > - believe that all-buffers-on-chip solutions are > > feasible and valid (wrt the points above, including > > #2) > > - can quantify the memory/pin/power/space cost > > savings for all-buffers-on-chip solutions > > > > Jim > > > > > > From owner-ips@ece.cmu.edu Tue Feb 5 15:47: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 PAA18737 for ; Tue, 5 Feb 2002 15:47:47 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g15JLNZ20295 for ips-outgoing; Tue, 5 Feb 2002 14:21:23 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from demetrius.hosting.pacbell.net (demetrius.hosting.pacbell.net [216.100.99.31]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g15JLFj20284 for ; Tue, 5 Feb 2002 14:21:15 -0500 (EST) Received: from somesh ([65.172.158.93]) by demetrius.hosting.pacbell.net id OAA22785; Tue, 5 Feb 2002 14:20:35 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Reply-To: From: "Somesh Gupta" To: "John Hufferd" Cc: "Jim Pinkerton" , "Mukund, Shridhar" , Subject: RE: iSCSI: No Framing Date: Tue, 5 Feb 2002 11:20:34 -0800 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit John, I have to point for the record, that I was the one that proposed markers over a year ago (not that many other did not also have this idea). I have also tried to keep this debate at a technical level. There are reasonable folks on both sides of the debate, and we should just continue in that spirit. Somesh > -----Original Message----- > From: John Hufferd [mailto:hufferd@us.ibm.com] > Sent: Tuesday, February 05, 2002 10:55 AM > To: somesh_gupta@silverbacksystems.com > Cc: Jim Pinkerton; Mukund, Shridhar; ips@ece.cmu.edu > Subject: RE: iSCSI: No Framing > > > > Somesh, > I usually give higher weight to the opinions of folks that take their > opinions and put their money on it, than the folks that do not. So I am > not sure you can so easily dismiss the ideas of folks that are committed > with actual money. > > . > . > . > 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 > > > "Somesh Gupta" on 02/05/2002 10:25:45 > AM > > Please respond to > > To: "Jim Pinkerton" , John Hufferd/San > Jose/IBM@IBMUS > cc: "Mukund, Shridhar" , > Subject: RE: iSCSI: No Framing > > > > Jim, > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Jim Pinkerton > > Sent: Tuesday, February 05, 2002 6:53 AM > > To: John Hufferd; somesh_gupta@silverbacksystems.com > > Cc: Mukund, Shridhar; ips@ece.cmu.edu > > Subject: RE: iSCSI: No Framing > > > > > > > > In reviewing the mail alias, and after having many conversations with > > various folks, I would like to retract my prior opinion on ripping out > > markers. It appears to me as though _every_ NIC vendor is in support of > > markers. > > Every NIC vendor may implement markers (or as is obvious from > interoperability results, may have the capability to implement > markers). On whether every (person who works at a) NIC/Chip vendor > supports it from a technical perspective (i.e. whether it solves > anything, or is a useful solution, or whether the analysis people > are using is correct) supports it, I think the count seems to be > evenly split. > > > > To me the evidence in support of keeping in "Sync and Steering with > > Fixed Interval Markers" is pretty compelling (now that I've been > > re-educated). Without going into proprietary issues - how often do NIC > > vendors agree unanimously on something? Also, a software implementation > > of markers is tractable. > > > > I have not heard a single NIC vendor in support of COWS, and I > > personally don't support COWS either. Thus I would recommend that COWS > > be "ripped out". > > > > > > Jim > > > > Julian indicates in his message that we are not really sure what > a good solution is and if we put something in, we are likely > to get to a better one in the second draft. I also concur that > the whole problem/solution space is experimental in nature, and > ought to be treated as such. > > I think it is meaningless to assume that one person or another > has a magic solution here. The problems are fairly well understood. > One can talk about it from an algorithmic perspective (like > error recovery) which will expose some of the assumptions/compromises > behind this. Of course, whether that will pass muster with > the community at large is another issue. > > > > > > > > -----Original Message----- > > From: John Hufferd [mailto:hufferd@us.ibm.com] > > Sent: Friday, February 01, 2002 11:31 PM > > To: somesh_gupta@silverbacksystems.com > > Cc: Mukund, Shridhar; ips@ece.cmu.edu > > Subject: RE: iSCSI: No Framing > > > > > > Somesh, > > This is not fair, we asked for Chip Vendors that were planning on using > > it, > > to make themselves known and to tell us why. Without exposing internal > > designs, he has tried to do that, likewise Trebia, and some others have > > said they want FIMs. You may not want FIMs for your design, but you > > should > > respect these folks that have been following our spec and found it to be > > valuable in their designs. They are putting their money on it not just > > talk, so we should at least give them the credit which their position > > deserves. Yes, of course they are disappointed with the rhetoric around > > this issue, since they and others have been following the spec, and can > > not > > understand why others haven't, since they have determined it to be of > > significant value. > > > > His note does speak to the issues. (And clearly has some silly parts :-) > > > > In fact he has found it of enough value to use now, since he believes > > they > > can not wait for iWARP to happen before the issue is addressed (and he > > really wants iWARP). It should be useful to listen to folks that are > > willing to put their money where their mouth is. > > > > OK, that said: don't you think we can find a way to address both your > > position and their position, since they both seem strong and heart felt. > > I > > would think that the "Should Implement" or at least "May Implement" > > would > > give both sides enough reasonable room to meet on an even business > > plane. > > > > > > . > > . > > . > > 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 > > > > > > "Somesh Gupta" @ece.cmu.edu on > > 02/01/2002 07:10:13 PM > > > > Please respond to > > > > Sent by: owner-ips@ece.cmu.edu > > > > > > To: "Mukund, Shridhar" , "'WENDT,JIM > > \(HP-Roseville,ex1\)'" , > > cc: > > Subject: RE: iSCSI: No Framing > > > > > > > > Mukund, > > > > With all due respect, taking on the mantle of > > the noble engineer being denied by politically > > motivated people, belittles the technical expertise > > and strengths of the people who have expressed an > > opinion against having any of the proposed schemes > > at this time in the spec. > > > > I would be very happy to work alongside a number of > > the people on both sides of the issue (and that does > > include you). > > > > None of your arguments below refutes the technical > > and some non-technical opinions expressed against > > FIM. > > > > Somesh > > > > > -----Original Message----- > > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > > Mukund, Shridhar > > > Sent: Friday, February 01, 2002 5:24 PM > > > To: 'WENDT,JIM (HP-Roseville,ex1)'; ips@ece.cmu.edu > > > Subject: RE: iSCSI: No Framing > > > > > > > > > Dear Colleagues, > > > > > > PART 1 of 3 : > > > > > > The pertinent points that "I" see in Jim's email are: > > > > > > A. Need to hear from iSCSI chip implementers ... > > > The issues that you raise for e.g. in #2 are simply > > > circumstantial( See PART 2 ). Answers to those questions > > > unnecessarily call for data flows and implementation > > > details that silicon vendors are not allowed to share > > > in public. While I do not know of many silicon vendors > > > in the multi gig space, clearly one of the competitions > > > I respect, namely Trebia, point to FIM as well. Granted, > > > no matter what, we are going to see several > > > trebia-on-the-other-end and adaptec-on-the-other-end > > > type of cost optimizations. > > > > > > B. The iWARP/TUF/SCTP under-current ... > > > The "only" message of significance in Jim's email is #5. > > > It seems like the iWARP/SCTP/TUF enthusiasts somehow feel > > > threatened that FIM-iSCSI will dilute the perceived value > > > proposition of iWARP :-) I for one am an enthusiast of > > > iWARP ideals myself, barring the proposed mechanics. I > > > would love to make a buck or two along with you in > > > building iWARP NICs, "at the right time". In the > > > meanwhile, iSCSI is the flag ship effort that has the > > > unique opportunity to make a dent in enabling IP Storage > > > visions. ( See PART 3 ) > > > > > > My assertions are : > > > i) TUF/SCTP/iWARP is ruled out in the near term. The > > > mechanics are unclear as hell. > > > ii) FIM is the least intrusive, TCP transparent, means for > > > enabling low-cost(power,b/w,latency,memory,space,CPU) > > > RDMA transport of bulk data. > > > iii) I do not see significant technical reasons that > > > merit major changes to the iSCSI draft at this late > > > date. > > > iii) Making it OPTIONAL to use, and SHOULD only on send > > > provides a graceful and incremental deployment path > > > for "real":-) providers and users to succeed. > > > > > > I have personally contributed nothing to the iSCSI effort > > > and do applaud the pains that several of you are taking to > > > pull it all together. In that very same spirit, I respect > > > David's decision w.r.t. consensus, whatever that turns out > > > to be. > > > > > > Thanks. > > > > > > -Shridhar Mukund + Todd Sperry, Siva Munnangi, Dev ... > > > > > > ------------------------------------------------------------ > > > PART 2 of 3 : MUST delete, SHOULD read > > > > > > Dear Jim, > > > > > > Congratulations Jim! Seems like when you bowl, pins > > > roll, unintentional as they may be. You make a "seemingly" > > > well balanced set of arguments and "tactfully" tilt the > > > balance towards your chosen side. I would love to be on > > > your side ... maybe in another effort :-) > > > > > > I would like to introduce you to my respectable friend, > > > who "vehemently" contradicts you on all accounts. One of > > > his numerous quotes goes as follows: > > > http://groups.yahoo.com/group/rdma/message/486 > > > "Much of today's usage of the Internet and IP networks > > > is for buffer-to-buffer data transfers, often in the > > > form of bulk data ... Gigabit and faster network transfers > > > incur 'heavy' system resource costs, including both CPU > > > use and system bus bandwidth, particularly on the > > > receiving side ... The costs incurred on hosts for protocol > > > processing and management has 'inhibited' the use of IP > > > in the high speed bulk data domain. ... Bulk data transfer > > > is dominated by the costs of copying and validating > > > incoming data in order to place it at its ultimate > > > destination." > > > > > > The good friend I quote above is none other than Jim > > > Wendt himself!!! I REST MY CASE. > > > > > > Thanks. > > > > > > -Shridhar Mukund > > > > > > ---------------------------------------------------------------- > > > PART 3 of 3: MUST delete, OPTIONAL read > > > > > > On the lighter side ... since the opponents have "no" technical > > > arguments whatsoever against FIM and it is all turning out to > > > be a pure political gimmick, I will put on my rusting tin > > > politician hat :-) > > > > > > My dear fellow iSCSI country (wo)men: If our goals are anything > > > short of enabling the HP's, Cisco's, uSoft's, IBM's and EMC's of > > > the world in globalization of storage for McDonald's and Macy's > > > from Kabul to Somalia, via iSCSI, we have lost our identity! > > > ( \insert APPLAUSE for 13 seconds )We are no more protected by > > > the vast oceans between us and other Storage efforts. The > > > freedom of iSCSI America is threatened from within by elements > > > who will not blink twice when it comes to using the world's most > > > potent BOO-bombs ... and grinnn while we end up sifting through > > > the rubbles for iSCSI, youSCSI and theySCSI. > > > ( \insert APPLAUSE for 11 seconds ) Beware of the elements that > > > sleep with "our" very ideals in their privacy(burkha clad > > > though) and yet attempt to destabilize us, only to accomplish > > > their mutated agenda.( \insert APPLAUSE for 57 seconds ) > > > > > > No offense folks. I respect each and every one of you and > > > especially Jim. I think that he was only attempting to > > > question, "are we sure ... should we commit ...". > > > I disagree with him anyway! > > > > > > - the running(actually limping) mate :-) :-) :-) > > > > > > -----Original Message----- > > > From: WENDT,JIM (HP-Roseville,ex1) [mailto:jim_wendt@hp.com] > > > Sent: Tuesday, January 29, 2002 10:47 PM > > > To: ips@ece.cmu.edu > > > Subject: iSCSI: No Framing > > > > > > > > > Perhaps we should discuss the possibility of not > > > specifying any framing mechanism (FIM or COWS) in the > > > first version of iSCSI. > > > > > > The arguments for not specifying framing include > > > (there may be others as well): > > > 1) The brute force approach of putting TCP receiver > > > reassembly memory on the iSCSI NIC will work for both > > > 1Gbps and 10Gbps. Cost is incurred for memory chips, > > > ASIC pins, power, and board space. But, it is a > > > feasible approach. > > > > > > 2) I/O bus latency (or bandwidth limitations) could > > > mandate inbound buffering (as a 'smoothing' buffer) > > > from the iSCSI NIC to the host system. If this buffer > > > memory is large enough to have to be off-chip, then > > > it will require some minimum number of memory chips > > > to provide the necessary bandwidth, and the > > > memory/pins/power/space costs will be incurred > > > anyway. > > > > > > 3) Very large receive buffering on the NIC is only > > > required for high-bandwidth links traversing large > > > geographic distances (which may not be the > > > predominate case). These specialized implementations > > > can cost more (e.g. more memory/power/pins/etc) and > > > customers will likely be willing to pay accordingly. > > > > > > 4) Many NICs will likely aspire to be combo > > > iSCSI+TOE+Ethernet NICs allowing the host system to > > > use a single Ethernet port for all of its network > > > communications. The TOE function on this combo NIC > > > will already require TCP receive buffering and off- > > > chip buffer memory to support the existing sockets > > > interface receive model. More importantly, to allow > > > senders to assume ownership of the buffer upon return > > > from a socket send call, the TOE NIC would need to > > > copy application send buffers into NIC memory as > > > well. > > > > > > 5) The framing/marker mechanism will be an iSCSI-only > > > solution. It is quite possible that the problem will > > > be solved via a different, and hopefully more > > > general, mechanism for other ULPs. > > > > > > 6) Both FIM and COWS are poor solutions for software > > > implementation. COWS requires, at a minimum, the > > > sender to read every word in the buffer. FIM either > > > imposes additional sender gather processing (iovecs) > > > or requires a data buffer copy (on systems that don't > > > support HW gather on sends). > > > > > > 7) Unless all senders thoroughly test framing/markers > > > now (i.e. unless the framing method is a MUST > > > implement), there is potential for future > > > interoperability problems as framing/marker receivers > > > are deployed in the future. > > > > > > 8) Neither FIM nor COWS is an elegant solution. Are > > > we comfortable with the legacy we are creating under > > > the umbrella of state-of-the-art IP networked > > > storage? > > > > > > 9) Is it essential to build in forward compatibility > > > now, or will there be a different solution in the > > > 10Gbps or 40Gbps timeframe - perhaps involving iSCSI- > > > 2? Will it be reasonable to update or bridge initial > > > 1Gbps deployments? > > > > > > > > > So, it would be good to hear from several iSCSI > > > NIC/chip implementors who: > > > - have or plan to implement FIM or COWS (or some > > > other framing mechanism) and take advantage of it to > > > minimize demands on on-NIC buffer memory > > > bandwidth/quantity. > > > - believe that all-buffers-on-chip solutions are > > > feasible and valid (wrt the points above, including > > > #2) > > > - can quantify the memory/pin/power/space cost > > > savings for all-buffers-on-chip solutions > > > > > > Jim > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Tue Feb 5 15:49: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 PAA18816 for ; Tue, 5 Feb 2002 15:49:14 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g15JvjZ23309 for ips-outgoing; Tue, 5 Feb 2002 14:57:45 -0500 (EST) 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 g15JvQj23271; Tue, 5 Feb 2002 14:57:39 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id UAA45824; Tue, 5 Feb 2002 20:55:33 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g15Jv1Z35704; Tue, 5 Feb 2002 20:57:02 +0100 To: Cc: ips@ece.cmu.edu, "John Hufferd" , "Jim Pinkerton" , owner-ips@ece.cmu.edu, "Mukund, Shridhar" MIME-Version: 1.0 Subject: RE: iSCSI: No Framing X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 5 Feb 2002 21:56:42 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 05/02/2002 21:57:01, Serialize complete at 05/02/2002 21:57:01 Content-Type: multipart/alternative; boundary="=_alternative 006CFA7FC2256B57_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 006CFA7FC2256B57_= Content-Type: text/plain; charset="us-ascii" Not exacly markers - those appeared in Haifa-summer of 2000 but something similar - aligned PDUs. Julo "Somesh Gupta" Sent by: owner-ips@ece.cmu.edu 05-02-02 21:20 Please respond to somesh_gupta To: John Hufferd/San Jose/IBM@IBMUS cc: "Jim Pinkerton" , "Mukund, Shridhar" , Subject: RE: iSCSI: No Framing John, I have to point for the record, that I was the one that proposed markers over a year ago (not that many other did not also have this idea). I have also tried to keep this debate at a technical level. There are reasonable folks on both sides of the debate, and we should just continue in that spirit. Somesh > -----Original Message----- > From: John Hufferd [mailto:hufferd@us.ibm.com] > Sent: Tuesday, February 05, 2002 10:55 AM > To: somesh_gupta@silverbacksystems.com > Cc: Jim Pinkerton; Mukund, Shridhar; ips@ece.cmu.edu > Subject: RE: iSCSI: No Framing > > > > Somesh, > I usually give higher weight to the opinions of folks that take their > opinions and put their money on it, than the folks that do not. So I am > not sure you can so easily dismiss the ideas of folks that are committed > with actual money. > > . > . > . > 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 > > > "Somesh Gupta" on 02/05/2002 10:25:45 > AM > > Please respond to > > To: "Jim Pinkerton" , John Hufferd/San > Jose/IBM@IBMUS > cc: "Mukund, Shridhar" , > Subject: RE: iSCSI: No Framing > > > > Jim, > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Jim Pinkerton > > Sent: Tuesday, February 05, 2002 6:53 AM > > To: John Hufferd; somesh_gupta@silverbacksystems.com > > Cc: Mukund, Shridhar; ips@ece.cmu.edu > > Subject: RE: iSCSI: No Framing > > > > > > > > In reviewing the mail alias, and after having many conversations with > > various folks, I would like to retract my prior opinion on ripping out > > markers. It appears to me as though _every_ NIC vendor is in support of > > markers. > > Every NIC vendor may implement markers (or as is obvious from > interoperability results, may have the capability to implement > markers). On whether every (person who works at a) NIC/Chip vendor > supports it from a technical perspective (i.e. whether it solves > anything, or is a useful solution, or whether the analysis people > are using is correct) supports it, I think the count seems to be > evenly split. > > > > To me the evidence in support of keeping in "Sync and Steering with > > Fixed Interval Markers" is pretty compelling (now that I've been > > re-educated). Without going into proprietary issues - how often do NIC > > vendors agree unanimously on something? Also, a software implementation > > of markers is tractable. > > > > I have not heard a single NIC vendor in support of COWS, and I > > personally don't support COWS either. Thus I would recommend that COWS > > be "ripped out". > > > > > > Jim > > > > Julian indicates in his message that we are not really sure what > a good solution is and if we put something in, we are likely > to get to a better one in the second draft. I also concur that > the whole problem/solution space is experimental in nature, and > ought to be treated as such. > > I think it is meaningless to assume that one person or another > has a magic solution here. The problems are fairly well understood. > One can talk about it from an algorithmic perspective (like > error recovery) which will expose some of the assumptions/compromises > behind this. Of course, whether that will pass muster with > the community at large is another issue. > > > > > > > > -----Original Message----- > > From: John Hufferd [mailto:hufferd@us.ibm.com] > > Sent: Friday, February 01, 2002 11:31 PM > > To: somesh_gupta@silverbacksystems.com > > Cc: Mukund, Shridhar; ips@ece.cmu.edu > > Subject: RE: iSCSI: No Framing > > > > > > Somesh, > > This is not fair, we asked for Chip Vendors that were planning on using > > it, > > to make themselves known and to tell us why. Without exposing internal > > designs, he has tried to do that, likewise Trebia, and some others have > > said they want FIMs. You may not want FIMs for your design, but you > > should > > respect these folks that have been following our spec and found it to be > > valuable in their designs. They are putting their money on it not just > > talk, so we should at least give them the credit which their position > > deserves. Yes, of course they are disappointed with the rhetoric around > > this issue, since they and others have been following the spec, and can > > not > > understand why others haven't, since they have determined it to be of > > significant value. > > > > His note does speak to the issues. (And clearly has some silly parts :-) > > > > In fact he has found it of enough value to use now, since he believes > > they > > can not wait for iWARP to happen before the issue is addressed (and he > > really wants iWARP). It should be useful to listen to folks that are > > willing to put their money where their mouth is. > > > > OK, that said: don't you think we can find a way to address both your > > position and their position, since they both seem strong and heart felt. > > I > > would think that the "Should Implement" or at least "May Implement" > > would > > give both sides enough reasonable room to meet on an even business > > plane. > > > > > > . > > . > > . > > 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 > > > > > > "Somesh Gupta" @ece.cmu.edu on > > 02/01/2002 07:10:13 PM > > > > Please respond to > > > > Sent by: owner-ips@ece.cmu.edu > > > > > > To: "Mukund, Shridhar" , "'WENDT,JIM > > \(HP-Roseville,ex1\)'" , > > cc: > > Subject: RE: iSCSI: No Framing > > > > > > > > Mukund, > > > > With all due respect, taking on the mantle of > > the noble engineer being denied by politically > > motivated people, belittles the technical expertise > > and strengths of the people who have expressed an > > opinion against having any of the proposed schemes > > at this time in the spec. > > > > I would be very happy to work alongside a number of > > the people on both sides of the issue (and that does > > include you). > > > > None of your arguments below refutes the technical > > and some non-technical opinions expressed against > > FIM. > > > > Somesh > > > > > -----Original Message----- > > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > > Mukund, Shridhar > > > Sent: Friday, February 01, 2002 5:24 PM > > > To: 'WENDT,JIM (HP-Roseville,ex1)'; ips@ece.cmu.edu > > > Subject: RE: iSCSI: No Framing > > > > > > > > > Dear Colleagues, > > > > > > PART 1 of 3 : > > > > > > The pertinent points that "I" see in Jim's email are: > > > > > > A. Need to hear from iSCSI chip implementers ... > > > The issues that you raise for e.g. in #2 are simply > > > circumstantial( See PART 2 ). Answers to those questions > > > unnecessarily call for data flows and implementation > > > details that silicon vendors are not allowed to share > > > in public. While I do not know of many silicon vendors > > > in the multi gig space, clearly one of the competitions > > > I respect, namely Trebia, point to FIM as well. Granted, > > > no matter what, we are going to see several > > > trebia-on-the-other-end and adaptec-on-the-other-end > > > type of cost optimizations. > > > > > > B. The iWARP/TUF/SCTP under-current ... > > > The "only" message of significance in Jim's email is #5. > > > It seems like the iWARP/SCTP/TUF enthusiasts somehow feel > > > threatened that FIM-iSCSI will dilute the perceived value > > > proposition of iWARP :-) I for one am an enthusiast of > > > iWARP ideals myself, barring the proposed mechanics. I > > > would love to make a buck or two along with you in > > > building iWARP NICs, "at the right time". In the > > > meanwhile, iSCSI is the flag ship effort that has the > > > unique opportunity to make a dent in enabling IP Storage > > > visions. ( See PART 3 ) > > > > > > My assertions are : > > > i) TUF/SCTP/iWARP is ruled out in the near term. The > > > mechanics are unclear as hell. > > > ii) FIM is the least intrusive, TCP transparent, means for > > > enabling low-cost(power,b/w,latency,memory,space,CPU) > > > RDMA transport of bulk data. > > > iii) I do not see significant technical reasons that > > > merit major changes to the iSCSI draft at this late > > > date. > > > iii) Making it OPTIONAL to use, and SHOULD only on send > > > provides a graceful and incremental deployment path > > > for "real":-) providers and users to succeed. > > > > > > I have personally contributed nothing to the iSCSI effort > > > and do applaud the pains that several of you are taking to > > > pull it all together. In that very same spirit, I respect > > > David's decision w.r.t. consensus, whatever that turns out > > > to be. > > > > > > Thanks. > > > > > > -Shridhar Mukund + Todd Sperry, Siva Munnangi, Dev ... > > > > > > ------------------------------------------------------------ > > > PART 2 of 3 : MUST delete, SHOULD read > > > > > > Dear Jim, > > > > > > Congratulations Jim! Seems like when you bowl, pins > > > roll, unintentional as they may be. You make a "seemingly" > > > well balanced set of arguments and "tactfully" tilt the > > > balance towards your chosen side. I would love to be on > > > your side ... maybe in another effort :-) > > > > > > I would like to introduce you to my respectable friend, > > > who "vehemently" contradicts you on all accounts. One of > > > his numerous quotes goes as follows: > > > http://groups.yahoo.com/group/rdma/message/486 > > > "Much of today's usage of the Internet and IP networks > > > is for buffer-to-buffer data transfers, often in the > > > form of bulk data ... Gigabit and faster network transfers > > > incur 'heavy' system resource costs, including both CPU > > > use and system bus bandwidth, particularly on the > > > receiving side ... The costs incurred on hosts for protocol > > > processing and management has 'inhibited' the use of IP > > > in the high speed bulk data domain. ... Bulk data transfer > > > is dominated by the costs of copying and validating > > > incoming data in order to place it at its ultimate > > > destination." > > > > > > The good friend I quote above is none other than Jim > > > Wendt himself!!! I REST MY CASE. > > > > > > Thanks. > > > > > > -Shridhar Mukund > > > > > > ---------------------------------------------------------------- > > > PART 3 of 3: MUST delete, OPTIONAL read > > > > > > On the lighter side ... since the opponents have "no" technical > > > arguments whatsoever against FIM and it is all turning out to > > > be a pure political gimmick, I will put on my rusting tin > > > politician hat :-) > > > > > > My dear fellow iSCSI country (wo)men: If our goals are anything > > > short of enabling the HP's, Cisco's, uSoft's, IBM's and EMC's of > > > the world in globalization of storage for McDonald's and Macy's > > > from Kabul to Somalia, via iSCSI, we have lost our identity! > > > ( \insert APPLAUSE for 13 seconds )We are no more protected by > > > the vast oceans between us and other Storage efforts. The > > > freedom of iSCSI America is threatened from within by elements > > > who will not blink twice when it comes to using the world's most > > > potent BOO-bombs ... and grinnn while we end up sifting through > > > the rubbles for iSCSI, youSCSI and theySCSI. > > > ( \insert APPLAUSE for 11 seconds ) Beware of the elements that > > > sleep with "our" very ideals in their privacy(burkha clad > > > though) and yet attempt to destabilize us, only to accomplish > > > their mutated agenda.( \insert APPLAUSE for 57 seconds ) > > > > > > No offense folks. I respect each and every one of you and > > > especially Jim. I think that he was only attempting to > > > question, "are we sure ... should we commit ...". > > > I disagree with him anyway! > > > > > > - the running(actually limping) mate :-) :-) :-) > > > > > > -----Original Message----- > > > From: WENDT,JIM (HP-Roseville,ex1) [mailto:jim_wendt@hp.com] > > > Sent: Tuesday, January 29, 2002 10:47 PM > > > To: ips@ece.cmu.edu > > > Subject: iSCSI: No Framing > > > > > > > > > Perhaps we should discuss the possibility of not > > > specifying any framing mechanism (FIM or COWS) in the > > > first version of iSCSI. > > > > > > The arguments for not specifying framing include > > > (there may be others as well): > > > 1) The brute force approach of putting TCP receiver > > > reassembly memory on the iSCSI NIC will work for both > > > 1Gbps and 10Gbps. Cost is incurred for memory chips, > > > ASIC pins, power, and board space. But, it is a > > > feasible approach. > > > > > > 2) I/O bus latency (or bandwidth limitations) could > > > mandate inbound buffering (as a 'smoothing' buffer) > > > from the iSCSI NIC to the host system. If this buffer > > > memory is large enough to have to be off-chip, then > > > it will require some minimum number of memory chips > > > to provide the necessary bandwidth, and the > > > memory/pins/power/space costs will be incurred > > > anyway. > > > > > > 3) Very large receive buffering on the NIC is only > > > required for high-bandwidth links traversing large > > > geographic distances (which may not be the > > > predominate case). These specialized implementations > > > can cost more (e.g. more memory/power/pins/etc) and > > > customers will likely be willing to pay accordingly. > > > > > > 4) Many NICs will likely aspire to be combo > > > iSCSI+TOE+Ethernet NICs allowing the host system to > > > use a single Ethernet port for all of its network > > > communications. The TOE function on this combo NIC > > > will already require TCP receive buffering and off- > > > chip buffer memory to support the existing sockets > > > interface receive model. More importantly, to allow > > > senders to assume ownership of the buffer upon return > > > from a socket send call, the TOE NIC would need to > > > copy application send buffers into NIC memory as > > > well. > > > > > > 5) The framing/marker mechanism will be an iSCSI-only > > > solution. It is quite possible that the problem will > > > be solved via a different, and hopefully more > > > general, mechanism for other ULPs. > > > > > > 6) Both FIM and COWS are poor solutions for software > > > implementation. COWS requires, at a minimum, the > > > sender to read every word in the buffer. FIM either > > > imposes additional sender gather processing (iovecs) > > > or requires a data buffer copy (on systems that don't > > > support HW gather on sends). > > > > > > 7) Unless all senders thoroughly test framing/markers > > > now (i.e. unless the framing method is a MUST > > > implement), there is potential for future > > > interoperability problems as framing/marker receivers > > > are deployed in the future. > > > > > > 8) Neither FIM nor COWS is an elegant solution. Are > > > we comfortable with the legacy we are creating under > > > the umbrella of state-of-the-art IP networked > > > storage? > > > > > > 9) Is it essential to build in forward compatibility > > > now, or will there be a different solution in the > > > 10Gbps or 40Gbps timeframe - perhaps involving iSCSI- > > > 2? Will it be reasonable to update or bridge initial > > > 1Gbps deployments? > > > > > > > > > So, it would be good to hear from several iSCSI > > > NIC/chip implementors who: > > > - have or plan to implement FIM or COWS (or some > > > other framing mechanism) and take advantage of it to > > > minimize demands on on-NIC buffer memory > > > bandwidth/quantity. > > > - believe that all-buffers-on-chip solutions are > > > feasible and valid (wrt the points above, including > > > #2) > > > - can quantify the memory/pin/power/space cost > > > savings for all-buffers-on-chip solutions > > > > > > Jim > > > > > > > > > > > > > > > --=_alternative 006CFA7FC2256B57_= Content-Type: text/html; charset="us-ascii"
Not exacly markers - those appeared in Haifa-summer of 2000 but something similar - aligned PDUs.

Julo


"Somesh Gupta" <somesh_gupta@silverbacksystems.com>
Sent by: owner-ips@ece.cmu.edu

05-02-02 21:20
Please respond to somesh_gupta

       
        To:        John Hufferd/San Jose/IBM@IBMUS
        cc:        "Jim Pinkerton" <jpink@microsoft.com>, "Mukund, Shridhar" <Shridhar_Mukund@adaptec.com>, <ips@ece.cmu.edu>
        Subject:        RE: iSCSI: No Framing

       


John,

I have to point for the record, that I was the one
that proposed markers over a year ago (not that many
other did not also have this idea). I have also tried
to keep this debate at a technical level. There
are reasonable folks on both sides of the debate,
and we should just continue in that spirit.

Somesh

> -----Original Message-----
> From: John Hufferd [mailto:hufferd@us.ibm.com]
> Sent: Tuesday, February 05, 2002 10:55 AM
> To: somesh_gupta@silverbacksystems.com
> Cc: Jim Pinkerton; Mukund, Shridhar; ips@ece.cmu.edu
> Subject: RE: iSCSI: No Framing
>
>
>
> Somesh,
> I usually give higher weight to the opinions of folks that take their
> opinions and put their money on it, than the folks that do not.   So I am
> not sure you can so easily dismiss the ideas of folks that are committed
> with actual money.
>
> .
> .
> .
> 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
>
>
> "Somesh Gupta" <somesh_gupta@silverbacksystems.com> on 02/05/2002 10:25:45
> AM
>
> Please respond to <somesh_gupta@silverbacksystems.com>
>
> To:    "Jim Pinkerton" <jpink@microsoft.com>, John Hufferd/San
>        Jose/IBM@IBMUS
> cc:    "Mukund, Shridhar" <Shridhar_Mukund@adaptec.com>, <ips@ece.cmu.edu>
> Subject:    RE: iSCSI: No Framing
>
>
>
> Jim,
>
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > Jim Pinkerton
> > Sent: Tuesday, February 05, 2002 6:53 AM
> > To: John Hufferd; somesh_gupta@silverbacksystems.com
> > Cc: Mukund, Shridhar; ips@ece.cmu.edu
> > Subject: RE: iSCSI: No Framing
> >
> >
> >
> > In reviewing the mail alias, and after having many conversations with
> > various folks, I would like to retract my prior opinion on ripping out
> > markers. It appears to me as though _every_ NIC vendor is in support of
> > markers.
>
>   Every NIC vendor may implement markers (or as is obvious from
>   interoperability results, may have the capability to implement
>   markers). On whether every (person who works at a) NIC/Chip vendor
>   supports it from a technical perspective (i.e. whether it solves
>   anything, or is a useful solution, or whether the analysis people
>   are using is correct) supports it, I think the count seems to be
>   evenly split.
> >
> > To me the evidence in support of keeping in "Sync and Steering with
> > Fixed Interval Markers" is pretty compelling (now that I've been
> > re-educated). Without going into proprietary issues - how often do NIC
> > vendors agree unanimously on something? Also, a software implementation
> > of markers is tractable.
> >
> > I have not heard a single NIC vendor in support of COWS, and I
> > personally don't support COWS either. Thus I would recommend that COWS
> > be "ripped out".
> >
> >
> > Jim
> >
>
>   Julian indicates in his message that we are not really sure what
>   a good solution is and if we put something in, we are likely
>   to get to a better one in the second draft. I also concur that
>   the whole problem/solution space is experimental in nature, and
>   ought to be treated as such.
>
>   I think it is meaningless to assume that one person or another
>   has a magic solution here. The problems are fairly well understood.
>   One can talk about it from an algorithmic perspective (like
>   error recovery) which will expose some of the assumptions/compromises
>   behind this. Of course, whether that will pass muster with
>   the community at large is another issue.
> >
> >
> >
> > -----Original Message-----
> > From: John Hufferd [mailto:hufferd@us.ibm.com]
> > Sent: Friday, February 01, 2002 11:31 PM
> > To: somesh_gupta@silverbacksystems.com
> > Cc: Mukund, Shridhar; ips@ece.cmu.edu
> > Subject: RE: iSCSI: No Framing
> >
> >
> > Somesh,
> > This is not fair, we asked for Chip Vendors that were planning on using
> > it,
> > to make themselves known and to tell us why.  Without exposing internal
> > designs, he has tried to do that, likewise Trebia, and some others have
> > said they want FIMs.  You may not want FIMs for your design, but you
> > should
> > respect these folks that have been following our spec and found it to be
> > valuable in their designs.  They are putting their money on it not just
> > talk, so we should at least give them the credit which their position
> > deserves.  Yes, of course they are disappointed with the rhetoric around
> > this issue, since they and others have been following the spec, and can
> > not
> > understand why others haven't, since they have determined it to be of
> > significant value.
> >
> > His note does speak to the issues. (And clearly has some silly parts :-)
> >
> > In fact he has found it of enough value to use now, since he believes
> > they
> > can not wait for iWARP to happen before the issue is addressed (and he
> > really wants iWARP).  It should be useful to listen to folks that are
> > willing to put their money where their mouth is.
> >
> > OK, that said: don't you think we can find a way to address both your
> > position and their position, since they both seem strong and heart felt.
> > I
> > would think that the "Should Implement" or at least "May Implement"
> > would
> > give both sides enough reasonable room to meet on an even business
> > plane.
> >
> >
> > .
> > .
> > .
> > 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
> >
> >
> > "Somesh Gupta" <somesh_gupta@silverbacksystems.com>@ece.cmu.edu on
> > 02/01/2002 07:10:13 PM
> >
> > Please respond to <somesh_gupta@silverbacksystems.com>
> >
> > Sent by:    owner-ips@ece.cmu.edu
> >
> >
> > To:    "Mukund, Shridhar" <Shridhar_Mukund@adaptec.com>, "'WENDT,JIM
> >        \(HP-Roseville,ex1\)'" <jim_wendt@hp.com>, <ips@ece.cmu.edu>
> > cc:
> > Subject:    RE: iSCSI: No Framing
> >
> >
> >
> > Mukund,
> >
> > With all due respect, taking on the mantle of
> > the noble engineer being denied by politically
> > motivated people, belittles the technical expertise
> > and strengths of the people who have expressed an
> > opinion against having any of the proposed schemes
> > at this time in the spec.
> >
> > I would be very happy to work alongside a number of
> > the people on both sides of the issue (and that does
> > include you).
> >
> > None of your arguments below refutes the technical
> > and some non-technical opinions expressed against
> > FIM.
> >
> > Somesh
> >
> > > -----Original Message-----
> > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > > Mukund, Shridhar
> > > Sent: Friday, February 01, 2002 5:24 PM
> > > To: 'WENDT,JIM (HP-Roseville,ex1)'; ips@ece.cmu.edu
> > > Subject: RE: iSCSI: No Framing
> > >
> > >
> > > Dear Colleagues,
> > >
> > > PART 1 of 3 :
> > >
> > > The pertinent points that "I" see in Jim's email are:
> > >
> > > A. Need to hear from iSCSI chip implementers ...
> > >    The issues that you raise for e.g. in #2&#4 are simply
> > >    circumstantial( See PART 2 ). Answers to those questions
> > >    unnecessarily call for data flows and implementation
> > >    details that silicon vendors are not allowed to share
> > >    in public. While I do not know of many silicon vendors
> > >    in the multi gig space, clearly one of the competitions
> > >    I respect, namely Trebia, point to FIM as well. Granted,
> > >    no matter what, we are going to see several
> > >    trebia-on-the-other-end and adaptec-on-the-other-end
> > >    type of cost optimizations.
> > >
> > > B. The iWARP/TUF/SCTP under-current ...
> > >    The "only" message of significance in Jim's email is #5.
> > >    It seems like the iWARP/SCTP/TUF enthusiasts somehow feel
> > >    threatened that FIM-iSCSI will dilute the perceived value
> > >    proposition of iWARP :-) I for one am an enthusiast of
> > >    iWARP ideals myself, barring the proposed mechanics. I
> > >    would love to make a buck or two along with you in
> > >    building iWARP NICs, "at the right time". In the
> > >    meanwhile, iSCSI is the flag ship effort that has the
> > >    unique opportunity to make a dent in enabling IP Storage
> > >    visions. ( See PART 3 )
> > >
> > > My assertions are :
> > >     i) TUF/SCTP/iWARP is ruled out in the near term. The
> > >        mechanics are unclear as hell.
> > >     ii) FIM is the least intrusive, TCP transparent, means for
> > >        enabling low-cost(power,b/w,latency,memory,space,CPU)
> > >        RDMA transport of bulk data.
> > >     iii) I do not see significant technical reasons that
> > >        merit major changes to the iSCSI draft at this late
> > >        date.
> > >     iii) Making it OPTIONAL to use, and SHOULD only on send
> > >        provides a graceful and incremental deployment path
> > >        for "real":-) providers and users to succeed.
> > >
> > > I have personally contributed nothing to the iSCSI effort
> > > and do applaud the pains that several of you are taking to
> > > pull it all together. In that very same spirit, I respect
> > > David's decision w.r.t. consensus, whatever that turns out
> > > to be.
> > >
> > > Thanks.
> > >
> > > -Shridhar Mukund + Todd Sperry, Siva Munnangi, Dev ...
> > >
> > > ------------------------------------------------------------
> > > PART 2 of 3 : MUST delete, SHOULD read
> > >
> > > Dear Jim,
> > >
> > > Congratulations Jim! Seems like when you bowl, pins
> > > roll, unintentional as they may be. You make a "seemingly"
> > > well balanced set of arguments and "tactfully" tilt the
> > > balance towards your chosen side. I would love to be on
> > > your side ... maybe in another effort :-)
> > >
> > > I would like to introduce you to my respectable friend,
> > > who "vehemently" contradicts you on all accounts. One of
> > > his numerous quotes goes as follows:
> > > http://groups.yahoo.com/group/rdma/message/486
> > > "Much of today's usage of the Internet and IP networks
> > > is for buffer-to-buffer data transfers, often in the
> > > form of bulk data ... Gigabit and faster network transfers
> > > incur 'heavy' system resource costs, including both CPU
> > > use and system bus bandwidth, particularly on the
> > > receiving side ... The costs incurred on hosts for protocol
> > > processing and management has 'inhibited' the use of IP
> > > in the high speed bulk data domain. ... Bulk data transfer
> > > is dominated by the costs of copying and validating
> > > incoming data in order to place it at its ultimate
> > > destination."
> > >
> > > The good friend I quote above is none other than Jim
> > > Wendt himself!!! I REST MY CASE.
> > >
> > > Thanks.
> > >
> > > -Shridhar Mukund
> > >
> > > ----------------------------------------------------------------
> > > PART 3 of 3: MUST delete, OPTIONAL read
> > >
> > > On the lighter side ... since the opponents have "no" technical
> > > arguments whatsoever against FIM and it is all turning out to
> > > be a pure political gimmick, I will put on my rusting tin
> > > politician hat :-)
> > >
> > > My dear fellow iSCSI country (wo)men: If our goals are anything
> > > short of enabling the HP's, Cisco's, uSoft's, IBM's and EMC's of
> > > the world in globalization of storage for McDonald's and Macy's
> > > from Kabul to Somalia, via iSCSI, we have lost our identity!
> > > ( \insert APPLAUSE for 13 seconds )We are no more protected by
> > > the vast oceans between us and other Storage efforts. The
> > > freedom of iSCSI America is threatened from within by elements
> > > who will not blink twice when it comes to using the world's most
> > > potent BOO-bombs ... and grinnn while we end up sifting through
> > > the rubbles for iSCSI, youSCSI and theySCSI.
> > > ( \insert APPLAUSE for 11 seconds ) Beware of the elements that
> > > sleep with "our" very ideals in their privacy(burkha clad
> > > though) and yet attempt to destabilize us, only to accomplish
> > > their mutated agenda.( \insert APPLAUSE for 57 seconds )
> > >
> > > No offense folks. I respect each and every one of you and
> > > especially Jim. I think that he was only attempting to
> > > question, "are we sure ... should we commit ...".
> > > I disagree with him anyway!
> > >
> > > - the running(actually limping) mate :-) :-) :-)
> > >
> > > -----Original Message-----
> > > From: WENDT,JIM (HP-Roseville,ex1) [mailto:jim_wendt@hp.com]
> > > Sent: Tuesday, January 29, 2002 10:47 PM
> > > To: ips@ece.cmu.edu
> > > Subject: iSCSI: No Framing
> > >
> > >
> > > Perhaps we should discuss the possibility of not
> > > specifying any framing mechanism (FIM or COWS) in the
> > > first version of iSCSI.
> > >
> > > The arguments for not specifying framing include
> > > (there may be others as well):
> > > 1) The brute force approach of putting TCP receiver
> > > reassembly memory on the iSCSI NIC will work for both
> > > 1Gbps and 10Gbps. Cost is incurred for memory chips,
> > > ASIC pins, power, and board space. But, it is a
> > > feasible approach.
> > >
> > > 2) I/O bus latency (or bandwidth limitations) could
> > > mandate inbound buffering (as a 'smoothing' buffer)
> > > from the iSCSI NIC to the host system. If this buffer
> > > memory is large enough to have to be off-chip, then
> > > it will require some minimum number of memory chips
> > > to provide the necessary bandwidth, and the
> > > memory/pins/power/space costs will be incurred
> > > anyway.
> > >
> > > 3) Very large receive buffering on the NIC is only
> > > required for high-bandwidth links traversing large
> > > geographic distances (which may not be the
> > > predominate case). These specialized implementations
> > > can cost more (e.g. more memory/power/pins/etc) and
> > > customers will likely be willing to pay accordingly.
> > >
> > > 4) Many NICs will likely aspire to be combo
> > > iSCSI+TOE+Ethernet NICs allowing the host system to
> > > use a single Ethernet port for all of its network
> > > communications. The TOE function on this combo NIC
> > > will already require TCP receive buffering and off-
> > > chip buffer memory to support the existing sockets
> > > interface receive model.  More importantly, to allow
> > > senders to assume ownership of the buffer upon return
> > > from a socket send call, the TOE NIC would need to
> > > copy application send buffers into NIC memory as
> > > well.
> > >
> > > 5) The framing/marker mechanism will be an iSCSI-only
> > > solution. It is quite possible that the problem will
> > > be solved via a different, and hopefully more
> > > general, mechanism for other ULPs.
> > >
> > > 6) Both FIM and COWS are poor solutions for software
> > > implementation. COWS requires, at a minimum, the
> > > sender to read every word in the buffer. FIM either
> > > imposes additional sender gather processing (iovecs)
> > > or requires a data buffer copy (on systems that don't
> > > support HW gather on sends).
> > >
> > > 7) Unless all senders thoroughly test framing/markers
> > > now (i.e. unless the framing method is a MUST
> > > implement), there is potential for future
> > > interoperability problems as framing/marker receivers
> > > are deployed in the future.
> > >
> > > 8) Neither FIM nor COWS is an elegant solution. Are
> > > we comfortable with the legacy we are creating under
> > > the umbrella of state-of-the-art IP networked
> > > storage?
> > >
> > > 9) Is it essential to build in forward compatibility
> > > now, or will there be a different solution in the
> > > 10Gbps or 40Gbps timeframe - perhaps involving iSCSI-
> > > 2?  Will it be reasonable to update or bridge initial
> > > 1Gbps deployments?
> > >
> > >
> > > So, it would be good to hear from several iSCSI
> > > NIC/chip implementors who:
> > > - have or plan to implement FIM or COWS (or some
> > > other framing mechanism) and take advantage of it to
> > > minimize demands on on-NIC buffer memory
> > > bandwidth/quantity.
> > > - believe that all-buffers-on-chip solutions are
> > > feasible and valid (wrt the points above, including
> > > #2)
> > > - can quantify the memory/pin/power/space cost
> > > savings for all-buffers-on-chip solutions
> > >
> > > Jim
> > >
> >
> >
> >
> >
>
>
>
>

--=_alternative 006CFA7FC2256B57_=-- From owner-ips@ece.cmu.edu Tue Feb 5 15:53: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 PAA18936 for ; Tue, 5 Feb 2002 15:53:02 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g15JrTS22979 for ips-outgoing; Tue, 5 Feb 2002 14:53:29 -0500 (EST) 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 g15JrQj22969 for ; Tue, 5 Feb 2002 14:53:26 -0500 (EST) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel13.hp.com (Postfix) with ESMTP id BD3344006CD for ; Tue, 5 Feb 2002 11:53:20 -0800 (PST) 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 LAA21166 for ; Tue, 5 Feb 2002 11:53:15 -0800 (PST) Message-ID: <3C6038B7.6EEC2178@cup.hp.com> Date: Tue, 05 Feb 2002 11:55:35 -0800 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: IPS Reflector Subject: ips : Is FirstBurstSize valid when InitialR2T=yes ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit 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 Tue Feb 5 17:08: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 RAA21225 for ; Tue, 5 Feb 2002 17:08:06 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g15L97p29280 for ips-outgoing; Tue, 5 Feb 2002 16:09:07 -0500 (EST) 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 g15L93j29263 for ; Tue, 5 Feb 2002 16:09:03 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id WAA123858; Tue, 5 Feb 2002 22:08:49 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g15LAD280536; Tue, 5 Feb 2002 22:10:15 +0100 Importance: Normal Subject: RE: IPsec Usage Question To: Paul Koning Cc: Black_David@emc.com, marjorie_krueger@hp.com, ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Ofer Biran" Date: Tue, 5 Feb 2002 23:12:19 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 05/02/2002 23:10:17 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Paul, I only meant that the 2-site tunnel scenario has nothing to do with the IPsec protection mandated to be implemented (yes, implemented, not used) by iSCSI. So I would not use this scenario at all to conclude about iSCSI security requirements (outer=inner etc.). Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 Paul Koning @ece.cmu.edu on 05/02/2002 18:52:28 Sent by: owner-ips@ece.cmu.edu To: Ofer Biran/Haifa/IBM@IBMIL cc: Black_David@emc.com, marjorie_krueger@hp.com, ips@ece.cmu.edu Subject: RE: IPsec Usage Question Excerpt of message (sent 5 February 2002) by Ofer Biran: > > Paul, > > >This example MUST work. So you cannot require inner == outer > >address, because that translates into saying that IP Storage cannot be > >protected by a site to site IPsec tunnel. > > This is not Kansas any more... The iSCSI devices on both sites (assuming > that's their only IPsec protection) are not iSCSI compliant. This > definitely > doesn't cover the IPsec protection mandated by iSCSI. No, you're mistaken. I said nothing about what the iSCSI devices IMPLEMENT. I only talked about what was IN USE by the customer. In the example, the customer chose to USE a different security mechanism for reasons of cost, convenience, site policy, or whatever. Remember that the proposed requirement is "required to implement" and NOT "required to use". My interpretation of having "use" be optional is that you also have the option of securing your traffic via other means. Am I right? Or is it the intent of the WG to say that no other security mechanisms are allowed -- if you want security you MUST use the one that is mandated in iSCSI nodes? If so, for what reason? paul From owner-ips@ece.cmu.edu Tue Feb 5 17:09: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 RAA21261 for ; Tue, 5 Feb 2002 17:09:48 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g15L1A428571 for ips-outgoing; Tue, 5 Feb 2002 16:01:10 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g15L18j28565 for ; Tue, 5 Feb 2002 16:01:08 -0500 (EST) Received: from hawk.corp.netapp.com (hawk [10.10.20.101]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id g15L12320314 for ; Tue, 5 Feb 2002 13:01:02 -0800 (PST) Received: from ussvlexc01.corp.netapp.com (localhost [127.0.0.1]) by hawk.corp.netapp.com (8.12.0/8.12.0/NTAP-1.3) with ESMTP id g15L11gq017429 for ; Tue, 5 Feb 2002 13:01:02 -0800 (PST) Received: by ussvlexc01.corp.netapp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Feb 2002 13:01:01 -0800 Message-ID: <02740A3D0809D5118C7C00034707E9F3015547BB@ussvlexc10.corp.netapp.com> From: "Pittman, Joseph" To: "'IPS Reflector'" Subject: iSCSI: R2T/ABORT_TASK interaction Date: Tue, 5 Feb 2002 13:00:58 -0800 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 Can anyone describe the required behavior of an initiator under the following condition? This may be a basic SCSI-3 question rather than iSCSI specific; if so, I apologize, but still ask for guidance. Suppose an initiator submits a SCSI Command PDU containing a large SCSI write operation (where large means >= FirstBurstSize). Before the initiator receives an R2T for the first (or next) chunk of the data, the initiator decides to abort the task with an ABORT_TASK (or other) Task Management PDU. In the meantime, the target has prepared its buffers and submits the R2T. The R2T and the ABORT_TASK PDUs 'cross paths': Time Initiator Target | 0 | SCSI_CMD ---------\ | \--------------> | | ABORT_TASK ------\ | \ /------------- R2T | \ / | X-------------> | / | <-------/ T | V At time T, the target has received an ABORT_TASK for the SCSI command, but has already sent an R2T. The initiator has just received an R2T for a SCSI task which it is trying to abort. The target has not yet sent a response to the ABORT_TASK task management command. The question is this: what are the responsibilities of the initiator and target at this point? - Is the initiator required or expected to respond to the R2T, perhaps with a zero-length DATA_OUT PDU? - Is the target expected to wait for the initiator to respond before aborting the task? Or is the initiator allowed (or required) to go ahead and abort the task and send the task management response, without waiting for any DATA_OUT, then silently discard any R2T it might receive later? Thanks in advance for any help. -- Joe Pittman jpittman@netapp.com From owner-ips@ece.cmu.edu Tue Feb 5 17:10: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 RAA21277 for ; Tue, 5 Feb 2002 17:10:01 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g15LGAQ29912 for ips-outgoing; Tue, 5 Feb 2002 16:16:10 -0500 (EST) 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 g15LG8j29906 for ; Tue, 5 Feb 2002 16:16:08 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id WAA28428; Tue, 5 Feb 2002 22:15:55 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g15LHJ252248; Tue, 5 Feb 2002 22:17:20 +0100 Importance: Normal Subject: RE: IPsec Usage Question To: "CAVANNA,VICENTE V (A-Roseville,ex1)" Cc: Black_David@emc.com, marjorie_krueger@hp.com, ips@ece.cmu.edu, Paul Koning X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Ofer Biran" Date: Tue, 5 Feb 2002 23:19:25 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 05/02/2002 23:17:21 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Vince, I meant in case "that's their only IPsec protection", i.e., you can combine your iSCSI with IPsec gateway/device and the box would be compliant. The 2-site tunnel scenario doesn't indicate if they are compliant or not - it's simply not relevant, and doesn't contribute to their compliance. Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 "CAVANNA,VICENTE V (A-Roseville,ex1)" on 05/02/2002 19:40:07 To: Ofer Biran/Haifa/IBM@IBMIL cc: Black_David@emc.com, marjorie_krueger@hp.com, ips@ece.cmu.edu, Paul Koning Subject: RE: IPsec Usage Question Hi Ofer | |>This example MUST work. So you cannot require inner == outer |>address, because that translates into saying that IP Storage cannot be |>protected by a site to site IPsec tunnel. | |This is not Kansas any more... The iSCSI devices on both sites |(assuming |that's their only IPsec protection) are not iSCSI compliant. This |definitely |doesn't cover the IPsec protection mandated by iSCSI. | | Regards, | Ofer Could you elaborate on this. Why would such devices be in violation of the iSCSI spec? Thanks. Vince |-----Original Message----- |From: Ofer Biran [mailto:BIRAN@il.ibm.com] |Sent: Monday, February 04, 2002 9:30 PM |To: Paul Koning |Cc: Black_David@emc.com; marjorie_krueger@hp.com; ips@ece.cmu.edu |Subject: RE: IPsec Usage Question | | | |Paul, | |>This example MUST work. So you cannot require inner == outer |>address, because that translates into saying that IP Storage cannot be |>protected by a site to site IPsec tunnel. | |This is not Kansas any more... The iSCSI devices on both sites |(assuming |that's their only IPsec protection) are not iSCSI compliant. This |definitely |doesn't cover the IPsec protection mandated by iSCSI. | | Regards, | Ofer | | |Ofer Biran |Storage and Systems Technology |IBM Research Lab in Haifa |biran@il.ibm.com 972-4-8296253 | | |Paul Koning @ece.cmu.edu on 05/02/2002 00:17:54 | |Sent by: owner-ips@ece.cmu.edu | | |To: Black_David@emc.com |cc: marjorie_krueger@hp.com, ips@ece.cmu.edu |Subject: RE: IPsec Usage Question | | | |>>>>> "BlackG" == Black David writes: | | BlackG> AFAIK, IPsec has no standard or widely deployed mechanism for | BlackG> handling gateway discovery or address association | BlackG> dynamically. | |True. | |But let's consider a very common IPsec deployment scenario. I think |this is actually the predominant one, but let's not argue about that; |it certainly is quite common. | |Scenario: two sites, each with an IPsec gateway, and an IPsec tunnel |set up between the two sites. All traffic between the two sites goes |through the tunnel. (This is the classic IPsec based VPN scenario.) | |The way this is handled is simply by configuring the routing tables on |the two IPsec gateways to forward to the other site through the |tunnel. As far as the other nodes on the two sites is concerned, the |other site is simply reachable via ordinary IP mechanisms, and the |existence of the tunnel, or the addresses used in the outer headers, |are none of its concern. And of course the IP addresses of the inner |header cannot possibly equal those of the outer header in this |example. | |This example MUST work. So you cannot require inner == outer |address, because that translates into saying that IP Storage cannot be |protected by a site to site IPsec tunnel. | |Now for a different case: if you use tunnel mode to protect traffic |for a single node (a common case for laptops, so this is often called |the "road warrior" case) then it may well be useful to allow inner == |outer. Some road warrior OS types will want that, others don't care |so much, so it can be a simplifying approach. I have no objection at |all to saying that inner == outer is useful, and for that matter I can |go along with saying inner == outer should be supported. But, either |way, inner != outer must be supported. | | paul | | | | From owner-ips@ece.cmu.edu Tue Feb 5 17:13: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 RAA21332 for ; Tue, 5 Feb 2002 17:13:54 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g15Lfph01924 for ips-outgoing; Tue, 5 Feb 2002 16:41:51 -0500 (EST) 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 g15Lfnj01919 for ; Tue, 5 Feb 2002 16:41:49 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel12.hp.com (Postfix) with ESMTP id 8150B60086A for ; Tue, 5 Feb 2002 13:41:43 -0800 (PST) Received: from swathi (pal1nai161237.nsr.hp.com [15.244.161.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id NAA00529 for ; Tue, 5 Feb 2002 13:43:21 -0800 (PST) Message-ID: <009d01c1ae8d$e66205d0$eda1f40f@rose.hp.com> From: "Mallikarjun C." To: "ips" References: Subject: Re: iSCSI: No Framing Date: Tue, 5 Feb 2002 13:41:41 -0800 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > To prevent fracturing of the market and creating standards competition > within IETF, FIM should be removed from the iSCSI draft. Just to make my original comment (about the potential for fracturing) clear - I *do not* believe defining FIM in iSCSI draft itself fractures the market. IMO, a market fracture can happen only if two conditions are met - a) if FIM is not mandated to implement (i.e. required as a SHOULD), AND b) if % of NICs is evenly split between those that can and those that can not (that a SHOULD enables) do framing. Perhaps we should consider mandating FIM just for iSCSI *hardware* implementations (similar to what we did for Node Name configurability, and ISID partition) if all NIC vendors are going to do it anyway - while leaving the software aside. That essentially ensures that (b) above is not ever satisfied. I am not unduly concerned about software_senders->NIC_receivers delivering lower performance (than NIC->NIC combination) - since that's true anyway. As Julian implied earlier, the evolution of this for iSCSI-2 could be to mandate a better generic alternative - if one exists by then. Comments? -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ----- Original Message ----- From: "Douglas Otis" To: Cc: "Tsvwg" Sent: Tuesday, February 05, 2002 11:01 AM Subject: RE: iSCSI: No Framing > Julian, > > Discussion regarding the concept of framing using FIM within iSCSI is a > valid topic at this time. I disagree strongly with your statement about the > market not becoming fractured. With this topic to be decided shortly, now > is my opportunity to speak. > > A generalized scheme for implementing DDP is relevant as opposed to one that > is proprietary and application specific. Yes, I know it is using the four > letter word SCTP. There is about to be a document released illustrating DDP > using SCTP. It removes the application specific nature of this endeavor and > does not impact existing TCP implementations or network layering. SCTP > provides a far superior solution when attempting Direct Data Placement, the > rational for FIM within iSCSI. iSCSI APIs need not change to introduce SCTP > as an alternative transport if implementing this DDP feature in the future. > To prevent fracturing of the market and creating standards competition > within IETF, FIM should be removed from the iSCSI draft. Transition to SCTP > for this feature and do not add layers to TCP. > > Doug > > David, > > Dough is continuing his rumblings - whether they are relevant to us or not. > I wonder if there is some administrative measure you can take to save us > some bandwidth or we should install our own > "Otis filters". > > Julo > > Julian, > > Implementing a scheme for doing direct data placement by means of an > application specific, undocumented or proprietary layer below TCP will > fracture the market. This will result in an unacceptable outcome having > hardware created for each application, limited by various vendors making as > yet unknown claims, if implementing the DDP feature using TCP. In the > future, should this feature become desired, iSCSI can adopt a generic method > that is possible through the use of SCTP. An eventual adoption of SCTP > would also simplify much of the existing complexity found with the > multi-connection TCP standard now proposed for iSCSI. Use of SCTP would > allow common hardware for many protocols desiring Direct Data Placement > without modification of the SCTP transport as it can deliver objects > unordered. A shim providing the DDP feature could ensure objects are > disclosed in the order sent if desired, independent of the reception at the > shim while not modifying SCTP or adding layers beneath this transport as > would be required for TCP. > > Only when constrained to conventional memory allocation, does DDP become > beneficial. The concept of placing a layer beneath TCP that structures an > array to hold each individual packet based on application specific > structures is fundamentally flawed. This presumes the layer beneath TCP > knows before hand the content of the byte stream prior to TCP composing the > stream. This lower layer will also need to create exceptions for handling > duplicates, for placement information not aligned with the TCP segment, and > for application informational errors. SCTP can easily avoid these > exceptional cases making such development less disruptive. In addition, an > SCTP stack that does not offer DDP in hardware need not change the API > behavior to the application nor modify any layer functionality. > > The ability of SCTP to support many different higher level protocols comes > from the capability of SCTP to deliver objects unordered. TCP's restriction > on ordered delivery mandates that any direct data placement is done prior to > TCP through the addition of a new and application unique layer between IP > and TCP. The saving caveat has been that disclosure to TCP of these packets > are sequential but the application interface to TCP will change as a result > of this modification in some undefined way to associate the steering > information with the desired buffers. This change impacts the interface > between this new layer, as well as the application and TCP. The desire to > keep this DDP scheme for TCP proprietary will ensure a fractured market in > terms of hardware, OS services, and perhaps interchange not to mention that > each application then also needs unique hardware. The security risks > involved in creating this new and highly complex layer below TCP is yet > unknown as details are lacking. In essence, an attempt to implement DDP by > creating a new layer beneath TCP in a proprietary fashion is in direct > competition with the far better practice of using SCTP to implement DDP. > > Doug > > From owner-ips@ece.cmu.edu Tue Feb 5 19:42: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 TAA26065 for ; Tue, 5 Feb 2002 19:42:05 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g15NiQL11346 for ips-outgoing; Tue, 5 Feb 2002 18:44:26 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mms2.broadcom.com (mms2.broadcom.com [63.70.210.59]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g15Nccj10938 for ; Tue, 5 Feb 2002 18:38:38 -0500 (EST) Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom MMS-2 SMTP Relay (MMS v4.7)); Tue, 05 Feb 2002 15:37:25 -0800 X-Server-Uuid: 2a12fa22-b688-11d4-a6a1-00508bfc9626 Received: from nt-irva-0701.broadcom.com (nt-irva-0701 [10.5.10.97]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id PAA26614; Tue, 5 Feb 2002 15:38:36 -0800 (PST) Received: by nt-irva-0701.broadcom.com with Internet Mail Service ( 5.5.2653.19) id ; Tue, 5 Feb 2002 15:38:36 -0800 Message-ID: <8DC1D21AADB9D411A6A000508BC7405A015F2CD2@nt-irva-0701.broadcom.com> From: "Uri Elzur" To: "WENDT,JIM (HP-Roseville,ex1)" , ips@ece.cmu.edu Subject: RE: iSCSI: No Framing Date: Tue, 5 Feb 2002 15:38:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 107EB33F452842-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jim I'd like to add our input to the "live discussion" (hoping we can reach broader consensus and closure in the Interim): We've analyzed the various proposals for long time. As the fundamentals of iSCSI is transmitting messages on top of a byte stream mechanism i.e. TCP, we share the views it needs to be addressed in a standard way. The preferred way to do it has been a generic Framing on top of TCP, but the recent IETF decisions has made it clear that this will not be available for some time, at least not on top of TCP. Therefore, we're back to square zero. iSCSI is better served with a Framing support that enjoys vendors support and that can also prevent a slow Initiator from placing high buffering requirements on a fast Target, running at 1Gb/s or 10Gb/s. So my conclusion has to be that IPS is better off with adoption of Markers that are not hard for HW or SW. FIM vs. COWS: FIM is preferred. COWS will drag the group to even more discussions on mode selection and impact on SW Initiators. We should leave room for negotiation of another Framing mechanism in the future, that may be the result of the TSVWG group efforts. SHOULD vs. MAY vs. MUST: we may have enough support in the WG for a MUST, but it seems to me that the bare minimum is to make sure FIM is supported without introducing interoperability risks. But if there isn't enough support for a MUST, at least we need to make sure the spec is very clear on Framing. Hence, the bare minimum is that Framing support is integrated into the Login negotiation and the all mechanics nailed down (e.g. FIM initialization, edge cases e.g. Marker inside the iSCSI PDU header etc.) thx Uri -----Original Message----- From: WENDT,JIM (HP-Roseville,ex1) [mailto:jim_wendt@hp.com] Sent: Tuesday, January 29, 2002 10:47 PM To: ips@ece.cmu.edu Subject: iSCSI: No Framing Perhaps we should discuss the possibility of not specifying any framing mechanism (FIM or COWS) in the first version of iSCSI. The arguments for not specifying framing include (there may be others as well): 1) The brute force approach of putting TCP receiver reassembly memory on the iSCSI NIC will work for both 1Gbps and 10Gbps. Cost is incurred for memory chips, ASIC pins, power, and board space. But, it is a feasible approach. 2) I/O bus latency (or bandwidth limitations) could mandate inbound buffering (as a 'smoothing' buffer) from the iSCSI NIC to the host system. If this buffer memory is large enough to have to be off-chip, then it will require some minimum number of memory chips to provide the necessary bandwidth, and the memory/pins/power/space costs will be incurred anyway. 3) Very large receive buffering on the NIC is only required for high-bandwidth links traversing large geographic distances (which may not be the predominate case). These specialized implementations can cost more (e.g. more memory/power/pins/etc) and customers will likely be willing to pay accordingly. 4) Many NICs will likely aspire to be combo iSCSI+TOE+Ethernet NICs allowing the host system to use a single Ethernet port for all of its network communications. The TOE function on this combo NIC will already require TCP receive buffering and off- chip buffer memory to support the existing sockets interface receive model. More importantly, to allow senders to assume ownership of the buffer upon return from a socket send call, the TOE NIC would need to copy application send buffers into NIC memory as well. 5) The framing/marker mechanism will be an iSCSI-only solution. It is quite possible that the problem will be solved via a different, and hopefully more general, mechanism for other ULPs. 6) Both FIM and COWS are poor solutions for software implementation. COWS requires, at a minimum, the sender to read every word in the buffer. FIM either imposes additional sender gather processing (iovecs) or requires a data buffer copy (on systems that don't support HW gather on sends). 7) Unless all senders thoroughly test framing/markers now (i.e. unless the framing method is a MUST implement), there is potential for future interoperability problems as framing/marker receivers are deployed in the future. 8) Neither FIM nor COWS is an elegant solution. Are we comfortable with the legacy we are creating under the umbrella of state-of-the-art IP networked storage? 9) Is it essential to build in forward compatibility now, or will there be a different solution in the 10Gbps or 40Gbps timeframe - perhaps involving iSCSI- 2? Will it be reasonable to update or bridge initial 1Gbps deployments? So, it would be good to hear from several iSCSI NIC/chip implementors who: - have or plan to implement FIM or COWS (or some other framing mechanism) and take advantage of it to minimize demands on on-NIC buffer memory bandwidth/quantity. - believe that all-buffers-on-chip solutions are feasible and valid (wrt the points above, including #2) - can quantify the memory/pin/power/space cost savings for all-buffers-on-chip solutions Jim From owner-ips@ece.cmu.edu Tue Feb 5 19:46: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 TAA26193 for ; Tue, 5 Feb 2002 19:46:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1608uN13066 for ips-outgoing; Tue, 5 Feb 2002 19:08:56 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1608rj13053 for ; Tue, 5 Feb 2002 19:08:53 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Feb 2002 19:03:37 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0293741F@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: RE: IPsec Usage Question Date: Tue, 5 Feb 2002 19:08:46 -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 IMHO, both Ofer and Paul appear to be right, so let me attempt to explain ... We cannot place general constraints on the extent of an IPsec implementation that happens to be used for IP Storage - if someone wants to implement full IPsec (e.g., additional ciphersuites, IKE ID payloads) and use that functionality to talk to security gateways that are not part of IP Storage implementations, there's nothing we can do to stop this ... and we probably should encourage this sort of thing. The upshot is that the implementation requirements and usage requirements/restrictions being placed on IPsec for securing IP Storage protocols apply only to SAs that have an IP Storage system (e.g., a security gateway that is part of an IP Storage system) at both ends. I don't believe that either of Paul's examples fall into this category as he described them, hence neither would be prohibited by what we do here, and I agree with Ofer that at least Paul's VPN scenario should not be used to motivate iSCSI security requirements. OTOH, Paul's second example could fall into this category if one considered an iSCSI system consisting of multiple initiators bundled with a security gateway, and based on that example, I'm inclined to agree with Paul's contention that requiring inner IP addresses to match outer IP addresses would be a mistake. The fact that IPS usage requirements/restrictions for IPsec only apply to SAs that have IPsec implementations that are part of IP Storage systems at both ends probably needs to be stated somewhere for clarity to avoid others jumping to the conclusion that an IPsec implementation used for IP Storage cannot use additional features when talking to a peer that is not an IP Storage system. 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: Ofer Biran [mailto:BIRAN@il.ibm.com] > Sent: Tuesday, February 05, 2002 4:12 PM > To: Paul Koning > Cc: Black_David@emc.com; marjorie_krueger@hp.com; ips@ece.cmu.edu > Subject: RE: IPsec Usage Question > > > > Paul, > > I only meant that the 2-site tunnel scenario has nothing to > do with the > IPsec protection mandated to be implemented (yes, implemented, > not used) by iSCSI. So I would not use this scenario at all > to conclude > about iSCSI security requirements (outer=inner etc.). > > Regards, > Ofer > > > Ofer Biran > Storage and Systems Technology > IBM Research Lab in Haifa > biran@il.ibm.com 972-4-8296253 > > > Paul Koning @ece.cmu.edu on 05/02/2002 18:52:28 > > Sent by: owner-ips@ece.cmu.edu > > > To: Ofer Biran/Haifa/IBM@IBMIL > cc: Black_David@emc.com, marjorie_krueger@hp.com, ips@ece.cmu.edu > Subject: RE: IPsec Usage Question > > > > Excerpt of message (sent 5 February 2002) by Ofer Biran: > > > > Paul, > > > > >This example MUST work. So you cannot require inner == outer > > >address, because that translates into saying that IP > Storage cannot be > > >protected by a site to site IPsec tunnel. > > > > This is not Kansas any more... The iSCSI devices on both > sites (assuming > > that's their only IPsec protection) are not iSCSI compliant. This > > definitely > > doesn't cover the IPsec protection mandated by iSCSI. > > No, you're mistaken. > > I said nothing about what the iSCSI devices IMPLEMENT. I only talked > about what was IN USE by the customer. In the example, the customer > chose to USE a different security mechanism for reasons of cost, > convenience, site policy, or whatever. > > Remember that the proposed requirement is "required to implement" and > NOT "required to use". > > My interpretation of having "use" be optional is that you also have > the option of securing your traffic via other means. > > Am I right? Or is it the intent of the WG to say that no other > security mechanisms are allowed -- if you want security you MUST use > the one that is mandated in iSCSI nodes? If so, for what reason? > > paul > > > > From owner-ips@ece.cmu.edu Tue Feb 5 20:32: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 UAA27149 for ; Tue, 5 Feb 2002 20:32:38 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g160iFX15236 for ips-outgoing; Tue, 5 Feb 2002 19:44:15 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g160iEj15232 for ; Tue, 5 Feb 2002 19:44:14 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Feb 2002 19:39:01 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937420@CORPMX14> From: Black_David@emc.com To: dotis@sanlight.net, ips@ece.cmu.edu Cc: tsvwg@ietf.org Subject: RE: iSCSI: No Framing Date: Tue, 5 Feb 2002 19:44:10 -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 Julian, > Dough is continuing his rumblings - whether they are relevant to us or not. > I wonder if there is some administrative measure you can take to save us > some bandwidth or we should install our own "Otis filters". Doug is within bounds, but not by much. He's basically correct that: > Discussion regarding the concept of framing using FIM within iSCSI is a > valid topic at this time. [... snip ...] With this topic to be decided > shortly, now is my opportunity to speak. On the other hand, Doug continues to engage in flawed reasoning that shows a lack of respect for other members of the WG. His very next sentence, for example: > A generalized scheme for implementing DDP is relevant as opposed to one that > is proprietary and application specific. The word "proprietary" is an unfortunately typical of Doug: (1) assuming that standardization of certain components and/or interfaces is/are necessary to the use of FIM, (2) failing to acknowledge the existence of implementation approaches that may not require such components or interfaces, AND (3) failing to consider the possibility that standardization of such components or interfaces may not be necessary to interoperability. The result is that here and elsewhere when the IPS WG avoids Doug's invitation to unnecessary standardization, Doug accuses the IPS WG of working in secret on proprietary solutions. Needless to say such accusations are not only groundless, but have also become boring due to excessive repetition. Doug might get more respect for his ideas if he showed more respect for the ideas of others. Nonetheless, it is fair for Doug to advocate that SCTP is the right long-term solution and that FIM is not a step in that direction: > To prevent fracturing of the market and creating standards competition > within IETF, FIM should be removed from the iSCSI draft. Transition to SCTP > for this feature and do not add layers to TCP. One's personal filters are ones own concern - I have a responsibility to pay attention to the contributions of all, but it would help if Doug would remove the words "proprietary" and "secret" from the vocabulary he uses when posting to this list. 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 Feb 5 21:43: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 VAA29520 for ; Tue, 5 Feb 2002 21:43:30 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1624Tb20203 for ips-outgoing; Tue, 5 Feb 2002 21:04:29 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1624Rj20197 for ; Tue, 5 Feb 2002 21:04:27 -0500 (EST) Received: from hightop (hightop.alacritech.com [10.1.1.55]) by smtp.alacritech.com (8.11.2/8.11.2) with SMTP id g1623BQ21898 for ; Tue, 5 Feb 2002 18:03:11 -0800 Reply-To: From: "Joe Gervais" To: Subject: RE: iSCSI: No Framing Date: Tue, 5 Feb 2002 17:55:41 -0800 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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit It seems that markers/framing is an issue open for debate for some time to come. In my mind that indicates that this is still experimental in nature and should be moved to an experimental RFC, outside of the scope of the iSCSI RFC. It seems that this is trying to optimize the case of a high bandwidth, long haul line. Certainly, iSCSI enables that, but also enables a much broader market for IP Storage. As Jim Wendt originally pointed out at the start of the thread, there are solutions today. Maybe these solutions are not as elegant as one would like to architect, but they can be made to work with Gigabit Ethernet and 10 Gigabit Ethernet. I am in favor of moving framing out to an experimental draft, and finishing this standard. Contrary to his opinion, Jim Pinkerton did not hear all TOE/NIC vendors in favor of FIM. Joe Gervais Alacritech -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Somesh Gupta John, I have to point for the record, that I was the one that proposed markers over a year ago (not that many other did not also have this idea). I have also tried to keep this debate at a technical level. There are reasonable folks on both sides of the debate, and we should just continue in that spirit. Somesh > > > -----Original Message----- > > > From: WENDT,JIM (HP-Roseville,ex1) [mailto:jim_wendt@hp.com] > > > Sent: Tuesday, January 29, 2002 10:47 PM > > > To: ips@ece.cmu.edu > > > Subject: iSCSI: No Framing > > > > > > > > > Perhaps we should discuss the possibility of not > > > specifying any framing mechanism (FIM or COWS) in the > > > first version of iSCSI. > > > > > > The arguments for not specifying framing include > > > (there may be others as well): > > > 1) The brute force approach of putting TCP receiver > > > reassembly memory on the iSCSI NIC will work for both > > > 1Gbps and 10Gbps. Cost is incurred for memory chips, > > > ASIC pins, power, and board space. But, it is a > > > feasible approach. > > > > > > 2) I/O bus latency (or bandwidth limitations) could > > > mandate inbound buffering (as a 'smoothing' buffer) > > > from the iSCSI NIC to the host system. If this buffer > > > memory is large enough to have to be off-chip, then > > > it will require some minimum number of memory chips > > > to provide the necessary bandwidth, and the > > > memory/pins/power/space costs will be incurred > > > anyway. > > > > > > 3) Very large receive buffering on the NIC is only > > > required for high-bandwidth links traversing large > > > geographic distances (which may not be the > > > predominate case). These specialized implementations > > > can cost more (e.g. more memory/power/pins/etc) and > > > customers will likely be willing to pay accordingly. > > > > > > 4) Many NICs will likely aspire to be combo > > > iSCSI+TOE+Ethernet NICs allowing the host system to > > > use a single Ethernet port for all of its network > > > communications. The TOE function on this combo NIC > > > will already require TCP receive buffering and off- > > > chip buffer memory to support the existing sockets > > > interface receive model. More importantly, to allow > > > senders to assume ownership of the buffer upon return > > > from a socket send call, the TOE NIC would need to > > > copy application send buffers into NIC memory as > > > well. > > > > > > 5) The framing/marker mechanism will be an iSCSI-only > > > solution. It is quite possible that the problem will > > > be solved via a different, and hopefully more > > > general, mechanism for other ULPs. > > > > > > 6) Both FIM and COWS are poor solutions for software > > > implementation. COWS requires, at a minimum, the > > > sender to read every word in the buffer. FIM either > > > imposes additional sender gather processing (iovecs) > > > or requires a data buffer copy (on systems that don't > > > support HW gather on sends). > > > > > > 7) Unless all senders thoroughly test framing/markers > > > now (i.e. unless the framing method is a MUST > > > implement), there is potential for future > > > interoperability problems as framing/marker receivers > > > are deployed in the future. > > > > > > 8) Neither FIM nor COWS is an elegant solution. Are > > > we comfortable with the legacy we are creating under > > > the umbrella of state-of-the-art IP networked > > > storage? > > > > > > 9) Is it essential to build in forward compatibility > > > now, or will there be a different solution in the > > > 10Gbps or 40Gbps timeframe - perhaps involving iSCSI- > > > 2? Will it be reasonable to update or bridge initial > > > 1Gbps deployments? > > > > > > > > > So, it would be good to hear from several iSCSI > > > NIC/chip implementors who: > > > - have or plan to implement FIM or COWS (or some > > > other framing mechanism) and take advantage of it to > > > minimize demands on on-NIC buffer memory > > > bandwidth/quantity. > > > - believe that all-buffers-on-chip solutions are > > > feasible and valid (wrt the points above, including > > > #2) > > > - can quantify the memory/pin/power/space cost > > > savings for all-buffers-on-chip solutions > > > > > > Jim > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Tue Feb 5 21:50: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 VAA29709 for ; Tue, 5 Feb 2002 21:50:10 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g161dAE18693 for ips-outgoing; Tue, 5 Feb 2002 20:39:10 -0500 (EST) 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 g161PYj17819 for ; Tue, 5 Feb 2002 20:25:34 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 5 Feb 2002 17:25:24 -0800 Received: from 131.107.3.78 by pv2fd.pav2.hotmail.msn.com with HTTP; Wed, 06 Feb 2002 01:25:23 GMT X-Originating-IP: [131.107.3.78] From: "Bernard Aboba" To: ips@ece.cmu.edu Subject: Proposed changes to IPS security draft -07 Date: Tue, 05 Feb 2002 17:25:23 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Feb 2002 01:25:24.0286 (UTC) FILETIME=[26937DE0:01C1AEAD] Sender: owner-ips@ece.cmu.edu Precedence: bulk Find enclosed a pointer to the changes proposed for inclusion in IPS security draft -08. Comments welcome. http://www.drizzle.com/~aboba/RDMA/changes08.txt _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. From owner-ips@ece.cmu.edu Tue Feb 5 23: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 XAA02459 for ; Tue, 5 Feb 2002 23:27:37 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g163HkN24980 for ips-outgoing; Tue, 5 Feb 2002 22:17:46 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from Gregorio.Stanford.EDU (Gregorio.Stanford.EDU [171.64.66.243]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g163Hij24975 for ; Tue, 5 Feb 2002 22:17:44 -0500 (EST) Received: from Pescadero.DSG.Stanford.EDU (Pescadero.DSG.Stanford.EDU [171.64.79.21]) by Gregorio.Stanford.EDU (8.11.6/8.9.1) with ESMTP id g163HJP01042; Tue, 5 Feb 2002 19:17:20 -0800 Message-Id: <200202060317.g163HJP01042@Gregorio.Stanford.EDU> To: "Peglar, Robert" cc: ips@ece.cmu.edu Subject: Re: iSCSI: No Framing In-reply-to: Your message of "Mon, 04 Feb 2002 14:21:22 CST." Date: Tue, 05 Feb 2002 19:09:41 -0800 From: Jonathan Stone Sender: owner-ips@ece.cmu.edu Precedence: bulk In message , "Peglar, Robert" writes: >The original thread began with a question (paraphrased) about '...what >applications could consume a 10G pipe for long periods of time'. I answered >that question - disk-disk backup and subsystem replication. Even disk-to-disk applications or backup applications really want approximately BW*RTT worth of buffering. Hugh Holbrook's recent Stanford PhD thesis traces the conventional wisdom back to an email from Van Jacobson to the e2e list in 1990. It's reasonably well-known in the TCP community that TCP slow-start generates spiky traffic. It leads to bursts of high buffer occupancy (e.g., at the point where the exponential rampup switches to congestion avoidance.) Indeed, that was the motivation behind TCP-Vegas, and the recent work on TCP pacing. The whole debate over framing/marking only makes sense if one views outboard NIC buffering of RTT*BW as very expensive (e.g., forcing a design from onchip RAM to external SRAM). Adding framing of iSCSI PDUs allows the NIC to continue doing direct data placement into host buffers, accomodating the BW*RTT of TCP buffering in "cheap" host RAM rather than "expensive" NIC RAM. But you can't get away from providing the buffers. Not unless you are also willing to artificially restrict throughput. If iSCSI doesn't provide some form of framing, then what can a NIC on a MAN with medium BW*RTT do, if it sees a drop? It has only a few choices: 1. start buffering data outboard, hoping that TCP fast-retransmit will send the missing segment(s) before the outboard buffers are exhausted; 2. Give up on direct data placment, and start delivering packets to host memory, any old how --at the cost of SW reassembly and alignment problems, and a software CRC, once the missing segment is recovered. 3. Start dropping packets, and pay a huge performance cost. There are some important caveats around the BW*RTT: if we can *guarantee* that the iSCSI NICs are never the bottleneck point, or that TCP never tries to reach the true link BW*RTT (due to undersized windows), then one can get away with less. (See Hugh Holbrook's thesis for more concrete details). But the lesson to take away is that even in relatively well-behaved LANs, TCP *by design* is always oscillating around overloading the available buffers, causing a drop, then backing off. See, for example, Figure 2 of the paper by Janey Hoe which introduced "New Reno"; or Fig. 2 and 3 of the paper by Floyd and Fall. New Reno avoids the long-timeouts between each drop, but the drops themselves still occur. Moral: TCP can require significant buffering even on quite modest networks. It __may__ be worth keeping framing, so that host NICs can do more of that buffering in host memory rather than outboard; and so they can continue performing DDP rather than software reassembly and software CRC checking. Storage devices are another issue again. References: Van Jacobson, modified TCP congestion avoidance algorithm. Email to end2end@isi.edu, April 1990. L Brakmo, , S O'Malley, L Peterson, TCP Vegas: new techniques for congestion detection and control, SIGCOMM 94. J Kulik, R Coulter, D Rockwell, and C Partridge, A simulation study of paced TCP. BBN TEchnical Memorandum 1218, BBN, August 1999. J Hoe, Improving the Startup Behaviour of a Congestion Control Scheme for TCP, ACM SIGCOMM 1996, S Floyd and K Fall, Simulation-based comparisons of Tahoe, Reno, and SACK TCP, Comp. COmm. Review no 6 v 3, April 1996. H Holbrook. A Channel Model for Multicast. PhD Dissertation. Department of Computer Science. Stanford University. August, 2001. http://dsg.stanford.edu/~holbrook/thesis.ps{,.gz}. (See Chapter 5.) (Holbrook cites Aggrawal, Savage, and Anderson, INFOCOMM 2000, on the downsides of TCP pacing; but I haven't read that. The PILC draft on link designs touch the same issue, but the throughput equations cited there factor out buffer size.) >FC is not sufficient. Storage-to-storage needs all the advantages as well >as that which iSCSI has to offer the host-storage model. But it will still need approximately BW*RTT of buffering, even for low-delay LANS. Or performance will fall off a cliff under "congestion" -- e.g., each time some other iSCSI flow starts up, begins competing for the same TCP endpoint buffers, on the same iSCSI device, and triggering a burst of TCP loss events for the storage-to-storage flow. From owner-ips@ece.cmu.edu Wed Feb 6 01:56: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 BAA04930 for ; Wed, 6 Feb 2002 01:56:23 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g165wlC04451 for ips-outgoing; Wed, 6 Feb 2002 00:58:47 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c003.snv.cp.net (c003-h000.c003.snv.cp.net [209.228.32.214]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g165wkj04447 for ; Wed, 6 Feb 2002 00:58:46 -0500 (EST) Received: (cpmta 16756 invoked from network); 5 Feb 2002 21:58:35 -0800 Received: from 64.130.130.105 (HELO dougrmt) by smtp.telocity.com (209.228.32.214) with SMTP; 5 Feb 2002 21:58:35 -0800 X-Sent: 6 Feb 2002 05:58:35 GMT From: "Douglas Otis" To: Cc: Subject: RE: iSCSI: No Framing Date: Tue, 5 Feb 2002 22:00:22 -0800 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.2910.0) Importance: Normal In-Reply-To: <277DD60FB639D511AC0400B0D068B71E02937420@CORPMX14> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, > Julian, > > > Dough is continuing his rumblings - whether they are relevant to us or > > not. I wonder if there is some administrative measure you can take to > > save us some bandwidth or we should install our own "Otis filters". > > Doug is within bounds, but not by much. He's basically correct that: > > > Discussion regarding the concept of framing using FIM within iSCSI is a > > valid topic at this time. [... snip ...] With this topic to be decided > > shortly, now is my opportunity to speak. > > On the other hand, Doug continues to engage in flawed reasoning that shows > a lack of respect for other members of the WG. His very next sentence, > for example: > > > A generalized scheme for implementing DDP is relevant as opposed to one > > that is proprietary and application specific. > > The word "proprietary" is an unfortunately typical of Doug: > (1) assuming that standardization of certain components and/or interfaces > is/are necessary to the use of FIM, FIM makes absolutely no sense following TCP. Advantages for FIM are realized if done prior to placement within system memory as typified by the general understanding this scheme is for NIC vendors. Whether it is done using specialized hardware, intelligent adapters, or software, the goal, as often stated, is to reduce buffering required in the event of packet loss. TCP is unable to deliver network traffic during such an event, and FIM is a scheme to allow a layer prior to TCP to interpret "as an application" the expected byte stream "out of sequence" as a means to steer encapsulated payloads. A generalization of this would be described as direct data placement. If done using a protocol employing the TCP transport, a layer must be added ahead of TCP, which would be, without documentation, a "privately owned" layer. Privately owned as such details of this layer are not shared publicly. This layer may be hardware or an intelligent adapter, or it could be a software solution within a memory starved CPU. Without documentation describing the information exchanged between the application and TCP, together with the states involved in this process, any efforts to extrapolate the details of this layer are likely to venture into proprietary areas. A means of avoiding this problem would be to document the basics and thereby make such a process public. It would also afford an ability for review. > (2) failing to acknowledge the existence of implementation approaches that > may not require such components or interfaces, AND Proprietary does not imply hardware although in this case it is a high probability that hardware or an intelligent adapter would implement this layer. Unfortunately, the use of TCP will also require that actions of this "synchronization and steering" layer will be unique for each application. This is a significant problem that is completely overcome through the use of SCTP. > (3) failing to consider the possibility that standardization of such > components or interfaces may not be necessary to interoperability. This is difficult to determine due to the lack of details. It is also difficult to judge security risks for the same reason. At this point, it is a black box. As this layer must anticipate the behavior of TCP, it would be wise to expose techniques used for doing so and this should be done within the tsvwg for a broader range of expertise. There is also a requirement for associations to be made between buffers and application specific structures communicated in some fashion from the application to this layer. > The result is that here and elsewhere when the IPS WG avoids Doug's > invitation to unnecessary standardization, Doug accuses the IPS WG > of working in secret on proprietary solutions. The IPS wg has demonstrated a desire to institute a scheme for incorporating direct data placement as a generalization of this feature allowed through the use of FIM. A noble goal. This desire has manifested itself as drafts designed to implement framing using Urgent Pointers, Fixed Interval Markers, Byte Stuffing, to an all out mandated framing of TCP as detected by segment length. This "improvement" to TCP was initiated at the pre-BOF for IPS and has not relented. I have never invited change to TCP, but rather strongly urged the wg to consider SCTP as an alternative solution for DDP versus these "improvements" to TCP. My continued opposition to these ideas have not won me any popularity as I still view these concepts as a kludge and a corruption of network layering. My reasoning for pressing this issue is not to prevent framing, but to suggest a better practice for achieving this feature. Failing that, have the iSCSI draft document the interface and states involved in this "synchronization and steering" layer to assist efforts in the creation of a generalized scheme for DDP using SCTP. This would ensure migration from this application specific layer if it were to become used in practice. The benefits of FIM would be marginal at this time as targets can use techniques to avoid the need for relocating buffers without the use of framing. This should allow time for deployment of generalized schemes at the clients using SCTP. NIC vendors would reap a larger return on their investment when offering a generalized feature as there would be a greater opportunity for its use. DDP could be employed in many protocols such as RPC as one example, in addition to SCSI without introducing complex layers beneath the transport. > Needless to say such accusations are not only groundless, but have also > become boring due to excessive repetition. Doug might get more respect > for his ideas if he showed more respect for the ideas of others. > Nonetheless, it is fair for Doug to advocate that SCTP is the right > long-term solution and that FIM is not a step in that direction: > > > To prevent fracturing of the market and creating standards competition > > within IETF, FIM should be removed from the iSCSI draft. Transition to > > SCTP for this feature and do not add layers to TCP. > > One's personal filters are ones own concern - I have a responsibility to > pay attention to the contributions of all, but it would help if Doug > would remove the words "proprietary" and "secret" from the vocabulary > he uses when posting to this list. I should have started my response at the bottom and worked my way up. By "proprietary", I am referring to private. If you see private, think proprietary and vice versa. I believe I am using this word correctly. I have not used the word "secret" except to comment about the NDT header offered by Julian. In that header is a "shared secret" field. My comment was that CRC does not mask the "shared secrets" or something to that effect. I apologize if this is becoming boring, but do not think my concerns are groundless. It has been a long process, however. Again, thank you for your response. Doug > > 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 Feb 6 06:12: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 GAA16813 for ; Wed, 6 Feb 2002 06:12:05 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g16A0Ff17131 for ips-outgoing; Wed, 6 Feb 2002 05:00:15 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c003.snv.cp.net (c003-h016.c003.snv.cp.net [209.228.32.230]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g16A0Dj17127 for ; Wed, 6 Feb 2002 05:00:13 -0500 (EST) Received: (cpmta 7550 invoked from network); 6 Feb 2002 02:00:06 -0800 Received: from 64.130.130.105 (HELO dougrmt) by smtp.telocity.com (209.228.32.230) with SMTP; 6 Feb 2002 02:00:06 -0800 X-Sent: 6 Feb 2002 10:00:06 GMT From: "Douglas Otis" To: Cc: Subject: RE: [Tsvwg] RE: iSCSI: No Framing Date: Wed, 6 Feb 2002 02:01:54 -0800 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.2910.0) Importance: Normal In-Reply-To: <20020205222153.A23964@openss7.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > David, > > On Tue, 05 Feb 2002, Black_David@emc.com wrote: > > > The result is that here and elsewhere when the IPS WG avoids Doug's > > invitation to unnecessary standardization, Doug accuses the IPS WG > > of working in secret on proprietary solutions. > > What's the matter with that? I would say that 80-90% of > those lurking on these working groups are doing exactly that: > working in secret on proprietary solutions; forming trade > secrets to embed in their implementations; and patenting > whatever the can to encumber the competition. That's just the > way of the world. > > As with any other standard body, IETF standards represent a > tenuous balance between interoperability and proprietary > implementation. Even so, the number of proprietary (and > patented) protocols proliferate the RFC servers as > "Informational" and some even as proposed standards with > Intellectual Property claims. By placing these concepts into the public forum, that marks the end in which "invented here" can be claimed and those organizations participating are expected to volunteer aspects they consider "proprietary." You are right that such is often the case and hence the general agreement for disclosure. > I find it hard to believe that a tortuous approach that has > only short-term viability is going to have such a deterious > effect in an industry that holds the trade secret and > intellectual property rights in so high an etseem. > > (I would invite Doug to re-read the copyright disclaimer > on all RFCs.) I am aware of the disclaimer. I am also aware of the need for review. There are many other applications clamoring for this "useful" dodge. It can be done in a haphazard fashion, or this transition toward Direct Data Placement can be done with little disruption to existing software and equipment. There is already an RDMA group wishing to form as well as other clustering schemes that desire this ability, in addition to iSCSI. > What will this market be fractured into? Those with trade > secrets and those without? Or is this a Beta vs. VHS thing? There will always be trade secrets or proprietary information regarding any solution offered by a vendor. Each has their investment to protect. The greatest danger regarding something as basic as a network interface comes from the vendors. Should a vendor lay claim to a means of accomplishing the interface to this beneath TCP "synchronization and steering" layer, then applications will be forced to modify their interface significantly between systems. In essence, it would be Beta vs VHS with respect to something that should remain ubiquitous. > At least the draft provides some basis for interoperability > and addresses the extent to which those taking this short-term > blind alley are willing to reveal their plans to each other. > > So how will it be fractured?--Into those up the blind alley > and those in the traffic jam? There are already many proprietary schemes in the market and the IETF has not prevented any vendor from entering that arena whether they are blind allies or not. The IETF should take the long view and strive to prevent unnecessary disruption to existing technology used within IP. SCTP offers the necessary features and protections to allow Direct Data Placement to be deployed without disruption. A clever state machines running beneath TCP attempting to anticipate TCP will likely work in the general case, but then fail completely when confronting a new and untried piece of equipment that does something unexpected. In that case, who would be at fault? You would have nothing upon which to judge the cause of the failure. Was it due to the application not properly monitoring this undefined status coming for the "synchronization and steering" layer beneath TCP? Was it the state machine within the S&S layer? There is nothing like complexity to allow a large company to dominate however. : ) > Please Doug, if there is a technical (not political) basis > on which this draft is somehow flawed, please express it. > You seem so vehemenently opposed to this draft over the > last number of months: surely there is some technical basis > upon which your first aversions were based. I think that the concept of network layering where functions are concisely defined is a technical aspect and not a political one. That does not mean, there are not politics at play. When you introduce a layer below the transport that manipulates a partial data stream on behalf of the application, you have thrown the concept of layering out the window. This goes well beyond techniques already on the fridge such as packet filters or ALGs within NATs. Here you would have continuous interchange between this S&S layer and the application. I must admit I am not surprised by the opposition to a ready made solution that preserves network layering while offering virtually every possible innovation. The storage industry rightfully considers themselves an industry unto themselves. It is also not surprising the zeal in their attacking perceived problems. It has been my privilege to work in this industry and networking for a quarter of a century. Working within the tape industry, I have also learned that it is difficult to make a difference in the direction the disk industry takes. The disk cadre and their barbs require a relatively thick skin if you wish to oppose their consensus. My resource in this effort is an annoying persistence. It may take a prolonged period for what may appear as a minor detail. > If it is the protocol layer boundary violations that concern > you, what is the technical (rather than preceived market) > disadvantages of such violation? This new layering concept is not without its risks as it devises placement of information prior to the protections offered by the transport. It does so in perhaps a dangerously predictable manner in that the location of the marking scheme may easily be spoofed later in time. This S&S layer through the use of a highly predictable marker is intended to allow "out of sequence" segments to be placed. Depending on how a duplication problem is handled within this S&S layer, evidence of this event may be obscured. There is also opportunity for information to be diverted by means of the communication sent to the S&S layer. As this layer is below the transport, this link may suffer weaknesses not present at the more robust API for the transport itself. If this communication is present at the transport API, it should be documented to allow applications consistent essential constructs when supporting this feature. > It is only on the basis of technical or procedural error that > an appeal can be honestly and successfully lodged under the > IETF process anyway and you had certainly better air those > technical objections within the WG first. I see the function of the IETF in broad terms. There is a general architecture that is being created in addition to individual protocols. This process should not opt for a proprietary solution (sorry David) especially making such a Must, Should, or even Recommended within a draft when the IETF has already provided a technically superior competing solution. SCTP is years ahead on this curve, and although the IPS wg is good, there is no doubt which is the technically superior solution. Although David has done an admirable job point out the lines I should not cross, I too feel there have been some lines crossed. > Could you provide a summarized list of your technical > objections with proposed solutions so that others in the > WG can comment? I think that I have indicated my concerns and these areas are judgment calls for those responsible perhaps should framing remain within the iSCSI draft. More than a year ago my opposition to the use of the TCP Urgent Pointer for framing caused a similar conflict between David and myself and perhaps set the stage for this friendly give and take. One might say that necessity is the mother of invention, but in this case, it is not necessity as SCTP is a ready made solution for this framing and layering problem. I think that if the IPS wg could see past creating new solutions for a problem already solved, they would be months, if not years, ahead. It is a minor point, remove the FIM from the iSCSI draft and forego use of a layer beneath TCP for the reasons stated. Doug > There might be several solutions that might > lead to improvements even at this late a stage. It is > normally only a technical argument that will lead to concensus > here. (I doubt that the WG chair could ask for comments on > a question concerning market fragmentation and trade secret > plots.) > > --brian > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ From owner-ips@ece.cmu.edu Wed Feb 6 11:30: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 LAA25166 for ; Wed, 6 Feb 2002 11:30:00 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g16Epxb22909 for ips-outgoing; Wed, 6 Feb 2002 09:51:59 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.san.yahoo.com (mail.san.yahoo.com [209.132.1.30]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g16Epvj22904 for ; Wed, 6 Feb 2002 09:51:57 -0500 (EST) Received: from bursar.muttsnuts.com (208.249.65.28) by mail.san.yahoo.com (5.5.056) id 3C584280001C6EB2 for ips@ece.cmu.edu; Wed, 6 Feb 2002 06:51:34 -0800 Message-Id: <5.1.0.14.2.20020206143707.04b4e920@mail.muttsnuts.com> X-Sender: markemuttsnuts@mail.muttsnuts.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 06 Feb 2002 14:48:46 +0000 To: ips@ece.cmu.edu From: "Mark S. Edwards" Subject: Piggyback status gripe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ips@ece.cmu.edu Precedence: bulk Over the last several weeks, I have found myself testing against some version 8 initiators that do not understand that a good status can be carried piggyback fashion in the DATA-IN PDU, as indicated by the 'S' bit. This makes life very difficult for a target, and takes a while to analyse the situation to find out what is wrong. Can I draw initiator writers (especially those in the Windows arena) attention to the text in 3.7 of both draft 8 and draft 9 and the equivalent text in 10.7 of draft 10. Initiators MUST cope with both cases of either a DATA-IN with the 'S' bit set, or a separate SCSI Response PDU, it's not up to the target to telepathically cope with which behaviour the initiator expects. For performance sake, most targets will piggyback the status in the DATA-IN PDU and this hangs a couple of initiators. Could the participants of next weeks Plugfest actively check for this compliance ? Regards, Mark. From owner-ips@ece.cmu.edu Wed Feb 6 12:15: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 MAA26029 for ; Wed, 6 Feb 2002 12:15:14 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g16GPoX00626 for ips-outgoing; Wed, 6 Feb 2002 11:25:50 -0500 (EST) 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 g16GPlj00616 for ; Wed, 6 Feb 2002 11:25:47 -0500 (EST) Received: from xparelay1.corp.hp.com (xparelay1.corp.hp.com [15.58.136.173]) by palrel12.hp.com (Postfix) with ESMTP id 1CA6A600850; Wed, 6 Feb 2002 08:25:42 -0800 (PST) Received: from xpabh3.corp.hp.com (xpabh3.corp.hp.com [15.58.136.223]) by xparelay1.corp.hp.com (Postfix) with ESMTP id 43819E0009B; Wed, 6 Feb 2002 08:25:33 -0800 (PST) Received: by xpabh3.corp.hp.com with Internet Mail Service (5.5.2653.19) id <1KHM23NH>; Wed, 6 Feb 2002 08:25:33 -0800 Message-ID: <499DC368E25AD411B3F100902740AD6508E99F1F@xrose03.rose.hp.com> From: "ERICKSON,SHAWN (HP-Roseville,ex1)" To: "'Lloyd Wood'" , "Brian F. G. Bidulock" Cc: Douglas Otis , tsvwg@ietf.org, ips@ece.cmu.edu Subject: RE: [Tsvwg] RE: iSCSI: No Framing Date: Wed, 6 Feb 2002 08:25:31 -0800 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 As well as... potentially security holes, debug-ability, interoperability. -Shawn ------------------------------------------------------- Shawn Carl Erickson > -----Original Message----- > From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] > Sent: Wednesday, February 06, 2002 7:35 AM > To: Brian F. G. Bidulock > Cc: Douglas Otis; tsvwg@ietf.org; ips@ece.cmu.edu > Subject: Re: [Tsvwg] RE: iSCSI: No Framing > > > On Wed, 6 Feb 2002, Brian F. G. Bidulock wrote: > > > What is lost by throwing layering out the window? > > modularity, ease of understanding, and portability. > > L. > > PGP > From owner-ips@ece.cmu.edu Wed Feb 6 12:15: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 MAA26045 for ; Wed, 6 Feb 2002 12:15:32 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g16GUeO01071 for ips-outgoing; Wed, 6 Feb 2002 11:30:40 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g16GTtj00977 for ; Wed, 6 Feb 2002 11:29:55 -0500 (EST) Received: from phys-hanwk16-1.ebay.sun.com ([129.149.1.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16494; Wed, 6 Feb 2002 09:29:39 -0700 (MST) Received: from jetsun (jetsun.Central.Sun.COM [129.153.128.60]) by phys-hanwk16-1.ebay.sun.com (8.10.2+Sun/8.10.2/ENSMAIL,v2.1p1) with SMTP id g16GTcU25106; Wed, 6 Feb 2002 08:29:38 -0800 (PST) Message-Id: <200202061629.g16GTcU25106@phys-hanwk16-1.ebay.sun.com> Date: Wed, 6 Feb 2002 10:29:38 -0600 (CST) From: David Robinson Reply-To: David Robinson Subject: RE: iSCSI: No Framing To: ips@ece.cmu.edu, dotis@sanlight.net Cc: tsvwg@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 01K7YCLjDOjG288LW9hYeg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_53 SunOS 5.9 sun4u sparc Sender: owner-ips@ece.cmu.edu Precedence: bulk > > The word "proprietary" is an unfortunately typical of Doug: > > (1) assuming that standardization of certain components and/or interfaces > > is/are necessary to the use of FIM, > If done using a protocol employing the TCP transport, a layer must be added > ahead of TCP, which would be, without documentation, a "privately owned" > layer. Privately owned as such details of this layer are not shared > publicly. This layer may be hardware or an intelligent adapter, or it could > be a software solution within a memory starved CPU. Without documentation > describing the information exchanged between the application and TCP, > together with the states involved in this process, any efforts to > extrapolate the details of this layer are likely to venture into proprietary > areas. A means of avoiding this problem would be to document the basics and > thereby make such a process public. It would also afford an ability for > review. What I am failing to understand is how what you describe is any different than the variablity of the design of existing NIC cards. Virtually every NIC card needs its own custom driver for each OS that is supported. Implementing FIM is no different than the multitude of existing checksumming offload NICs. It is true that the hardware is using knowledge of the upper layer protocols, but it is all within the confines of the implementation details. There is no wire protocol implication here. In order to "standardize" these techniques the IETF will be dictating hardware design and/or protocol stack design. While this might be useful for an industry consortium to make portability of software easier, it is not a fundemental IETF issue. In what is essentially an implementation specific communications between layers of a software stack, how can you standardize something that will be uniquely different depending on if the OS uses STREAMS, BSD sockets, Windows XYZ, or custom OS frozbits. This doesn't make sense for the IETF, you may consider going to SNIA to standardize implemenation details. If I am not understanding your point, I suggest that it would be useful for you to write a couple paragraphs suitable for inclusion in a standards document that describes how you would standardize the FIM specification. Without such a concrete proposal I believe we are all just flailing at amorphous ideas and making no progress on this issue. -David From owner-ips@ece.cmu.edu Wed Feb 6 12:18: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 MAA26125 for ; Wed, 6 Feb 2002 12:18:37 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g16GHRr29802 for ips-outgoing; Wed, 6 Feb 2002 11:17:27 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bfgbhome.inetint.com (IDENT:root@tnt-dal-42-200.dallas.net [209.44.42.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g164M9j28736 for ; Tue, 5 Feb 2002 23:22:10 -0500 (EST) Received: (from brian@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id WAA29886; Tue, 5 Feb 2002 22:21:53 -0600 Date: Tue, 5 Feb 2002 22:21:53 -0600 From: "Brian F. G. Bidulock" To: Black_David@emc.com Cc: dotis@sanlight.net, ips@ece.cmu.edu, tsvwg@ietf.org Subject: Re: [Tsvwg] RE: iSCSI: No Framing Message-ID: <20020205222153.A23964@openss7.org> Reply-To: bidulock@openss7.org References: <277DD60FB639D511AC0400B0D068B71E02937420@CORPMX14> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <277DD60FB639D511AC0400B0D068B71E02937420@CORPMX14>; from Black_David@emc.com on Tue, Feb 05, 2002 at 07:44:10PM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk David, On Tue, 05 Feb 2002, Black_David@emc.com wrote: > The result is that here and elsewhere when the IPS WG avoids Doug's > invitation to unnecessary standardization, Doug accuses the IPS WG > of working in secret on proprietary solutions. What's the matter with that? I would say that 80-90% of those lurking on these working groups are doing exactly that: working in secret on proprietary solutions; forming trade secrets to embed in their implementations; and patenting whatever the can to encumber the competition. That's just the way of the world. As with any other standard body, IETF standards represent a tenuous balance between interoperability and proprietary implementation. Even so, the number of proprietary (and patented) protocols proliferate the RFC servers as "Informational" and some even as proposed standards with Intellectual Property claims. I find it hard to believe that a tortuous approach that has only short-term viability is going to have such a deterious effect in an industry that holds the trade secret and intellectual property rights in so high an etseem. (I would invite Doug to re-read the copyright disclaimer on all RFCs.) What will this market be fractured into? Those with trade secrets and those without? Or is this a Beta vs. VHS thing? At least the draft provides some basis for interoperability and addresses the extent to which those taking this short-term blind alley are willing to reveal their plans to each other. So how will it be fractured?--Into those up the blind alley and those in the traffic jam? Please Doug, if there is a technical (not political) basis on which this draft is somehow flawed, please express it. You seem so vehemenently opposed to this draft over the last number of months: surely there is some technical basis upon which your first aversions were based. If it is the protocol layer boundary violations that concern you, what is the technical (rather than preceived market) disadvantages of such violation? It is only on the basis of technical or procedural error that an appeal can be honestly and successfully lodged under the IETF process anyway and you had certainly better air those technical objections within the WG first. Could you provide a summarized list of your technical objections with proposed solutions so that others in the WG can comment? There might be several solutions that might lead to improvements even at this late a stage. It is normally only a technical argument that will lead to concensus here. (I doubt that the WG chair could ask for comments on a question concerning market fragmentation and trade secret plots.) --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From owner-ips@ece.cmu.edu Wed Feb 6 12:20: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 MAA26179 for ; Wed, 6 Feb 2002 12:20:36 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g16GIrk29970 for ips-outgoing; Wed, 6 Feb 2002 11:18:53 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g16FZlj26529 for ; Wed, 6 Feb 2002 10:35:47 -0500 (EST) Received: from phaestos.ee.surrey.ac.uk ([131.227.88.14] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 16YU6I-0006ia-00; Wed, 06 Feb 2002 15:35:10 +0000 Date: Wed, 6 Feb 2002 15:34:51 +0000 (GMT) From: Lloyd Wood X-X-Sender: eep1lw@phaestos.ee.surrey.ac.uk Reply-To: Lloyd Wood To: "Brian F. G. Bidulock" cc: Douglas Otis , , Subject: Re: [Tsvwg] RE: iSCSI: No Framing In-Reply-To: <20020206092354.B23964@openss7.org> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *16YU6I-0006ia-00*dHMzEGl0ovM* (SECM, UniS) Sender: owner-ips@ece.cmu.edu Precedence: bulk On Wed, 6 Feb 2002, Brian F. G. Bidulock wrote: > What is lost by throwing layering out the window? modularity, ease of understanding, and portability. L. PGP From owner-ips@ece.cmu.edu Wed Feb 6 12:21: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 MAA26223 for ; Wed, 6 Feb 2002 12:21:03 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g16GJ1r29987 for ips-outgoing; Wed, 6 Feb 2002 11:19:01 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bfgbhome.inetint.com (IDENT:root@tnt-dal-42-200.dallas.net [209.44.42.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g16GCxj29422 for ; Wed, 6 Feb 2002 11:12:59 -0500 (EST) Received: (from brian@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id KAA08511; Wed, 6 Feb 2002 10:12:28 -0600 Date: Wed, 6 Feb 2002 10:12:28 -0600 From: "Brian F. G. Bidulock" To: Lloyd Wood Cc: Douglas Otis , tsvwg@ietf.org, ips@ece.cmu.edu Subject: Re: [Tsvwg] RE: iSCSI: No Framing Message-ID: <20020206101228.D23964@openss7.org> Reply-To: bidulock@openss7.org References: <20020206092354.B23964@openss7.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from l.wood@eim.surrey.ac.uk on Wed, Feb 06, 2002 at 03:34:51PM +0000 Organization: http://www.openss7.org/ Dsn-Notification-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Lloyd, On Wed, 06 Feb 2002, Lloyd Wood wrote: > On Wed, 6 Feb 2002, Brian F. G. Bidulock wrote: > > > What is lost by throwing layering out the window? > > modularity, ease of understanding, and portability. Modularity can be acheived without layering. The entire field of OOAD proves this. Ease of understanding is acheived through accurate interface description. Again OO shows this. Portability can also be acheived through OO approaches. The classical layering of communications functions into functional groupings is not a necessary condition for any of these benefits. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From owner-ips@ece.cmu.edu Wed Feb 6 12:22: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 MAA26237 for ; Wed, 6 Feb 2002 12:22:01 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g16GIPW29914 for ips-outgoing; Wed, 6 Feb 2002 11:18:25 -0500 (EST) 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 g16Dgfj17818 for ; Wed, 6 Feb 2002 08:42:41 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19557; Wed, 6 Feb 2002 08:42:38 -0500 (EST) Message-Id: <200202061342.IAA19557@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-scsi-mib-01.txt Date: Wed, 06 Feb 2002 08:42:38 -0500 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 : Definition of Managed Objects for SCSI Entities Author(s) : M. Bakke et al. Filename : draft-ietf-ips-scsi-mib-01.txt Pages : 50 Date : 05-Feb-02 This memo defines a Management Information Base (MIB) for Small Computer System Interface (SCSI) entities, independently of the transport layer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-scsi-mib-01.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-scsi-mib-01.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-scsi-mib-01.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: <20020205140747.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-scsi-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-scsi-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020205140747.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Wed Feb 6 12:27: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 MAA26362 for ; Wed, 6 Feb 2002 12:27:19 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g16GlQP02513 for ips-outgoing; Wed, 6 Feb 2002 11:47:26 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bfgbhome.inetint.com (IDENT:root@tnt-dal-42-200.dallas.net [209.44.42.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g16Gdaj01838 for ; Wed, 6 Feb 2002 11:39:36 -0500 (EST) Received: (from brian@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id KAA09097; Wed, 6 Feb 2002 10:39:12 -0600 Date: Wed, 6 Feb 2002 10:39:12 -0600 From: "Brian F. G. Bidulock" To: "ERICKSON,SHAWN (HP-Roseville,ex1)" Cc: "'Lloyd Wood'" , Douglas Otis , tsvwg@ietf.org, ips@ece.cmu.edu Subject: Re: [Tsvwg] RE: iSCSI: No Framing Message-ID: <20020206103912.E23964@openss7.org> Reply-To: bidulock@openss7.org References: <499DC368E25AD411B3F100902740AD6508E99F1F@xrose03.rose.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: <499DC368E25AD411B3F100902740AD6508E99F1F@xrose03.rose.hp.com>; from shawn_erickson@hp.com on Wed, Feb 06, 2002 at 08:25:31AM -0800 Organization: http://www.openss7.org/ Dsn-Notification-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit ERICKSON,SHAWN, These too are better acheived through approaches other than functional grouping. --brian On Wed, 06 Feb 2002, ERICKSON,SHAWN (HP-Roseville,ex1) wrote: > As well as... potentially security holes, debug-ability, interoperability. > > -Shawn > > ------------------------------------------------------- > Shawn Carl Erickson > > > > -----Original Message----- > > From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] > > Sent: Wednesday, February 06, 2002 7:35 AM > > To: Brian F. G. Bidulock > > Cc: Douglas Otis; tsvwg@ietf.org; ips@ece.cmu.edu > > Subject: Re: [Tsvwg] RE: iSCSI: No Framing > > > > > > On Wed, 6 Feb 2002, Brian F. G. Bidulock wrote: > > > > > What is lost by throwing layering out the window? > > > > modularity, ease of understanding, and portability. > > > > L. > > > > PGP > > -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-ips@ece.cmu.edu Wed Feb 6 12:28: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 MAA26384 for ; Wed, 6 Feb 2002 12:28:38 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g16GIim29943 for ips-outgoing; Wed, 6 Feb 2002 11:18:44 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bfgbhome.inetint.com (IDENT:root@tnt-dal-42-200.dallas.net [209.44.42.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g16FO8j25617 for ; Wed, 6 Feb 2002 10:24:08 -0500 (EST) Received: (from brian@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id JAA07447; Wed, 6 Feb 2002 09:23:54 -0600 Date: Wed, 6 Feb 2002 09:23:54 -0600 From: "Brian F. G. Bidulock" To: Douglas Otis Cc: tsvwg@ietf.org, ips@ece.cmu.edu Subject: Re: [Tsvwg] RE: iSCSI: No Framing Message-ID: <20020206092354.B23964@openss7.org> Reply-To: bidulock@openss7.org References: <20020205222153.A23964@openss7.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: ; from dotis@sanlight.net on Wed, Feb 06, 2002 at 02:01:54AM -0800 Organization: http://www.openss7.org/ Dsn-Notification-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Douglas, On Wed, 06 Feb 2002, Douglas Otis wrote: [snip] > > Please Doug, if there is a technical (not political) basis > > on which this draft is somehow flawed, please express it. > > You seem so vehemenently opposed to this draft over the > > last number of months: surely there is some technical basis > > upon which your first aversions were based. > > I think that the concept of network layering where functions are concisely > defined is a technical aspect and not a political one. That does not mean, > there are not politics at play. When you introduce a layer below the > transport that manipulates a partial data stream on behalf of the > application, you have thrown the concept of layering out the window. This > goes well beyond techniques already on the fridge such as packet filters or > ALGs within NATs. Here you would have continuous interchange between this > S&S layer and the application. I must admit I am not surprised by the > opposition to a ready made solution that preserves network layering while > offering virtually every possible innovation. [snip] What is lost by throwing layering out the window? Layering is an artificial categorization of functions at best. What technical advantages are lost? --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-ips@ece.cmu.edu Wed Feb 6 13:05: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 NAA27205 for ; Wed, 6 Feb 2002 13:05:31 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g16HGKr04886 for ips-outgoing; Wed, 6 Feb 2002 12:16:20 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c003.snv.cp.net (c003-h016.c003.snv.cp.net [209.228.32.230]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g16HGIj04879 for ; Wed, 6 Feb 2002 12:16:18 -0500 (EST) Received: (cpmta 12718 invoked from network); 6 Feb 2002 09:16:11 -0800 Received: from 64.130.130.105 (HELO dougrmt) by smtp.telocity.com (209.228.32.230) with SMTP; 6 Feb 2002 09:16:11 -0800 X-Sent: 6 Feb 2002 17:16:11 GMT From: "Douglas Otis" To: Cc: Subject: RE: [Tsvwg] RE: iSCSI: No Framing Date: Wed, 6 Feb 2002 09:18:01 -0800 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.2910.0) Importance: Normal In-Reply-To: <200202061629.g16GTcU25106@phys-hanwk16-1.ebay.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, > > > The word "proprietary" is an unfortunately typical of Doug: > > > (1) assuming that standardization of certain components > > > and/or interfaces is/are necessary to the use of FIM, > > > If done using a protocol employing the TCP transport, a layer > > must be added ahead of TCP, which would be, without > > documentation, a "privately owned" layer. Privately owned as > > such details of this layer are not shared publicly. This > > layer may be hardware or an intelligent adapter, or it could > > be a software solution within a memory starved CPU. Without > > documentation describing the information exchanged between the > > application and TCP, together with the states involved in this > > process, any efforts to extrapolate the details of this layer > > are likely to venture into proprietary areas. A means of > > avoiding this problem would be to document the basics and > > thereby make such a process public. It would also afford an > > ability for review. > > What I am failing to understand is how what you describe is any > different than the variablity of the design of existing NIC > cards. Virtually every NIC card needs its own custom driver > for each OS that is supported. Implementing FIM is no different > than the multitude of existing checksumming offload NICs. It > is true that the hardware is using knowledge of the upper layer > protocols, but it is all within the confines of the implementation > details. There is no wire protocol implication here. I think you have quickly glossed over the difference. The interface created will need to include a portion of the application. This is very different than virtually ever NIC card interface. > In order to "standardize" these techniques the IETF will be > dictating hardware design and/or protocol stack design. While > this might be useful for an industry consortium to make > portability of software easier, it is not a fundemental IETF > issue. In what is essentially an implementation specific communications > between layers of a software stack, how can you standardize > something that will be uniquely different depending on if > the OS uses STREAMS, BSD sockets, Windows XYZ, or custom OS frozbits. > This doesn't make sense for the IETF, you may consider going > to SNIA to standardize implemenation details. Again, you are touching on the problem. Why should the application dictate the NIC interface? If this were the common practice, every protocol would need a portion of the application built into every NIC. Worse yet, you will then see this complexity repeated for OS STREAMS, BSD, Windows XYZ and OS Frozbits. You will also be required to modify your NIC to accomodate the next wonderful version of iSCSI. > If I am not understanding your point, I suggest that it would > be useful for you to write a couple paragraphs suitable for > inclusion in a standards document that describes how you > would standardize the FIM specification. Without such a concrete > proposal I believe we are all just flailing at amorphous > ideas and making no progress on this issue. There is such a document. At this point it is waiting for feedback from Stephen Bailey and Allyn Romanow of the RDMA for their edits. It has been awhile, so I guess they are fighting other problems. > -David > From owner-ips@ece.cmu.edu Wed Feb 6 13: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 NAA27274 for ; Wed, 6 Feb 2002 13:09:00 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g16H08N03580 for ips-outgoing; Wed, 6 Feb 2002 12:00:08 -0500 (EST) 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 g16H05j03565 for ; Wed, 6 Feb 2002 12:00:05 -0500 (EST) Received: from iol.unh.edu (mangelwurzel.iol.unh.edu [132.177.117.100]) by iol.unh.edu (8.12.2/8.12.2) with ESMTP id g16H00Uj002772 for ; Wed, 6 Feb 2002 12:00:00 -0500 Message-ID: <3C615DEB.6A5D6852@iol.unh.edu> Date: Wed, 06 Feb 2002 11:46:35 -0500 From: Stephen Schaeffer Organization: InterOperability Laboratory X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 CC: ips@ece.cmu.edu Subject: Re: Piggyback status gripe References: <5.1.0.14.2.20020206143707.04b4e920@mail.muttsnuts.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mark, We will indeed write this into our recommended interop procedure. We are in the process of finishing up the interop suite, but if anyone would like a copy please ping me, and I'll send you a copy of the current version. I intend to release the final thing in all it's glory soon. Stephen "Mark S. Edwards" wrote: > Over the last several weeks, I have found myself testing against some > version 8 initiators that do not understand that a good status can be > carried piggyback fashion in the DATA-IN PDU, as indicated by the 'S' bit. > > This makes life very difficult for a target, and takes a while to analyse > the situation to find out what is wrong. > > Can I draw initiator writers (especially those in the Windows arena) > attention to the text in 3.7 of both draft 8 and draft 9 and the equivalent > text in 10.7 of draft 10. > > Initiators MUST cope with both cases of either a DATA-IN with the 'S' bit > set, or a separate SCSI Response PDU, it's not up to the target to > telepathically cope with which behaviour the initiator expects. For > performance sake, most targets will piggyback the status in the DATA-IN PDU > and this hangs a couple of initiators. > > Could the participants of next weeks Plugfest actively check for this > compliance ? > > Regards, > > Mark. -- Stephen Schaeffer Fibre Channel and iSCSI Consortia Manager InterOperability Lab, University of New Hampshire Email: stephens@iol.unh.edu Phone: 603-862-5083 Lab Phone: 603-862-0701 URL: www.iol.unh.edu From owner-ips@ece.cmu.edu Wed Feb 6 13:10: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 NAA27320 for ; Wed, 6 Feb 2002 13:10:34 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g16Haco06537 for ips-outgoing; Wed, 6 Feb 2002 12:36:38 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c003.snv.cp.net (c003-h000.c003.snv.cp.net [209.228.32.214]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g16HaZj06522 for ; Wed, 6 Feb 2002 12:36:35 -0500 (EST) Received: (cpmta 9141 invoked from network); 6 Feb 2002 09:36:28 -0800 Received: from 64.130.130.105 (HELO dougrmt) by smtp.telocity.com (209.228.32.214) with SMTP; 6 Feb 2002 09:36:28 -0800 X-Sent: 6 Feb 2002 17:36:28 GMT From: "Douglas Otis" To: Cc: Subject: RE: [Tsvwg] RE: iSCSI: No Framing Date: Wed, 6 Feb 2002 09:38:18 -0800 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.2910.0) Importance: Normal In-Reply-To: <20020206101228.D23964@openss7.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Brian, > Lloyd, > > On Wed, 06 Feb 2002, Lloyd Wood wrote: > > > On Wed, 6 Feb 2002, Brian F. G. Bidulock wrote: > > > > > What is lost by throwing layering out the window? > > > > modularity, ease of understanding, and portability. > > Modularity can be acheived without layering. The entire > field of OOAD proves this. > > Ease of understanding is acheived through accurate > interface description. Again OO shows this. > > Portability can also be acheived through OO approaches. > > The classical layering of communications functions > into functional groupings is not a necessary condition > for any of these benefits. Unlike a typical play dough program, this stuff is more like working with concrete. A portion of each application demanding a direct placement feature would be included in hardware or intelligent adapters if using FIM and TCP, or framing and TCP, for the most part. SCTP allows layering for this "clean modularity" needed if one is to design an adapter that need not understand the complexities and structures of every application that desires this function. The adapter interface only needs to understand SCTP and not the application. By using the unordered delivery mode, a shim would be able to implement generalized structures for including Direct Data Placement or even a full implementation of RDMA. It would be possible for more elaborate interfaces to built upon this foundation, but at least this establishes the modularity, ease of understanding, and portability desired, if one is going to start working in concrete. Unlike the case with FIM and TCP, this would introduce NIC devices that will be forever sensitive to even minor changes to structures employed in these applications and the desire for this feature does not even begin to end at just one application. Doug > --brian > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ From owner-ips@ece.cmu.edu Wed Feb 6 13:12: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 NAA27350 for ; Wed, 6 Feb 2002 13:12:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g16HSic05984 for ips-outgoing; Wed, 6 Feb 2002 12:28:44 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g16HSgj05979 for ; Wed, 6 Feb 2002 12:28:42 -0500 (EST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4617); Wed, 6 Feb 2002 09:28:22 -0800 Received: from 157.54.6.150 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 06 Feb 2002 09:28:35 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Feb 2002 09:28:21 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Feb 2002 09:28:22 -0800 Received: from win-msg-03.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.198]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Wed, 6 Feb 2002 09:26:08 -0800 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6132.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: iSCSI: Boolean value (yes, no) negotiation Date: Wed, 6 Feb 2002 09:26:07 -0800 Message-ID: Thread-Topic: iSCSI: Boolean value (yes, no) negotiation Thread-Index: AcGvL3uiAtkRBxjhSWuOqFMN2B29HQAAwdHA From: "Lakshmi Ramasubramanian" To: X-OriginalArrivalTime: 06 Feb 2002 17:26:08.0100 (UTC) FILETIME=[5CF77A40:01C1AF33] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g16HSgj05980 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Could someone please clarify Boolean key=value usage (such as "ImmediateData=yes", etc)? For example, the initiator sends to target "ImmediateData=no". But the target wants ImmediateData. So, it sends back "ImmediateData=yes". The initiator, being able to handle it, sends back "ImmediateData=no". Now, they use immediate data in the PDUs. Is this valid? Or, in the above case if the target can't handle non-immediate data it has to reject the login ? thanks! -lakshmi From owner-ips@ece.cmu.edu Wed Feb 6 13:19: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 NAA27492 for ; Wed, 6 Feb 2002 13:19:27 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g16Hkwk07319 for ips-outgoing; Wed, 6 Feb 2002 12:46:58 -0500 (EST) 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 g16Hkuj07312 for ; Wed, 6 Feb 2002 12:46:56 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Feb 2002 12:46:55 -0500 Message-ID: <25369470B6F0D41194820002B328BDD2202683@ATLOPS> From: Eddy Quicksall To: Santosh Rao , IPS Reflector Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ? Date: Wed, 6 Feb 2002 12:46:45 -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 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 Wed Feb 6 13: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 NAA27526 for ; Wed, 6 Feb 2002 13:20:02 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g16HTGE06031 for ips-outgoing; Wed, 6 Feb 2002 12:29:16 -0500 (EST) 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 g16HTFj06027 for ; Wed, 6 Feb 2002 12:29:15 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Feb 2002 12:28:54 -0500 Message-ID: <25369470B6F0D41194820002B328BDD2202682@ATLOPS> From: Eddy Quicksall To: "Pittman, Joseph" , "'IPS Reflector'" Subject: RE: iSCSI: R2T/ABORT_TASK interaction Date: Wed, 6 Feb 2002 12:28:47 -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 Here is my initial thinking --- The initiator must not make any assumptions about timing of the abort. There are other cases similar to what you have pointed out (such as the status is on its way back at the time the abort begins). The target also has internal race conditions of its own and its code must also take that into account (such as the command is being completed by a lower layer or HBA at the same time it is issuing an abort to the lower layer or HBA). Now, since anything can go wrong that causes the need for the abort, both parties are already in a position to recover. So, if the initiator does or does not respond to the R2T, the target should be able to cope (even if the response comes to the target after the target has already sent the TMF response or started the abort). One thing is for sure, the initiator should not respond to the R2T after it has received the TMF response. Eddy -----Original Message----- From: Pittman, Joseph [mailto:Joseph.Pittman@netapp.com] Sent: Tuesday, February 05, 2002 4:01 PM To: 'IPS Reflector' Subject: iSCSI: R2T/ABORT_TASK interaction Can anyone describe the required behavior of an initiator under the following condition? This may be a basic SCSI-3 question rather than iSCSI specific; if so, I apologize, but still ask for guidance. Suppose an initiator submits a SCSI Command PDU containing a large SCSI write operation (where large means >= FirstBurstSize). Before the initiator receives an R2T for the first (or next) chunk of the data, the initiator decides to abort the task with an ABORT_TASK (or other) Task Management PDU. In the meantime, the target has prepared its buffers and submits the R2T. The R2T and the ABORT_TASK PDUs 'cross paths': Time Initiator Target | 0 | SCSI_CMD ---------\ | \--------------> | | ABORT_TASK ------\ | \ /------------- R2T | \ / | X-------------> | / | <-------/ T | V At time T, the target has received an ABORT_TASK for the SCSI command, but has already sent an R2T. The initiator has just received an R2T for a SCSI task which it is trying to abort. The target has not yet sent a response to the ABORT_TASK task management command. The question is this: what are the responsibilities of the initiator and target at this point? - Is the initiator required or expected to respond to the R2T, perhaps with a zero-length DATA_OUT PDU? - Is the target expected to wait for the initiator to respond before aborting the task? Or is the initiator allowed (or required) to go ahead and abort the task and send the task management response, without waiting for any DATA_OUT, then silently discard any R2T it might receive later? Thanks in advance for any help. -- Joe Pittman jpittman@netapp.com From owner-ips@ece.cmu.edu Wed Feb 6 13:53: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 NAA28316 for ; Wed, 6 Feb 2002 13:53:10 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g16I3Pu08577 for ips-outgoing; Wed, 6 Feb 2002 13:03:25 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from svldns02.veritas.com (bay-bridge.veritas.com [143.127.3.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g16I3Mj08570 for ; Wed, 6 Feb 2002 13:03:22 -0500 (EST) Received: from megami.veritas.com (megami.veritas.com [10.182.128.180]) by svldns02.veritas.com (8.11.6/8.11.6) with SMTP id g16HxEc14633; Wed, 6 Feb 2002 09:59:14 -0800 (PST) Received: from vxindia.veritas.com(revati.vxindia.veritas.com[202.41.69.12]) (2533 bytes) by megami.veritas.com via sendmail with P:esmtp/R:smart_host/T:smtp (sender: ) id for ; Wed, 6 Feb 2002 10:03:11 -0800 (PST) (Smail-3.2.0.101 1997-Dec-17 #15 built 2001-Aug-30) Received: from april.vxindia.veritas.com (april.vxindia.veritas.com [10.212.108.7]) by vxindia.veritas.com (8.9.3/8.9.3) with ESMTP id XAA16304; Wed, 6 Feb 2002 23:32:16 +0530 (IST) Received: from RAHULB (rahulb.vxindia.veritas.com [10.212.80.59]) by april.vxindia.veritas.com (8.9.3+Sun/8.9.3) with SMTP id XAA01139; Wed, 6 Feb 2002 23:40:44 -0530 (GMT) Message-ID: <033601c1af39$13247e80$3b50d40a@vxindia.veritas.com> From: "Rahul Bhagwat" To: "Lakshmi Ramasubramanian" , References: Subject: Re: iSCSI: Boolean value (yes, no) negotiation Date: Wed, 6 Feb 2002 23:37:00 +0530 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I believe a key is not negotiated thrice as you have pointed out. That is a sender offers a value, receiver offers it's own and that's it. (I think specs has a mention that a key cannot be negotiated twice. This example falls into that category.) The result of the negotiation is key dependent. For example, in this particular key, when initiator sends ImmediateData=no, the negotiation is over as this is an AND function. However it is not an error to send back a response. In any case, the outcome of the result was decided for the initiator when it sent the key first and for the target when it received the key. Regards, Rahul ----- Original Message ----- From: "Lakshmi Ramasubramanian" To: Sent: Wednesday, February 06, 2002 10:56 PM Subject: iSCSI: Boolean value (yes, no) negotiation > Could someone please clarify Boolean key=value usage > (such as "ImmediateData=yes", etc)? > > For example, the initiator sends to target "ImmediateData=no". > But the target wants ImmediateData. So, it sends back > "ImmediateData=yes". > The initiator, being able to handle it, sends back "ImmediateData=no". > Now, they use immediate data in the PDUs. > > Is this valid? Or, in the above case if the target can't handle > non-immediate data it has to reject the login ? > > thanks! > -lakshmi > From owner-ips@ece.cmu.edu Wed Feb 6 13:56: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 NAA28511 for ; Wed, 6 Feb 2002 13:56:43 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g16IYv911258 for ips-outgoing; Wed, 6 Feb 2002 13:34:57 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bfgbhome.inetint.com (IDENT:root@tnt-dal-42-200.dallas.net [209.44.42.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g16IEDj09480 for ; Wed, 6 Feb 2002 13:14:14 -0500 (EST) Received: (from brian@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id MAA11746; Wed, 6 Feb 2002 12:14:05 -0600 Date: Wed, 6 Feb 2002 12:14:05 -0600 From: "Brian F. G. Bidulock" To: Douglas Otis Cc: tsvwg@ietf.org, ips@ece.cmu.edu Subject: Re: [Tsvwg] RE: iSCSI: No Framing Message-ID: <20020206121405.A10800@openss7.org> Reply-To: bidulock@openss7.org References: <20020206101228.D23964@openss7.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from dotis@sanlight.net on Wed, Feb 06, 2002 at 09:38:18AM -0800 Organization: http://www.openss7.org/ Dsn-Notification-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Douglas, On Wed, 06 Feb 2002, Douglas Otis wrote: > Brian, > > > Lloyd, > > > > On Wed, 06 Feb 2002, Lloyd Wood wrote: > > > > > On Wed, 6 Feb 2002, Brian F. G. Bidulock wrote: > > > > > > > What is lost by throwing layering out the window? > > > > > > modularity, ease of understanding, and portability. > > > > Modularity can be acheived without layering. The entire > > field of OOAD proves this. > > > > Ease of understanding is acheived through accurate > > interface description. Again OO shows this. > > > > Portability can also be acheived through OO approaches. > > > > The classical layering of communications functions > > into functional groupings is not a necessary condition > > for any of these benefits. > > Unlike a typical play dough program, this stuff is more like working with > concrete. A portion of each application demanding a direct placement > feature would be included in hardware or intelligent adapters if using FIM > and TCP, or framing and TCP, for the most part. SCTP allows layering for > this "clean modularity" needed if one is to design an adapter that need not > understand the complexities and structures of every application that desires > this function. The adapter interface only needs to understand SCTP and not > the application. By using the unordered delivery mode, a shim would be able > to implement generalized structures for including Direct Data Placement or > even a full implementation of RDMA. It would be possible for more elaborate > interfaces to built upon this foundation, but at least this establishes the > modularity, ease of understanding, and portability desired, if one is going > to start working in concrete. Not necessarily... Nowadays entire OS's and applications are embedded on the adapter. The adtapter can have full knowledge of all applications which it supports and provide only higher level application interfaces to app blades. This is the preferred architecture for scalability and redundancy as well as proving a clean separation between applications and the application engine. If some want to agree on how this embedding is going to occur with some vestige of interoperability, what does it matter? Would not your time be better spent furthering DDP/SCTP? It is certainly not the first time that IETF has had competing approaches: ultimately the market decides. --brian > > Unlike the case with FIM and TCP, this would introduce NIC devices that will > be forever sensitive to even minor changes to structures employed in these > applications and the desire for this feature does not even begin to end at > just one application. > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From owner-ips@ece.cmu.edu Wed Feb 6 14:05: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 OAA28712 for ; Wed, 6 Feb 2002 14:05:40 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g16IDEB09400 for ips-outgoing; Wed, 6 Feb 2002 13:13:14 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g16IDBj09391 for ; Wed, 6 Feb 2002 13:13:11 -0500 (EST) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4617); Wed, 6 Feb 2002 10:12:51 -0800 Received: from 157.54.6.150 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 06 Feb 2002 10:13:05 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Feb 2002 10:12:51 -0800 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.2966); Wed, 6 Feb 2002 10:12:50 -0800 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.3588.0); Wed, 6 Feb 2002 10:10:28 -0800 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6132.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: iSCSI: Boolean value (yes, no) negotiation Date: Wed, 6 Feb 2002 10:10:27 -0800 Message-ID: Thread-Topic: iSCSI: Boolean value (yes, no) negotiation Thread-Index: AcGvODZ84blnQ77tSsaU2W/zcf8PzwAALwnA From: "Lakshmi Ramasubramanian" To: "Rahul Bhagwat" , X-OriginalArrivalTime: 06 Feb 2002 18:10:28.0020 (UTC) FILETIME=[8E670F40:01C1AF39] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g16IDBj09394 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit So that means, if the target needs to use ONLY immediate data, it has to fail the login because the initiator said NO to ImmediateData? thanks! -lakshmi -----Original Message----- From: Rahul Bhagwat [mailto:rahulb@veritas.com] Sent: Wednesday, February 06, 2002 10:07 AM To: Lakshmi Ramasubramanian; ips@ece.cmu.edu Subject: Re: iSCSI: Boolean value (yes, no) negotiation I believe a key is not negotiated thrice as you have pointed out. That is a sender offers a value, receiver offers it's own and that's it. (I think specs has a mention that a key cannot be negotiated twice. This example falls into that category.) The result of the negotiation is key dependent. For example, in this particular key, when initiator sends ImmediateData=no, the negotiation is over as this is an AND function. However it is not an error to send back a response. In any case, the outcome of the result was decided for the initiator when it sent the key first and for the target when it received the key. Regards, Rahul ----- Original Message ----- From: "Lakshmi Ramasubramanian" To: Sent: Wednesday, February 06, 2002 10:56 PM Subject: iSCSI: Boolean value (yes, no) negotiation > Could someone please clarify Boolean key=value usage > (such as "ImmediateData=yes", etc)? > > For example, the initiator sends to target "ImmediateData=no". > But the target wants ImmediateData. So, it sends back > "ImmediateData=yes". > The initiator, being able to handle it, sends back "ImmediateData=no". > Now, they use immediate data in the PDUs. > > Is this valid? Or, in the above case if the target can't handle > non-immediate data it has to reject the login ? > > thanks! > -lakshmi > From owner-ips@ece.cmu.edu Wed Feb 6 14:43: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 OAA29626 for ; Wed, 6 Feb 2002 14:43:35 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g16IesW11791 for ips-outgoing; Wed, 6 Feb 2002 13:40:54 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from svldns02.veritas.com (bay-bridge.veritas.com [143.127.3.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g16Iepj11783 for ; Wed, 6 Feb 2002 13:40:52 -0500 (EST) Received: from megami.veritas.com (megami.veritas.com [10.182.128.180]) by svldns02.veritas.com (8.11.6/8.11.6) with SMTP id g16Iafc15307; Wed, 6 Feb 2002 10:36:41 -0800 (PST) Received: from vxindia.veritas.com(revati.vxindia.veritas.com[202.41.69.12]) (3994 bytes) by megami.veritas.com via sendmail with P:esmtp/R:smart_host/T:smtp (sender: ) id for ; Wed, 6 Feb 2002 10:40:39 -0800 (PST) (Smail-3.2.0.101 1997-Dec-17 #15 built 2001-Aug-30) Received: from april.vxindia.veritas.com (april.vxindia.veritas.com [10.212.108.7]) by vxindia.veritas.com (8.9.3/8.9.3) with ESMTP id AAA22639; Thu, 7 Feb 2002 00:09:43 +0530 (IST) Received: from RAHULB (rahulb.vxindia.veritas.com [10.212.80.59]) by april.vxindia.veritas.com (8.9.3+Sun/8.9.3) with SMTP id AAA05874; Thu, 7 Feb 2002 00:18:12 -0530 (GMT) Message-ID: <034801c1af3e$4eab3200$3b50d40a@vxindia.veritas.com> From: "Rahul Bhagwat" To: "Lakshmi Ramasubramanian" , References: Subject: Re: iSCSI: Boolean value (yes, no) negotiation Date: Thu, 7 Feb 2002 00:14:28 +0530 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit In this particular case, the default value for the key is "Yes". Initiator should be able to express it's preference that it wants to do away with immediate date if the target is willing to do so (without forcing it through the AND function), else the initiator is okay to work with immedidate data. Looks like this is not possible with the boolean negotiation. Can we use ImmediateData=? to get the supported value from the target. If the target responds with yes, the initiator can either use immediate data (by responding Yes) or not use it (by responding No). If the target response no, the initiator does not use immediate data. In this case, the Login need not terminate. Does this give the solution ? Is this a valid thing ? Regards, Rahul ----- Original Message ----- From: "Lakshmi Ramasubramanian" To: "Rahul Bhagwat" ; Sent: Wednesday, February 06, 2002 11:40 PM Subject: RE: iSCSI: Boolean value (yes, no) negotiation > So that means, if the target needs to use ONLY immediate data, > it has to fail the login because the initiator said NO to ImmediateData? > > thanks! > -lakshmi > > -----Original Message----- > From: Rahul Bhagwat [mailto:rahulb@veritas.com] > Sent: Wednesday, February 06, 2002 10:07 AM > To: Lakshmi Ramasubramanian; ips@ece.cmu.edu > Subject: Re: iSCSI: Boolean value (yes, no) negotiation > > > I believe a key is not negotiated thrice as you have pointed out. That > is a sender offers a value, receiver offers it's own and that's it. (I > think specs has a mention that a key cannot be negotiated twice. This > example falls into that category.) The result of the negotiation is key > dependent. For example, in this particular key, when initiator sends > ImmediateData=no, the negotiation is over as this is an > AND function. However it is not an error to send back a response. In any > case, the outcome of the result was decided for the initiator when it > sent the key first and for the target when it received the key. > > Regards, > Rahul > ----- Original Message ----- > From: "Lakshmi Ramasubramanian" > To: > Sent: Wednesday, February 06, 2002 10:56 PM > Subject: iSCSI: Boolean value (yes, no) negotiation > > > > Could someone please clarify Boolean key=value usage > > (such as "ImmediateData=yes", etc)? > > > > For example, the initiator sends to target "ImmediateData=no". > > But the target wants ImmediateData. So, it sends back > > "ImmediateData=yes". > > The initiator, being able to handle it, sends back "ImmediateData=no". > > Now, they use immediate data in the PDUs. > > > > Is this valid? Or, in the above case if the target can't handle > > non-immediate data it has to reject the login ? > > > > thanks! > > -lakshmi > > > From owner-ips@ece.cmu.edu Wed Feb 6 14:48: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 OAA29722 for ; Wed, 6 Feb 2002 14:48:38 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g16J3TJ13883 for ips-outgoing; Wed, 6 Feb 2002 14:03:29 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c003.snv.cp.net (c003-h013.c003.snv.cp.net [209.228.32.227]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g16J3Sj13878 for ; Wed, 6 Feb 2002 14:03:28 -0500 (EST) Received: (cpmta 29599 invoked from network); 6 Feb 2002 11:03:21 -0800 Received: from 64.130.130.105 (HELO dougrmt) by smtp.telocity.com (209.228.32.227) with SMTP; 6 Feb 2002 11:03:21 -0800 X-Sent: 6 Feb 2002 19:03:21 GMT From: "Douglas Otis" To: Cc: Subject: RE: [Tsvwg] RE: iSCSI: No Framing Date: Wed, 6 Feb 2002 11:05:10 -0800 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.2910.0) Importance: Normal In-Reply-To: <20020206121405.A10800@openss7.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Brian, > > Douglas, > > On Wed, 06 Feb 2002, Douglas Otis wrote: > > > Brian, > > > > > Lloyd, > > > > > > On Wed, 06 Feb 2002, Lloyd Wood wrote: > > > > > > > On Wed, 6 Feb 2002, Brian F. G. Bidulock wrote: > > > > > > > > > What is lost by throwing layering out the window? > > > > > > > > modularity, ease of understanding, and portability. > > > > > > Modularity can be acheived without layering. The entire > > > field of OOAD proves this. > > > > > > Ease of understanding is acheived through accurate > > > interface description. Again OO shows this. > > > > > > Portability can also be acheived through OO approaches. > > > > > > The classical layering of communications functions > > > into functional groupings is not a necessary condition > > > for any of these benefits. > > > > Unlike a typical play dough program, this stuff is more like > > working with concrete. A portion of each application demanding > > a direct placement feature would be included in hardware or > > intelligent adapters if using FIM and TCP, or framing and TCP, > > for the most part. SCTP allows layering for this "clean > > modularity" needed if one is to design an adapter that need not > > understand the complexities and structures of every application > > that desires this function. The adapter interface only needs to > > understand SCTP and not the application. By using the unordered > > delivery mode, a shim would be able to implement generalized > > structures for including Direct Data Placement or even a full > > implementation of RDMA. It would be possible for more elaborate > > interfaces to built upon this foundation, but at least this > > establishes the modularity, ease of understanding, and portability > > desired, if one is going to start working in concrete. > > Not necessarily... Nowadays entire OS's and applications are embedded on > the adapter. The adtapter can have full knowledge of all applications > which it supports and provide only higher level application interfaces > to app blades. This is the preferred architecture for scalability and > redundancy as well as proving a clean separation between applications > and the application engine. The rationale for FIM was to avoid the rather modest use of adapter buffer space. Now you are suggesting that the adapter will include the entire OS and application. It sounds as if you are describing clustering where I think RDMA is an attempt to standardize this type of interface. > If some want to agree on how this embedding is going to occur with some > vestige of interoperability, what does it matter? Would not your time be > better spent furthering DDP/SCTP? It is certainly not the first time that > IETF has had competing approaches: ultimately the market decides. This change in architecture is profound with respect to impact on competing approaches. I would not wish to under estimate leverage found from storage as it can be used to wrest control away from standards into an array of vendor unique solutions. This FIM/TCP scheme adds a layer beneath the transport and either modifies the layer above or adds a new interface to this added layer. Either way, the definition of what is included within a transport is greatly diminished. You are asking me to turn my back to this while I see it in my interest to keep this interface open and I see SCTP as a viable solution for doing so. Restricting iSCSI to TCP would not prevent future use of SCTP for this application provided this interface remains open. If you are right about what can be included within an adapter, then justification for FIM/TCP vanishes. Doug > --brian From owner-ips@ece.cmu.edu Wed Feb 6 14:50: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 OAA29772 for ; Wed, 6 Feb 2002 14:50:51 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g16JPbr15846 for ips-outgoing; Wed, 6 Feb 2002 14:25:37 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g16J6rj14198 for ; Wed, 6 Feb 2002 14:06:53 -0500 (EST) Received: from phaestos.ee.surrey.ac.uk ([131.227.88.14] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 16YXOp-0002iz-00; Wed, 06 Feb 2002 19:06:31 +0000 Date: Wed, 6 Feb 2002 19:06:28 +0000 (GMT) From: Lloyd Wood X-X-Sender: eep1lw@phaestos.ee.surrey.ac.uk Reply-To: Lloyd Wood To: "Brian F. G. Bidulock" cc: Douglas Otis , , Subject: Re: [Tsvwg] RE: iSCSI: No Framing In-Reply-To: <20020206121405.A10800@openss7.org> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *16YXOp-0002iz-00*3U6dxmuO98E* (SECM, UniS) Sender: owner-ips@ece.cmu.edu Precedence: bulk On Wed, 6 Feb 2002, Brian F. G. Bidulock wrote: [much oo psychobabble] > If some want to agree on how this embedding is going to occur with some > vestige of interoperability, what does it matter? so why are you here? [I simply can't be bothered to talk about how design choices that might make sense within some closed oo system become meaningless outside that system. Solipsistic ontologies have little intrinsic worth. Network layering provides basic axioms, and lacks solipsism.] L. PGP From owner-ips@ece.cmu.edu Wed Feb 6 15:17: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 PAA00294 for ; Wed, 6 Feb 2002 15:17:24 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g16JI8215192 for ips-outgoing; Wed, 6 Feb 2002 14:18:08 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g16JI6j15182 for ; Wed, 6 Feb 2002 14:18:06 -0500 (EST) Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.110.250.124]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 501A93F95 for ; Wed, 6 Feb 2002 13:18:00 -0600 (CST) Received: from cceexc18.americas.cpqcorp.net ([16.110.250.64]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Feb 2002 13:17:55 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: iSCSI: Boolean value (yes, no) negotiation Date: Wed, 6 Feb 2002 13:17:36 -0600 Message-ID: <31891B757C09184BBFEC5275F85D5595104E28@cceexc18.americas.cpqcorp.net> Thread-Topic: iSCSI: Boolean value (yes, no) negotiation Thread-Index: AcGvL3uiAtkRBxjhSWuOqFMN2B29HQAAwdHAAADBenA= From: "Martin, Nick" To: "Lakshmi Ramasubramanian" , X-OriginalArrivalTime: 06 Feb 2002 19:17:55.0748 (UTC) FILETIME=[FB095640:01C1AF42] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g16JI6j15186 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Lakshmi, It is my understanding, that if either initiator or target begins negotiation for a boolean by sending a key=value pair, the responder applies the specified boolean function (to the requested value and the current value) to obtain the result. The result is then included in a reply (unless the rules say it may be omitted). This negotiation is concluded. I believe it should not be permitted for the responder, desiring a different outcome, to later initiate negotiation for a different value of the same parameter. If both initiator and target were permitted to do this, it can cause an endless loop. However I do not find where this is documented. I have found an option for the target other than rejecting the login. It can reject this parameter value with key=Reject. The initiator in this case can then accept the value previously in effect, negotiate for another value, or close the connection. I believe sending key=Reject does not require that the entire login should fail. The current value for key should be unchanged by a negotiation ending in key=Reject, just as if it never happened. It is not always clear to me whether such negotiations are intended only to allow selection of preferred modes of operation, or to enable implementations which do not support certain features to operate with other implementations which do not require those features. For example, it is not stated whether a target or an initiator SHOULD or MUST implement/accept both ImmediateData=yes and ImmediateData=no. If these are for preferences, and the initiator and target are configured for different preferences, what should be the result? Either result may allow operation. In fact neither may be optimal for both parties at the same time. Is the result predictable? Should we negotiate differently for preferences versus requirements? For example should an initiator only negotiate preferences after the target has had a chance to negotiate requirements? Should we expect that key=Reject could be the response to almost any key negotiation? The suggestion by Rahul to use key=? is not permitted. key=? is only permitted in text commands, during full feature phase. It returns the current value, not the list of support values. Requesting the list of supported values is not a current capability. Thanks, Nick > -----Original Message----- > From: Lakshmi Ramasubramanian [mailto:nramas@windows.microsoft.com] > Sent: Wednesday, February 06, 2002 11:26 AM > To: ips@ece.cmu.edu > Subject: iSCSI: Boolean value (yes, no) negotiation > > > Could someone please clarify Boolean key=value usage > (such as "ImmediateData=yes", etc)? > > For example, the initiator sends to target "ImmediateData=no". > But the target wants ImmediateData. So, it sends back > "ImmediateData=yes". > The initiator, being able to handle it, sends back "ImmediateData=no". > Now, they use immediate data in the PDUs. > > Is this valid? Or, in the above case if the target can't handle > non-immediate data it has to reject the login ? > > thanks! > -lakshmi > From owner-ips@ece.cmu.edu Wed Feb 6 15:21: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 PAA00445 for ; Wed, 6 Feb 2002 15:21:46 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g16Jx6I18732 for ips-outgoing; Wed, 6 Feb 2002 14:59:06 -0500 (EST) 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 g16Jx4j18727 for ; Wed, 6 Feb 2002 14:59:04 -0500 (EST) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel12.hp.com (Postfix) with ESMTP id C1EA46002BA; Wed, 6 Feb 2002 11:58:58 -0800 (PST) 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 LAA03881; Wed, 6 Feb 2002 11:58:53 -0800 (PST) Message-ID: <3C618B8C.ECD88B11@cup.hp.com> Date: Wed, 06 Feb 2002 12:01:16 -0800 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: "Fischer, Michael" Cc: "'Eddy Quicksall'" , IPS Reflector Subject: Re: ips : Is FirstBurstSize valid when InitialR2T=yes ? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit 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 > ################################## -- ################################## 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 Wed Feb 6 15:23: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 PAA00552 for ; Wed, 6 Feb 2002 15:23:37 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g16JenQ17184 for ips-outgoing; Wed, 6 Feb 2002 14:40:49 -0500 (EST) 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 g16Jemj17179 for ; Wed, 6 Feb 2002 14:40:48 -0500 (EST) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id LAA29133; Wed, 6 Feb 2002 11:40:29 -0800 (PST) Received: from aimexc06.corp.adaptec.com (aimexc06.corp.adaptec.com [162.62.62.46]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id LAA29184; Wed, 6 Feb 2002 11:23:34 -0800 (PST) Received: by aimexc06.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Feb 2002 11:38:54 -0800 Message-ID: From: "Fischer, Michael" To: "'Eddy Quicksall'" , Santosh Rao , IPS Reflector Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ? Date: Wed, 6 Feb 2002 11:38:54 -0800 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 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 Wed Feb 6 16:15: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 QAA02322 for ; Wed, 6 Feb 2002 16:15:07 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g16K65o19305 for ips-outgoing; Wed, 6 Feb 2002 15:06:05 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mc.va3.ummail.com (mc.va3.ummail.com [66.187.242.22]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g16K63j19301 for ; Wed, 6 Feb 2002 15:06:03 -0500 (EST) Received: from hqmailweb.COMMSTOR.Crossroads.com (HQMailWeb.Crossroads.com [63.237.99.250:25]) by mc.va3.ummail.com with ESMTP id A0206-1505-6c6000; Wed, 6 Feb 2002 20:05:40 GMT Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 6 Feb 2002 13:59:42 -0600 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: RE: iSCSI: Boolean value (yes, no) negotiation Date: Wed, 6 Feb 2002 13:59:41 -0600 Message-ID: Thread-Topic: iSCSI: Boolean value (yes, no) negotiation Thread-Index: AcGvRtp8H6CUJY+jQ26nkw7G/4H3RwAAGfyQ From: "Buck Landry" To: "Rahul Bhagwat" , "Lakshmi Ramasubramanian" , X-OriginalArrivalTime: 06 Feb 2002 19:59:42.0312 (UTC) FILETIME=[D110A680:01C1AF48] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g16K64j19302 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Not that sixty other people won't answer this, but draft v10 states pretty clearly in section 1.2.4 that: -> The value "?" MUST be used ONLY in Full Feature Phase. IMHO if the initiator is willing to work with *or* without ImmediateData it should send ImmediateData=yes and let the target decide. If the initiator can't use ImmediateData, it should send ImmediateData=no. If the target supports only ImmediateData (now *that* would be interesting), the login session might as well terminate because the two implementations clearly aren't compatible. I suppose if the initiator can only handle ImmediateData=yes, it should send that and terminate the session if the target sends back ImmediateData=no. "Bad initiator! *whack*" To respond directly to lakshmi, > So that means, if the target needs to use ONLY immediate data, > it has to fail the login because the initiator said NO to ImmediateData? (again, IMHO) yup. --buck -----Original Message----- From: Rahul Bhagwat [mailto:rahulb@veritas.com] Sent: Wednesday, February 06, 2002 12:44 PM To: Lakshmi Ramasubramanian; ips@ece.cmu.edu Subject: Re: iSCSI: Boolean value (yes, no) negotiation In this particular case, the default value for the key is "Yes". Initiator should be able to express it's preference that it wants to do away with immediate date if the target is willing to do so (without forcing it through the AND function), else the initiator is okay to work with immedidate data. Looks like this is not possible with the boolean negotiation. Can we use ImmediateData=? to get the supported value from the target. If the target responds with yes, the initiator can either use immediate data (by responding Yes) or not use it (by responding No). If the target response no, the initiator does not use immediate data. In this case, the Login need not terminate. Does this give the solution ? Is this a valid thing ? Regards, Rahul ----- Original Message ----- From: "Lakshmi Ramasubramanian" To: "Rahul Bhagwat" ; Sent: Wednesday, February 06, 2002 11:40 PM Subject: RE: iSCSI: Boolean value (yes, no) negotiation > So that means, if the target needs to use ONLY immediate data, > it has to fail the login because the initiator said NO to ImmediateData? > > thanks! > -lakshmi > > -----Original Message----- > From: Rahul Bhagwat [mailto:rahulb@veritas.com] > Sent: Wednesday, February 06, 2002 10:07 AM > To: Lakshmi Ramasubramanian; ips@ece.cmu.edu > Subject: Re: iSCSI: Boolean value (yes, no) negotiation > > > I believe a key is not negotiated thrice as you have pointed out. That > is a sender offers a value, receiver offers it's own and that's it. (I > think specs has a mention that a key cannot be negotiated twice. This > example falls into that category.) The result of the negotiation is key > dependent. For example, in this particular key, when initiator sends > ImmediateData=no, the negotiation is over as this is an > AND function. However it is not an error to send back a response. In any > case, the outcome of the result was decided for the initiator when it > sent the key first and for the target when it received the key. > > Regards, > Rahul > ----- Original Message ----- > From: "Lakshmi Ramasubramanian" > To: > Sent: Wednesday, February 06, 2002 10:56 PM > Subject: iSCSI: Boolean value (yes, no) negotiation > > > > Could someone please clarify Boolean key=value usage > > (such as "ImmediateData=yes", etc)? > > > > For example, the initiator sends to target "ImmediateData=no". > > But the target wants ImmediateData. So, it sends back > > "ImmediateData=yes". > > The initiator, being able to handle it, sends back "ImmediateData=no". > > Now, they use immediate data in the PDUs. > > > > Is this valid? Or, in the above case if the target can't handle > > non-immediate data it has to reject the login ? > > > > thanks! > > -lakshmi > > > From owner-ips@ece.cmu.edu Wed Feb 6 17:05: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 RAA03939 for ; Wed, 6 Feb 2002 17:05:00 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g16LULp26256 for ips-outgoing; Wed, 6 Feb 2002 16:30:21 -0500 (EST) 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 g16LUJj26250 for ; Wed, 6 Feb 2002 16:30:19 -0500 (EST) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel10.hp.com (Postfix) with ESMTP id BBECEC00771; Wed, 6 Feb 2002 13:30:13 -0800 (PST) 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 NAA09096; Wed, 6 Feb 2002 13:30:09 -0800 (PST) Message-ID: <3C61A0EF.E4061171@cup.hp.com> Date: Wed, 06 Feb 2002 13:32:31 -0800 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: Eddy Quicksall Cc: IPS Reflector Subject: Re: ips : Is FirstBurstSize valid when InitialR2T=yes ? References: <25369470B6F0D41194820002B328BDD2202688@ATLOPS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit 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 Wed Feb 6 17:07: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 RAA03975 for ; Wed, 6 Feb 2002 17:07:04 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g16LJoo25349 for ips-outgoing; Wed, 6 Feb 2002 16:19:50 -0500 (EST) 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 g16LJkj25337 for ; Wed, 6 Feb 2002 16:19:47 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Feb 2002 16:19:46 -0500 Message-ID: <25369470B6F0D41194820002B328BDD2202688@ATLOPS> From: Eddy Quicksall To: Santosh Rao , "Fischer, Michael" Cc: Eddy Quicksall , IPS Reflector Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ? Date: Wed, 6 Feb 2002 16:19:46 -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 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 > ################################## -- ################################## 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 Wed Feb 6 17:08: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 RAA04001 for ; Wed, 6 Feb 2002 17:08:05 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g16KxnR23660 for ips-outgoing; Wed, 6 Feb 2002 15:59:49 -0500 (EST) 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 g16Kxjj23650 for ; Wed, 6 Feb 2002 15:59:46 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Feb 2002 15:59:45 -0500 Message-ID: <25369470B6F0D41194820002B328BDD2202687@ATLOPS> From: Eddy Quicksall To: Rahul Bhagwat , Lakshmi Ramasubramanian , ips@ece.cmu.edu Subject: RE: iSCSI: Boolean value (yes, no) negotiation Date: Wed, 6 Feb 2002 15:59:44 -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 The "?" value is only valid in FFP. Eddy -----Original Message----- From: Rahul Bhagwat [mailto:rahulb@veritas.com] Sent: Wednesday, February 06, 2002 1:44 PM To: Lakshmi Ramasubramanian; ips@ece.cmu.edu Subject: Re: iSCSI: Boolean value (yes, no) negotiation In this particular case, the default value for the key is "Yes". Initiator should be able to express it's preference that it wants to do away with immediate date if the target is willing to do so (without forcing it through the AND function), else the initiator is okay to work with immedidate data. Looks like this is not possible with the boolean negotiation. Can we use ImmediateData=? to get the supported value from the target. If the target responds with yes, the initiator can either use immediate data (by responding Yes) or not use it (by responding No). If the target response no, the initiator does not use immediate data. In this case, the Login need not terminate. Does this give the solution ? Is this a valid thing ? Regards, Rahul ----- Original Message ----- From: "Lakshmi Ramasubramanian" To: "Rahul Bhagwat" ; Sent: Wednesday, February 06, 2002 11:40 PM Subject: RE: iSCSI: Boolean value (yes, no) negotiation > So that means, if the target needs to use ONLY immediate data, > it has to fail the login because the initiator said NO to ImmediateData? > > thanks! > -lakshmi > > -----Original Message----- > From: Rahul Bhagwat [mailto:rahulb@veritas.com] > Sent: Wednesday, February 06, 2002 10:07 AM > To: Lakshmi Ramasubramanian; ips@ece.cmu.edu > Subject: Re: iSCSI: Boolean value (yes, no) negotiation > > > I believe a key is not negotiated thrice as you have pointed out. That > is a sender offers a value, receiver offers it's own and that's it. (I > think specs has a mention that a key cannot be negotiated twice. This > example falls into that category.) The result of the negotiation is key > dependent. For example, in this particular key, when initiator sends > ImmediateData=no, the negotiation is over as this is an > AND function. However it is not an error to send back a response. In any > case, the outcome of the result was decided for the initiator when it > sent the key first and for the target when it received the key. > > Regards, > Rahul > ----- Original Message ----- > From: "Lakshmi Ramasubramanian" > To: > Sent: Wednesday, February 06, 2002 10:56 PM > Subject: iSCSI: Boolean value (yes, no) negotiation > > > > Could someone please clarify Boolean key=value usage > > (such as "ImmediateData=yes", etc)? > > > > For example, the initiator sends to target "ImmediateData=no". > > But the target wants ImmediateData. So, it sends back > > "ImmediateData=yes". > > The initiator, being able to handle it, sends back "ImmediateData=no". > > Now, they use immediate data in the PDUs. > > > > Is this valid? Or, in the above case if the target can't handle > > non-immediate data it has to reject the login ? > > > > thanks! > > -lakshmi > > > From owner-ips@ece.cmu.edu Wed Feb 6 18:10: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 SAA04816 for ; Wed, 6 Feb 2002 18:10:18 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g16MSqx00804 for ips-outgoing; Wed, 6 Feb 2002 17:28:52 -0500 (EST) 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 g16MSnj00798 for ; Wed, 6 Feb 2002 17:28:49 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Feb 2002 17:28:49 -0500 Message-ID: <25369470B6F0D41194820002B328BDD220268F@ATLOPS> From: Eddy Quicksall To: "ips@ece. cmu. edu (E-mail)" Subject: iSCSI: support value of ? Date: Wed, 6 Feb 2002 17:28:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AF5D.A4AAC980" 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_01C1AF5D.A4AAC980 Content-Type: text/plain; charset="iso-8859-1" Section 2.2.4 of draft 10 says: The value "?" with any key has the meaning of enquiry and should be answered with the current value or "NotUnderstood". What good is this? You should already know the answer as a result of login or text negotiations. Here are the only keys that can be used in FFP by the initiator: 1) SendTargets - we already have defined behavior for that key and those get the information anyway 2) TargetName - that is IO by initiator so he can't send that key anyway. Also, he has to already know the target. 3) TargetAlias - "this name MUST be communicated to the initiator during a Login". So that is already known. 4) InitiatorAlias - the initiator should already know his alias 5) TargetAddress - the target is the only one that can send this in a response 6) MaxRecvPDULength - this should be known from the negotiations 7) Vendor Specific - Could this be the reason? If so, lets say that so we don't have to add a lot of silly code. Or, lets say that the response to "?" can be "Reject" meaning that we don't support that syntax (currently, the definition of the "Reject value" does not fit this). Eddy ------_=_NextPart_001_01C1AF5D.A4AAC980 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Section 2.2.4 of draft 10 says:

 

=

The value "?" with any key has the meaning of = enquiry and should be

answered with the current value or = "NotUnderstood".<= /p>

 

=

What good is this?

 

=

You should already know the answer as a result of login or text = negotiations.

 

=

Here are the only keys that can be used in FFP by the = initiator:

 

=

1)       SendTargets – we already have defined behavior for = that key and those get the information anyway

2)       TargetName – that is IO by initiator so he = can’t send that key anyway. Also, he has to already know the = target.

3)       TargetAlias –  “this name MUST be communicated to the initiator during a Login”. So = that is already known.

4)       InitiatorAlias – the initiator should already know = his alias

5)       TargetAddress – the target is the only one that can = send this in a response

6)       MaxRecvPDULength – this should be known from the = negotiations

7)       Vendor Specific – Could this be the reason? If so, = lets say that so we don’t have to add a lot of silly code. Or, lets say that the = response to “?” can be “Reject” meaning that we don’t support that = syntax (currently, the definition of the “Reject value” does not fit = this).

 

=

Eddy=

------_=_NextPart_001_01C1AF5D.A4AAC980-- From owner-ips@ece.cmu.edu Wed Feb 6 18: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 SAA04838 for ; Wed, 6 Feb 2002 18:10:43 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g16M6Hv29093 for ips-outgoing; Wed, 6 Feb 2002 17:06:17 -0500 (EST) 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 g16M6Fj29087 for ; Wed, 6 Feb 2002 17:06:15 -0500 (EST) Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.110.250.124]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 65A2727BF; Wed, 6 Feb 2002 16:06:09 -0600 (CST) Received: from cceexc18.americas.cpqcorp.net ([16.110.250.64]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Feb 2002 16:06:09 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ? Date: Wed, 6 Feb 2002 16:06:08 -0600 Message-ID: <31891B757C09184BBFEC5275F85D5595104E29@cceexc18.americas.cpqcorp.net> Thread-Topic: ips : Is FirstBurstSize valid when InitialR2T=yes ? Thread-Index: AcGufxiB/k3nmMteQ/y8HuX/mSmf2wA0FuGg From: "Martin, Nick" To: "Santosh Rao" , "IPS Reflector" X-OriginalArrivalTime: 06 Feb 2002 22:06:09.0263 (UTC) FILETIME=[7B3D7FF0:01C1AF5A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g16M6Fj29088 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit 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 Wed Feb 6 18:10: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 SAA04850 for ; Wed, 6 Feb 2002 18:10:47 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g16Ltmu28281 for ips-outgoing; Wed, 6 Feb 2002 16:55:48 -0500 (EST) 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 g16Ltkj28276 for ; Wed, 6 Feb 2002 16:55:46 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Feb 2002 16:55:46 -0500 Message-ID: <25369470B6F0D41194820002B328BDD220268C@ATLOPS> From: Eddy Quicksall To: "Martin, Nick" , Lakshmi Ramasubramanian , ips@ece.cmu.edu Cc: "julian_satran@il. ibm. com (E-mail)" Subject: RE: iSCSI: Boolean value (yes, no) negotiation Date: Wed, 6 Feb 2002 16:55:45 -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 It looks to me like "reject" is intended for list negotiations (notice "all of the offered options" ... I think that is referring to list options): If a responder does not support or is not allowed to use all of the offered options with a specific originator, it may use the constant "Reject". Julian, correct me if I am wrong. Eddy -----Original Message----- From: Martin, Nick [mailto:Nick.Martin@compaq.com] Sent: Wednesday, February 06, 2002 2:18 PM To: Lakshmi Ramasubramanian; ips@ece.cmu.edu Subject: RE: iSCSI: Boolean value (yes, no) negotiation Lakshmi, It is my understanding, that if either initiator or target begins negotiation for a boolean by sending a key=value pair, the responder applies the specified boolean function (to the requested value and the current value) to obtain the result. The result is then included in a reply (unless the rules say it may be omitted). This negotiation is concluded. I believe it should not be permitted for the responder, desiring a different outcome, to later initiate negotiation for a different value of the same parameter. If both initiator and target were permitted to do this, it can cause an endless loop. However I do not find where this is documented. I have found an option for the target other than rejecting the login. It can reject this parameter value with key=Reject. The initiator in this case can then accept the value previously in effect, negotiate for another value, or close the connection. I believe sending key=Reject does not require that the entire login should fail. The current value for key should be unchanged by a negotiation ending in key=Reject, just as if it never happened. It is not always clear to me whether such negotiations are intended only to allow selection of preferred modes of operation, or to enable implementations which do not support certain features to operate with other implementations which do not require those features. For example, it is not stated whether a target or an initiator SHOULD or MUST implement/accept both ImmediateData=yes and ImmediateData=no. If these are for preferences, and the initiator and target are configured for different preferences, what should be the result? Either result may allow operation. In fact neither may be optimal for both parties at the same time. Is the result predictable? Should we negotiate differently for preferences versus requirements? For example should an initiator only negotiate preferences after the target has had a chance to negotiate requirements? Should we expect that key=Reject could be the response to almost any key negotiation? The suggestion by Rahul to use key=? is not permitted. key=? is only permitted in text commands, during full feature phase. It returns the current value, not the list of support values. Requesting the list of supported values is not a current capability. Thanks, Nick > -----Original Message----- > From: Lakshmi Ramasubramanian [mailto:nramas@windows.microsoft.com] > Sent: Wednesday, February 06, 2002 11:26 AM > To: ips@ece.cmu.edu > Subject: iSCSI: Boolean value (yes, no) negotiation > > > Could someone please clarify Boolean key=value usage > (such as "ImmediateData=yes", etc)? > > For example, the initiator sends to target "ImmediateData=no". > But the target wants ImmediateData. So, it sends back > "ImmediateData=yes". > The initiator, being able to handle it, sends back "ImmediateData=no". > Now, they use immediate data in the PDUs. > > Is this valid? Or, in the above case if the target can't handle > non-immediate data it has to reject the login ? > > thanks! > -lakshmi > From owner-ips@ece.cmu.edu Wed Feb 6 20:34: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 UAA06445 for ; Wed, 6 Feb 2002 20:34:47 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g170csj10423 for ips-outgoing; Wed, 6 Feb 2002 19:38:54 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from relay1.softcomca.com (relay.softcomca.com [168.144.1.67] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g170cpj10414 for ; Wed, 6 Feb 2002 19:38:51 -0500 (EST) Received: from m2w057 ([168.144.108.57]) by relay1.softcomca.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 6 Feb 2002 19:38:49 -0500 X-Originating-IP: 64.170.220.19 X-URL: http://www.mail2web.com/ Subject: RE: Re: iSCSI: Boolean value (yes, no) negotiation From: "rakesh@qpackets.com" Date: Wed, 6 Feb 2002 19:38:43 -0500 To: "rahulb@veritas.com" , "nramas@windows.microsoft.com" , "ips@ece.cmu.edu" Reply-To: rakesh@qpackets.com X-Priority: 3 X-MSMail-Priority: Normal MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: JMail 3.7.0 by Dimac (www.dimac.net) Message-ID: X-OriginalArrivalTime: 07 Feb 2002 00:38:49.0181 (UTC) FILETIME=[CEFA10D0:01C1AF6F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by ece.cmu.edu id g170cpj10415 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit This seems to be a interesting scenario. Mapping this to traditional SCSI model the initiator during message out phase sends to the target its capabilities (support disconnect/reconnect etc) if the target supports the message it acknowledges and the agreement prevails as long as the devices stay powered or else a message reject is sent by the target and the state machine moves on to the next phase. An inference out of this quote is that the target holds the authority to make final decisions on any proposals that the initiator may choose to make. Elaborating the example on which this thread started - I->T ImmediateData=no T->I ImmediateData=no Irrespective of intelligence either in the target and/or initiator, they should not be soliciting choices otherwise convergence of a proposal might be cumbersome. Thanks, Rakesh Original Message: ----------------- From: Rahul Bhagwat rahulb@veritas.com Date: Thu, 7 Feb 2002 00:14:28 +0530 To: nramas@windows.microsoft.com, ips@ece.cmu.edu Subject: Re: iSCSI: Boolean value (yes, no) negotiation In this particular case, the default value for the key is "Yes". Initiator should be able to express it's preference that it wants to do away with immediate date if the target is willing to do so (without forcing it through the AND function), else the initiator is okay to work with immedidate data. Looks like this is not possible with the boolean negotiation. Can we use ImmediateData=? to get the supported value from the target. If the target responds with yes, the initiator can either use immediate data (by responding Yes) or not use it (by responding No). If the target response no, the initiator does not use immediate data. In this case, the Login need not terminate. Does this give the solution ? Is this a valid thing ? Regards, Rahul ----- Original Message ----- From: "Lakshmi Ramasubramanian" To: "Rahul Bhagwat" ; Sent: Wednesday, February 06, 2002 11:40 PM Subject: RE: iSCSI: Boolean value (yes, no) negotiation > So that means, if the target needs to use ONLY immediate data, > it has to fail the login because the initiator said NO to ImmediateData? > > thanks! > -lakshmi > > -----Original Message----- > From: Rahul Bhagwat [mailto:rahulb@veritas.com] > Sent: Wednesday, February 06, 2002 10:07 AM > To: Lakshmi Ramasubramanian; ips@ece.cmu.edu > Subject: Re: iSCSI: Boolean value (yes, no) negotiation > > > I believe a key is not negotiated thrice as you have pointed out. That > is a sender offers a value, receiver offers it's own and that's it. (I > think specs has a mention that a key cannot be negotiated twice. This > example falls into that category.) The result of the negotiation is key > dependent. For example, in this particular key, when initiator sends > ImmediateData=no, the negotiation is over as this is an > AND function. However it is not an error to send back a response. In any > case, the outcome of the result was decided for the initiator when it > sent the key first and for the target when it received the key. > > Regards, > Rahul > ----- Original Message ----- > From: "Lakshmi Ramasubramanian" > To: > Sent: Wednesday, February 06, 2002 10:56 PM > Subject: iSCSI: Boolean value (yes, no) negotiation > > > > Could someone please clarify Boolean key=value usage > > (such as "ImmediateData=yes", etc)? > > > > For example, the initiator sends to target "ImmediateData=no". > > But the target wants ImmediateData. So, it sends back > > "ImmediateData=yes". > > The initiator, being able to handle it, sends back "ImmediateData=no". > > Now, they use immediate data in the PDUs. > > > > Is this valid? Or, in the above case if the target can't handle > > non-immediate data it has to reject the login ? > > > > thanks! > > -lakshmi > > > -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . From owner-ips@ece.cmu.edu Thu Feb 7 00:43: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 AAA12326 for ; Thu, 7 Feb 2002 00:43:50 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g174knA26849 for ips-outgoing; Wed, 6 Feb 2002 23:46:49 -0500 (EST) 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 g174klj26844 for ; Wed, 6 Feb 2002 23:46:47 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id FAA82270 for ; Thu, 7 Feb 2002 05:46:36 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g174m7841460 for ; Thu, 7 Feb 2002 05:48:08 +0100 Subject: Re: ips : Is FirstBurstSize valid when InitialR2T=yes ? To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Thu, 7 Feb 2002 06:39:10 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 07/02/2002 06:48:06 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk 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 Thu Feb 7 00:43: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 AAA12338 for ; Thu, 7 Feb 2002 00:43:54 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g174kpk26859 for ips-outgoing; Wed, 6 Feb 2002 23:46:51 -0500 (EST) 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 g174koj26852 for ; Wed, 6 Feb 2002 23:46:50 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id FAA82274; Thu, 7 Feb 2002 05:46:39 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g174m6w68070; Thu, 7 Feb 2002 05:48:07 +0100 Subject: RE: iSCSI: Boolean value (yes, no) negotiation To: Eddy Quicksall Cc: ips@ece.cmu.edu, "julian_satran@il. ibm. com (E-mail)" , "Martin, Nick" , Lakshmi Ramasubramanian X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Thu, 7 Feb 2002 06:41:15 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 07/02/2002 06:48:08 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy is right - reject is not intended/valid for booleans. Julo Eddy Quicksall , ivity.com> Lakshmi Ramasubramanian , ips@ece.cmu.edu 06-02-02 23:55 cc: Julian Satran/Haifa/IBM@IBMIL Subject: RE: iSCSI: Boolean value (yes, no) negotiation It looks to me like "reject" is intended for list negotiations (notice "all of the offered options" ... I think that is referring to list options): If a responder does not support or is not allowed to use all of the offered options with a specific originator, it may use the constant "Reject". Julian, correct me if I am wrong. Eddy -----Original Message----- From: Martin, Nick [mailto:Nick.Martin@compaq.com] Sent: Wednesday, February 06, 2002 2:18 PM To: Lakshmi Ramasubramanian; ips@ece.cmu.edu Subject: RE: iSCSI: Boolean value (yes, no) negotiation Lakshmi, It is my understanding, that if either initiator or target begins negotiation for a boolean by sending a key=value pair, the responder applies the specified boolean function (to the requested value and the current value) to obtain the result. The result is then included in a reply (unless the rules say it may be omitted). This negotiation is concluded. I believe it should not be permitted for the responder, desiring a different outcome, to later initiate negotiation for a different value of the same parameter. If both initiator and target were permitted to do this, it can cause an endless loop. However I do not find where this is documented. I have found an option for the target other than rejecting the login. It can reject this parameter value with key=Reject. The initiator in this case can then accept the value previously in effect, negotiate for another value, or close the connection. I believe sending key=Reject does not require that the entire login should fail. The current value for key should be unchanged by a negotiation ending in key=Reject, just as if it never happened. It is not always clear to me whether such negotiations are intended only to allow selection of preferred modes of operation, or to enable implementations which do not support certain features to operate with other implementations which do not require those features. For example, it is not stated whether a target or an initiator SHOULD or MUST implement/accept both ImmediateData=yes and ImmediateData=no. If these are for preferences, and the initiator and target are configured for different preferences, what should be the result? Either result may allow operation. In fact neither may be optimal for both parties at the same time. Is the result predictable? Should we negotiate differently for preferences versus requirements? For example should an initiator only negotiate preferences after the target has had a chance to negotiate requirements? Should we expect that key=Reject could be the response to almost any key negotiation? The suggestion by Rahul to use key=? is not permitted. key=? is only permitted in text commands, during full feature phase. It returns the current value, not the list of support values. Requesting the list of supported values is not a current capability. Thanks, Nick > -----Original Message----- > From: Lakshmi Ramasubramanian [mailto:nramas@windows.microsoft.com] > Sent: Wednesday, February 06, 2002 11:26 AM > To: ips@ece.cmu.edu > Subject: iSCSI: Boolean value (yes, no) negotiation > > > Could someone please clarify Boolean key=value usage > (such as "ImmediateData=yes", etc)? > > For example, the initiator sends to target "ImmediateData=no". > But the target wants ImmediateData. So, it sends back > "ImmediateData=yes". > The initiator, being able to handle it, sends back "ImmediateData=no". > Now, they use immediate data in the PDUs. > > Is this valid? Or, in the above case if the target can't handle > non-immediate data it has to reject the login ? > > thanks! > -lakshmi > From owner-ips@ece.cmu.edu Thu Feb 7 07:47: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 HAA25693 for ; Thu, 7 Feb 2002 07:47:56 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g17BuLN04964 for ips-outgoing; Thu, 7 Feb 2002 06:56:21 -0500 (EST) 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 g17BuJj04960 for ; Thu, 7 Feb 2002 06:56:19 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Feb 2002 06:56:19 -0500 Message-ID: <25369470B6F0D41194820002B328BDD22026AE@ATLOPS> From: Eddy Quicksall To: Julian Satran , ips@ece.cmu.edu Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ? Date: Thu, 7 Feb 2002 06:56:17 -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 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 Thu Feb 7 07:52: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 HAA25744 for ; Thu, 7 Feb 2002 07:52:49 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g17CXte07608 for ips-outgoing; Thu, 7 Feb 2002 07:33:55 -0500 (EST) 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 g17CXqj07596 for ; Thu, 7 Feb 2002 07:33:52 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Feb 2002 07:33:52 -0500 Message-ID: <25369470B6F0D41194820002B328BDD22026B0@ATLOPS> From: Eddy Quicksall To: "Martin, Nick" Cc: Santosh Rao , IPS Reflector Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ? Date: Thu, 7 Feb 2002 07:33:50 -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 Nick, Given your last paragraph below, do you agree this would be correct (draft 10) (InitialR2T=yes and ImmediateData=no make FirstBurstSize meaningless): I->T FirstBurstSize=512, InitialR2T=no, ImmediateData=no T->I FirstBurstSize=Irrelevant, InitialR2T=yes, ImmediateData=no Eddy -----Original Message----- From: Martin, Nick [mailto:Nick.Martin@compaq.com] Sent: Wednesday, February 06, 2002 5: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 Thu Feb 7 08: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 IAA25855 for ; Thu, 7 Feb 2002 08:04:16 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g17CTIG07274 for ips-outgoing; Thu, 7 Feb 2002 07:29:18 -0500 (EST) 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 g17CTGj07267 for ; Thu, 7 Feb 2002 07:29:16 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Feb 2002 07:13:26 -0500 Message-ID: <25369470B6F0D41194820002B328BDD22026AF@ATLOPS> From: Eddy Quicksall To: "julian_satran@il. ibm. com (E-mail)" Cc: "ips@ece. cmu. edu (E-mail)" Subject: iSCSI: case of none Date: Thu, 7 Feb 2002 07:13:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AFD0.D8495EF0" 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_01C1AFD0.D8495EF0 Content-Type: text/plain; charset="iso-8859-1" Draft 10, section 2.2.4 says: (literal constants which may include "None") But it also says: The constant "none" MUST always be used to indicate ... And the examples show 'none'. Section 10.10.4 says: All the text keys and text values specified in this document are to be presented and interpreted in the case they appear in this document. They are case sensitive. Should "none" be leading upper or lower case? Also, it appears as though all values have changed to leading upper case but "yes" and "no". Can we be consistent and make those leading upper case also? Eddy ------_=_NextPart_001_01C1AFD0.D8495EF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Draft 10, section 2.2.4 says:

 

=

(literal constants which may include = "None")<= /p>

 

=

But it also says:

 

=

The constant "none" MUST always be used to = indicate ...<= /p>

 

=

And the examples show = ‘none’.

 

=

Section 10.10.4 says:

 

=

All the text keys and text values = specified

in this document are to be presented and interpreted in = the case they

appear in this document. They are case = sensitive.<= /p>

 

=

Should “none” be leading upper or lower = case?

 

=

Also, it appears as though all values have changed to leading upper case but = “yes” and “no”. Can we be consistent and make those leading upper = case also?

 

=

 

=

Eddy=

------_=_NextPart_001_01C1AFD0.D8495EF0-- From owner-ips@ece.cmu.edu Thu Feb 7 15:06: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 PAA08078 for ; Thu, 7 Feb 2002 15:06:52 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g17J48I11550 for ips-outgoing; Thu, 7 Feb 2002 14:04:08 -0500 (EST) 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 g17IN3j07592 for ; Thu, 7 Feb 2002 13:23:03 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04600; Thu, 7 Feb 2002 13:23:00 -0500 (EST) Message-Id: <200202071823.NAA04600@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-08.txt Date: Thu, 07 Feb 2002 13:23:00 -0500 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-08.txt Pages : 63 Date : 06-Feb-02 This document discusses how block storage protocols running over IP, including iSCSI, iFCP and FCIP, can utilize IPsec for security. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-security-08.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-08.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-08.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: <20020206132229.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-security-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-security-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020206132229.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Thu Feb 7 16:41: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 QAA10692 for ; Thu, 7 Feb 2002 16:41:14 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g17KfgE19873 for ips-outgoing; Thu, 7 Feb 2002 15:41:42 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mc.va3.ummail.com (mc.va3.ummail.com [66.187.242.18]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g17KfZj19854 for ; Thu, 7 Feb 2002 15:41:39 -0500 (EST) Received: from hqmailweb.COMMSTOR.Crossroads.com (HQMailWeb.Crossroads.com [63.237.99.250:25]) by mc.va3.ummail.com with ESMTP id V0207-1541-705b00; Thu, 7 Feb 2002 20:41:30 GMT Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 7 Feb 2002 14:40:16 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B017.A69C7610" Subject: iSCSI: MaxCmdSN rule Date: Thu, 7 Feb 2002 14:40:16 -0600 Message-ID: Thread-Topic: iSCSI: case of none Thread-Index: AcGv2E8+xCZeXc/8SOaWwEDSJyqAawAOywEw From: "Buck Landry" To: X-OriginalArrivalTime: 07 Feb 2002 20:40:16.0985 (UTC) FILETIME=[A6A80490:01C1B017] Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C1B017.A69C7610 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I'm struggling over how to interpret this rule in section 1.2.2 = of draft v10: =20 >>> The target MUST NOT transmit a MaxCmdSN that is less than=20 the last ExpCmdSN. <<< =20 This confuses me because it says to me (in some cases) that a target = must be able to handle an unlimited number of commands. For example, = let's say the target has just about reached the limit of the commands it = can handle: =20 T=3D>(Nop-In) (MaxCmdSN =3D 1, ExpCmdSN =3D 1) =20 I=3D>(Scsi Read Cmd) (CmdSN =3D 1) =20 T=3D>(Data-in) (MaxCmdSN =3D 1, ExpCmdSN =3D 2 /* acknowledging scsi = read cmd */) =20 Now the target may have many more data-ins to transmit. But according = to the rule, since the last ExpCmdSN the target transmitted was 2, the = target is now forced to send a MaxCmdSN of 2: =20 T=3D>(Data-in) (MaxCmdSN =3D 2, ExpCmdSN =3D 2) =20 But this allows the initiator to send another command, even though the = target can't handle it! =20 Obviously something is wrong with my reasoning here (perhaps my = interpretation of 'last ExpCmdSN', or when I"m supposed to acknowledge = the scsi cmd); can anybody clarify? =20 --buck =20 =20 =20 =20 ------_=_NextPart_001_01C1B017.A69C7610 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all, I'm struggling over how to interpret = this rule=20 in section 1.2.2 of draft = v10:
 = ;
>>> The target MUST NOT = transmit a=20 MaxCmdSN that is less than =
        the=20 last ExpCmdSN.
<<<=
 = ;
This confuses me because it says to me = (in some=20 cases) that a target must be able to handle an unlimited number of=20 commands.  For example, let's say the target has just about reached = the=20 limit of the commands it can=20 handle:
 = ;
T=3D>(Nop-In) (MaxCmdSN =3D 1, ExpCmdSN = =3D=20 1)
 = ;
I=3D>(Scsi Read Cmd) (CmdSN =3D=20 1)
 = ;
T=3D>(Data-in) (MaxCmdSN =3D 1, ExpCmdSN = =3D 2 /*=20 acknowledging scsi read cmd=20 */)
 = ;
Now the target may have many more data-ins to = transmit.  But according to the rule, since the last ExpCmdSN the = target=20 transmitted was 2, the target is now forced to send a MaxCmdSN of=20 2:
 = ;
T=3D>(Data-in) (MaxCmdSN =3D 2, ExpCmdSN = =3D=20 2)
 = ;
But this allows the initiator to send another = command,=20 even though the target can't handle=20 it!
 = ;
Obviously something is wrong with my = reasoning=20 here (perhaps my interpretation of 'last ExpCmdSN', or when I"m = supposed to=20 acknowledge the scsi cmd); can anybody=20 clarify?
 = ;
--buck
 = ;
 = ;
 = ;
 = ;
------_=_NextPart_001_01C1B017.A69C7610-- From owner-ips@ece.cmu.edu Thu Feb 7 18:50: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 SAA13323 for ; Thu, 7 Feb 2002 18:50:55 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g17N6g800281 for ips-outgoing; Thu, 7 Feb 2002 18:06:42 -0500 (EST) 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 g17N6ej00273 for ; Thu, 7 Feb 2002 18:06:40 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id AAA147760; Fri, 8 Feb 2002 00:06:29 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g17N80C54810; Fri, 8 Feb 2002 00:08:00 +0100 Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ? 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: Fri, 8 Feb 2002 01:00:01 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 08/02/2002 01:07:59 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk It can give any legal value. Why should we add rules? Is something wrong having a value that is not used? Julo Eddy Quicksall ips@ece.cmu.edu cc: 07-02-02 13:56 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 Thu Feb 7 18:58: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 SAA13429 for ; Thu, 7 Feb 2002 18:58:00 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g17MrON29433 for ips-outgoing; Thu, 7 Feb 2002 17:53:24 -0500 (EST) 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 g17MrMj29429 for ; Thu, 7 Feb 2002 17:53:22 -0500 (EST) Received: from aghanemw2k (dhcp-161-44-68-129.cisco.com [161.44.68.129]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id RAA07773 for ; Thu, 7 Feb 2002 17:53:16 -0500 (EST) From: "Ayman Ghanem" To: Subject: RE: iSCSI: MaxCmdSN rule Date: Thu, 7 Feb 2002 16:53:16 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C1AFF7.F00ECFD0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C1AFF7.F00ECFD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit This sentence should be changed to: "The target MUST NOT transmit a MaxCmdSN that is less than the last ExpCmdSN-1" The paragraph above this states: "If the PDU MaxCmdSN is less than the PDU ExpCmdSN-1 (in Serial Arithmetic Sense), they are both ignored." which allows MaxCmdSN = ExpCmdSN-1,valid, for the case when the target's command window is closed. -Ayman -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Buck Landry Sent: Thursday, February 07, 2002 2:40 PM To: ips@ece.cmu.edu Subject: iSCSI: MaxCmdSN rule Hi all, I'm struggling over how to interpret this rule in section 1.2.2 of draft v10: >>> The target MUST NOT transmit a MaxCmdSN that is less than the last ExpCmdSN. <<< This confuses me because it says to me (in some cases) that a target must be able to handle an unlimited number of commands. For example, let's say the target has just about reached the limit of the commands it can handle: T=>(Nop-In) (MaxCmdSN = 1, ExpCmdSN = 1) I=>(Scsi Read Cmd) (CmdSN = 1) T=>(Data-in) (MaxCmdSN = 1, ExpCmdSN = 2 /* acknowledging scsi read cmd */) Now the target may have many more data-ins to transmit. But according to the rule, since the last ExpCmdSN the target transmitted was 2, the target is now forced to send a MaxCmdSN of 2: T=>(Data-in) (MaxCmdSN = 2, ExpCmdSN = 2) But this allows the initiator to send another command, even though the target can't handle it! Obviously something is wrong with my reasoning here (perhaps my interpretation of 'last ExpCmdSN', or when I"m supposed to acknowledge the scsi cmd); can anybody clarify? --buck ------=_NextPart_000_000A_01C1AFF7.F00ECFD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This=20 sentence should be changed to:
 
"The target MUST NOT transmit a MaxCmdSN that = is less=20 than the last=20 ExpCmdSN-1"
 
The=20 paragraph above this=20 states:
 
"If the=20 PDU MaxCmdSN is less than the PDU ExpCmdSN-1 (in Serial Arithmetic = Sense),=20 they are both ignored."
 
which=20 allows=20 MaxCmdSN =3D ExpCmdSN-1,valid, for the case when the target's command = window is=20 closed.
 
-Ayman
 
-----Original Message-----
From: = owner-ips@ece.cmu.edu=20 [mailto:owner-ips@ece.cmu.edu]On Behalf Of Buck = Landry
Sent:=20 Thursday, February 07, 2002 2:40 PM
To:=20 ips@ece.cmu.edu
Subject: iSCSI: MaxCmdSN = rule

Hi all, I'm struggling over how to = interpret this=20 rule in section 1.2.2 of draft=20 v10:
 = ;
>>> The target MUST NOT = transmit a=20 MaxCmdSN that is less than =
        the=20 last ExpCmdSN.
<<<=
 = ;
This confuses me because it says to me = (in some=20 cases) that a target must be able to handle an unlimited number = of=20 commands.  For example, let's say the target has just about = reached the=20 limit of the commands it can=20 handle:
 = ;
T=3D>(Nop-In) (MaxCmdSN =3D 1, ExpCmdSN = =3D=20 1)
 = ;
I=3D>(Scsi Read Cmd) (CmdSN =3D=20 1)
 = ;
T=3D>(Data-in) (MaxCmdSN =3D 1, ExpCmdSN = =3D 2 /*=20 acknowledging scsi read cmd=20 */)
 = ;
Now the target may have many more data-ins = to=20 transmit.  But according to the rule, since the last ExpCmdSN the = target=20 transmitted was 2, the target is now forced to send a MaxCmdSN of = 2:
 = ;
T=3D>(Data-in) (MaxCmdSN =3D 2, ExpCmdSN = =3D=20 2)
 = ;
But this allows the initiator to send = another=20 command, even though the target can't handle=20 it!
 = ;
Obviously something is wrong with my = reasoning=20 here (perhaps my interpretation of 'last ExpCmdSN', or when I"m = supposed=20 to acknowledge the scsi cmd); can anybody=20 clarify?
 = ;
--buck
 = ;
 = ;
 = ;
 = ;
------=_NextPart_000_000A_01C1AFF7.F00ECFD0-- From owner-ips@ece.cmu.edu Thu Feb 7 21:32: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 VAA16275 for ; Thu, 7 Feb 2002 21:32:02 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g181bvb08966 for ips-outgoing; Thu, 7 Feb 2002 20:37:57 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g181bmj08956 for ; Thu, 7 Feb 2002 20:37:48 -0500 (EST) Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.110.250.124]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 75B6940AA; Thu, 7 Feb 2002 19:37:42 -0600 (CST) Received: from cceexc18.americas.cpqcorp.net ([16.110.250.64]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 7 Feb 2002 19:37:42 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ? Date: Thu, 7 Feb 2002 19:37:41 -0600 Message-ID: <31891B757C09184BBFEC5275F85D5595104E2B@cceexc18.americas.cpqcorp.net> Thread-Topic: ips : Is FirstBurstSize valid when InitialR2T=yes ? Thread-Index: AcGv09WNG6UbswUYTD2GAUrylOMe1AAbCWSw From: "Martin, Nick" To: "Eddy Quicksall" Cc: "Santosh Rao" , "IPS Reflector" X-OriginalArrivalTime: 08 Feb 2002 01:37:42.0248 (UTC) FILETIME=[33430E80:01C1B041] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g181bmj08957 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Eddy, Regarding your example exchange below. First, I would have parsed the incoming buffer from left to right so I would have constructed my response for FirstBurstSize before recognizing that it would not be used. Second, I am confident that FirstBurstSize=512 is a sensible response, even given that the initiator will not be allowed to send a first burst due to the other settings (soon to be in effect), and also presuming that FirstBurstSize=512 had been listed last in the buffer. The target and initiator would each have a new value for FirstBurstSize. However, I suppose I must admit that this may not be an invalid response. The originator must treat the response as negotiation failure for FirstBurstSize. The value previously in effect (probably the default) is unchanged for both originator and responder. If the initiator is parsing from left to right (as I presume it should), it will not yet know why the value Irrelevant was returned by the target. (It might over-react and close the connection.) 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 > -----Original Message----- > From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] > Sent: Thursday, February 07, 2002 6:34 AM > To: Martin, Nick > Cc: Santosh Rao; IPS Reflector > Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ? > > > Nick, > > Given your last paragraph below, do you agree this would be > correct (draft > 10) (InitialR2T=yes and ImmediateData=no make FirstBurstSize > meaningless): > > I->T FirstBurstSize=512, InitialR2T=no, ImmediateData=no > T->I FirstBurstSize=Irrelevant, InitialR2T=yes, ImmediateData=no > > Eddy > > -----Original Message----- > From: Martin, Nick [mailto:Nick.Martin@compaq.com] > Sent: Wednesday, February 06, 2002 5: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 Feb 8 07: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 HAA04799 for ; Fri, 8 Feb 2002 07:46:31 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g18BmXP17458 for ips-outgoing; Fri, 8 Feb 2002 06:48:33 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13902.mail.yahoo.com (web13902.mail.yahoo.com [216.136.175.28]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g18BmVj17453 for ; Fri, 8 Feb 2002 06:48:31 -0500 (EST) Message-ID: <20020208114830.35500.qmail@web13902.mail.yahoo.com> Received: from [209.179.198.45] by web13902.mail.yahoo.com via HTTP; Fri, 08 Feb 2002 03:48:30 PST Date: Fri, 8 Feb 2002 03:48:30 -0800 (PST) From: Daniel Lee Subject: iSCSI: Seven minor draft 10 editorial comments To: ips@ece.cmu.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Julian, Here are some more comments on the draft 10 PDF file. Minor Editorial Comment #1 On page 105 the "9.4" section heading is missing from the "Sync and Steering Layer and Performance" section. As a result, the next section entitled "Unsolicited Data and Performance" is mislabled as "9.4" instead of "9.5". Minor Editorial Comment #2 There's a typo in Section 2.2.1, in the second paragraph on page 26. I've extracted the paragraph below, the typo is beginning of the 4th sentence. Across all connections within a session, an initiator sees one "target image". All target identifying elements, such as LUN, are the same. In addition, a target sees one "initiator image" across all connections within a session. Initiator that identifying elements, such as the Initiator Task Tag, can be used to identify the same entity regardless of the connection on which they are sent or received. I recommend rewriting the paragraph as follows: An initiator sees one "target image" across all connections within a session. All target identifying elements, such as LUN, are identical regardless of the connection on which they are sent or received. In addition, a target sees one "initiator image" across all connections within a session. Initiator identifying elements, such as the Initiator Task Tag, are identical regardless of the connection on which they are sent or received. Minor Editorial Comment #3 Typo on page 234: 'Success' is misspelled as 'Sucess' Minor Editorial Comment #4 For consistency and clarity reasons I recommend changing the following pseudocode at the top of page 230 as follows. if (current StatSN is not expected) { Recover-Status-if-Possible(Connection, CurrentPDU); } if (current ExpCmdSN is not our NextCmdSN) { Retransmit-Command-if-Possible(Connection, CurrentPDU.ExpCmdSN); } if (CurrentPDU.StatSN is not expected) { Recover-Status-if-Possible(Connection, CurrentPDU); } if (CurrentPDU.ExpCmdSN != Session.NextCmdSN) { Retransmit-Command-if-Possible(Connection, CurrentPDU.ExpCmdSN); } In addition, the 'Session.NextCmdSN' should probably be 'Connection.SessionReference.NextCmdSN', but it's not used this way elsewhere in the pseudocode and it's easy enough to understand the way it's currently used. Minor Editorial Comment #5 In the pseudocode for the previous Editorial Comment (on page 230) and in the 'struct Session' definition on page 222, it might make sense to change 'NextCmdSN' to just 'CmdSN' for consistency reasons (since on page 28 it says 'CmdSn always contains the number to be assigned next'). Minor Editorial Comment #6 The 'n' in 'CmdSn' on page 28 (referenced in Editorial Comment #4) should be capitalized. Minor Editorial Comment #7 (Note: I'll stop my Editorial Comments with this one since 7 is a lucky number.) I suggest the following line on page 29 be either modified as follows or removed completely to make it less confusing to first time readers of the spec. -If the PDU MaxCmdSN is less than the PDU ExpCmdSN-1 (in Serial Arithmetic Sense), they are both ignored. -If the PDU MaxCmdSN is less than the PDU ExpCmdSN-1 (in Serial Arithmetic Sense), the target has made an error generating this PDU so both fields are ignored. The reason I suggest this change is that it isn't until a few lines down the in the spec that you learn 'The target MUST NOT transmit a MaxCmdSN that is less than the last ExpCmdSN.' (note: the previous line might be clearer as 'The target MUST NOT transmit a MaxCmdSN that is less than ExpCmdSN-1 (in Serial Arithmetic Sense)'. Regards, Daniel Lee Unemployed Person dan@danielslee.com "iSCSI, therefore I am" __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com From owner-ips@ece.cmu.edu Fri Feb 8 10:49: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 KAA12190 for ; Fri, 8 Feb 2002 10:49:43 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g18Eo2v26806 for ips-outgoing; Fri, 8 Feb 2002 09:50:02 -0500 (EST) 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 g18Enxj26792 for ; Fri, 8 Feb 2002 09:49:59 -0500 (EST) Received: from aghanemw2k (dhcp-161-44-68-129.cisco.com [161.44.68.129]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id JAA09833 for ; Fri, 8 Feb 2002 09:49:53 -0500 (EST) From: "Ayman Ghanem" To: Subject: iSCSI: draft-10 editorial Date: Fri, 8 Feb 2002 08:49:53 -0600 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, Since the I-bit is now reserved in response PDUs, the following from 10.2.1.1 should be removed: "This bit is always 1 for response PDUs (PDUs from target to initiator)." -Ayman From owner-ips@ece.cmu.edu Fri Feb 8 11:45: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 LAA14372 for ; Fri, 8 Feb 2002 11:45:27 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g18FgGn00135 for ips-outgoing; Fri, 8 Feb 2002 10:42:16 -0500 (EST) 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 g18FgFj00131 for ; Fri, 8 Feb 2002 10:42:15 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Feb 2002 10:42:09 -0500 Message-ID: <25369470B6F0D41194820002B328BDD22026D3@ATLOPS> From: Eddy Quicksall To: Julian Satran Cc: ips@ece.cmu.edu Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ? Date: Fri, 8 Feb 2002 10:42: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 I actually use 512 in my code because I know it won't be used. I gave this example because the current definition of Irrelevant implied that it was acceptable. I think the definition for Irrelevant should be improved. But, if everyone else is fine with it, I'll accept that. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, February 07, 2002 6:00 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu; Julian Satran Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ? It can give any legal value. Why should we add rules? Is something wrong having a value that is not used? Julo Eddy Quicksall ips@ece.cmu.edu cc: 07-02-02 13:56 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 Feb 8 12:45: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 MAA17031 for ; Fri, 8 Feb 2002 12:45:42 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g18Glsp04741 for ips-outgoing; Fri, 8 Feb 2002 11:47:54 -0500 (EST) 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 g18Gloj04734 for ; Fri, 8 Feb 2002 11:47:51 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id RAA67146 for ; Fri, 8 Feb 2002 17:47:43 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g18GnCf21844 for ; Fri, 8 Feb 2002 17:49:12 +0100 Subject: RE: iSCSI: MaxCmdSN rule To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Fri, 8 Feb 2002 02:30:16 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 08/02/2002 18:49:14 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Please consider also carefully the Serial Arithmetic rules with regard to "lower/higher" and the bounds on the ExpComdSN and MaxCmdSN difference. Julo ----- Forwarded by Julian Satran/Haifa/IBM on 08-02-02 02:26 ----- "Ayman Ghanem" .com> cc: Sent by: Subject: RE: iSCSI: MaxCmdSN rule owner-ips@ece. cmu.edu 08-02-02 00:53 This sentence should be changed to: "The target MUST NOT transmit a MaxCmdSN that is less than the last ExpCmdSN-1" The paragraph above this states: "If the PDU MaxCmdSN is less than the PDU ExpCmdSN-1 (in Serial Arithmetic Sense), they are both ignored." which allows MaxCmdSN = ExpCmdSN-1,valid, for the case when the target's command window is closed. -Ayman -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Buck Landry Sent: Thursday, February 07, 2002 2:40 PM To: ips@ece.cmu.edu Subject: iSCSI: MaxCmdSN rule Hi all, I'm struggling over how to interpret this rule in section 1.2.2 of draft v10: >>> The target MUST NOT transmit a MaxCmdSN that is less than the last ExpCmdSN. <<< This confuses me because it says to me (in some cases) that a target must be able to handle an unlimited number of commands. For example, let's say the target has just about reached the limit of the commands it can handle: T=>(Nop-In) (MaxCmdSN = 1, ExpCmdSN = 1) I=>(Scsi Read Cmd) (CmdSN = 1) T=>(Data-in) (MaxCmdSN = 1, ExpCmdSN = 2 /* acknowledging scsi read cmd */) Now the target may have many more data-ins to transmit. But according to the rule, since the last ExpCmdSN the target transmitted was 2, the target is now forced to send a MaxCmdSN of 2: T=>(Data-in) (MaxCmdSN = 2, ExpCmdSN = 2) But this allows the initiator to send another command, even though the target can't handle it! Obviously something is wrong with my reasoning here (perhaps my interpretation of 'last ExpCmdSN', or when I"m supposed to acknowledge the scsi cmd); can anybody clarify? --buck ----- Forwarded by Julian Satran/Haifa/IBM on 08-02-02 02:26 ----- "Buck Landry" roads.com> cc: Sent by: Subject: iSCSI: MaxCmdSN rule owner-ips@ece. cmu.edu 07-02-02 22:40 Hi all, I'm struggling over how to interpret this rule in section 1.2.2 of draft v10: >>> The target MUST NOT transmit a MaxCmdSN that is less than the last ExpCmdSN. <<< This confuses me because it says to me (in some cases) that a target must be able to handle an unlimited number of commands. For example, let's say the target has just about reached the limit of the commands it can handle: T=>(Nop-In) (MaxCmdSN = 1, ExpCmdSN = 1) I=>(Scsi Read Cmd) (CmdSN = 1) T=>(Data-in) (MaxCmdSN = 1, ExpCmdSN = 2 /* acknowledging scsi read cmd */) Now the target may have many more data-ins to transmit. But according to the rule, since the last ExpCmdSN the target transmitted was 2, the target is now forced to send a MaxCmdSN of 2: T=>(Data-in) (MaxCmdSN = 2, ExpCmdSN = 2) But this allows the initiator to send another command, even though the target can't handle it! Obviously something is wrong with my reasoning here (perhaps my interpretation of 'last ExpCmdSN', or when I"m supposed to acknowledge the scsi cmd); can anybody clarify? --buck From owner-ips@ece.cmu.edu Fri Feb 8 16:22: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 QAA25373 for ; Fri, 8 Feb 2002 16:22:52 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g18Kega23781 for ips-outgoing; Fri, 8 Feb 2002 15:40:42 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from osmtp1.electric.net (osmtp1.electric.net [216.129.90.28]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g18Keej23776 for ; Fri, 8 Feb 2002 15:40:40 -0500 (EST) Received: from [216.192.35.19] (helo=EGRodriguez) by osmtp1.electric.net with esmtp (Exim 3.22 #1) id 16ZHoy-0005GW-04 for ips@ece.cmu.edu; Fri, 08 Feb 2002 12:40:37 -0800 From: "Elizabeth G. Rodriguez" To: Subject: IPS-ALL: Last Call process Date: Fri, 8 Feb 2002 14:37:00 -0600 Message-ID: <000701c1b0e0$6bc39ff0$1323c0d8@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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The following is the contents of the presentation made Thursday evening, on the last call process. Working group Last Call will be issued . Editorial comments directly to authors/editor (e.g. typos, grammar, etc.), with copy to chairs/technical coordinator. . Technical comments to WG mailing list . All should review the document carefully, to insure that it is technically correct, the document has been prepared according to IETF guidelines and that it is ready to be forwarded to the IESG. Please Consult . "Considerations for Internet Drafts" - covers information on process, including nits that will insure that the IESG will return the draft. (http://www.ietf.org/ID-nits.html ) . "Recent and Proposed RFC Editorial Policy Changes" -- . (http://www.rfc-editor.org/policy.html) *** Note: The latter is now policy. 4 types of RFCs . Informational . Experimental . BCP . Standards Track The five initial documents to go to last call (Security, FC Encapsulation, iSCSI, FCIP, iFCP) will all be standards track documents. Working Group Last Call . Will be announced on IPS reflector . Review period of 2-4 weeks will be noted. . Comments will be resolved on the reflector. . New document resulting from comment resolution submitted to the WG for quick review, and then submitted to the ADs. *** Request to editors: Please generate companion documentation indicating changes from Last Called drafted (such as PDF document with change bars, or simple text to the reflector)if at all possible. The remainder of the presentation was taken from 'A Year in the Life of an Internet Draft' by Ned Freed, Allison Mankin & Thomas Narten, with minor changes. Becoming an RFC - The Process . AD review (3 business days ;-) - Is document ready? . Is document full of nits? - Is IETF last call needed? . Required for BCP, Standards track . Sometimes used with Info or Experimental RFCs . 2 weeks for WG documents . During IETF Last call - Community has chance to comment - IANA review (IANA considerations) *** Note: IANA ONLY looks at the IANA consideration section. Make sure this section is clear and self contained. - RFC Editor check (formatting, normative refs, etc.) IESG Review . AD verifies that outstanding issues resolved, then sends to IESG for full review - Technical quality? - Interoperability? - Completeness? - Adequate security? - ID nits (MUST/MAY/SHOULD defined?...) - Readability? - Usefulness?... Returned Documents . IESG comments are returned to author(s)/WG chair/WG . Iteration sometimes necessary... . Revised ID may be needed . Revised drafts may go directly to IESG, may need WG last call, or even another IETF last call (extreme cases) Are We Done Yet? . IESG concerns satisfactorily addressed? . IANA concerns satisfactorily addressed? . No normative references to Internet Drafts? . Is final ID in ID directory? . Finally!!! - IESG Secretary sends approval announcement The RFC Editor's Turn . ID enters RFC editor's queue . Some IDs are more equal than others - Standards track, WG documents have priority - IESG sometimes requests high priority (e.g., for RFC needed by another standards body) . Editing process begins - Check with IANA - fill in IANA assigned values (Oops -- IANA has more questions...) - 48 hour author review . Author must OK final version (Hello... where are the authors???) . Editorial changes only (Oops - these changes seem substantive...) . An RFC is born!!! . Total Elapsed time: 2.7 weeks - 13.4 years :-) Something to Think About . Internet Draft Statistics (Dec. 12, 2001): - Overall: . 2972 total . 2313 (excluding expired -- < 4kB in size) - Working Group Ids (excluding expired) . 975 Ids . 197 -00 submissions - Individual Submissions (excluding expired) . 1338 IDs . 681 -00 submissions Useful URLs . http://www.ietf.org/ietf/1id-guidelines.txt . http://www.ietf.org/ID-nits.html . http://www.ietf.org/IESG/request.html . http://www.rfc-editor.org/queue.html . http://www.rfc-editor.org/howtopub.html From owner-ips@ece.cmu.edu Fri Feb 8 16:36: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 QAA25679 for ; Fri, 8 Feb 2002 16:36:01 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g18Keeu23771 for ips-outgoing; Fri, 8 Feb 2002 15:40:40 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from osmtp1.electric.net (osmtp1.electric.net [216.129.90.28]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g18Kebj23766 for ; Fri, 8 Feb 2002 15:40:37 -0500 (EST) Received: from [216.192.35.19] (helo=EGRodriguez) by osmtp1.electric.net with esmtp (Exim 3.22 #1) id 16ZHoc-0005GW-04 for ips@ece.cmu.edu; Fri, 08 Feb 2002 12:40:24 -0800 Reply-To: , From: "Elizabeth G. Rodriguez" To: Subject: Request for new IPS 'additional page' Date: Fri, 8 Feb 2002 14:36:59 -0600 Message-ID: <000201c1b0e0$63fc8160$1323c0d8@EGRodriguez> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C1B0AE.19639800" 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_0003_01C1B0AE.19639800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, As mentioned before, due to changes at CMU, we no longer have an official auxiliary IPS web page. It is however useful to have a such a web page. Therefore, the chairs would like to ask if anyone is willing to host an auxiliary web page for IPS. On this page would be placed presentations, relevant links to other information, including protocol open source implementations, meeting announcements, agendas, minutes, design teams members, etc. On this page would not be links to corporate documents, logos, ads, etc. Anyone interested, please contact David and I. Thanks, Elizabeth & David ------=_NextPart_000_0003_01C1B0AE.19639800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

As mentioned before, due to changes at CMU, we no = longer have an official auxiliary IPS web page.

It is however useful to have a such a web = page.

 

Therefore, the chairs would like to ask if anyone is = willing to host an auxiliary web page for IPS.

On this page would be placed presentations, relevant = links to other information, including protocol open source = implementations,

meeting announcements, agendas, minutes, design teams members, etc.

On this page would not be links to corporate = documents, logos, ads, etc.

Anyone interested, please contact David and = I.

 

Thanks,

 

Elizabeth & David

------=_NextPart_000_0003_01C1B0AE.19639800-- From owner-ips@ece.cmu.edu Fri Feb 8 17:11: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 RAA26358 for ; Fri, 8 Feb 2002 17:11:53 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g18LUT927776 for ips-outgoing; Fri, 8 Feb 2002 16:30:29 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g18LURj27772 for ; Fri, 8 Feb 2002 16:30:28 -0500 (EST) Received: from cceexg13.americas.cpqcorp.net (cceexg13.americas.cpqcorp.net [16.110.250.119]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id F296D3E26; Fri, 8 Feb 2002 15:30:21 -0600 (CST) Received: from cceexc18.americas.cpqcorp.net ([16.110.250.64]) by cceexg13.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 8 Feb 2002 15:30:21 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: iSCSI: Boolean value (yes, no) negotiation Date: Fri, 8 Feb 2002 15:30:21 -0600 Message-ID: <31891B757C09184BBFEC5275F85D5595104E2D@cceexc18.americas.cpqcorp.net> Thread-Topic: iSCSI: Boolean value (yes, no) negotiation Thread-Index: AcGvknHIQ69kKxcETTWCA+D0Xy9ACgBU9ywA From: "Martin, Nick" To: "Julian Satran" , "Eddy Quicksall" Cc: , "Lakshmi Ramasubramanian" X-OriginalArrivalTime: 08 Feb 2002 21:30:21.0849 (UTC) FILETIME=[D01BA090:01C1B0E7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g18LUSj27773 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Julian, Eddy, and Lakshmi, OK, since I had it wrong last time. Let me try to explain it again. The default for ImmediateData is yes. The result function is AND. I->T ImmediateData=no Presuming the target wanted "yes", the result ("yes" AND "no") is "no". The target has one option T->I ImmediateData=no If this response is omitted, the result is the same. Login proceeds presuming ImmediateData=no. I have been corrected that ImmediateData=Reject is not valid. A response of ImmediateData=yes is also not valid. I do not see a login response code meaning option not supported by target. From this in infer that support for both ImmediateData=yes and ImmediateData=no is required. One is not supposed to build a target nor an initiator which does not support both possible values for each boolean. For either possible result of the negotiation, both parties should be able to proceed. Is this correct? If so, I think it is worth stating that support for both outcomes is required. Thanks, Nick > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Wednesday, February 06, 2002 10:41 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; julian_satran@il. ibm. com (E-mail); > Martin, Nick; > Lakshmi Ramasubramanian > Subject: RE: iSCSI: Boolean value (yes, no) negotiation > > > Eddy is right - reject is not intended/valid for booleans. > > Julo > > > > > Eddy Quicksall > > Nick" , > ivity.com> Lakshmi > Ramasubramanian > > , ips@ece.cmu.edu > 06-02-02 23:55 cc: Julian > Satran/Haifa/IBM@IBMIL > Subject: RE: > iSCSI: Boolean value (yes, no) > negotiation > > > > > > > > > > > It looks to me like "reject" is intended for list > negotiations (notice "all > of the offered options" ... I think that is referring to list > options): > > If a responder does not support or is not allowed to use all of the > offered options with a specific originator, it may use the constant > "Reject". > > Julian, correct me if I am wrong. > > Eddy > > -----Original Message----- > From: Martin, Nick [mailto:Nick.Martin@compaq.com] > Sent: Wednesday, February 06, 2002 2:18 PM > To: Lakshmi Ramasubramanian; ips@ece.cmu.edu > Subject: RE: iSCSI: Boolean value (yes, no) negotiation > > Lakshmi, > > It is my understanding, that if either initiator or target begins > negotiation for a boolean by sending a key=value pair, the responder > applies the specified boolean function (to the requested value and the > current value) to obtain the result. The result is then included in a > reply (unless the rules say it may be omitted). This negotiation is > concluded. > > I believe it should not be permitted for the responder, desiring a > different outcome, to later initiate negotiation for a different value > of the same parameter. If both initiator and target were permitted to > do this, it can cause an endless loop. However I do not find > where this > is documented. > > I have found an option for the target other than rejecting the login. > It can reject this parameter value with key=Reject. The initiator in > this case can then accept the value previously in effect, > negotiate for > another value, or close the connection. I believe sending key=Reject > does not require that the entire login should fail. The current value > for key should be unchanged by a negotiation ending in > key=Reject, just > as if it never happened. > > It is not always clear to me whether such negotiations are > intended only > to allow selection of preferred modes of operation, or to enable > implementations which do not support certain features to operate with > other implementations which do not require those features. > > For example, it is not stated whether a target or an > initiator SHOULD or > MUST implement/accept both ImmediateData=yes and ImmediateData=no. > > If these are for preferences, and the initiator and target are > configured for different preferences, what should be the > result? Either > result may allow operation. In fact neither may be optimal for both > parties at the same time. Is the result predictable? Should we > negotiate differently for preferences versus requirements? > For example > should an initiator only negotiate preferences after the > target has had > a chance to negotiate requirements? Should we expect that key=Reject > could be the response to almost any key negotiation? > > The suggestion by Rahul to use key=? is not permitted. key=? is only > permitted in text commands, during full feature phase. It returns the > current value, not the list of support values. Requesting the list of > supported values is not a current capability. > > Thanks, > Nick > > > -----Original Message----- > > From: Lakshmi Ramasubramanian [mailto:nramas@windows.microsoft.com] > > Sent: Wednesday, February 06, 2002 11:26 AM > > To: ips@ece.cmu.edu > > Subject: iSCSI: Boolean value (yes, no) negotiation > > > > > > Could someone please clarify Boolean key=value usage > > (such as "ImmediateData=yes", etc)? > > > > For example, the initiator sends to target "ImmediateData=no". > > But the target wants ImmediateData. So, it sends back > > "ImmediateData=yes". > > The initiator, being able to handle it, sends back > "ImmediateData=no". > > Now, they use immediate data in the PDUs. > > > > Is this valid? Or, in the above case if the target can't handle > > non-immediate data it has to reject the login ? > > > > thanks! > > -lakshmi > > > > > > > From owner-ips@ece.cmu.edu Fri Feb 8 21:55: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 VAA00827 for ; Fri, 8 Feb 2002 21:55:20 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g191xtD15301 for ips-outgoing; Fri, 8 Feb 2002 20:59:55 -0500 (EST) 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 g191xrj15295 for ; Fri, 8 Feb 2002 20:59:53 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id CAA256642 for ; Sat, 9 Feb 2002 02:59:46 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1921Ff33214 for ; Sat, 9 Feb 2002 03:01:15 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: draft-10 editorial X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 9 Feb 2002 04:01:13 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 09/02/2002 04:01:18, Serialize complete at 09/02/2002 04:01:18 Content-Type: multipart/alternative; boundary="=_alternative 000ACB69C2256B5B_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 000ACB69C2256B5B_= Content-Type: text/plain; charset="us-ascii" Thanks - I will - Julo "Ayman Ghanem" Sent by: owner-ips@ece.cmu.edu 08-02-02 16:49 To: cc: Subject: iSCSI: draft-10 editorial Julian, Since the I-bit is now reserved in response PDUs, the following from 10.2.1.1 should be removed: "This bit is always 1 for response PDUs (PDUs from target to initiator)." -Ayman --=_alternative 000ACB69C2256B5B_= Content-Type: text/html; charset="us-ascii"
Thanks - I will - Julo


"Ayman Ghanem" <aghanem@cisco.com>
Sent by: owner-ips@ece.cmu.edu

08-02-02 16:49

       
        To:        <ips@ece.cmu.edu>
        cc:        
        Subject:        iSCSI: draft-10 editorial

       


Julian,

Since the I-bit is now reserved in response PDUs, the following from
10.2.1.1 should be removed:

                "This bit is always 1 for response PDUs (PDUs from target to initiator)."

-Ayman

--=_alternative 000ACB69C2256B5B_=-- From owner-ips@ece.cmu.edu Fri Feb 8 22:58: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 WAA02502 for ; Fri, 8 Feb 2002 22:58:29 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g193FeY19308 for ips-outgoing; Fri, 8 Feb 2002 22:15:40 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g193Fcj19304 for ; Fri, 8 Feb 2002 22:15:38 -0500 (EST) Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.110.250.124]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 76CFE42B5; Fri, 8 Feb 2002 21:15:31 -0600 (CST) Received: from cceexc18.americas.cpqcorp.net ([16.110.250.64]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 8 Feb 2002 21:15:31 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: iSCSI: draft-10 more editorial Date: Fri, 8 Feb 2002 21:15:30 -0600 Message-ID: <31891B757C09184BBFEC5275F85D559501F22B5B@cceexc18.americas.cpqcorp.net> Thread-Topic: iSCSI: draft-10 more editorial Thread-Index: AcGxGAdXKN51+971SzutXYvwKW5rZA== From: "Martin, Nick" To: "Julian Satran" Cc: X-OriginalArrivalTime: 09 Feb 2002 03:15:31.0207 (UTC) FILETIME=[07D8E170:01C1B118] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g193Fcj19305 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Julian, The following are some more comments about the iSCSI draft 10 document. These are primarily editorial comments. Thanks, Nick As previously noted, the section numbers and page numbers are different between the text and pdf versions of the document. All my comments are based on the pdf version. Page 26 "Initiator that identifying elements, such as..." The word "that" does not fit. One of the words "unique", "defined", "specific" or "assigned" may have been intended, or perhaps it can just be removed. On page 33, The capitalization of the quoted keyword "None" is confusing "(literal constants which may include "None")". I have previously believed that keywords were case sensitive and that "none" (not "None") was the correct string. I note however that nearly all other keywords have been capitalized ("Reject", "NotUnderstood", etc.). For consistency with other keywords perhaps we should use "None". (As someone else noted, "yes" and "no" are also not currently capitalized.) On page 35, I presume the text "(up to the mode page limit)" is obsolete since iSCSI mode pages have been removed. On page 36 "It is also an error ..., than the SCSI limit for first burst." Should "SCSI" not be "iSCSI"? In the next sentence, which mentions "MAY request to send data blocks and a first burst of any size;..." This looks like it might have been a reference to 0 meaning any value which is now removed. On page 44, the sentence "During login, each end of the iSCSI session specifies the maximum iSCSI PDU size it will accept." This sounds like the PDU size could be negotiated differently in each direction. This is not how I think it works. On page 87, one paragraph starts with "LS:When". I presume the LS: should be removed. This may be more of an issue than editorial: On page 89, section 7.7 Negotiation Failures, I believe another reason needs to be listed. - The text request was answered with Irrelevant. Alternatively perhaps Irrelevant was added as a way to avoid sending a reject. If a negotiation ending in Irrelevant is to be considered a successful negotiation, this needs to be clearly stated. On page 115, in "than no more data PDUs are expected", "than" should be "then". On page 124, in the section Referenced Task Tag, ABORT TASK is referred to as TASK ABORT. On page 134, in the section R2TSN, the maximum number of R2Ts is given in hexadecimal 0xffffffff. In most other cases (like DataSN on page 131) the limits are expressed in decimal 2**32 or 2**32-1. The form 0xffffffff is generally used when specifying a reserved value. On page 141, for the list of characters valid in a text value, I would suggest also allowing the character '@' as would be used in e-mail addresses. On page 141, it is explained that binary items may be expressed in decimal, hex, or Base64. Are the protocol defined binary values, such as MaxRecvPDULength required to be accepted in all these formats? Request for clarification/restriction of text key=value continuations: Are there any special rules for text key=value pairs spanning PDUs? Is a pair of length less than MaxRecvPDULength permitted to span PDUs? Is the sender required to fill MaxRecvPDULength before continuing to the next PDU? Can a key=value pair which will require continuation begin somewhere in the middle of a PDU text buffer due to other key=value pairs already in the buffer? If so, can a key=value pair be continued before the "=" ? Is the text buffer to be continued required to fill a multiple of 4 bytes in the current text buffer (no padding required)? I would personally prefer to see key=value continuation restricted to cases where the key=value string exceeds MaxRecvPDULength. In other cases when the next key=value will not fit in the remaining space in the current PDU, one could put the entire key=value in the next text PDU. This would eliminate the possibility that one could be expected to correctly parse small strings such as ImmediateData=yes or MaxBurstSize=16384 with PDU breaks within them (MaxBurstSize=16384). On page 149, in the section Login Parameters, the text appears contradictory. "All keys in Chapter 12, except for the X- extension format, MUST be supported by iSCSI initiators and targets. Keys in Chapter 12, only need to be supported when the function to which they refer is mandatory to implement." On page 173, there is no section header (and number) for the beginning of CHAP protocol. On page 179, an example for TargetAlias uses an apostrophe (') although this is not among the permitted characters (on page 141). On page 181, InitialR2T has no section number. On page 184, LogoutLoginMaxTime has no section number. From owner-ips@ece.cmu.edu Sat Feb 9 00:33: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 AAA03933 for ; Sat, 9 Feb 2002 00:33:11 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g194rsi24583 for ips-outgoing; Fri, 8 Feb 2002 23:53:54 -0500 (EST) 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 g194rqj24575 for ; Fri, 8 Feb 2002 23:53:52 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id FAA181702 for ; Sat, 9 Feb 2002 05:53:45 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g194tFf62120 for ; Sat, 9 Feb 2002 05:55:15 +0100 Subject: iSCSI: Seven minor draft 10 editorial comments To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Sat, 9 Feb 2002 06:36:37 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 09/02/2002 06:55:18 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk thanks - julo ----- Forwarded by Julian Satran/Haifa/IBM on 09-02-02 06:36 ----- Daniel Lee cc: Sent by: Subject: iSCSI: Seven minor draft 10 editorial owner-ips@ece. comments cmu.edu 08-02-02 13:48 Hi Julian, Here are some more comments on the draft 10 PDF file. Minor Editorial Comment #1 On page 105 the "9.4" section heading is missing from the "Sync and Steering Layer and Performance" section. As a result, the next section entitled "Unsolicited Data and Performance" is mislabled as "9.4" instead of "9.5". Minor Editorial Comment #2 There's a typo in Section 2.2.1, in the second paragraph on page 26. I've extracted the paragraph below, the typo is beginning of the 4th sentence. Across all connections within a session, an initiator sees one "target image". All target identifying elements, such as LUN, are the same. In addition, a target sees one "initiator image" across all connections within a session. Initiator that identifying elements, such as the Initiator Task Tag, can be used to identify the same entity regardless of the connection on which they are sent or received. I recommend rewriting the paragraph as follows: An initiator sees one "target image" across all connections within a session. All target identifying elements, such as LUN, are identical regardless of the connection on which they are sent or received. In addition, a target sees one "initiator image" across all connections within a session. Initiator identifying elements, such as the Initiator Task Tag, are identical regardless of the connection on which they are sent or received. Minor Editorial Comment #3 Typo on page 234: 'Success' is misspelled as 'Sucess' Minor Editorial Comment #4 For consistency and clarity reasons I recommend changing the following pseudocode at the top of page 230 as follows. if (current StatSN is not expected) { Recover-Status-if-Possible(Connection, CurrentPDU); } if (current ExpCmdSN is not our NextCmdSN) { Retransmit-Command-if-Possible(Connection, CurrentPDU.ExpCmdSN); } if (CurrentPDU.StatSN is not expected) { Recover-Status-if-Possible(Connection, CurrentPDU); } if (CurrentPDU.ExpCmdSN != Session.NextCmdSN) { Retransmit-Command-if-Possible(Connection, CurrentPDU.ExpCmdSN); } In addition, the 'Session.NextCmdSN' should probably be 'Connection.SessionReference.NextCmdSN', but it's not used this way elsewhere in the pseudocode and it's easy enough to understand the way it's currently used. Minor Editorial Comment #5 In the pseudocode for the previous Editorial Comment (on page 230) and in the 'struct Session' definition on page 222, it might make sense to change 'NextCmdSN' to just 'CmdSN' for consistency reasons (since on page 28 it says 'CmdSn always contains the number to be assigned next'). Minor Editorial Comment #6 The 'n' in 'CmdSn' on page 28 (referenced in Editorial Comment #4) should be capitalized. Minor Editorial Comment #7 (Note: I'll stop my Editorial Comments with this one since 7 is a lucky number.) I suggest the following line on page 29 be either modified as follows or removed completely to make it less confusing to first time readers of the spec. -If the PDU MaxCmdSN is less than the PDU ExpCmdSN-1 (in Serial Arithmetic Sense), they are both ignored. -If the PDU MaxCmdSN is less than the PDU ExpCmdSN-1 (in Serial Arithmetic Sense), the target has made an error generating this PDU so both fields are ignored. The reason I suggest this change is that it isn't until a few lines down the in the spec that you learn 'The target MUST NOT transmit a MaxCmdSN that is less than the last ExpCmdSN.' (note: the previous line might be clearer as 'The target MUST NOT transmit a MaxCmdSN that is less than ExpCmdSN-1 (in Serial Arithmetic Sense)'. Regards, Daniel Lee Unemployed Person dan@danielslee.com "iSCSI, therefore I am" __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com From owner-ips@ece.cmu.edu Sat Feb 9 00:33: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 AAA03945 for ; Sat, 9 Feb 2002 00:33:12 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g194s8i24597 for ips-outgoing; Fri, 8 Feb 2002 23:54:08 -0500 (EST) 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 g194s6j24589 for ; Fri, 8 Feb 2002 23:54:06 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id FAA39532; Sat, 9 Feb 2002 05:53:57 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g194tQf96460; Sat, 9 Feb 2002 05:55:26 +0100 Subject: RE: iSCSI: Boolean value (yes, no) negotiation To: "Martin, Nick" Cc: "Eddy Quicksall" , ips@ece.cmu.edu, "Julian Satran" , "Lakshmi Ramasubramanian" X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Sat, 9 Feb 2002 06:51:44 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 09/02/2002 06:55:30 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Martin, All you say is correct. The function AND means that both parties have to say yes for it to hold. The target cannot force his decision on the initiator. On the other hand I do not see this as an issue of practical importance (in this case) as a initiator will most probably say yes about ImmediateData (no resources involved) and a target will say what it wants (resources involved) and will have the issue settled in one round. I->T ImmediateData=Yes T->I ImediateData=No /No Julo "Martin, Nick" Quicksall" cc: , "Lakshmi 08-02-02 23:30 Ramasubramanian" Subject: RE: iSCSI: Boolean value (yes, no) negotiation Julian, Eddy, and Lakshmi, OK, since I had it wrong last time. Let me try to explain it again. The default for ImmediateData is yes. The result function is AND. I->T ImmediateData=no Presuming the target wanted "yes", the result ("yes" AND "no") is "no". The target has one option T->I ImmediateData=no If this response is omitted, the result is the same. Login proceeds presuming ImmediateData=no. I have been corrected that ImmediateData=Reject is not valid. A response of ImmediateData=yes is also not valid. I do not see a login response code meaning option not supported by target. From this in infer that support for both ImmediateData=yes and ImmediateData=no is required. One is not supposed to build a target nor an initiator which does not support both possible values for each boolean. For either possible result of the negotiation, both parties should be able to proceed. Is this correct? If so, I think it is worth stating that support for both outcomes is required. Thanks, Nick > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Wednesday, February 06, 2002 10:41 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; julian_satran@il. ibm. com (E-mail); > Martin, Nick; > Lakshmi Ramasubramanian > Subject: RE: iSCSI: Boolean value (yes, no) negotiation > > > Eddy is right - reject is not intended/valid for booleans. > > Julo > > > > > Eddy Quicksall > > Nick" , > ivity.com> Lakshmi > Ramasubramanian > > , ips@ece.cmu.edu > 06-02-02 23:55 cc: Julian > Satran/Haifa/IBM@IBMIL > Subject: RE: > iSCSI: Boolean value (yes, no) > negotiation > > > > > > > > > > > It looks to me like "reject" is intended for list > negotiations (notice "all > of the offered options" ... I think that is referring to list > options): > > If a responder does not support or is not allowed to use all of the > offered options with a specific originator, it may use the constant > "Reject". > > Julian, correct me if I am wrong. > > Eddy > > -----Original Message----- > From: Martin, Nick [mailto:Nick.Martin@compaq.com] > Sent: Wednesday, February 06, 2002 2:18 PM > To: Lakshmi Ramasubramanian; ips@ece.cmu.edu > Subject: RE: iSCSI: Boolean value (yes, no) negotiation > > Lakshmi, > > It is my understanding, that if either initiator or target begins > negotiation for a boolean by sending a key=value pair, the responder > applies the specified boolean function (to the requested value and the > current value) to obtain the result. The result is then included in a > reply (unless the rules say it may be omitted). This negotiation is > concluded. > > I believe it should not be permitted for the responder, desiring a > different outcome, to later initiate negotiation for a different value > of the same parameter. If both initiator and target were permitted to > do this, it can cause an endless loop. However I do not find > where this > is documented. > > I have found an option for the target other than rejecting the login. > It can reject this parameter value with key=Reject. The initiator in > this case can then accept the value previously in effect, > negotiate for > another value, or close the connection. I believe sending key=Reject > does not require that the entire login should fail. The current value > for key should be unchanged by a negotiation ending in > key=Reject, just > as if it never happened. > > It is not always clear to me whether such negotiations are > intended only > to allow selection of preferred modes of operation, or to enable > implementations which do not support certain features to operate with > other implementations which do not require those features. > > For example, it is not stated whether a target or an > initiator SHOULD or > MUST implement/accept both ImmediateData=yes and ImmediateData=no. > > If these are for preferences, and the initiator and target are > configured for different preferences, what should be the > result? Either > result may allow operation. In fact neither may be optimal for both > parties at the same time. Is the result predictable? Should we > negotiate differently for preferences versus requirements? > For example > should an initiator only negotiate preferences after the > target has had > a chance to negotiate requirements? Should we expect that key=Reject > could be the response to almost any key negotiation? > > The suggestion by Rahul to use key=? is not permitted. key=? is only > permitted in text commands, during full feature phase. It returns the > current value, not the list of support values. Requesting the list of > supported values is not a current capability. > > Thanks, > Nick > > > -----Original Message----- > > From: Lakshmi Ramasubramanian [mailto:nramas@windows.microsoft.com] > > Sent: Wednesday, February 06, 2002 11:26 AM > > To: ips@ece.cmu.edu > > Subject: iSCSI: Boolean value (yes, no) negotiation > > > > > > Could someone please clarify Boolean key=value usage > > (such as "ImmediateData=yes", etc)? > > > > For example, the initiator sends to target "ImmediateData=no". > > But the target wants ImmediateData. So, it sends back > > "ImmediateData=yes". > > The initiator, being able to handle it, sends back > "ImmediateData=no". > > Now, they use immediate data in the PDUs. > > > > Is this valid? Or, in the above case if the target can't handle > > non-immediate data it has to reject the login ? > > > > thanks! > > -lakshmi > > > > > > > From owner-ips@ece.cmu.edu Sat Feb 9 03:24: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 DAA12989 for ; Sat, 9 Feb 2002 03:24:45 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g197hVl03219 for ips-outgoing; Sat, 9 Feb 2002 02:43:31 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g197hUj03215 for ; Sat, 9 Feb 2002 02:43:30 -0500 (EST) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Sat, 9 Feb 2002 02:46:11 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E03D021A1@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: Full Text of Phoenix letter Date: Sat, 9 Feb 2002 02:43:12 -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 To: IETF IP Storage Working Group Subject: Phoenix Patents and RFC 2945 February 6, 2002 Dear working group members, Regarding the inquiry by working group co-chair David Black into the nature of U.S. patent 6,226,383 and its relation to SRP and RFC 2945, this letter presents a status update on Phoenix's plans to provide an appropriate response for the working group. This letter also presents a general summary of our licensing practices and products in the field of password-based cryptography, which I hope will assist you in the planning process. Phoenix owns patent 6,226,383 which describes the SPEKE methods for zero-knowledge password authentication. An investigation into exactly how this patent relates to RFC 2945 is now underway within the company. While providing guarantees and assurances for use of technology developed by other organizations has not been a traditional priority for Phoenix, there is now recognition of the need for this working group and others to have clarity in this matter, and a position statement will be provided very soon. Phoenix Technologies, in part through the acquisition of Integrity Sciences, has developed the SPEKE family of zero-knowledge password methods, providing both licenses and implementations. These protocols have been cited and studied in numerous research papers over the past several years. In particular, the BSPEKE protocol can provide a plug-and-play upgrade for SRP. An Internet Draft discussing these issues is also being prepared. These methods are comparable to the best of any similar methods, and they are easily shown to be unencumbered by the other patents in this field. It would seem a shame for a new standards effort to avoid zero-knowledge password techniques as a purely cost-savings measure, given the choices available. The need for convenient, strong, and inexpensive security built-in to the infrastructure of Internet applications is as great today as ever. The SPEKE techniques represent a generational improvement in personal authentication, providing strong security with minimal effort. These methods provide the best choices in this field, with the cleanest implementations, optimal security, best alignment with standards, and easiest license agreements for commercial deployment of zero-knowledge password techniques. A statement regarding licensing of the SPEKE patent in the context of the IEEE 1363 standard is on file with the IEEE, and Phoenix is also committed to providing an updated statement in this same time frame that conforms to both IEEE and IETF policies assuring reasonable and non-discriminatory terms. But more importantly, as a leading provider to the PC industry, Phoenix will stand behind its technology. Phoenix has a 20-year history of broadly licensing products to this industry, and has helped to pioneer many widely used standards and technologies that are built-in to the systems that we all take for granted. Our history of cooperation with many of the leading companies in the industry makes Phoenix naturally suited to gently encouraging the adoption of this new class of strong and convenient security techniques. Sincerely, David Jablon CTO, Phoenix Technologies From owner-ips@ece.cmu.edu Sat Feb 9 03:26: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 DAA13014 for ; Sat, 9 Feb 2002 03:26:30 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g197hPc03207 for ips-outgoing; Sat, 9 Feb 2002 02:43:26 -0500 (EST) 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 g197hNj03202 for ; Sat, 9 Feb 2002 02:43:23 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id <1B55LR1S>; Sat, 9 Feb 2002 02:43:17 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E03D021A0@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: SRP IPR Update Presentation Date: Sat, 9 Feb 2002 02:43:10 -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 Here is the entire text of the Update presentation I gave on SRP Intellectual Property Rights. I'm also about to post the letter to the list and recommend that it be read in its entirety as opposed to relying on the summary excerpts in this presentation. Thanks, --David SRP Intellectual Property Rights Update David Black, IP Storage WG co-chair February 7, 2002 Huntington Beach, CA -- Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session. - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB, or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function. Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group, or function are not subject to these provisions. -- Disclaimer I am NOT a lawyer This is NOT legal advice If you need legal advice ... You need to talk to a lawyer If actions or decisions based on information in this presentation have legal consequences Those consequences are YOUR responsibility The IETF and yours truly disclaim all responsibility -- IETF Policy: Intellectual Property and Contributions RFC 2026, Section 10.3.1, Clause 6: 6. The contributor represents that he has disclosed the existence of any proprietary or intellectual property rights in the contribution that are reasonably and personally known to the contributor. The contributor does not represent that he personally knows of all potentially pertinent proprietary and intellectual property rights owned or claimed by the organization he represents (if any) or third parties. This is an obligation to disclose. Includes things you should know. How to disclose: www.ietf.org/ipr.html -- IETF Policy: Intellectual Property Rights Claims (I) RFC 2026, Section 10.3.2, Clause (A): (A) Where any patents, patent applications, or other proprietary rights are known, or claimed, with respect to any specification on the standards track, and brought to the attention of the IESG, the IESG shall not advance the specification without including in the document a note indicating the existence of such rights, or claimed rights. If rights are known or claimed, the RFC will say that the IETF has been notified. As of the date the RFC is published Nothing specific about the claim(s) -- IETF Policy: Intellectual Property Rights Claims (II) RFC 2026, Section 10.3.2, Clause (B): (B) The IESG disclaims any responsibility for identifying the existence of or for evaluating the applicability of any claimed copyrights, patents, patent applications, or other rights in the fulfilling of the its obligations under (A), and will take no position on the validity or scope of any such rights. No IETF obligation to identify claims. The IETF takes no positions on validity or scope. -- IETF Policy: Intellectual Property Rights Claims (III) RFC 2026, Section 10.3.2, Clause (C): (C) Where the IESG knows of rights, or claimed rights under (A), the IETF Executive Director shall attempt to obtain from the claimant of such rights, a written assurance that upon approval by the IESG of the relevant Internet standards track specification(s), any party will be able to obtain the right to implement, use and distribute the technology or works when implementing, using or distributing technology based upon the specific specification(s) under openly specified, reasonable, non-discriminatory terms. Attempt to obtain promise, response not required. Promises are recorded at: www.ietf.org/ipr.html . -- SRP and iSCSI Context iSCSI currently REQUIRES SRP SRP = Secure Remote Password, RFC 2945 Rumors of patent claims covering SRP Goal: Avoid basing decisions on rumors Make information available to reduce uncertainty Non-goal (still): Determine SRP requirement now Insufficient time for technical/legal analysis of new information by WG members -- Stanford Has filed for a patent on SRP No-cost licenses are available http://otl.stanford.edu/pdf/97006.pdf Explicitly references RFC 2945 Unidirectional license, not reciprocal -- Lucent: EKE Patents In December at the Salt Lake City mtg., Elizabeth Rodriguez, speaking as a Lucent employee said: - Lucent is researching whether the EKE patents (US 5,241,599 and US 5,440,635) or any other Lucent patents are essential to SRP implementation. - If patent(s) is/are found that is/are determined to be necessary to SRP implementation, Lucent will license the Intellectual Property under normal Lucent licensing practices. Lucent has subsequently changed their position(s) Details on next slide -- Lucent: EKE patents (II) This morning (Feb. 7), a Lucent employee speaking on behalf of Lucent told me that: - Lucent will not proceed with research on the EKE patents. - Lucent will not take a public position on whether the EKE patents apply to SRP. - Lucent takes the position that SRP implementers are responsible for their own technical and legal analysis. - Lucent will license the EKE patents under normal Lucent licensing practices. Caveat: This is based on my understanding of the (oral) conversation. -- Phoenix: SPEKE patent A Letter was received yesterday (Feb. 6) from David Jablon, CTO of Phoenix, regarding the SPEKE patent: US 6,226,383 (2001): Cryptographic methods for remote authentication Paragraphs relevant to SRP on next 3 slides Entire text of the letter will be posted to the mailing list shortly (if in doubt, read that). -- Phoenix: SPEKE letter text (I) Regarding the inquiry by working group co-chair David Black into the nature of U.S. patent 6,226,383 and its relation to SRP and RFC 2945, this letter presents a status update on Phoenix's plans to provide an appropriate response for the working group. This letter also presents a general summary of our licensing practices and products in the field of password-based cryptography, which I hope will assist you in the planning process. -- Phoenix: SPEKE letter text (II) Phoenix owns patent 6,226,383 which describes the SPEKE methods for zero-knowledge password authentication. An investigation into exactly how this patent relates to RFC 2945 is now underway within the company. While providing guarantees and assurances for use of technology developed by other organizations has not been a traditional priority for Phoenix, there is now recognition of the need for this working group and others to have clarity in this matter, and a position statement will be provided very soon. Note: RFC 2945 specifies SRP. -- Phoenix: SPEKE letter text (III) A statement regarding licensing of the SPEKE patent in the context of the IEEE 1363 standard is on file with the IEEE, and Phoenix is also committed to providing an updated statement in this same time frame that conforms to both IEEE and IETF policies assuring reasonable and non-discriminatory terms. But more importantly, as a leading provider to the PC industry, Phoenix will stand behind its technology. Phoenix has a 20-year history of broadly licensing products to this industry, and has helped to pioneer many widely used standards and technologies that are built-in to the systems that we all take for granted. Our history of cooperation with many of the leading companies in the industry makes Phoenix naturally suited to gently encouraging the adoption of this new class of strong and convenient security techniques. -- Next Steps Clarification questions: Ok to ask here Technical questions/discussion: IPS mailing list NOTE: cryptographic and legal expertise are needed to understand these patents - Request (1): Please obtain expertise before posting - Request (2): Please wait for text of this talk to be posted to the list (will happen in next day or so) SRP requirements level: Minneapolis IETF meeting - There will be no further postponements of this issue!! From owner-ips@ece.cmu.edu Sat Feb 9 17:02: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 RAA20048 for ; Sat, 9 Feb 2002 17:02:33 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g19Kt9M24128 for ips-outgoing; Sat, 9 Feb 2002 15:55:09 -0500 (EST) 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 g19Kt7j24123 for ; Sat, 9 Feb 2002 15:55:07 -0500 (EST) Received: from amirdesktop (dhcp62 [172.21.2.62]) by astutenetworks.com (8.11.6/8.11.2) with SMTP id g19Ks3615368; Sat, 9 Feb 2002 12:54:03 -0800 From: "Amir Shalit" To: "Julian Satran" , Subject: RE: iSCSI: Seven minor draft 10 editorial comments Date: Sat, 9 Feb 2002 12:54:03 -0800 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 Julo, Regarding comment number 2: An initiator sees one "target image" across all connections within a session. All target identifying elements, such as LUN, are identical regardless of the connection on which they are sent or received. In addition, a target sees one "initiator image" across all connections within a session. Initiator identifying elements, such as the Initiator Task Tag, are identical regardless of the connection on which they are sent or received. I find the following sentence rather misleading: "Initiator identifying elements, such as the Initiator Task Tag, are identical regardless of the connection on which they are sent or received." I recommend to leave the old statement "as-is" or change it to: "Initiator identifying elements, such as the Initiator Task Tag, are global across the session regardless of the connection on which they are sent or received." Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Friday, February 08, 2002 8:37 PM To: ips@ece.cmu.edu Subject: iSCSI: Seven minor draft 10 editorial comments thanks - julo ----- Forwarded by Julian Satran/Haifa/IBM on 09-02-02 06:36 ----- Daniel Lee cc: Sent by: Subject: iSCSI: Seven minor draft 10 editorial owner-ips@ece. comments cmu.edu 08-02-02 13:48 Hi Julian, Here are some more comments on the draft 10 PDF file. Minor Editorial Comment #1 On page 105 the "9.4" section heading is missing from the "Sync and Steering Layer and Performance" section. As a result, the next section entitled "Unsolicited Data and Performance" is mislabled as "9.4" instead of "9.5". Minor Editorial Comment #2 There's a typo in Section 2.2.1, in the second paragraph on page 26. I've extracted the paragraph below, the typo is beginning of the 4th sentence. Across all connections within a session, an initiator sees one "target image". All target identifying elements, such as LUN, are the same. In addition, a target sees one "initiator image" across all connections within a session. Initiator that identifying elements, such as the Initiator Task Tag, can be used to identify the same entity regardless of the connection on which they are sent or received. I recommend rewriting the paragraph as follows: An initiator sees one "target image" across all connections within a session. All target identifying elements, such as LUN, are identical regardless of the connection on which they are sent or received. In addition, a target sees one "initiator image" across all connections within a session. Initiator identifying elements, such as the Initiator Task Tag, are identical regardless of the connection on which they are sent or received. Minor Editorial Comment #3 Typo on page 234: 'Success' is misspelled as 'Sucess' Minor Editorial Comment #4 For consistency and clarity reasons I recommend changing the following pseudocode at the top of page 230 as follows. if (current StatSN is not expected) { Recover-Status-if-Possible(Connection, CurrentPDU); } if (current ExpCmdSN is not our NextCmdSN) { Retransmit-Command-if-Possible(Connection, CurrentPDU.ExpCmdSN); } if (CurrentPDU.StatSN is not expected) { Recover-Status-if-Possible(Connection, CurrentPDU); } if (CurrentPDU.ExpCmdSN != Session.NextCmdSN) { Retransmit-Command-if-Possible(Connection, CurrentPDU.ExpCmdSN); } In addition, the 'Session.NextCmdSN' should probably be 'Connection.SessionReference.NextCmdSN', but it's not used this way elsewhere in the pseudocode and it's easy enough to understand the way it's currently used. Minor Editorial Comment #5 In the pseudocode for the previous Editorial Comment (on page 230) and in the 'struct Session' definition on page 222, it might make sense to change 'NextCmdSN' to just 'CmdSN' for consistency reasons (since on page 28 it says 'CmdSn always contains the number to be assigned next'). Minor Editorial Comment #6 The 'n' in 'CmdSn' on page 28 (referenced in Editorial Comment #4) should be capitalized. Minor Editorial Comment #7 (Note: I'll stop my Editorial Comments with this one since 7 is a lucky number.) I suggest the following line on page 29 be either modified as follows or removed completely to make it less confusing to first time readers of the spec. -If the PDU MaxCmdSN is less than the PDU ExpCmdSN-1 (in Serial Arithmetic Sense), they are both ignored. -If the PDU MaxCmdSN is less than the PDU ExpCmdSN-1 (in Serial Arithmetic Sense), the target has made an error generating this PDU so both fields are ignored. The reason I suggest this change is that it isn't until a few lines down the in the spec that you learn 'The target MUST NOT transmit a MaxCmdSN that is less than the last ExpCmdSN.' (note: the previous line might be clearer as 'The target MUST NOT transmit a MaxCmdSN that is less than ExpCmdSN-1 (in Serial Arithmetic Sense)'. Regards, Daniel Lee Unemployed Person dan@danielslee.com "iSCSI, therefore I am" __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com From owner-ips@ece.cmu.edu Sun Feb 10 13: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 NAA08921 for ; Sun, 10 Feb 2002 13:26:47 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1AHE5o04524 for ips-outgoing; Sun, 10 Feb 2002 12:14:05 -0500 (EST) 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 g1AHE3j04518 for ; Sun, 10 Feb 2002 12:14:03 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Sun, 10 Feb 2002 12:13:47 -0500 Message-ID: <25369470B6F0D41194820002B328BDD22026FB@ATLOPS> From: Eddy Quicksall To: "Martin, Nick" , "julian_satran@il. ibm. com (E-mail)" Cc: ips@ece.cmu.edu, Lakshmi Ramasubramanian Subject: RE: iSCSI: Boolean value (yes, no) negotiation Date: Sun, 10 Feb 2002 12:13:43 -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 Regarding "support for both outcomes is required". I don't agree. Targets can have all sorts of reasons not to support both. It may be useful to have a value like "Reject" apply for cases like this. Then, the initiator or target would the option to disconnect or try to keep going depending on the key. Eddy -----Original Message----- From: Martin, Nick [mailto:Nick.Martin@COMPAQ.com] Sent: Friday, February 08, 2002 4:30 PM To: Julian Satran; Eddy Quicksall Cc: ips@ece.cmu.edu; Lakshmi Ramasubramanian Subject: RE: iSCSI: Boolean value (yes, no) negotiation Julian, Eddy, and Lakshmi, OK, since I had it wrong last time. Let me try to explain it again. The default for ImmediateData is yes. The result function is AND. I->T ImmediateData=no Presuming the target wanted "yes", the result ("yes" AND "no") is "no". The target has one option T->I ImmediateData=no If this response is omitted, the result is the same. Login proceeds presuming ImmediateData=no. I have been corrected that ImmediateData=Reject is not valid. A response of ImmediateData=yes is also not valid. I do not see a login response code meaning option not supported by target. From this in infer that support for both ImmediateData=yes and ImmediateData=no is required. One is not supposed to build a target nor an initiator which does not support both possible values for each boolean. For either possible result of the negotiation, both parties should be able to proceed. Is this correct? If so, I think it is worth stating that support for both outcomes is required. Thanks, Nick > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Wednesday, February 06, 2002 10:41 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; julian_satran@il. ibm. com (E-mail); > Martin, Nick; > Lakshmi Ramasubramanian > Subject: RE: iSCSI: Boolean value (yes, no) negotiation > > > Eddy is right - reject is not intended/valid for booleans. > > Julo > > > > > Eddy Quicksall > > Nick" , > ivity.com> Lakshmi > Ramasubramanian > > , ips@ece.cmu.edu > 06-02-02 23:55 cc: Julian > Satran/Haifa/IBM@IBMIL > Subject: RE: > iSCSI: Boolean value (yes, no) > negotiation > > > > > > > > > > > It looks to me like "reject" is intended for list > negotiations (notice "all > of the offered options" ... I think that is referring to list > options): > > If a responder does not support or is not allowed to use all of the > offered options with a specific originator, it may use the constant > "Reject". > > Julian, correct me if I am wrong. > > Eddy > > -----Original Message----- > From: Martin, Nick [mailto:Nick.Martin@compaq.com] > Sent: Wednesday, February 06, 2002 2:18 PM > To: Lakshmi Ramasubramanian; ips@ece.cmu.edu > Subject: RE: iSCSI: Boolean value (yes, no) negotiation > > Lakshmi, > > It is my understanding, that if either initiator or target begins > negotiation for a boolean by sending a key=value pair, the responder > applies the specified boolean function (to the requested value and the > current value) to obtain the result. The result is then included in a > reply (unless the rules say it may be omitted). This negotiation is > concluded. > > I believe it should not be permitted for the responder, desiring a > different outcome, to later initiate negotiation for a different value > of the same parameter. If both initiator and target were permitted to > do this, it can cause an endless loop. However I do not find > where this > is documented. > > I have found an option for the target other than rejecting the login. > It can reject this parameter value with key=Reject. The initiator in > this case can then accept the value previously in effect, > negotiate for > another value, or close the connection. I believe sending key=Reject > does not require that the entire login should fail. The current value > for key should be unchanged by a negotiation ending in > key=Reject, just > as if it never happened. > > It is not always clear to me whether such negotiations are > intended only > to allow selection of preferred modes of operation, or to enable > implementations which do not support certain features to operate with > other implementations which do not require those features. > > For example, it is not stated whether a target or an > initiator SHOULD or > MUST implement/accept both ImmediateData=yes and ImmediateData=no. > > If these are for preferences, and the initiator and target are > configured for different preferences, what should be the > result? Either > result may allow operation. In fact neither may be optimal for both > parties at the same time. Is the result predictable? Should we > negotiate differently for preferences versus requirements? > For example > should an initiator only negotiate preferences after the > target has had > a chance to negotiate requirements? Should we expect that key=Reject > could be the response to almost any key negotiation? > > The suggestion by Rahul to use key=? is not permitted. key=? is only > permitted in text commands, during full feature phase. It returns the > current value, not the list of support values. Requesting the list of > supported values is not a current capability. > > Thanks, > Nick > > > -----Original Message----- > > From: Lakshmi Ramasubramanian [mailto:nramas@windows.microsoft.com] > > Sent: Wednesday, February 06, 2002 11:26 AM > > To: ips@ece.cmu.edu > > Subject: iSCSI: Boolean value (yes, no) negotiation > > > > > > Could someone please clarify Boolean key=value usage > > (such as "ImmediateData=yes", etc)? > > > > For example, the initiator sends to target "ImmediateData=no". > > But the target wants ImmediateData. So, it sends back > > "ImmediateData=yes". > > The initiator, being able to handle it, sends back > "ImmediateData=no". > > Now, they use immediate data in the PDUs. > > > > Is this valid? Or, in the above case if the target can't handle > > non-immediate data it has to reject the login ? > > > > thanks! > > -lakshmi > > > > > > > From owner-ips@ece.cmu.edu Mon Feb 11 01:23: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 BAA17876 for ; Mon, 11 Feb 2002 01:23:23 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1B5DXo13428 for ips-outgoing; Mon, 11 Feb 2002 00:13:33 -0500 (EST) 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 g1B5DWj13423 for ; Mon, 11 Feb 2002 00:13:32 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel11.hp.com (Postfix) with ESMTP id 07C12600467 for ; Sun, 10 Feb 2002 21:13:26 -0800 (PST) Received: from swathi (pal1nai160096.nsr.hp.com [15.244.160.96]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id VAA14392 for ; Sun, 10 Feb 2002 21:15:04 -0800 (PST) Message-ID: <003a01c1b2ba$d52fb7e0$60a0f40f@rose.hp.com> From: "Mallikarjun C." To: References: <31891B757C09184BBFEC5275F85D559501F22B5B@cceexc18.americas.cpqcorp.net> Subject: Re: iSCSI: draft-10 more editorial Date: Sun, 10 Feb 2002 21:13:24 -0800 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Nick, I assume Julian will answer the rest, but let me comment on one. > This may be more of an issue than editorial: > On page 89, section 7.7 Negotiation Failures, I believe another reason > needs to be listed. > - The text request was answered with Irrelevant. > Alternatively perhaps Irrelevant was added as a way to avoid sending a > reject. If a negotiation ending in Irrelevant is to be considered a > successful negotiation, this needs to be clearly stated. The reference to Reject in section 7.7 is describing when the entire text *request* is being rejected via a Reject PDU. Since it is somewhat drastic for the negotiation in progress, it is categorized under "negotiation failures". Rejecting one text *key* with "Reject" key value is not as severe, and I think it's best not to kill the entire negotiation. I suggest that we change the constant key value "Reject" in section 2.2.4 to "Declined" to make this distinction explicit. Comments? -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ----- Original Message ----- From: "Martin, Nick" To: "Julian Satran" Cc: Sent: Friday, February 08, 2002 7:15 PM Subject: iSCSI: draft-10 more editorial > Julian, > > The following are some more comments about the iSCSI draft 10 document. > These are primarily editorial comments. > > Thanks, > Nick > > As previously noted, the section numbers and page numbers are different > between the text and pdf versions of the document. All my comments are > based on the pdf version. > > Page 26 "Initiator that identifying elements, such as..." The word > "that" does not fit. One of the words "unique", "defined", "specific" > or "assigned" may have been intended, or perhaps it can just be removed. > > On page 33, The capitalization of the quoted keyword "None" is confusing > "(literal constants which may include "None")". I have previously > believed that keywords were case sensitive and that "none" (not "None") > was the correct string. I note however that nearly all other keywords > have been capitalized ("Reject", "NotUnderstood", etc.). For > consistency with other keywords perhaps we should use "None". (As > someone else noted, "yes" and "no" are also not currently capitalized.) > > On page 35, I presume the text "(up to the mode page limit)" is obsolete > since iSCSI mode pages have been removed. > > On page 36 "It is also an error ..., than the SCSI limit for first > burst." Should "SCSI" not be "iSCSI"? > > In the next sentence, which mentions "MAY request to send data blocks > and a first burst of any size;..." This looks like it might have been a > reference to 0 meaning any value which is now removed. > > On page 44, the sentence "During login, each end of the iSCSI session > specifies the maximum iSCSI PDU size it will accept." This sounds like > the PDU size could be negotiated differently in each direction. This is > not how I think it works. > > On page 87, one paragraph starts with "LS:When". I presume the LS: > should be removed. > > This may be more of an issue than editorial: > On page 89, section 7.7 Negotiation Failures, I believe another reason > needs to be listed. > - The text request was answered with Irrelevant. > Alternatively perhaps Irrelevant was added as a way to avoid sending a > reject. If a negotiation ending in Irrelevant is to be considered a > successful negotiation, this needs to be clearly stated. > > On page 115, in "than no more data PDUs are expected", "than" should be > "then". > > On page 124, in the section Referenced Task Tag, ABORT TASK is referred > to as TASK ABORT. > > On page 134, in the section R2TSN, the maximum number of R2Ts is given > in hexadecimal 0xffffffff. In most other cases (like DataSN on page > 131) the limits are expressed in decimal 2**32 or 2**32-1. The form > 0xffffffff is generally used when specifying a reserved value. > > On page 141, for the list of characters valid in a text value, I would > suggest also allowing the character '@' as would be used in e-mail > addresses. > > On page 141, it is explained that binary items may be expressed in > decimal, hex, or Base64. Are the protocol defined binary values, such > as MaxRecvPDULength required to be accepted in all these formats? > > Request for clarification/restriction of text key=value continuations: > Are there any special rules for text key=value pairs spanning PDUs? Is > a pair of length less than MaxRecvPDULength permitted to span PDUs? Is > the sender required to fill MaxRecvPDULength before continuing to the > next PDU? Can a key=value pair which will require continuation begin > somewhere in the middle of a PDU text buffer due to other key=value > pairs already in the buffer? If so, can a key=value pair be continued > before the "=" ? Is the text buffer to be continued required to fill a > multiple of 4 bytes in the current text buffer (no padding required)? > I would personally prefer to see key=value continuation restricted to > cases where the key=value string exceeds MaxRecvPDULength. In other > cases when the next key=value will not fit in the remaining space in the > current PDU, one could put the entire key=value in the next text PDU. > This would eliminate the possibility that one could be expected to > correctly parse small strings such as ImmediateData=yes or > MaxBurstSize=16384 with PDU breaks within them > (MaxBurstSize=16384). > > On page 149, in the section Login Parameters, the text appears > contradictory. "All keys in Chapter 12, except for the X- extension > format, MUST be supported by iSCSI initiators and targets. Keys in > Chapter 12, only need to be supported when the function to which they > refer is mandatory to implement." > > On page 173, there is no section header (and number) for the beginning > of CHAP protocol. > > On page 179, an example for TargetAlias uses an apostrophe (') although > this is not among the permitted characters (on page 141). > > On page 181, InitialR2T has no section number. > > On page 184, LogoutLoginMaxTime has no section number. > > > From owner-ips@ece.cmu.edu Mon Feb 11 11:22: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 LAA08054 for ; Mon, 11 Feb 2002 11:22:56 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1BFHHW28514 for ips-outgoing; Mon, 11 Feb 2002 10:17:17 -0500 (EST) 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 g1BFHDj28510 for ; Mon, 11 Feb 2002 10:17:14 -0500 (EST) 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 g1BFH5i16575; Mon, 11 Feb 2002 10:17:05 -0500 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with SMTP id g1BFH4110969; Mon, 11 Feb 2002 10:17:04 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15463.57456.566316.665312@pkoning.dev.equallogic.com> Date: Mon, 11 Feb 2002 10:17:04 -0500 (EST) From: Paul Koning To: Nick.Martin@compaq.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Boolean value (yes, no) negotiation References: <31891B757C09184BBFEC5275F85D5595104E2D@cceexc18.americas.cpqcorp.net> X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Martin," == Martin, Nick writes: Martin,> From this in infer that support for both ImmediateData=yes and Martin,> ImmediateData=no is required. One is not supposed to build Martin,> a target nor an initiator which does not support both Martin,> possible values for each boolean. For either possible Martin,> result of the negotiation, both parties should be able to Martin,> proceed. I don't agree, and it doesn't follow from the analysis. If the rule is AND, then either end can force the outcome "no" by proposing "no" (as initiator) or replying with "no" (as target). If the rule is OR, then either end can force outcome "yes" by similar reasoning. So the negotiation rules imply that you must support the outcome that the other end can force. The rules imply nothing about the other outcome (e.g., "yes" for ImmediateData). That could be optional to support as far as the mechanism goes. The spec can make it mandatory if it is agreed to do so, but the mechanism doesn't affect such a decision. paul From owner-ips@ece.cmu.edu Mon Feb 11 11:26: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 LAA08153 for ; Mon, 11 Feb 2002 11:26:22 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1BFe6X00370 for ips-outgoing; Mon, 11 Feb 2002 10:40:06 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1BFe4j00362 for ; Mon, 11 Feb 2002 10:40:04 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Feb 2002 10:32:01 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937432@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSCSI: SRP status Date: Mon, 11 Feb 2002 10:37:00 -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 I received an off-list inquiry on this, and thought I'd answer it on list due to general interest. First, the usual disclaimer: I am NOT a lawyer This is NOT legal advice If you need legal advice ... - You need to talk to a lawyer If actions or decisions based on information in this message have legal consequences - Those consequences are YOUR responsibility - The IETF and yours truly disclaim all responsibility SRP is currently mandatory to implement, with further discussion of whether it is to remain mandatory anticipated in Minneapolis. AFAIK, the only functionally equivalent alternatives also have IPR issues. Those alternatives are EKE and SPEKE, which would require licensing the Lucent or Phoenix patents respectively. For SRP, Stanford requires a no-cost license and I've been told that Stanford believes that no other patent license is necessary. Whether you believe Stanford is between you and your lawyers. I've been working on getting Lucent and Phoenix to say whether they think SRP requires licensing their patents. Lucent previously promised to make such a statement about their EKE patents and has now broken that promise. 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 Feb 11 12:52: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 MAA12540 for ; Mon, 11 Feb 2002 12:52:38 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1BGqNV06387 for ips-outgoing; Mon, 11 Feb 2002 11:52:23 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1BGqKj06377 for ; Mon, 11 Feb 2002 11:52:20 -0500 (EST) Received: from cceexg13.americas.cpqcorp.net (cceexg13.americas.cpqcorp.net [16.110.250.119]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id ECFC4417F; Mon, 11 Feb 2002 10:52:14 -0600 (CST) Received: from cceexc18.americas.cpqcorp.net ([16.110.250.64]) by cceexg13.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 11 Feb 2002 10:52:07 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: iSCSI: Boolean value (yes, no) negotiation X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 11 Feb 2002 10:52:06 -0600 Message-ID: <31891B757C09184BBFEC5275F85D559501F22B5C@cceexc18.americas.cpqcorp.net> Thread-Topic: iSCSI: Boolean value (yes, no) negotiation Thread-Index: AcGzDzM/PNrHWWZiTwSONGyUTVCR4wADEZAQ From: "Martin, Nick" To: "Paul Koning" Cc: X-OriginalArrivalTime: 11 Feb 2002 16:52:07.0841 (UTC) FILETIME=[70F16910:01C1B31C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g1BGqKj06378 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Paul, I agree. You are correct, I was not. Only the irresistible boolean negotiation values are required to be supported. This would be "no" where the rule is "AND", and "yes" where the rule is "OR". Thanks, Nick > -----Original Message----- > From: Paul Koning [mailto:ni1d@arrl.net] > Sent: Monday, February 11, 2002 9:17 AM > To: Martin, Nick > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI: Boolean value (yes, no) negotiation > > > >>>>> "Martin," == Martin, Nick writes: > > Martin,> From this in infer that support for both > ImmediateData=yes and > Martin,> ImmediateData=no is required. One is not supposed to build > Martin,> a target nor an initiator which does not support both > Martin,> possible values for each boolean. For either possible > Martin,> result of the negotiation, both parties should be able to > Martin,> proceed. > > I don't agree, and it doesn't follow from the analysis. > > If the rule is AND, then either end can force the outcome "no" by > proposing "no" (as initiator) or replying with "no" (as target). > > If the rule is OR, then either end can force outcome "yes" by similar > reasoning. > > So the negotiation rules imply that you must support the outcome that > the other end can force. The rules imply nothing about the other > outcome (e.g., "yes" for ImmediateData). That could be optional to > support as far as the mechanism goes. The spec can make it mandatory > if it is agreed to do so, but the mechanism doesn't affect such a > decision. > > paul > > From owner-ips@ece.cmu.edu Mon Feb 11 13:38: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 NAA13615 for ; Mon, 11 Feb 2002 13:38:24 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1BHTeA09725 for ips-outgoing; Mon, 11 Feb 2002 12:29:40 -0500 (EST) 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 g1BHTbj09719 for ; Mon, 11 Feb 2002 12:29:37 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id SAA40768 for ; Mon, 11 Feb 2002 18:29:26 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1BHUvG21568 for ; Mon, 11 Feb 2002 18:30:57 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: Boolean value (yes, no) negotiation X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Mon, 11 Feb 2002 19:30:57 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 11/02/2002 19:31:01, Serialize complete at 11/02/2002 19:31:01 Content-Type: multipart/alternative; boundary="=_alternative 005FED25C2256B5D_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005FED25C2256B5D_= Content-Type: text/plain; charset="us-ascii" Eddy, You are correct. Support for both, in this case, is a SCSI issue. We can't mandate support for immediate data. Julo Eddy Quicksall 10-02-02 19:13 To: "Martin, Nick" , Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, Lakshmi Ramasubramanian Subject: RE: iSCSI: Boolean value (yes, no) negotiation Regarding "support for both outcomes is required". I don't agree. Targets can have all sorts of reasons not to support both. It may be useful to have a value like "Reject" apply for cases like this. Then, the initiator or target would the option to disconnect or try to keep going depending on the key. Eddy -----Original Message----- From: Martin, Nick [mailto:Nick.Martin@COMPAQ.com] Sent: Friday, February 08, 2002 4:30 PM To: Julian Satran; Eddy Quicksall Cc: ips@ece.cmu.edu; Lakshmi Ramasubramanian Subject: RE: iSCSI: Boolean value (yes, no) negotiation Julian, Eddy, and Lakshmi, OK, since I had it wrong last time. Let me try to explain it again. The default for ImmediateData is yes. The result function is AND. I->T ImmediateData=no Presuming the target wanted "yes", the result ("yes" AND "no") is "no". The target has one option T->I ImmediateData=no If this response is omitted, the result is the same. Login proceeds presuming ImmediateData=no. I have been corrected that ImmediateData=Reject is not valid. A response of ImmediateData=yes is also not valid. I do not see a login response code meaning option not supported by target. From this in infer that support for both ImmediateData=yes and ImmediateData=no is required. One is not supposed to build a target nor an initiator which does not support both possible values for each boolean. For either possible result of the negotiation, both parties should be able to proceed. Is this correct? If so, I think it is worth stating that support for both outcomes is required. Thanks, Nick > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Wednesday, February 06, 2002 10:41 PM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu; julian_satran@il. ibm. com (E-mail); > Martin, Nick; > Lakshmi Ramasubramanian > Subject: RE: iSCSI: Boolean value (yes, no) negotiation > > > Eddy is right - reject is not intended/valid for booleans. > > Julo > > > > > Eddy Quicksall > > Nick" , > ivity.com> Lakshmi > Ramasubramanian > > , ips@ece.cmu.edu > 06-02-02 23:55 cc: Julian > Satran/Haifa/IBM@IBMIL > Subject: RE: > iSCSI: Boolean value (yes, no) > negotiation > > > > > > > > > > > It looks to me like "reject" is intended for list > negotiations (notice "all > of the offered options" ... I think that is referring to list > options): > > If a responder does not support or is not allowed to use all of the > offered options with a specific originator, it may use the constant > "Reject". > > Julian, correct me if I am wrong. > > Eddy > > -----Original Message----- > From: Martin, Nick [mailto:Nick.Martin@compaq.com] > Sent: Wednesday, February 06, 2002 2:18 PM > To: Lakshmi Ramasubramanian; ips@ece.cmu.edu > Subject: RE: iSCSI: Boolean value (yes, no) negotiation > > Lakshmi, > > It is my understanding, that if either initiator or target begins > negotiation for a boolean by sending a key=value pair, the responder > applies the specified boolean function (to the requested value and the > current value) to obtain the result. The result is then included in a > reply (unless the rules say it may be omitted). This negotiation is > concluded. > > I believe it should not be permitted for the responder, desiring a > different outcome, to later initiate negotiation for a different value > of the same parameter. If both initiator and target were permitted to > do this, it can cause an endless loop. However I do not find > where this > is documented. > > I have found an option for the target other than rejecting the login. > It can reject this parameter value with key=Reject. The initiator in > this case can then accept the value previously in effect, > negotiate for > another value, or close the connection. I believe sending key=Reject > does not require that the entire login should fail. The current value > for key should be unchanged by a negotiation ending in > key=Reject, just > as if it never happened. > > It is not always clear to me whether such negotiations are > intended only > to allow selection of preferred modes of operation, or to enable > implementations which do not support certain features to operate with > other implementations which do not require those features. > > For example, it is not stated whether a target or an > initiator SHOULD or > MUST implement/accept both ImmediateData=yes and ImmediateData=no. > > If these are for preferences, and the initiator and target are > configured for different preferences, what should be the > result? Either > result may allow operation. In fact neither may be optimal for both > parties at the same time. Is the result predictable? Should we > negotiate differently for preferences versus requirements? > For example > should an initiator only negotiate preferences after the > target has had > a chance to negotiate requirements? Should we expect that key=Reject > could be the response to almost any key negotiation? > > The suggestion by Rahul to use key=? is not permitted. key=? is only > permitted in text commands, during full feature phase. It returns the > current value, not the list of support values. Requesting the list of > supported values is not a current capability. > > Thanks, > Nick > > > -----Original Message----- > > From: Lakshmi Ramasubramanian [mailto:nramas@windows.microsoft.com] > > Sent: Wednesday, February 06, 2002 11:26 AM > > To: ips@ece.cmu.edu > > Subject: iSCSI: Boolean value (yes, no) negotiation > > > > > > Could someone please clarify Boolean key=value usage > > (such as "ImmediateData=yes", etc)? > > > > For example, the initiator sends to target "ImmediateData=no". > > But the target wants ImmediateData. So, it sends back > > "ImmediateData=yes". > > The initiator, being able to handle it, sends back > "ImmediateData=no". > > Now, they use immediate data in the PDUs. > > > > Is this valid? Or, in the above case if the target can't handle > > non-immediate data it has to reject the login ? > > > > thanks! > > -lakshmi > > > > > > > --=_alternative 005FED25C2256B5D_= Content-Type: text/html; charset="us-ascii"

Eddy,

You are correct. Support for both, in this case, is a SCSI issue. We can't mandate support for immediate data.

Julo


Eddy Quicksall <Eddy_Quicksall@ivivity.com>

10-02-02 19:13

       
        To:        "Martin, Nick" <Nick.Martin@COMPAQ.com>, Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu, Lakshmi Ramasubramanian <nramas@windows.microsoft.com>
        Subject:        RE: iSCSI: Boolean value (yes, no) negotiation

       


Regarding "support for both outcomes is required". I don't agree. Targets
can have all sorts of reasons not to support both.

It may be useful to have a value like "Reject" apply for cases like this.
Then, the initiator or target would the option to disconnect or try to keep
going depending on the key.


Eddy

-----Original Message-----
From: Martin, Nick [mailto:Nick.Martin@COMPAQ.com]
Sent: Friday, February 08, 2002 4:30 PM
To: Julian Satran; Eddy Quicksall
Cc: ips@ece.cmu.edu; Lakshmi Ramasubramanian
Subject: RE: iSCSI: Boolean value (yes, no) negotiation

Julian, Eddy, and Lakshmi,

OK, since I had it wrong last time.  Let me try to explain it again.

The default for ImmediateData is yes.  The result function is AND.

I->T ImmediateData=no

Presuming the target wanted "yes", the result ("yes" AND "no") is "no".

The target has one option

T->I ImmediateData=no          

If this response is omitted, the result is the same.  Login proceeds
presuming ImmediateData=no.

I have been corrected that ImmediateData=Reject is not valid.
A response of ImmediateData=yes is also not valid.
I do not see a login response code meaning option not supported by
target.

From this in infer that support for both ImmediateData=yes and
ImmediateData=no is required.  One is not supposed to build a target nor
an initiator which does not support both possible values for each
boolean.  For either possible result of the negotiation, both parties
should be able to proceed.

Is this correct?  If so, I think it is worth stating that support for
both outcomes is required.

Thanks,
Nick

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Wednesday, February 06, 2002 10:41 PM
> To: Eddy Quicksall
> Cc: ips@ece.cmu.edu; julian_satran@il. ibm. com (E-mail);
> Martin, Nick;
> Lakshmi Ramasubramanian
> Subject: RE: iSCSI: Boolean value (yes, no) negotiation
>
>
> Eddy is right - reject is not intended/valid for booleans.
>
> Julo
>
>
>                                                              
>                                  
>                     Eddy Quicksall                          
>                                  
>                     <Eddy_Quicksall@iv       To:     "Martin,
> Nick" <Nick.Martin@compaq.com>,  
>                     ivity.com>                Lakshmi
> Ramasubramanian                          
>                                              
> <nramas@windows.microsoft.com>, ips@ece.cmu.edu  
>                     06-02-02 23:55           cc:     Julian
> Satran/Haifa/IBM@IBMIL              
>                                              Subject:     RE:
> iSCSI: Boolean value (yes, no)    
>                                               negotiation    
>                                  
>                                                              
>                                  
>                                                              
>                                  
>                                                              
>                                  
>
>
>
> It looks to me like "reject" is intended for list
> negotiations (notice "all
> of the offered options" ... I think that is referring to list
> options):
>
> If a responder does not support or is not allowed to use all of the
> offered options with a specific originator, it may use the constant
> "Reject".
>
> Julian, correct me if I am wrong.
>
> Eddy
>
> -----Original Message-----
> From: Martin, Nick [mailto:Nick.Martin@compaq.com]
> Sent: Wednesday, February 06, 2002 2:18 PM
> To: Lakshmi Ramasubramanian; ips@ece.cmu.edu
> Subject: RE: iSCSI: Boolean value (yes, no) negotiation
>
> Lakshmi,
>
> It is my understanding, that if either initiator or target begins
> negotiation for a boolean by sending a key=value pair, the responder
> applies the specified boolean function (to the requested value and the
> current value) to obtain the result.  The result is then included in a
> reply (unless the rules say it may be omitted).  This negotiation is
> concluded.
>
> I believe it should not be permitted for the responder, desiring a
> different outcome, to later initiate negotiation for a different value
> of the same parameter.  If both initiator and target were permitted to
> do this, it can cause an endless loop.  However I do not find
> where this
> is documented.
>
> I have found an option for the target other than rejecting the login.
> It can reject this parameter value with key=Reject.  The initiator in
> this case can then accept the value previously in effect,
> negotiate for
> another value, or close the connection.  I believe sending key=Reject
> does not require that the entire login should fail.  The current value
> for key should be unchanged by a negotiation ending in
> key=Reject, just
> as if it never happened.
>
> It is not always clear to me whether such negotiations are
> intended only
> to allow selection of preferred modes of operation, or to enable
> implementations which do not support certain features to operate with
> other implementations which do not require those features.
>
> For example, it is not stated whether a target or an
> initiator SHOULD or
> MUST implement/accept both ImmediateData=yes and ImmediateData=no.
>
> If these are for preferences, and the initiator and target are
> configured for different preferences, what should be the
> result?  Either
> result may allow operation.  In fact neither may be optimal for both
> parties at the same time.  Is the result predictable?  Should we
> negotiate differently for preferences versus requirements?
> For example
> should an initiator only negotiate preferences after the
> target has had
> a chance to negotiate requirements?  Should we expect that key=Reject
> could be the response to almost any key negotiation?
>
> The suggestion by Rahul to use key=? is not permitted.  key=? is only
> permitted in text commands, during full feature phase.  It returns the
> current value, not the list of support values.  Requesting the list of
> supported values is not a current capability.
>
> Thanks,
> Nick
>
> > -----Original Message-----
> > From: Lakshmi Ramasubramanian [mailto:nramas@windows.microsoft.com]
> > Sent: Wednesday, February 06, 2002 11:26 AM
> > To: ips@ece.cmu.edu
> > Subject: iSCSI: Boolean value (yes, no) negotiation
> >
> >
> > Could someone please clarify Boolean key=value usage
> > (such as "ImmediateData=yes", etc)?
> >
> > For example, the initiator sends to target "ImmediateData=no".
> > But the target wants ImmediateData. So, it sends back
> > "ImmediateData=yes".
> > The initiator, being able to handle it, sends back
> "ImmediateData=no".
> > Now, they use immediate data in the PDUs.
> >
> > Is this valid? Or, in the above case if the target can't handle
> > non-immediate data it has to reject the login ?
> >
> > thanks!
> >  -lakshmi
> >
>
>
>
>
>



--=_alternative 005FED25C2256B5D_=-- From owner-ips@ece.cmu.edu Mon Feb 11 14:15: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 OAA14432 for ; Mon, 11 Feb 2002 14:15:09 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1BIBah13991 for ips-outgoing; Mon, 11 Feb 2002 13:11:36 -0500 (EST) 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 g1BIBWj13978; Mon, 11 Feb 2002 13:11:32 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id TAA120010; Mon, 11 Feb 2002 19:11:26 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1BID0E29406; Mon, 11 Feb 2002 19:13:01 +0100 To: Paul Koning Cc: ips@ece.cmu.edu, Nick.Martin@compaq.com, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: Boolean value (yes, no) negotiation X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Mon, 11 Feb 2002 20:12:57 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 11/02/2002 20:13:00, Serialize complete at 11/02/2002 20:13:00 Content-Type: multipart/alternative; boundary="=_alternative 00626DBAC2256B5D_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00626DBAC2256B5D_= Content-Type: text/plain; charset="us-ascii" Paul is correct. The AND rule was chosen in order to avoid having one party force ImmediateData when the other party does not want it. Julo Paul Koning Sent by: owner-ips@ece.cmu.edu 11-02-02 17:17 To: Nick.Martin@compaq.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: Boolean value (yes, no) negotiation >>>>> "Martin," == Martin, Nick writes: Martin,> From this in infer that support for both ImmediateData=yes and Martin,> ImmediateData=no is required. One is not supposed to build Martin,> a target nor an initiator which does not support both Martin,> possible values for each boolean. For either possible Martin,> result of the negotiation, both parties should be able to Martin,> proceed. I don't agree, and it doesn't follow from the analysis. If the rule is AND, then either end can force the outcome "no" by proposing "no" (as initiator) or replying with "no" (as target). If the rule is OR, then either end can force outcome "yes" by similar reasoning. So the negotiation rules imply that you must support the outcome that the other end can force. The rules imply nothing about the other outcome (e.g., "yes" for ImmediateData). That could be optional to support as far as the mechanism goes. The spec can make it mandatory if it is agreed to do so, but the mechanism doesn't affect such a decision. paul --=_alternative 00626DBAC2256B5D_= Content-Type: text/html; charset="us-ascii"
Paul is correct. The AND rule was chosen in order to avoid having one party force ImmediateData when the other party does not want it.

Julo


Paul Koning <ni1d@arrl.net>
Sent by: owner-ips@ece.cmu.edu

11-02-02 17:17

       
        To:        Nick.Martin@compaq.com
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: Boolean value (yes, no) negotiation

       


>>>>> "Martin," == Martin, Nick <Nick.Martin@compaq.com> writes:

Martin,> From this in infer that support for both ImmediateData=yes and
Martin,> ImmediateData=no is required.  One is not supposed to build
Martin,> a target nor an initiator which does not support both
Martin,> possible values for each boolean.  For either possible
Martin,> result of the negotiation, both parties should be able to
Martin,> proceed.

I don't agree, and it doesn't follow from the analysis.

If the rule is AND, then either end can force the outcome "no" by
proposing "no" (as initiator) or replying with "no" (as target).

If the rule is OR, then either end can force outcome "yes" by similar
reasoning.

So the negotiation rules imply that you must support the outcome that
the other end can force.  The rules imply nothing about the other
outcome (e.g., "yes" for ImmediateData).  That could be optional to
support as far as the mechanism goes.  The spec can make it mandatory
if it is agreed to do so, but the mechanism doesn't affect such a
decision.

   paul

--=_alternative 00626DBAC2256B5D_=-- From owner-ips@ece.cmu.edu Mon Feb 11 16:35: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 QAA17946 for ; Mon, 11 Feb 2002 16:35:39 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1BKW6o27727 for ips-outgoing; Mon, 11 Feb 2002 15:32:06 -0500 (EST) 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 g1BKW3j27720 for ; Mon, 11 Feb 2002 15:32:03 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id VAA157524; Mon, 11 Feb 2002 21:31:52 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1BKXSE34470; Mon, 11 Feb 2002 21:33:28 +0100 Importance: Normal Subject: RE: IPsec Usage Question To: Paul Koning Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Ofer Biran" Date: Mon, 11 Feb 2002 22:32:06 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 11/02/2002 22:33:27 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Paul, "2-site tunnel scenario" is not exactly "2-tunnel scenario". It all started with my response to your original scenario: "Scenario: two sites, each with an IPsec gateway, and an IPsec tunnel set up between the two sites. All traffic between the two sites goes through the tunnel. (This is the classic IPsec based VPN scenario.)" But then you resent anyway more suitable scenarios, so I don't think we have any real disagreement. Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 Paul Koning on 11/02/2002 16:34:05 To: Ofer Biran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: IPsec Usage Question >>>>> "Ofer" == Ofer Biran writes: Ofer> Paul, Ofer> I only meant that the 2-site tunnel scenario has nothing to do Ofer> with the IPsec protection mandated to be implemented (yes, Ofer> implemented, not used) by iSCSI. So I would not use this Ofer> scenario at all to conclude about iSCSI security requirements Ofer> (outer=inner etc.). What 2-tunnel scenario? My scenario is a one-tunnel scenario, where one end of the tunnel terminates an an iSCSI device and the other terminates at an IPsec gateway. That's a perfectly standard tunnel configuration. In fact, it's the most obvious example of why tunnel mode support (in addition to transport mode) is required for IPsec hosts. In that scenario, you can have inner==outer for one of the endpoint addresses (the host) but not for the other. Unless it is your goal to disallow IPsec gateways talking to iSCSI devices, you have to support this configuration if you're going to support IPsec at all. paul From owner-ips@ece.cmu.edu Mon Feb 11 22:48: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 WAA24828 for ; Mon, 11 Feb 2002 22:48:51 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1C2xF622514 for ips-outgoing; Mon, 11 Feb 2002 21:59:15 -0500 (EST) 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 g1C0nRj15737 for ; Mon, 11 Feb 2002 19:49:27 -0500 (EST) Received: from io.iol.unh.edu (IDENT:rdr@localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.2/8.12.2) with ESMTP id g1C0nLUj003644; Mon, 11 Feb 2002 19:49:21 -0500 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.2/8.12.1/Submit) with ESMTP id g1C0nLGK003641; Mon, 11 Feb 2002 19:49:21 -0500 Date: Mon, 11 Feb 2002 19:49:21 -0500 (EST) From: "Robert D. Russell" To: Julian Satran cc: ips@ece.cmu.edu Subject: UNH Plugfest 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: Attached are some of the issues that arose during the first day of the iSCSI plugfest at UNH on Monday 11-February-2001. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 -------------------------------------------------------------------------- 1a)The following operational keys are labeled with "Use: ALL" and have session-wide applicability: InitialR2T BidiInitialR2T ImmediateData This means that they can be negotiated during the login phase for any connection in a session, as well as during full feature phase on any connection in a session, but at the successful conclusion of that negotiation, the results apply immediately to all connections in the session. The question is: "What is the rationale for making these 3 keys session-wide instead of connection-specific?" Phrased another way, the question is: "Would it not be better if these keys were connection-specific instead of session-wide?" In particular, it appears that dynamic changes to these values on one connection can have an effect on outstanding commands on other connections that requires considerable complication in implementations to handle correctly, yet the benefit is not obvious from the standard. Could someone please supply a rationale for keeping these keys session-wide? 1b)A related issue is that the values negotiated for InitialR2T and ImmediateData are intimately intertwined, as evidenced by the table accompanying the description of ImmediateData in Appendix D. However, InitialR2T has a specific restriction (in the description of InitialR2T in Appendix D): "Once InitialR2T has been set to 'no', it cannot be set back to 'yes'. BidiInitalR2T has the same restriction. But ImmediateData does not have this restriction. The question is: "Why doesn't ImmediateData have a similar restriction?" In particular, this restriction on (Bidi)InitialR2T limits the possibilities for (re)negotiation at any time on any connection mentioned in 1a above, because once unsolicited data PDUs have been negotiated off, they can never be negotiated on again, effectively eliminating InitialR2T from all further negotiations. Could someone please supply a rationale for allowing ImmediateData to be negotiated on/off at any time on any connection but not InitialR2T? 2. Section 3.11.3 discusses the use of the Target Transfer Tag in the Text Response pdu. It says that when the target has more work to do, it MUST set the Target Transfer Tag to some value other than 0xffffffff. When the target does not have more work to do, the standard does not say what value the Target Transfer Tag should have. There are 2 possibilities: a. If the target must set the Target Transfer Tag to 0xffffffff, then the standard should state this explicitly. b. If the target can set the Target Transfer Tag to any value (or leave it undefined) then it appears that there is no need to reserve 0xffffffff for the Target Transfer Tag at all, and there is no need to require a value other than 0xffffffff when F = 0 (any value will work fine). 3. Section 3.8.3 limits the value of the Desired Data Transfer Length in an R2T to at most MaxBurstSize. What is the rationale for this? An R2T is sent by the target to the initiator, so why can't the target specify any size it wants in the R2T? The target already uses R2Ts to control the flow of Data-Out PDUs from the initiator, so why impose this restriction on the R2Ts? Could someone please explain the benefit to this limitation on R2Ts? 4. Section 3.7.1 says that the Data-In pdus sent by the target to satisfy a SCSI read command can be split into sequences each terminated by a pdu having F=1. The standard does not seem to require that this be done. However, if it is done, then the description of MaxBurstSize in Appendix D limits these sequences to at most MaxBurstSize bytes. 4a.The first question is: "What is the benefit for allowing the Data-In pdus to be split into sequences?" It appears that doing so forces a dual role on the F-bit -- as end of sequence and as end of all input -- and complicates the interpretation of this bit in the initiator. This feature seems to be necessary to change direction in bidirectional transfers, but are there other uses for this? 4b.The second question is: "Is the target required to split Data-In pdus into sequences?" If so, this should be made explicit in the standard, and the rationale for this should also be given. From owner-ips@ece.cmu.edu Tue Feb 12 04:36: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 EAA06819 for ; Tue, 12 Feb 2002 04:36:45 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1C8VtE08738 for ips-outgoing; Tue, 12 Feb 2002 03:31:55 -0500 (EST) 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 g1C8Vrj08734 for ; Tue, 12 Feb 2002 03:31:53 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id JAA31168; Tue, 12 Feb 2002 09:31:46 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1C8XGA06976; Tue, 12 Feb 2002 09:33:16 +0100 To: "Robert D. Russell" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: UNH Plugfest X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 12 Feb 2002 10:33:18 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 12/02/2002 10:33:20, Serialize complete at 12/02/2002 10:33:20 Content-Type: multipart/alternative; boundary="=_alternative 002ED4C5C2256B5E_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 002ED4C5C2256B5E_= Content-Type: text/plain; charset="us-ascii" Bob, Comments in text - Thanks, Julo "Robert D. Russell" 12-02-02 02:49 To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: UNH Plugfest Julian: Attached are some of the issues that arose during the first day of the iSCSI plugfest at UNH on Monday 11-February-2001. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 -------------------------------------------------------------------------- 1a)The following operational keys are labeled with "Use: ALL" and have session-wide applicability: InitialR2T BidiInitialR2T ImmediateData This means that they can be negotiated during the login phase for any connection in a session, as well as during full feature phase on any connection in a session, but at the successful conclusion of that negotiation, the results apply immediately to all connections in the session. The question is: "What is the rationale for making these 3 keys session-wide instead of connection-specific?" Phrased another way, the question is: "Would it not be better if these keys were connection-specific instead of session-wide?" In particular, it appears that dynamic changes to these values on one connection can have an effect on outstanding commands on other connections that requires considerable complication in implementations to handle correctly, yet the benefit is not obvious from the standard. Could someone please supply a rationale for keeping these keys session-wide? +++ Those key convey propoerties that are specific to the SCSI target (not iSCSI transport). Using R2T means not allocating SCSI buffers for unsolicited commands (that you have no idea on what connection they will be comming). +++ 1b)A related issue is that the values negotiated for InitialR2T and ImmediateData are intimately intertwined, as evidenced by the table accompanying the description of ImmediateData in Appendix D. However, InitialR2T has a specific restriction (in the description of InitialR2T in Appendix D): "Once InitialR2T has been set to 'no', it cannot be set back to 'yes'. BidiInitalR2T has the same restriction. But ImmediateData does not have this restriction. The question is: "Why doesn't ImmediateData have a similar restriction?" In particular, this restriction on (Bidi)InitialR2T limits the possibilities for (re)negotiation at any time on any connection mentioned in 1a above, because once unsolicited data PDUs have been negotiated off, they can never be negotiated on again, effectively eliminating InitialR2T from all further negotiations. Could someone please supply a rationale for allowing ImmediateData to be negotiated on/off at any time on any connection but not InitialR2T? +++ We saw no reason to force the targets to handle the "uncertainty" related to the transition from No to Yes of R2T (i.e., when can the target remove resources related to the unsolicited data). We saw a need for a yet-to-no transition (speed increase) but none for a no-to-yes. Immediate data on the other hand has a very restricted and well-defined resource need - a single PDU asociated with the command and there is no uncertainty in the transition (or very limited). +++ 2. Section 3.11.3 discusses the use of the Target Transfer Tag in the Text Response pdu. It says that when the target has more work to do, it MUST set the Target Transfer Tag to some value other than 0xffffffff. When the target does not have more work to do, the standard does not say what value the Target Transfer Tag should have. There are 2 possibilities: a. If the target must set the Target Transfer Tag to 0xffffffff, then the standard should state this explicitly. b. If the target can set the Target Transfer Tag to any value (or leave it undefined) then it appears that there is no need to reserve 0xffffffff for the Target Transfer Tag at all, and there is no need to require a value other than 0xffffffff when F = 0 (any value will work fine). +++ The value 0xfffffff should be used exclusively to covey a "soft reset" i.e., while the target has more work to do the initiator wnats to start fresh I will try to make clear in the text that if there is no more work to do it MUST be set to 0xffffffff +++ 3. Section 3.8.3 limits the value of the Desired Data Transfer Length in an R2T to at most MaxBurstSize. What is the rationale for this? An R2T is sent by the target to the initiator, so why can't the target specify any size it wants in the R2T? The target already uses R2Ts to control the flow of Data-Out PDUs from the initiator, so why impose this restriction on the R2Ts? Could someone please explain the benefit to this limitation on R2Ts? +++ Is this a plugfest question or one of your own? For your own questions the channels are always open. The MaxBurstSize is there to enable the initiator to share resources between several executing commands and limit the number of "pending buffers" a target will have to keep in case one of the Data Out PDUS is damaged and transfer to a device is not possible. +++ 4. Section 3.7.1 says that the Data-In pdus sent by the target to satisfy a SCSI read command can be split into sequences each terminated by a pdu having F=1. The standard does not seem to require that this be done. However, if it is done, then the description of MaxBurstSize in Appendix D limits these sequences to at most MaxBurstSize bytes. 4a.The first question is: "What is the benefit for allowing the Data-In pdus to be split into sequences?" It appears that doing so forces a dual role on the F-bit -- as end of sequence and as end of all input -- and complicates the interpretation of this bit in the initiator. This feature seems to be necessary to change direction in bidirectional transfers, but are there other uses for this? +++ End of all input is the satus or Response - no ambiguity +++ 4b.The second question is: "Is the target required to split Data-In pdus into sequences?" If so, this should be made explicit in the standard, and the rationale for this should also be given. +++ It is required and the rational is in 2.4.1.5 (version 10). The rational is direction change and Ack if required +++ --=_alternative 002ED4C5C2256B5E_= Content-Type: text/html; charset="us-ascii"
Bob,

Comments in text -

Thanks,
Julo




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

12-02-02 02:49

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        UNH Plugfest

       


Julian:

Attached are some of the issues that arose during the first day
of the iSCSI plugfest at UNH on Monday 11-February-2001.

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

--------------------------------------------------------------------------

1a)The following operational keys are labeled with "Use: ALL" and have
  session-wide applicability:
      InitialR2T
      BidiInitialR2T
      ImmediateData

  This means that they can be negotiated during the login phase for
  any connection in a session, as well as during full feature phase on
  any connection in a session, but at the successful conclusion of that
  negotiation, the results apply immediately to all connections in
  the session.

  The question is: "What is the rationale for making these 3 keys
  session-wide instead of connection-specific?"

  Phrased another way, the question is: "Would it not be better if these
  keys were connection-specific instead of session-wide?"

  In particular, it appears that dynamic changes to these values on one
  connection can have an effect on outstanding commands on other
  connections that requires considerable complication in implementations
  to handle correctly, yet the benefit is not obvious from the standard.

  Could someone please supply a rationale for keeping these keys
  session-wide?

+++

Those key convey propoerties that are specific to the SCSI target (not iSCSI transport).
Using R2T means not allocating SCSI buffers for unsolicited commands (that you have no idea on what connection they will be comming).

+++

1b)A related issue is that the values negotiated for InitialR2T and
  ImmediateData are intimately intertwined, as evidenced by the
  table accompanying the description of ImmediateData in Appendix D.

  However, InitialR2T has a specific restriction (in the description
  of InitialR2T in Appendix D): "Once InitialR2T has been set to 'no',
  it cannot be set back to 'yes'. BidiInitalR2T has the same restriction.
  But ImmediateData does not have this restriction.

  The question is: "Why doesn't ImmediateData have a similar restriction?"

  In particular, this restriction on (Bidi)InitialR2T limits the
  possibilities for (re)negotiation at any time on any connection
  mentioned in 1a above, because once unsolicited data PDUs have been
  negotiated off, they can never be negotiated on again, effectively
  eliminating InitialR2T from all further negotiations.

  Could someone please supply a rationale for allowing ImmediateData to
  be negotiated on/off at any time on any connection but not InitialR2T?

+++

We saw no reason to force the targets to handle the "uncertainty" related to the transition from No to Yes of R2T (i.e., when can the target remove resources related to the unsolicited data).  We saw a need for a yet-to-no transition (speed increase) but none for a no-to-yes.
Immediate data on the other hand has a very restricted and well-defined resource need - a single PDU asociated with the command and there is no uncertainty in the transition (or very limited).

+++
2. Section 3.11.3 discusses the use of the Target Transfer Tag in the Text
  Response pdu.  It says that when the target has more work to do, it
  MUST set the Target Transfer Tag to some value other than 0xffffffff.
  When the target does not have more work to do, the standard does not
  say what value the Target Transfer Tag should have.  There are 2
  possibilities:

  a. If the target must set the Target Transfer Tag to 0xffffffff,
     then the standard should state this explicitly.
  b. If the target can set the Target Transfer Tag to any value
     (or leave it undefined) then it appears that there is no need to
     reserve 0xffffffff for the Target Transfer Tag at all, and there
     is no need to require a value other than 0xffffffff when F = 0
     (any value will work fine).
+++
The value 0xfffffff should be used exclusively to covey a "soft reset" i.e., while the target has more work to do the initiator wnats to start fresh
I will try to make clear in the text that if there is no more work to do it MUST be set to 0xffffffff

+++

3. Section 3.8.3 limits the value of the Desired Data Transfer Length in
  an R2T to at most MaxBurstSize.  What is the rationale for this?
   An R2T is sent by the target to the initiator, so why can't the
  target specify any size it wants in the R2T?  The target already
  uses R2Ts to control the flow of Data-Out PDUs from the initiator,
  so why impose this restriction on the R2Ts?

  Could someone please explain the benefit to this limitation on R2Ts?

+++ Is this a plugfest question or one of your own?  For your own questions the channels are always open.  The MaxBurstSize is there to enable the initiator to share resources between several executing commands and limit the number of "pending buffers" a target will have to keep
in case one of the Data Out PDUS is damaged and transfer to a device is not possible.

+++

4. Section 3.7.1 says that the Data-In pdus sent by the target to satisfy
  a SCSI read command can be split into sequences each terminated by
  a pdu having F=1.  The standard does not seem to require that this
  be done.  However, if it is done, then the description of MaxBurstSize
  in Appendix D limits these sequences to at most MaxBurstSize bytes.

4a.The first question is: "What is the benefit for allowing the
  Data-In pdus to be split into sequences?"

  It appears that doing so forces a dual role on the F-bit -- as end of
  sequence and as end of all input -- and complicates the interpretation
  of this bit in the initiator.  This feature seems to be necessary to
  change direction in bidirectional transfers, but are there other uses
  for this?

+++ End of all input is the satus or Response - no ambiguity +++

4b.The second question is: "Is the target required to split Data-In pdus
  into sequences?"

  If so, this should be made explicit in the standard, and the rationale
  for this should also be given.

+++ It is required and the rational is in 2.4.1.5 (version 10). The rational is direction change and Ack if required +++

--=_alternative 002ED4C5C2256B5E_=-- From owner-ips@ece.cmu.edu Tue Feb 12 05:22: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 FAA07258 for ; Tue, 12 Feb 2002 05:22:56 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1C9ZVu11107 for ips-outgoing; Tue, 12 Feb 2002 04:35:31 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mc.va3.ummail.com (mc.va3.ummail.com [66.187.242.22]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1C9ZTj11103 for ; Tue, 12 Feb 2002 04:35:29 -0500 (EST) Received: from hqmailweb.COMMSTOR.Crossroads.com (HQMailWeb.Crossroads.com [63.237.99.250:25]) by mc.va3.ummail.com with ESMTP id M0212-0435-573700; Tue, 12 Feb 2002 09:35:06 GMT Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 12 Feb 2002 03:35:04 -0600 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: RE: UNH Plugfest Date: Tue, 12 Feb 2002 03:35:02 -0600 Message-ID: Thread-Topic: UNH Plugfest Thread-Index: AcGzeHMdwr5kEwqLQ0WBGVg5Tp6qAAALoFMA From: "Buck Landry" To: "Robert D. Russell" Cc: X-OriginalArrivalTime: 12 Feb 2002 09:35:04.0476 (UTC) FILETIME=[8D0335C0:01C1B3A8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g1C9ZUj11104 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit >>> 1a) (snip) draft v10 addresses these problems. InitialR2T, BidiInitialR2T and ImmediateData are all LO parameters. >>> 1b) However, InitialR2T has a specific restriction (in the description of InitialR2T in Appendix D): In draft 10 it doesn't. BidiInitialR2T does though.. I wonder if it's vestigal text. --buck -----Original Message----- From: Robert D. Russell [mailto:rdr@io.iol.unh.edu] Sent: Monday, February 11, 2002 6:49 PM To: Julian Satran Cc: ips@ece.cmu.edu Subject: UNH Plugfest Julian: Attached are some of the issues that arose during the first day of the iSCSI plugfest at UNH on Monday 11-February-2001. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 -------------------------------------------------------------------------- 1a)The following operational keys are labeled with "Use: ALL" and have session-wide applicability: InitialR2T BidiInitialR2T ImmediateData This means that they can be negotiated during the login phase for any connection in a session, as well as during full feature phase on any connection in a session, but at the successful conclusion of that negotiation, the results apply immediately to all connections in the session. The question is: "What is the rationale for making these 3 keys session-wide instead of connection-specific?" Phrased another way, the question is: "Would it not be better if these keys were connection-specific instead of session-wide?" In particular, it appears that dynamic changes to these values on one connection can have an effect on outstanding commands on other connections that requires considerable complication in implementations to handle correctly, yet the benefit is not obvious from the standard. Could someone please supply a rationale for keeping these keys session-wide? 1b)A related issue is that the values negotiated for InitialR2T and ImmediateData are intimately intertwined, as evidenced by the table accompanying the description of ImmediateData in Appendix D. However, InitialR2T has a specific restriction (in the description of InitialR2T in Appendix D): "Once InitialR2T has been set to 'no', it cannot be set back to 'yes'. BidiInitalR2T has the same restriction. But ImmediateData does not have this restriction. The question is: "Why doesn't ImmediateData have a similar restriction?" In particular, this restriction on (Bidi)InitialR2T limits the possibilities for (re)negotiation at any time on any connection mentioned in 1a above, because once unsolicited data PDUs have been negotiated off, they can never be negotiated on again, effectively eliminating InitialR2T from all further negotiations. Could someone please supply a rationale for allowing ImmediateData to be negotiated on/off at any time on any connection but not InitialR2T? 2. Section 3.11.3 discusses the use of the Target Transfer Tag in the Text Response pdu. It says that when the target has more work to do, it MUST set the Target Transfer Tag to some value other than 0xffffffff. When the target does not have more work to do, the standard does not say what value the Target Transfer Tag should have. There are 2 possibilities: a. If the target must set the Target Transfer Tag to 0xffffffff, then the standard should state this explicitly. b. If the target can set the Target Transfer Tag to any value (or leave it undefined) then it appears that there is no need to reserve 0xffffffff for the Target Transfer Tag at all, and there is no need to require a value other than 0xffffffff when F = 0 (any value will work fine). 3. Section 3.8.3 limits the value of the Desired Data Transfer Length in an R2T to at most MaxBurstSize. What is the rationale for this? An R2T is sent by the target to the initiator, so why can't the target specify any size it wants in the R2T? The target already uses R2Ts to control the flow of Data-Out PDUs from the initiator, so why impose this restriction on the R2Ts? Could someone please explain the benefit to this limitation on R2Ts? 4. Section 3.7.1 says that the Data-In pdus sent by the target to satisfy a SCSI read command can be split into sequences each terminated by a pdu having F=1. The standard does not seem to require that this be done. However, if it is done, then the description of MaxBurstSize in Appendix D limits these sequences to at most MaxBurstSize bytes. 4a.The first question is: "What is the benefit for allowing the Data-In pdus to be split into sequences?" It appears that doing so forces a dual role on the F-bit -- as end of sequence and as end of all input -- and complicates the interpretation of this bit in the initiator. This feature seems to be necessary to change direction in bidirectional transfers, but are there other uses for this? 4b.The second question is: "Is the target required to split Data-In pdus into sequences?" If so, this should be made explicit in the standard, and the rationale for this should also be given. From owner-ips@ece.cmu.edu Tue Feb 12 08:30: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 IAA10646 for ; Tue, 12 Feb 2002 08:30:10 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1CChBS29448 for ips-outgoing; Tue, 12 Feb 2002 07:43:11 -0500 (EST) 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 g1CCh8j29442; Tue, 12 Feb 2002 07:43:08 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id NAA57390; Tue, 12 Feb 2002 13:42:54 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1CCiOA100414; Tue, 12 Feb 2002 13:44:25 +0100 To: "Buck Landry" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu, "Robert D. Russell" MIME-Version: 1.0 Subject: RE: UNH Plugfest X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 12 Feb 2002 14:44:26 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 12/02/2002 14:44:28, Serialize complete at 12/02/2002 14:44:28 Content-Type: multipart/alternative; boundary="=_alternative 00451675C2256B5E_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00451675C2256B5E_= Content-Type: text/plain; charset="us-ascii" You are right it is vestigial - I'll remove it. Julo "Buck Landry" Sent by: owner-ips@ece.cmu.edu 12-02-02 11:35 To: "Robert D. Russell" cc: Subject: RE: UNH Plugfest >>> 1a) (snip) draft v10 addresses these problems. InitialR2T, BidiInitialR2T and ImmediateData are all LO parameters. >>> 1b) However, InitialR2T has a specific restriction (in the description of InitialR2T in Appendix D): In draft 10 it doesn't. BidiInitialR2T does though.. I wonder if it's vestigal text. --buck -----Original Message----- From: Robert D. Russell [mailto:rdr@io.iol.unh.edu] Sent: Monday, February 11, 2002 6:49 PM To: Julian Satran Cc: ips@ece.cmu.edu Subject: UNH Plugfest Julian: Attached are some of the issues that arose during the first day of the iSCSI plugfest at UNH on Monday 11-February-2001. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 -------------------------------------------------------------------------- 1a)The following operational keys are labeled with "Use: ALL" and have session-wide applicability: InitialR2T BidiInitialR2T ImmediateData This means that they can be negotiated during the login phase for any connection in a session, as well as during full feature phase on any connection in a session, but at the successful conclusion of that negotiation, the results apply immediately to all connections in the session. The question is: "What is the rationale for making these 3 keys session-wide instead of connection-specific?" Phrased another way, the question is: "Would it not be better if these keys were connection-specific instead of session-wide?" In particular, it appears that dynamic changes to these values on one connection can have an effect on outstanding commands on other connections that requires considerable complication in implementations to handle correctly, yet the benefit is not obvious from the standard. Could someone please supply a rationale for keeping these keys session-wide? 1b)A related issue is that the values negotiated for InitialR2T and ImmediateData are intimately intertwined, as evidenced by the table accompanying the description of ImmediateData in Appendix D. However, InitialR2T has a specific restriction (in the description of InitialR2T in Appendix D): "Once InitialR2T has been set to 'no', it cannot be set back to 'yes'. BidiInitalR2T has the same restriction. But ImmediateData does not have this restriction. The question is: "Why doesn't ImmediateData have a similar restriction?" In particular, this restriction on (Bidi)InitialR2T limits the possibilities for (re)negotiation at any time on any connection mentioned in 1a above, because once unsolicited data PDUs have been negotiated off, they can never be negotiated on again, effectively eliminating InitialR2T from all further negotiations. Could someone please supply a rationale for allowing ImmediateData to be negotiated on/off at any time on any connection but not InitialR2T? 2. Section 3.11.3 discusses the use of the Target Transfer Tag in the Text Response pdu. It says that when the target has more work to do, it MUST set the Target Transfer Tag to some value other than 0xffffffff. When the target does not have more work to do, the standard does not say what value the Target Transfer Tag should have. There are 2 possibilities: a. If the target must set the Target Transfer Tag to 0xffffffff, then the standard should state this explicitly. b. If the target can set the Target Transfer Tag to any value (or leave it undefined) then it appears that there is no need to reserve 0xffffffff for the Target Transfer Tag at all, and there is no need to require a value other than 0xffffffff when F = 0 (any value will work fine). 3. Section 3.8.3 limits the value of the Desired Data Transfer Length in an R2T to at most MaxBurstSize. What is the rationale for this? An R2T is sent by the target to the initiator, so why can't the target specify any size it wants in the R2T? The target already uses R2Ts to control the flow of Data-Out PDUs from the initiator, so why impose this restriction on the R2Ts? Could someone please explain the benefit to this limitation on R2Ts? 4. Section 3.7.1 says that the Data-In pdus sent by the target to satisfy a SCSI read command can be split into sequences each terminated by a pdu having F=1. The standard does not seem to require that this be done. However, if it is done, then the description of MaxBurstSize in Appendix D limits these sequences to at most MaxBurstSize bytes. 4a.The first question is: "What is the benefit for allowing the Data-In pdus to be split into sequences?" It appears that doing so forces a dual role on the F-bit -- as end of sequence and as end of all input -- and complicates the interpretation of this bit in the initiator. This feature seems to be necessary to change direction in bidirectional transfers, but are there other uses for this? 4b.The second question is: "Is the target required to split Data-In pdus into sequences?" If so, this should be made explicit in the standard, and the rationale for this should also be given. --=_alternative 00451675C2256B5E_= Content-Type: text/html; charset="us-ascii"
You are right it is vestigial - I'll remove it.  Julo


"Buck Landry" <blandry@crossroads.com>
Sent by: owner-ips@ece.cmu.edu

12-02-02 11:35

       
        To:        "Robert D. Russell" <rdr@io.iol.unh.edu>
        cc:        <ips@ece.cmu.edu>
        Subject:        RE: UNH Plugfest

       


>>> 1a) (snip)

draft v10 addresses these problems.  InitialR2T, BidiInitialR2T and ImmediateData are all LO parameters.

>>> 1b) However, InitialR2T has a specific restriction (in the description
  of InitialR2T in Appendix D):

In draft 10 it doesn't.  BidiInitialR2T does though.. I wonder if it's vestigal text.

--buck



-----Original Message-----
From: Robert D. Russell [mailto:rdr@io.iol.unh.edu]
Sent: Monday, February 11, 2002 6:49 PM
To: Julian Satran
Cc: ips@ece.cmu.edu
Subject: UNH Plugfest


Julian:

Attached are some of the issues that arose during the first day
of the iSCSI plugfest at UNH on Monday 11-February-2001.

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

--------------------------------------------------------------------------

1a)The following operational keys are labeled with "Use: ALL" and have
  session-wide applicability:
      InitialR2T
      BidiInitialR2T
      ImmediateData

  This means that they can be negotiated during the login phase for
  any connection in a session, as well as during full feature phase on
  any connection in a session, but at the successful conclusion of that
  negotiation, the results apply immediately to all connections in
  the session.

  The question is: "What is the rationale for making these 3 keys
  session-wide instead of connection-specific?"

  Phrased another way, the question is: "Would it not be better if these
  keys were connection-specific instead of session-wide?"

  In particular, it appears that dynamic changes to these values on one
  connection can have an effect on outstanding commands on other
  connections that requires considerable complication in implementations
  to handle correctly, yet the benefit is not obvious from the standard.

  Could someone please supply a rationale for keeping these keys
  session-wide?


1b)A related issue is that the values negotiated for InitialR2T and
  ImmediateData are intimately intertwined, as evidenced by the
  table accompanying the description of ImmediateData in Appendix D.

  However, InitialR2T has a specific restriction (in the description
  of InitialR2T in Appendix D): "Once InitialR2T has been set to 'no',
  it cannot be set back to 'yes'. BidiInitalR2T has the same restriction.
  But ImmediateData does not have this restriction.

  The question is: "Why doesn't ImmediateData have a similar restriction?"

  In particular, this restriction on (Bidi)InitialR2T limits the
  possibilities for (re)negotiation at any time on any connection
  mentioned in 1a above, because once unsolicited data PDUs have been
  negotiated off, they can never be negotiated on again, effectively
  eliminating InitialR2T from all further negotiations.

  Could someone please supply a rationale for allowing ImmediateData to
  be negotiated on/off at any time on any connection but not InitialR2T?


2. Section 3.11.3 discusses the use of the Target Transfer Tag in the Text
   Response pdu.  It says that when the target has more work to do, it
  MUST set the Target Transfer Tag to some value other than 0xffffffff.
  When the target does not have more work to do, the standard does not
  say what value the Target Transfer Tag should have.  There are 2
  possibilities:

  a. If the target must set the Target Transfer Tag to 0xffffffff,
     then the standard should state this explicitly.
  b. If the target can set the Target Transfer Tag to any value
     (or leave it undefined) then it appears that there is no need to
     reserve 0xffffffff for the Target Transfer Tag at all, and there
     is no need to require a value other than 0xffffffff when F = 0
     (any value will work fine).


3. Section 3.8.3 limits the value of the Desired Data Transfer Length in
  an R2T to at most MaxBurstSize.  What is the rationale for this?
  An R2T is sent by the target to the initiator, so why can't the
  target specify any size it wants in the R2T?  The target already
  uses R2Ts to control the flow of Data-Out PDUs from the initiator,
  so why impose this restriction on the R2Ts?

  Could someone please explain the benefit to this limitation on R2Ts?


4. Section 3.7.1 says that the Data-In pdus sent by the target to satisfy
  a SCSI read command can be split into sequences each terminated by
  a pdu having F=1.  The standard does not seem to require that this
  be done.  However, if it is done, then the description of MaxBurstSize
  in Appendix D limits these sequences to at most MaxBurstSize bytes.

4a.The first question is: "What is the benefit for allowing the
  Data-In pdus to be split into sequences?"

  It appears that doing so forces a dual role on the F-bit -- as end of
  sequence and as end of all input -- and complicates the interpretation
  of this bit in the initiator.  This feature seems to be necessary to
  change direction in bidirectional transfers, but are there other uses
  for this?

4b.The second question is: "Is the target required to split Data-In pdus
  into sequences?"

  If so, this should be made explicit in the standard, and the rationale
  for this should also be given.

--=_alternative 00451675C2256B5E_=-- From owner-ips@ece.cmu.edu Tue Feb 12 10:57: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 KAA16179 for ; Tue, 12 Feb 2002 10:57:36 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1CEsiS06750 for ips-outgoing; Tue, 12 Feb 2002 09:54:44 -0500 (EST) 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 g1CC1ej27672 for ; Tue, 12 Feb 2002 07:01:55 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08385; Tue, 12 Feb 2002 07:01:38 -0500 (EST) Message-Id: <200202121201.HAA08385@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-fcencapsulation-06.txt,.pdf Date: Tue, 12 Feb 2002 07:01:38 -0500 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 : FC Frame Encapsulation Author(s) : R. Weber, M. Rajagopal, F. Travostino, M. O'Donnell, C. Monia, M. Merhar Filename : draft-ietf-ips-fcencapsulation-06.txt,.pdf Pages : 15 Date : 11-Feb-02 This is the ips (IP Storage) working group draft describing the common encapsulation format and a procedure for the measurement and calculation of frame transit time through the IP network. This specification is intended for use by any IETF protocol that encapsulates Fibre Channel (FC) frames. This draft describes a frame header containing information mandated for encapsulating, transmitting, de-encapsulating, and calculating the transit times of FC frames. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcencapsulation-06.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-fcencapsulation-06.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-fcencapsulation-06.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: <20020211152152.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-fcencapsulation-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-fcencapsulation-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020211152152.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Tue Feb 12 16:27: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 QAA28044 for ; Tue, 12 Feb 2002 16:27:06 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1CKM6A05643 for ips-outgoing; Tue, 12 Feb 2002 15:22:06 -0500 (EST) 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 g1CKM4j05636 for ; Tue, 12 Feb 2002 15:22:04 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id <15A8VFZK>; Tue, 12 Feb 2002 15:21:58 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937468@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: RE: Full Text of Phoenix letter Date: Tue, 12 Feb 2002 15:21:39 -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 Here's the contact info that goes with the text of the letter. Sorry for omitting it earlier. --David David Jablon CTO 508.898.9024 direct 509.561.1953 eFax david_jablon@phoenix.com Phoenix Technologies Ltd. 320 Norwood Park South Norwood, MA 02062 781.551.5000 main www.phoenix.com > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Saturday, February 09, 2002 2:43 AM > To: ips@ece.cmu.edu > Subject: Full Text of Phoenix letter > > > To: IETF IP Storage Working Group > Subject: Phoenix Patents and RFC 2945 > > February 6, 2002 > > > Dear working group members, > > Regarding the inquiry by working group co-chair David Black into the nature > of U.S. patent 6,226,383 and its relation to SRP and RFC 2945, this letter > presents a status update on Phoenix's plans to provide an appropriate > response for the working group. This letter also presents a general summary > of our licensing practices and products in the field of password-based > cryptography, which I hope will assist you in the planning process. > > Phoenix owns patent 6,226,383 which describes the SPEKE methods for > zero-knowledge password authentication. An investigation into exactly how > this patent relates to RFC 2945 is now underway within the company. While > providing guarantees and assurances for use of technology developed by other > organizations has not been a traditional priority for Phoenix, there is now > recognition of the need for this working group and others to have clarity in > this matter, and a position statement will be provided very soon. > > Phoenix Technologies, in part through the acquisition of Integrity Sciences, > has developed the SPEKE family of zero-knowledge password methods, providing > both licenses and implementations. These protocols have been cited and > studied in numerous research papers over the past several years. In > particular, the BSPEKE protocol can provide a plug-and-play upgrade for SRP. > An Internet Draft discussing these issues is also being prepared. These > methods are comparable to the best of any similar methods, and they are > easily shown to be unencumbered by the other patents in this field. > > It would seem a shame for a new standards effort to avoid zero-knowledge > password techniques as a purely cost-savings measure, given the choices > available. The need for convenient, strong, and inexpensive security > built-in to the infrastructure of Internet applications is as great today as > ever. The SPEKE techniques represent a generational improvement in personal > authentication, providing strong security with minimal effort. These > methods provide the best choices in this field, with the cleanest > implementations, optimal security, best alignment with standards, and > easiest license agreements for commercial deployment of zero-knowledge > password techniques. > > A statement regarding licensing of the SPEKE patent in the context of the > IEEE 1363 standard is on file with the IEEE, and Phoenix is also committed > to providing an updated statement in this same time frame that conforms to > both IEEE and IETF policies assuring reasonable and non-discriminatory > terms. But more importantly, as a leading provider to the PC industry, > Phoenix will stand behind its technology. Phoenix has a 20-year history of > broadly licensing products to this industry, and has helped to pioneer many > widely used standards and technologies that are built-in to the systems that > we all take for granted. Our history of cooperation with many of the > leading companies in the industry makes Phoenix naturally suited to gently > encouraging the adoption of this new class of strong and convenient security > techniques. > > Sincerely, > > > David Jablon > CTO, Phoenix Technologies From owner-ips@ece.cmu.edu Tue Feb 12 17:42: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 RAA29825 for ; Tue, 12 Feb 2002 17:42:11 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1CLreV13778 for ips-outgoing; Tue, 12 Feb 2002 16:53:40 -0500 (EST) 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 g1CLrcj13765 for ; Tue, 12 Feb 2002 16:53:38 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Feb 2002 16:53:21 -0500 Message-ID: <25369470B6F0D41194820002B328BDD210B7C3@ATLOPS> From: Sukha Ghosh To: ips@ece.cmu.edu Subject: iSCSI: FIM Marker related Date: Tue, 12 Feb 2002 16:53:15 -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 Hi, In Specs version 10, Appendix A, Section A.2 page 196, you say that if the negotiated marker interval is 512 and the login ended at byte 1003, the first marker will be inserted after byte 1031 in the stream. How did you arrive at this number? In this example, I thought that from pure iSCSI byte point of view, the marker should be inserted after byte 1023, 1535 etc of iSCSI byte. Could you please clarify? From owner-ips@ece.cmu.edu Tue Feb 12 23:16: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 XAA07392 for ; Tue, 12 Feb 2002 23:16:20 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1D3LTT01394 for ips-outgoing; Tue, 12 Feb 2002 22:21:29 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from philotas.hosting.pacbell.net (philotas.hosting.pacbell.net [216.100.99.24]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1D2l6j29790; Tue, 12 Feb 2002 21:47:07 -0500 (EST) Received: from ephi ([65.172.158.93]) by philotas.hosting.pacbell.net id VAA03053; Tue, 12 Feb 2002 21:46:46 -0500 (EST) [ConcentricHost SMTP Relay 1.14] From: "Ephi Dror" To: Cc: , , Subject: Please help Date: Tue, 12 Feb 2002 18:46:46 -0800 Message-ID: <001f01c1b438$adbd30f0$2010000a@corp.silverbacksystems.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01C1B3F5.9F99F0F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0020_01C1B3F5.9F99F0F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Costa and all, I saw yours posting long ago about NFS V2/V3 header splitting technique (http://www.pdl.cmu.edu/mailinglists/ips/mail/msg00075.html ) and I would just like to ask if I may a quick question. In CIFS, you said it may be costly to perform it since it does not have fix size trailer. >From my understanding, if I just interested in splitting SMB read respond and write request commands from their payloads, all I need is to parse the header by hunting for those commands and then for each of those commands, the actual payload starts at the offset specified by a field called DataOffset. So to me it does not look like it cost much to do header split for the few commands that are important. Of course, do a pure header split of all SMB commands from their payload could be costly in terms of firmware code space and performance. Am I missing some thing big time here? I really appreciate and respect your view on this subject. Cheers, Ephi ------=_NextPart_000_0020_01C1B3F5.9F99F0F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Costa and all,

 

I saw yours posting long ago about NFS V2/V3 header splitting technique (http:= //www.pdl.cmu.edu/mailinglists/ips/mail/msg00075.html ) and I would just like to ask if I may a quick = question.

 

In CIFS, you said it may be costly to perform it = since it does not have fix size trailer.

 

From my understanding, if I just interested in = splitting  SMB read respond and write = request commands from their payloads, all I need is to parse the header by = hunting for those commands and then for each of those commands, the actual payload = starts at the offset specified by a field called  DataOffset.

 

So to me it does not look like it cost much to do header split = for the few commands that are important.

 

Of course, do a pure header split of all SMB commands from their = payload could be costly in terms of firmware code space and = performance.


Am I missing some thing big time here?

 

I really appreciate and respect your view on this = subject.

 

Cheers,

Ephi

 

 

------=_NextPart_000_0020_01C1B3F5.9F99F0F0-- From owner-ips@ece.cmu.edu Wed Feb 13 03:11: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 DAA22713 for ; Wed, 13 Feb 2002 03:11:46 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1D7VAf12230 for ips-outgoing; Wed, 13 Feb 2002 02:31:10 -0500 (EST) 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 g1D7V8j12225 for ; Wed, 13 Feb 2002 02:31:08 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id IAA85062; Wed, 13 Feb 2002 08:31:01 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1D7WZp69124; Wed, 13 Feb 2002 08:32:39 +0100 To: Sukha Ghosh , ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: FIM Marker related X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 13 Feb 2002 09:32:30 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 13/02/2002 09:32:37, Serialize complete at 13/02/2002 09:32:37 Content-Type: multipart/alternative; boundary="=_alternative 00290D63C2256B5F_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00290D63C2256B5F_= Content-Type: text/plain; charset="us-ascii" Although markers start being inserted only after login - the insertion points are calculated as if markers where there from point 0 (so that nobody has to remember when login ended). So you had a set of "virtual markers" at 512-519 Julo Sukha Ghosh Sent by: owner-ips@ece.cmu.edu 12-02-02 23:53 To: ips@ece.cmu.edu cc: Subject: iSCSI: FIM Marker related Hi, In Specs version 10, Appendix A, Section A.2 page 196, you say that if the negotiated marker interval is 512 and the login ended at byte 1003, the first marker will be inserted after byte 1031 in the stream. How did you arrive at this number? In this example, I thought that from pure iSCSI byte point of view, the marker should be inserted after byte 1023, 1535 etc of iSCSI byte. Could you please clarify? --=_alternative 00290D63C2256B5F_= Content-Type: text/html; charset="us-ascii"
Although markers start being inserted only after login - the insertion points are calculated as if markers where there from point 0 (so that nobody has to remember when login ended). So you had a set of "virtual markers" at 512-519

Julo


Sukha Ghosh <sukha_ghosh@ivivity.com>
Sent by: owner-ips@ece.cmu.edu

12-02-02 23:53

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI: FIM Marker related

       


Hi,

In Specs version 10, Appendix A, Section A.2 page 196, you say that if the
negotiated marker interval is 512 and the login ended at byte 1003, the
first marker will be inserted after byte 1031 in the stream. How did you
arrive at this number? In this example, I thought that from pure iSCSI byte
point of view, the marker should be inserted after byte 1023, 1535 etc of
iSCSI byte. Could you please clarify?

--=_alternative 00290D63C2256B5F_=-- From owner-ips@ece.cmu.edu Wed Feb 13 09:56: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 JAA05750 for ; Wed, 13 Feb 2002 09:56:35 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1DDpWV09478 for ips-outgoing; Wed, 13 Feb 2002 08:51:32 -0500 (EST) 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 g1DCACj05120 for ; Wed, 13 Feb 2002 07:10:12 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28847; Wed, 13 Feb 2002 07:10:09 -0500 (EST) Message-Id: <200202131210.HAA28847@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-09.txt Date: Wed, 13 Feb 2002 07:10:09 -0500 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-09.txt Pages : 64 Date : 12-Feb-02 This document discusses how block storage protocols running over IP, including iSCSI, iFCP and FCIP, can utilize IPsec for security. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-security-09.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-09.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-09.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: <20020212150553.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-security-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-security-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020212150553.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Wed Feb 13 12:18: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 MAA14346 for ; Wed, 13 Feb 2002 12:18:17 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1DGHsh19125 for ips-outgoing; Wed, 13 Feb 2002 11:17:54 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from erie.mcdata.com (mcjekyll.mcdata.com [144.49.6.25]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1DGHqj19121 for ; Wed, 13 Feb 2002 11:17:52 -0500 (EST) Received: from erie.mcdata.com ([172.18.1.35]) by erie.mcdata.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DXFNLC89; Wed, 13 Feb 2002 09:17:46 -0700 Received: from 144.49.154.169 by erie.mcdata.com (InterScan E-Mail VirusWall NT); Wed, 13 Feb 2002 09:17:44 -0700 Received: by grizzly.mcdata.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Feb 2002 11:17:43 -0500 Message-ID: <1B8A58D6C376FE4DB329408E27013842448043@grizzly.mcdata.com> From: Robert Grant To: ips@ece.cmu.edu Subject: iSCSI: EUI64 slides from Feb6 IPS WG meet Date: Wed, 13 Feb 2002 11:17:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-ff39e9ca-f707-48bb-a4d2-68b561556253" 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-ff39e9ca-f707-48bb-a4d2-68b561556253 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B4A9.F3D156E0" ------_=_NextPart_001_01C1B4A9.F3D156E0 Content-Type: text/plain; charset="iso-8859-1" Hello all, Sorry for taking so long to post the slides that I presented on Feb. 6 on the EUI64 identifier (wasn't I supposed to do this BEFORE the meeting?), but you can find the slides I presented at ftp://ietfpresentations@ftp.mcdata.com/ in draft-grant-iscsi-eui64node-00.ppt. The userid is ietfpresentations and the password is ietf. The titles should even be on the top :-) ! Regards, Rob Rob Grant McDATA Corporation ------_=_NextPart_001_01C1B4A9.F3D156E0 Content-Type: text/html; charset="iso-8859-1"
Hello all,
 
Sorry for taking so long to post the slides that I presented on Feb. 6 on the EUI64 identifier (wasn't I supposed to do this BEFORE the meeting?), but you can find the slides I presented at ftp://ietfpresentations@ftp.mcdata.com/ in draft-grant-iscsi-eui64node-00.ppt. The userid is ietfpresentations and the password is ietf. The titles should even be on the top :-) !

Regards,
Rob
 
Rob Grant
McDATA Corporation

------_=_NextPart_001_01C1B4A9.F3D156E0-- ------=_NextPartTM-000-ff39e9ca-f707-48bb-a4d2-68b561556253-- From owner-ips@ece.cmu.edu Wed Feb 13 12:25: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 MAA14532 for ; Wed, 13 Feb 2002 12:25:23 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1DGs6g21638 for ips-outgoing; Wed, 13 Feb 2002 11:54:06 -0500 (EST) 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 g1DGs5j21633 for ; Wed, 13 Feb 2002 11:54:05 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Feb 2002 11:54:04 -0500 Message-ID: <25369470B6F0D41194820002B328BDD210B7C7@ATLOPS> From: Sukha Ghosh To: "'Julian Satran'" Cc: "'ips@ece.cmu.edu'" Subject: RE: iSCSI: FIM Marker related Date: Wed, 13 Feb 2002 11:53:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B4AF.077EC6F0" 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_01C1B4AF.077EC6F0 Content-Type: text/plain; charset="iso-8859-1" So if I understand it right, as a receiver at whatever byte stream point the log-in ended, after that I would have start of an 8 byte marker at byte point determined by the formula [(MI + 8) * n - 8] where MI = Marker Interval, n = integer number. Please let me know if it is correct or not. Thanks -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, February 13, 2002 2:33 AM To: Sukha Ghosh; ips@ece.cmu.edu Subject: Re: iSCSI: FIM Marker related Although markers start being inserted only after login - the insertion points are calculated as if markers where there from point 0 (so that nobody has to remember when login ended). So you had a set of "virtual markers" at 512-519 Julo Sukha Ghosh Sent by: owner-ips@ece.cmu.edu 12-02-02 23:53 To: ips@ece.cmu.edu cc: Subject: iSCSI: FIM Marker related Hi, In Specs version 10, Appendix A, Section A.2 page 196, you say that if the negotiated marker interval is 512 and the login ended at byte 1003, the first marker will be inserted after byte 1031 in the stream. How did you arrive at this number? In this example, I thought that from pure iSCSI byte point of view, the marker should be inserted after byte 1023, 1535 etc of iSCSI byte. Could you please clarify? ------_=_NextPart_001_01C1B4AF.077EC6F0 Content-Type: text/html; charset="iso-8859-1"
So if I understand it right, as a receiver at whatever byte stream point the log-in ended, after that I would have start of an 8 byte marker at byte point determined by the formula [(MI + 8) * n - 8] where MI = Marker Interval, n = integer number. Please let me know if it is correct or not.
 
Thanks 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, February 13, 2002 2:33 AM
To: Sukha Ghosh; ips@ece.cmu.edu
Subject: Re: iSCSI: FIM Marker related


Although markers start being inserted only after login - the insertion points are calculated as if markers where there from point 0 (so that nobody has to remember when login ended). So you had a set of "virtual markers" at 512-519

Julo


Sukha Ghosh <sukha_ghosh@ivivity.com>
Sent by: owner-ips@ece.cmu.edu

12-02-02 23:53

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI: FIM Marker related

       


Hi,

In Specs version 10, Appendix A, Section A.2 page 196, you say that if the
negotiated marker interval is 512 and the login ended at byte 1003, the
first marker will be inserted after byte 1031 in the stream. How did you
arrive at this number? In this example, I thought that from pure iSCSI byte
point of view, the marker should be inserted after byte 1023, 1535 etc of
iSCSI byte. Could you please clarify?




------_=_NextPart_001_01C1B4AF.077EC6F0-- From owner-ips@ece.cmu.edu Wed Feb 13 13:09: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 NAA15762 for ; Wed, 13 Feb 2002 13:09:42 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1DHGuo23357 for ips-outgoing; Wed, 13 Feb 2002 12:16:56 -0500 (EST) 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 g1DHGsj23352 for ; Wed, 13 Feb 2002 12:16:54 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id SAA42386 for ; Wed, 13 Feb 2002 18:16:48 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1DHIPp83400 for ; Wed, 13 Feb 2002 18:18:25 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: FIM Marker related X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 13 Feb 2002 19:18:23 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 13/02/2002 19:18:24, Serialize complete at 13/02/2002 19:18:24 Content-Type: multipart/alternative; boundary="=_alternative 005EA4DDC2256B5F_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005EA4DDC2256B5F_= Content-Type: text/plain; charset="us-ascii" Correct - Julo Sukha Ghosh 13-02-02 18:53 To: Julian Satran/Haifa/IBM@IBMIL cc: "'ips@ece.cmu.edu'" Subject: RE: iSCSI: FIM Marker related So if I understand it right, as a receiver at whatever byte stream point the log-in ended, after that I would have start of an 8 byte marker at byte point determined by the formula [(MI + 8) * n - 8] where MI = Marker Interval, n = integer number. Please let me know if it is correct or not. Thanks -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, February 13, 2002 2:33 AM To: Sukha Ghosh; ips@ece.cmu.edu Subject: Re: iSCSI: FIM Marker related Although markers start being inserted only after login - the insertion points are calculated as if markers where there from point 0 (so that nobody has to remember when login ended). So you had a set of "virtual markers" at 512-519 Julo Sukha Ghosh Sent by: owner-ips@ece.cmu.edu 12-02-02 23:53 To: ips@ece.cmu.edu cc: Subject: iSCSI: FIM Marker related Hi, In Specs version 10, Appendix A, Section A.2 page 196, you say that if the negotiated marker interval is 512 and the login ended at byte 1003, the first marker will be inserted after byte 1031 in the stream. How did you arrive at this number? In this example, I thought that from pure iSCSI byte point of view, the marker should be inserted after byte 1023, 1535 etc of iSCSI byte. Could you please clarify? --=_alternative 005EA4DDC2256B5F_= Content-Type: text/html; charset="us-ascii"
Correct - Julo


Sukha Ghosh <sukha_ghosh@ivivity.com>

13-02-02 18:53

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
        Subject:        RE: iSCSI: FIM Marker related

       


So if I understand it right, as a receiver at whatever byte stream point the log-in ended, after that I would have start of an 8 byte marker at byte point determined by the formula [(MI + 8) * n - 8] where MI = Marker Interval, n = integer number. Please let me know if it is correct or not.
 
Thanks
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, February 13, 2002 2:33 AM
To: Sukha Ghosh; ips@ece.cmu.edu
Subject: Re: iSCSI: FIM Marker related

Although markers start being inserted only after login - the insertion points are calculated as if markers where there from point 0 (so that nobody has to remember when login ended). So you had a set of "virtual markers" at 512-519

Julo

Sukha Ghosh <sukha_ghosh@ivivity.com>
Sent by: owner-ips@ece.cmu.edu

12-02-02 23:53

       
       To:        ips@ece.cmu.edu
       cc:        
       Subject:        iSCSI: FIM Marker related

     



Hi,

In Specs version 10, Appendix A, Section A.2 page 196, you say that if the
negotiated marker interval is 512 and the login ended at byte 1003, the
first marker will be inserted after byte 1031 in the stream. How did you
arrive at this number? In this example, I thought that from pure iSCSI byte
point of view, the marker should be inserted after byte 1023, 1535 etc of
iSCSI byte. Could you please clarify?

--=_alternative 005EA4DDC2256B5F_=-- From owner-ips@ece.cmu.edu Wed Feb 13 19: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 TAA24767 for ; Wed, 13 Feb 2002 19:20:56 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1DNx2q20682 for ips-outgoing; Wed, 13 Feb 2002 18:59:02 -0500 (EST) 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 g1DNx0j20678 for ; Wed, 13 Feb 2002 18:59:00 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel9.hp.com (Postfix) with ESMTP id 25CFA80500B for ; Wed, 13 Feb 2002 18:58:52 -0500 (EST) 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 QAA28159 for ; Wed, 13 Feb 2002 16:00:30 -0800 (PST) Message-ID: <005401c1b4ea$624e7360$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "ips" Subject: iSCSI: X-bit in Login Date: Wed, 13 Feb 2002 15:58:28 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0051_01C1B4A7.46D6E0B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0051_01C1B4A7.46D6E0B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, It seems to me that we do not need the X-bit even in the Login PDU. "Connection reinstatement"/"implicit connection logout" can be = implicitly=20 signaled by using an active ISID-TSID-CID combination to request the target to implicitly logout the connection state machine for the CID. = This is=20 conceptually nothing but the "option A" choice we made for implicit=20 session logout sometime ago (remember the "reusing ISID for recovery"=20 thread?), albeit at the connection level. As far as I can tell, the = current=20 X-bit in Login PDU is similar to the C-bit that we considered and = rejected=20 for "implicit" session logout. I suggest we apply the same design = principle=20 here. I propose that the draft should continue to formally define the notion = of=20 "connection reinstatement" with the existing rules on its usage, but = retire=20 the X-bit to make that bit position reserved. Leaving the X-bit in = would only=20 lead to needless error cases. Comments? -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668=20 Roseville CA 95747 ------=_NextPart_000_0051_01C1B4A7.46D6E0B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
All,
 
It seems to me that we do not need the = X-bit even=20 in the Login PDU.
 
"Connection reinstatement"/"implicit = connection=20 logout" can be implicitly
signaled by using an active = ISID-TSID-CID=20 combination to request the
target to implicitly logout the = connection state=20 machine for the CID.  This is
conceptually nothing but the = "option A" choice=20 we made for implicit
session logout sometime ago (remember the "reusing ISID for recovery" =
thread?), albeit at=20 the connection level.  As far as I can tell, the current =
X-bit in Login PDU is similar to the C-bit that = we considered=20 and rejected
for "implicit" session logout.  I suggest we apply the same design principle =
here.
 
I propose that the draft should = continue to=20 formally define the notion of
"connection reinstatement" with the = existing rules=20 on its usage, but retire =
the X-bit to make that bit position = reserved.  Leaving the X-bit in would only =
lead to needless error = cases.
 
Comments?
--
Mallikarjun
 
Mallikarjun Chadalapaka
Networked = Storage=20 Architecture
Network Storage Solutions = Organization
Hewlett-Packard MS=20 5668
Roseville CA 95747
------=_NextPart_000_0051_01C1B4A7.46D6E0B0-- From owner-ips@ece.cmu.edu Wed Feb 13 19:22: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 TAA24794 for ; Wed, 13 Feb 2002 19:22:36 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1DNQdK18936 for ips-outgoing; Wed, 13 Feb 2002 18:26:39 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1DNQcj18931 for ; Wed, 13 Feb 2002 18:26:38 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Feb 2002 18:21:16 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937485@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSCSI bridge and gateway issues Date: Wed, 13 Feb 2002 18:26:11 -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 At the Huntington Beach interim meeting last week, a couple of brave souls talked to the IPS WG about specific issues that arise in bridges and/or gateways from iSCSI to other SCSI protocols. The overall conclusion from the meeting is that rather than dealing with individual issues in this area as they arise, the right thing to do is to start with a survey of potential problems in this area and things to do or not do to avoid them. This would be an Implementer's Guide sort of document whose goal would be to warn implementers of bridges and gateways about things that could go wrong and how to avoid them using iSCSI as it currently stands - the likely destination of this document would be an Informational RFC. The two people who gave these presentations have agreed to form the core of a team to produce this document - for now, this will be a team effort open to anyone who wants to contribute. Those who are interested should contact these two individuals directly, Dave Peterson [dap@cisco.com] Robert Grant [Robert.Grant@McDATA.com] With a good effort here, we can help iSCSI avoid the sort of issues that have caused problems for bridges between parallel SCSI and Fibre Channel. Anyone who has experience with such issues/problems is encouraged to contribute to this effort. 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 Feb 13 20:08: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 UAA25195 for ; Wed, 13 Feb 2002 20:08:43 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1E0DWl21452 for ips-outgoing; Wed, 13 Feb 2002 19:13:32 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mc.va3.ummail.com (mc.va3.ummail.com [66.187.242.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1E0DUj21446 for ; Wed, 13 Feb 2002 19:13:30 -0500 (EST) Received: from hqmailweb.COMMSTOR.Crossroads.com (HQMailWeb.Crossroads.com [63.237.99.250:25]) by mc.va3.ummail.com with ESMTP id V0213-1913-553f04; Thu, 14 Feb 2002 00:13:27 GMT Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 13 Feb 2002 18:13:20 -0600 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: Location of digests in PDUs Date: Wed, 13 Feb 2002 18:12:02 -0600 Message-ID: Thread-Topic: Location of digests in PDUs Thread-Index: AcG07Dlbvi2Fa/HnQTSywb/TvOeBhw== From: "Michael Klock" To: "Ips Reflector (E-mail)" X-OriginalArrivalTime: 14 Feb 2002 00:13:20.0508 (UTC) FILETIME=[68B553C0:01C1B4EC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g1E0DVj21449 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Please ignore if this has already been mentioned, but some of the v10 command figures appear confusing in regards to digests. While section 10.2 lists the PDU structure as, - BHS - AHS (optional) - Header Digest (optional) - Data Segment (optional) - Data Digest (optional) The command sections do not always have the same sequence of segments. For example, - Section 10.3 (SCSI Cmd PDU) lists the Header digest, but never mentions the Data digest which could exist - Sections 10.4, 10.7, 10.9, 10.10, etc. show PDU structures with a "Digests if any..." statement before the Data Segment which would put the Data Digest in a different place than section 10.2. - Section 10.17 (Reject) includes a Data Segment but no Data Digest Thanks, Mike. Michael M. Klock Crossroads Systems, Inc. (512) 928-7292 From owner-ips@ece.cmu.edu Thu Feb 14 11:03: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 LAA25368 for ; Thu, 14 Feb 2002 11:03:46 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1EF5Ed11935 for ips-outgoing; Thu, 14 Feb 2002 10:05:14 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1EF5Dj11931 for ; Thu, 14 Feb 2002 10:05:13 -0500 (EST) Received: from frejya.corp.netapp.com (frejya [10.10.20.91]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id g1EF56309401 for ; Thu, 14 Feb 2002 07:05:06 -0800 (PST) Received: from tahoe.corp.netapp.com (localhost [127.0.0.1]) by frejya.corp.netapp.com (8.12.2/8.12.2/NTAP-1.4) with ESMTP id g1EF56b7012389 for ; Thu, 14 Feb 2002 07:05:06 -0800 (PST) Received: by tahoe.corp.netapp.com with Internet Mail Service (5.5.2650.21) id <1657N0ZV>; Thu, 14 Feb 2002 06:56:32 -0800 Message-ID: <02740A3D0809D5118C7C00034707E9F3015547D5@ussvlexc10.corp.netapp.com> From: "Pittman, Joseph" To: "'ips@ece.cmu.edu'" Subject: iSCSI: cmd_sn management on rejected PDUs Date: Thu, 14 Feb 2002 07:04:14 -0800 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 I have a question about sequence number management when command PDUs are rejected. If an initiator sends a non-immediate command PDU which the target rejects, does this command consume a cmd_sn? For example, consider this case: - initiator sends a non-immediate text request with a non-zero target transfer tag, sequence number 37 - target looks up the target transfer tag, doesn't recognize it, and generates a reject/UNKNOWN_TT_TAG message Should the next command PDU sent by initiator use cmd_sn=37 or cmd_sn=38? 2 follow-up questions: IF the rejected PDU IS supposed to consume a cmd_sn, then what are the rules regarding how badly a PDU BHS may be mangled before it can be considered worthy of consuming a cmd_sn? That is, should a PDU BHS with the expected cmd_sn and I-bit == 0, but containing an otherwise random stream of bytes, consume a cmd_sn? And what if the header digest is incorrect? IF the rejected PDU is NOT supposed to consume a cmd_sn (i.e. next command PDU should be cmd_sn=37), then what is supposed to happen in the following case: - target supports command window size of 4 - initiator sends a non-immediate text request with a non-zero target transfer tag, sequence number 37 - initiator sends three more non-immediate commands with cmd_sn 38, 39, and 40 - target rejects cmd 37 In this case, cmds 38, 39, and 40 have arrived 'out of order'. Should the target wait for the initiator to 'fill the hole' by issuing some other command with cmd_sn=37? Thanks in advance for any spec interpretation or advice. -- Joe Pittman jpittman@netapp.com From owner-ips@ece.cmu.edu Thu Feb 14 13:18: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 NAA05142 for ; Thu, 14 Feb 2002 13:18:57 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1EHOms20412 for ips-outgoing; Thu, 14 Feb 2002 12:24:48 -0500 (EST) 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 g1EHOkj20407 for ; Thu, 14 Feb 2002 12:24:46 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel10.hp.com (Postfix) with ESMTP id A2555C0069E for ; Thu, 14 Feb 2002 09:24:37 -0800 (PST) Received: from rose.hp.com (hpsil34.rose.hp.com [15.43.211.225]) by core.rose.hp.com with ESMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id JAA03602 for ; Thu, 14 Feb 2002 09:26:15 -0800 (PST) Message-Id: <200202141726.JAA03602@core.rose.hp.com> Date: Thu, 14 Feb 2002 09:38:56 -0800 From: "Mallikarjun C." Reply-To: cbm@rose.hp.com Organization: Hewlett-Packard, Roseville X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.10.20 9000/715) X-Accept-Language: en MIME-Version: 1.0 To: ips Subject: [Fwd: Re: iSCSI: connection timeout mgmt - clarifications/changes] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, Please find the attached email that details the proposed text changes for rev11. Except the renaming of two text keys (details below), the proposed changes are all clarifications and corrections of current text. Hopefully, the changes would bring clarity on how to use the different connection timeouts that the draft defines. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 -------- Original Message -------- Subject: Re: timers Date: Thu, 14 Feb 2002 09:31:33 +0200 From: "Julian Satran" To: "Mallikarjun C." Excellent - Julo "Mallikarjun C." To: Julian Satran/Haifa/IBM@IBMIL 14-02-02 05:19 cc: Subject: Re: timers Julian, Here is the new text per our phone conversation today on the ERT proposal to add a new section to Error Recovery. To summarize - - LogoutLoginMaxTime & LogoutLoginMinTime are respectively renamed as DefaultTime2Retain and DefaultTime2Wait since they are no longer related to Logout per se, and also to align the names better with the Time2Wait and Time2Retain ideas - The new text for these keys makes it clear that only the implicit connection logout and the task reassignment are constrained by Time2Wait. Adding a new connection with a new CID is not constrained. - Clarified the wording in Logout Response section for Time2Wait and Time2Retain. - Added a new section in the Error Recovery chapter on usage of these different timeout values. Attached are the sections of new/changed text. Please comment, and feel free to forward to the ips list if you're in agreement. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ------------------------------------------------------------------------------------- - 12.15 DefaultTime2Wait Use: LO Senders: Initiator and Target Scope: SW DefaultTime2Wait= Default is 3. The initiator and target negotiate the minimum time, in seconds, to wait before attempting an explicit/implict logout or active task reassignment after an unexpected connection termination or a connec-tion reset. The higher of the two values is selected. A value of 0 indicates that logout or active task reassignment can be attempted immediately. 12.16 DefaultTime2Retain Use: LO Senders: Initiator and Target Scope: SW DefaultTime2Retain= Default is 3. The initiator and target negotiate the maximum time, in seconds after an initial wait (Time2Wait), before which an explicit/implicit con-nection Logout or active task reassignment is still possible after an unexpected connection termination or a connection reset. This value is also the session state timeout if the connection in question is the last LOGGED_IN connection in the session. The lesser of the two values is selected. A value of 0 indicates that connection/task state is immediately dis-carded by the target. -------------------------------------------------------------------------------- 7.3 Connection timeout management iSCSI defines two session-global timeout values (in seconds) -Time2Wait and Time2Retain - that are applicable when an iSCSI full-feature phase connection is taken out of service either intentionally or on an exception. Time2Wait is the initial "respite time" before attempting a connection reinstatement for the CID in question and/or task reassignment for the affected tasks (if any). Time2Retain is the maximum time after the initial respite interval that the task and/or connection state(s) is/are guaranteed to be maintained on the target to cater to a possible recovery attempt. 7.3.1 Timeouts on transport exception events A transport connection shutdown or a transport reset without any preceding iSCSI protocol interactions informing of the fact causes a full-feature phase iSCSI connection to be abruptly terminated. The timeout values to be used in this case are the negotiated values of DefaultTime2Wait (Appendix 12.15) and DefaultTime2Retain (Appendix 12.16) text keys for the session. 7.3.2 Timeouts on planned decommisioning Any planned decommisioning of a full-feature phase iSCSI connection is preceded by either a Logout Response PDU, or an Async MessagePDU. The Time2Wait and Time2Retain field values (section 10.15)in a Logout Response PDU, and the Parameter2 and Parameter3 fields of an Async Message (AsyncEvent types "drop the connection" or "drop all the con-nections"; section 10.9.1) specify the timeout values to be used in each case. These timeout values are applicable only for the affected connection, and the tasks active on that connection. These timeout values have no bearing on initiator timers (if any) that are already running on con-nections or tasks associated with that session. ------------------------------------------------------------------------------ 10.15.2 Time2Wait If the Logout response code is 0 and if the operational ErrorRecovery-Level is 2, this is the minimum amount of time, in seconds, to wait before attempting task reassignment. If the Logout response code is 0 and if the operational ErrorRecoveryLevel is less than 2, this field is to be ignored. This field is invalid if the Logout response code is 1. If the Logout response code is 2 or 3, this field specifies the mini-mum time to wait before attempting a new implicit or explict logout. If Time2Wait is 0, the reassignment or a new Logout may be attempted immediately. 10.15.3 Time2Retain If the Logout response code is 0 and if the operational ErrorRecovery-Level is 2, this is the maximum amount of time, in seconds, after the initial wait (Time2Wait), the target waits for the allegiance reas-signment for any active task after which the task state is discarded. If the Logout response code is 0 and if the operational ErrorRecovery-Level is less than 2, this field is to be ignored. This field is invalid if the Logout response code is 1. If the Logout response code is 2 or 3, this field specifies the maxi-mum amount of time, in seconds, after the initial wait (Time2Wait),the target waits for a new implicit or explict logout. If it is the last connection of a session, the whole session state is discarded after Time2Retain. If Time2Retain is 0, the target had already discarded the connection (and possibly the session) state along with the task states. No reas-signment or Logout is required in this case. From owner-ips@ece.cmu.edu Thu Feb 14 13:20: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 NAA05205 for ; Thu, 14 Feb 2002 13:20:24 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1EHPr220513 for ips-outgoing; Thu, 14 Feb 2002 12:25:53 -0500 (EST) 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 g1EHPoj20503 for ; Thu, 14 Feb 2002 12:25:51 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel10.hp.com (Postfix) with ESMTP id 48BC3C009A2 for ; Thu, 14 Feb 2002 09:25:45 -0800 (PST) Received: from rose.hp.com (hpsil34.rose.hp.com [15.43.211.225]) by core.rose.hp.com with ESMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id JAA03751 for ; Thu, 14 Feb 2002 09:27:24 -0800 (PST) Message-Id: <200202141727.JAA03751@core.rose.hp.com> Date: Thu, 14 Feb 2002 09:40:05 -0800 From: "Mallikarjun C." Reply-To: cbm@rose.hp.com Organization: Hewlett-Packard, Roseville X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.10.20 9000/715) X-Accept-Language: en MIME-Version: 1.0 To: ips Subject: [Fwd: Re: iSCSI: X-bit in Login] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Copying to the list.... -------- Original Message -------- Subject: Re: iSCSI: X-bit in Login Date: Thu, 14 Feb 2002 09:31:33 +0200 From: "Julian Satran" To: "Mallikarjun C." Mallikarjun, I agree with this. Julo "Mallikarjun C." To: "ips" Sent by: owner-ips@ece.cmu.edu cc: 14-02-02 01:58 Subject: iSCSI: X-bit in Login All, It seems to me that we do not need the X-bit even in the Login PDU. "Connection reinstatement"/"implicit connection logout" can be implicitly signaled by using an active ISID-TSID-CID combination to request the target to implicitly logout the connection state machine for the CID. This is conceptually nothing but the "option A" choice we made for implicit session logout sometime ago (remember the "reusing ISID for recovery" thread?), albeit at the connection level. As far as I can tell, the current X-bit in Login PDU is similar to the C-bit that we considered and rejected for "implicit" session logout. I suggest we apply the same design principle here. I propose that the draft should continue to formally define the notion of "connection reinstatement" with the existing rules on its usage, but retire the X-bit to make that bit position reserved. Leaving the X-bit in would only lead to needless error cases. Comments? -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 From owner-ips@ece.cmu.edu Thu Feb 14 14:57: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 OAA08120 for ; Thu, 14 Feb 2002 14:57:19 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1EJ0ph27600 for ips-outgoing; Thu, 14 Feb 2002 14:00:51 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from AVEXCH01.qlogic.org (216-231-2-2.qlc.com [216.231.2.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1EJ0nj27596 for ; Thu, 14 Feb 2002 14:00:49 -0500 (EST) 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: iSCSI: DataACK SNACK Date: Thu, 14 Feb 2002 11:02:39 -0800 Message-ID: Thread-Topic: iSCSI: X-bit in Login Thread-Index: AcG065Ql0wQuI7FSSEiS+PGf5ABregAkZ/AA From: "Chuck Micalizzi" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g1EJ0nj27597 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit All, I have a question regarding DataACK. Rev. 10 section 10.16.1 states: For a Data/R2T SNACK, the Initiator Task Tag MUST be set to the Initiator Task Tag of the referenced Command. Otherwise, it is reserved. it also states: The DataACK is used to free resources at the target and not to request or imply data retransmission. Is the target allowed to have more than one DataACK outstanding on a connection? If multiple outstanding DataACKs are allowed per connection then in my opinion the DataACK must have a valid task tag inorder for the target to associate the DataACK with the appropriate resources to be freed. chuck micalizzi Qlogic Corp. From owner-ips@ece.cmu.edu Thu Feb 14 18:07: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 SAA12331 for ; Thu, 14 Feb 2002 18:07:23 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1EMXUW13775 for ips-outgoing; Thu, 14 Feb 2002 17:33:30 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (IDENT:root@ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1EMXRj13769 for ; Thu, 14 Feb 2002 17:33:27 -0500 (EST) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g1EMTxn12488 for ; Thu, 14 Feb 2002 17:29:59 -0500 Message-ID: <3C6C3B36.7AD25DCF@splentec.com> Date: Thu, 14 Feb 2002 17:33:26 -0500 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: iSCSI Subject: ISCSI: [Q] connection timeout? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit If T/I gets half a PDU, what is the timeout on the active socket of the connection? What should be done after such [data read from socket] timeout? -- Luben From owner-ips@ece.cmu.edu Thu Feb 14 18:10: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 SAA12383 for ; Thu, 14 Feb 2002 18:10:56 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1EMCZX12663 for ips-outgoing; Thu, 14 Feb 2002 17:12:35 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (IDENT:root@ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1EMCXj12658 for ; Thu, 14 Feb 2002 17:12:33 -0500 (EST) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g1EM8tn12348; Thu, 14 Feb 2002 17:08:55 -0500 Message-ID: <3C6C3646.6701F71D@splentec.com> Date: Thu, 14 Feb 2002 17:12:22 -0500 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Pittman, Joseph" CC: "'ips@ece.cmu.edu'" Subject: Re: iSCSI: cmd_sn management on rejected PDUs References: <02740A3D0809D5118C7C00034707E9F3015547D5@ussvlexc10.corp.netapp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit "Pittman, Joseph" wrote: > > I have a question about sequence number management when > command PDUs are rejected. > > If an initiator sends a non-immediate command PDU which the > target rejects, does this command consume a cmd_sn? For > example, consider this case: > > - initiator sends a non-immediate text request with a > non-zero target transfer tag, sequence number 37 > - target looks up the target transfer tag, doesn't recognize > it, and generates a reject/UNKNOWN_TT_TAG message > > Should the next command PDU sent by initiator use cmd_sn=37 > or cmd_sn=38? Draft 10, pg. 28: The target iSCSI layer sets ExpCmdSN to the largest non-immediate CmdSN that it can deliver for execution plus 1 (no holes in the CmdSN sequence). Thus, if everything was normal before the initiator sent the buggy PDU w/ CmdSn 37, then ExpCmdSN at the target will not change, and be 37. Previously at the initiator ExpCmdSN was 37 (if all was ok before that), and you'd apply the rules on page 29. Let's do the last one (more general): Initiator upon recv. Rej. PDU: IF Rej. PDU ExpCmdSN (=37) < ExpCmdSN (=37) THEN Ignore ELSE ExpCmdSN = PDU ExpCmdSN ENDIF So, ExpCmdSN at the initiator is now still 37, and the next PDU the initiator will send will bear CmdSN 37. This solves the problem of cycling through CmdSN too quickly. In a large network (say company X, doing video editing), 32 bits is too small and we don't want to go through them too quickly. The above IF THEN ELSE can be optimized to <= and thus is equivalent to: IF Rej. PDU ExpCmdSN > ExpCmdSN THEN ExpCmdSN = PDU ExpCmdSN ENDIF At which point the text will have to say ``If ... less than or equal ... then it is ignored ...''. P.S. All integer comparisons are in terms of RFC1982. -- Luben From owner-ips@ece.cmu.edu Thu Feb 14 19:45: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 TAA13750 for ; Thu, 14 Feb 2002 19:45:36 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1ENrgo18623 for ips-outgoing; Thu, 14 Feb 2002 18:53:42 -0500 (EST) 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 g1ENrdj18619 for ; Thu, 14 Feb 2002 18:53:40 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel11.hp.com (Postfix) with ESMTP id 8E6A1600296 for ; Thu, 14 Feb 2002 15:53:33 -0800 (PST) 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 PAA04948 for ; Thu, 14 Feb 2002 15:55:12 -0800 (PST) Message-ID: <000d01c1b5b2$cee49ea0$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: References: <02740A3D0809D5118C7C00034707E9F3015547D5@ussvlexc10.corp.netapp.com> Subject: Re: iSCSI: cmd_sn management on rejected PDUs Date: Thu, 14 Feb 2002 15:53:31 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Joseph, Refer section 7.2 of rev10 draft for the answer to this question. Now, on to your question - >Should the target wait for the initiator to 'fill the hole' >by issuing some other command with cmd_sn=37? Generally yes - since the target treats it no different from an unreceived PDU. Specifically, the regular operational ErrorRecoveryLevel expectations apply to recover the situation you describe. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ----- Original Message ----- From: Pittman, Joseph To: 'ips@ece.cmu.edu' Sent: Thursday, February 14, 2002 7:04 AM Subject: iSCSI: cmd_sn management on rejected PDUs I have a question about sequence number management when command PDUs are rejected. If an initiator sends a non-immediate command PDU which the target rejects, does this command consume a cmd_sn? For example, consider this case: - initiator sends a non-immediate text request with a non-zero target transfer tag, sequence number 37 - target looks up the target transfer tag, doesn't recognize it, and generates a reject/UNKNOWN_TT_TAG message Should the next command PDU sent by initiator use cmd_sn=37 or cmd_sn=38? 2 follow-up questions: IF the rejected PDU IS supposed to consume a cmd_sn, then what are the rules regarding how badly a PDU BHS may be mangled before it can be considered worthy of consuming a cmd_sn? That is, should a PDU BHS with the expected cmd_sn and I-bit == 0, but containing an otherwise random stream of bytes, consume a cmd_sn? And what if the header digest is incorrect? IF the rejected PDU is NOT supposed to consume a cmd_sn (i.e. next command PDU should be cmd_sn=37), then what is supposed to happen in the following case: - target supports command window size of 4 - initiator sends a non-immediate text request with a non-zero target transfer tag, sequence number 37 - initiator sends three more non-immediate commands with cmd_sn 38, 39, and 40 - target rejects cmd 37 In this case, cmds 38, 39, and 40 have arrived 'out of order'. Should the target wait for the initiator to 'fill the hole' by issuing some other command with cmd_sn=37? Thanks in advance for any spec interpretation or advice. -- Joe Pittman jpittman@netapp.com From owner-ips@ece.cmu.edu Thu Feb 14 19:45: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 TAA13777 for ; Thu, 14 Feb 2002 19:45:42 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1F05JN19286 for ips-outgoing; Thu, 14 Feb 2002 19:05:19 -0500 (EST) 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 g1F05Hj19276 for ; Thu, 14 Feb 2002 19:05:17 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel9.hp.com (Postfix) with ESMTP id C52A380533F for ; Thu, 14 Feb 2002 19:05:11 -0500 (EST) 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 QAA06676 for ; Thu, 14 Feb 2002 16:06:50 -0800 (PST) Message-ID: <001301c1b5b4$6ebebfe0$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "iSCSI" References: <3C6C3B36.7AD25DCF@splentec.com> Subject: Re: ISCSI: [Q] connection timeout? Date: Thu, 14 Feb 2002 16:03:47 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Luben, iSCSI does not define the absolute timeout value to be used for assuming a transport connection timeout. That's left to implementations. Regarding your second question, the only option is to unceremoniously terminate the FFP connection. State transition description for T15 in chapter 6 of rev10 details this case. Once the connection enters the CLEANUP_WAIT as a result of this, the DefaultTime2Wait/DefaultTime2Retain timeouts come into picture. Please refer to the new proposed text that I posted to the list earlier today. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ----- Original Message ----- From: Luben Tuikov To: iSCSI Sent: Thursday, February 14, 2002 2:33 PM Subject: ISCSI: [Q] connection timeout? If T/I gets half a PDU, what is the timeout on the active socket of the connection? What should be done after such [data read from socket] timeout? -- Luben From owner-ips@ece.cmu.edu Thu Feb 14 21: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 VAA16094 for ; Thu, 14 Feb 2002 21:44:16 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1F216M25527 for ips-outgoing; Thu, 14 Feb 2002 21:01:06 -0500 (EST) 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 g1EMBlj12594 for ; Thu, 14 Feb 2002 17:11:47 -0500 (EST) Received: from io.iol.unh.edu (IDENT:rdr@localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.2/8.12.2) with ESMTP id g1EMBgUj017794; Thu, 14 Feb 2002 17:11:42 -0500 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.2/8.12.1/Submit) with ESMTP id g1EMBfpC017791; Thu, 14 Feb 2002 17:11:42 -0500 Date: Thu, 14 Feb 2002 17:11:41 -0500 (EST) From: "Robert D. Russell" To: Julian Satran cc: ips@ece.cmu.edu Subject: Re: UNH Plugfest 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: The last several days at the UNH plugfest have uncovered no major issues relating to the standard. One thing that was observed was that a number of implementations are dealing with SCSI-2 systems, because most of the world (i.e., Windows) is still based on SCSI-2. The iSCSI standard clearly references the SCSI-3 specifications. However, perhaps we should consider how iSCSI could be used with SCSI-2. In particular, there is the issue of LUNs. Some implementers are expecting some SCSI-2 CDBs to carry a LUN number in the 3 high-order bits of byte 1 in the CDB, and are not setting/using the LUN field in the iSCSI PDU. This is clearly wrong, although if both target and initiator do it, then they interoperate with each other but not with standard-conformant implementations. Of course, there may be (and probably are) additional issues (besides the LUN issue) that may arise. However, it still might be useful to warn implementers that this is an issue, and perhaps to suggest a "conversion rule" that would allow SCSI-2 to interoperate with iSCSI. One possibility for such a rule follows: If an iSCSI initiator has to send a SCSI-2 PDU containing a LUN, it should extract the LUN from the 3 high-order bits of CDB byte 1 and send that in the iSCSI LUN field (unless, of course, it has some other means of obtaining the LUN value independent of the CDB, in which case it should send that value in the iSCSI LUN field). If an iSCSI target receives a SCSI-2 PDU containing a LUN, then if the iSCSI LUN field is 0 it should extract the LUN value from the 3 high-order bits of CDB byte 1 (which in the SCSI-3 case should always be 0 anyway) and use that as the LUN value; if the iSCSI LUN field is not 0 then it should use that as the LUN value. At first glance this rule seems to allow an initiator and/or a target to interoperate with both SCSI-2 and SCSI-3 systems. Comments? Bob Russell, UNH Rod Harrison, Wind river From owner-ips@ece.cmu.edu Thu Feb 14 22:35: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 WAA17657 for ; Thu, 14 Feb 2002 22:35:20 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1F2vq528736 for ips-outgoing; Thu, 14 Feb 2002 21:57:52 -0500 (EST) 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 g1F2voj28732 for ; Thu, 14 Feb 2002 21:57:50 -0500 (EST) Received: from cceexg11.americas.cpqcorp.net (cceexg11.americas.cpqcorp.net [16.110.250.125]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 9695B39DE for ; Thu, 14 Feb 2002 20:57:41 -0600 (CST) Received: from cceexc17.americas.cpqcorp.net ([16.110.250.84]) by cceexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 14 Feb 2002 20:57:41 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: iSCSI UNH Plugfest Date: Thu, 14 Feb 2002 20:57:41 -0600 Message-ID: <78AF3C342AEAEF4BA33B35A8A15668C6019E21A6@cceexc17.americas.cpqcorp.net> Thread-Topic: UNH Plugfest Thread-Index: AcG1xQNv2JlM0xSPTmeRvn4Xw4TbtwAAal3w From: "Elliott, Robert" To: X-OriginalArrivalTime: 15 Feb 2002 02:57:41.0491 (UTC) FILETIME=[88B9AC30:01C1B5CC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g1F2vpj28733 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Although those bits are often reserved, some commands use them (e.g. SEND DIAGNOSTIC). It's not safe to guess that they contain a 3 bit LUN value. The iSCSI initiator driver should clean up the CDB as needed (your first suggestion) and keep the wire protocol clean. If it's in an OS generating old CDBs, it knows that and is best suited to fix them. Don't burden the iSCSI targets with any of this. The UNH test suite should check for compliance for this and other basic SCSI functionality, like: * initiators can send 16 byte CDBs * initiators can send 8-byte LUNs * but honor the LUN structure in SAM-2 * logical units implement all mandatory commands: * INQUIRY * REQUEST SENSE * REPORT LUNS * TEST UNIT READY * additional mandatory commands for block or stream devices * initiators handle all status codes, especially: * CHECK CONDITION * BUSY * TASK SET FULL (using recommended retry algorithm from SAM-2) * RESERVATION CONFLICT * logical units implement mandatory task management functions: * ABORT TASK * ABORT TASK SET * CLEAR TASK SET * LOGICAL UNIT RESET * logical units implement VPD pages 80h and 83h * 80h unit serial number * 83h NAA type IEEE Registered or IEEE Registered Extended * initiators don't send TARGET RESETs * initiators check the page code in the sense data * initiators use logical unit VPD data to identify logical units, not the dynamic fabric/bus address of the target --- Rob Elliott, Compaq Server Storage Robert.Elliott@compaq.com > -----Original Message----- > From: Robert D. Russell [mailto:rdr@io.iol.unh.edu] > Sent: Thursday, February 14, 2002 4:12 PM > To: Julian Satran > Cc: ips@ece.cmu.edu > Subject: Re: UNH Plugfest > > > Julian: > > The last several days at the UNH plugfest have uncovered no major > issues relating to the standard. > > One thing that was observed was that a number of implementations are > dealing with SCSI-2 systems, because most of the world (i.e., Windows) > is still based on SCSI-2. The iSCSI standard clearly references the > SCSI-3 specifications. However, perhaps we should consider how iSCSI > could be used with SCSI-2. > > In particular, there is the issue of LUNs. Some implementers are > expecting some SCSI-2 CDBs to carry a LUN number in the 3 high-order > bits of byte 1 in the CDB, and are not setting/using the LUN field > in the iSCSI PDU. This is clearly wrong, although if both target and > initiator do it, then they interoperate with each other but not with > standard-conformant implementations. > > Of course, there may be (and probably are) additional issues (besides > the LUN issue) that may arise. However, it still might be useful to > warn implementers that this is an issue, and perhaps to suggest a > "conversion rule" that would allow SCSI-2 to interoperate with iSCSI. > > One possibility for such a rule follows: > > If an iSCSI initiator has to send a SCSI-2 PDU containing a LUN, > it should extract the LUN from the 3 high-order bits of CDB byte 1 > and send that in the iSCSI LUN field (unless, of course, it has some > other means of obtaining the LUN value independent of the > CDB, in which > case it should send that value in the iSCSI LUN field). > > If an iSCSI target receives a SCSI-2 PDU containing a LUN, then if > the iSCSI LUN field is 0 it should extract the LUN value from the > 3 high-order bits of CDB byte 1 (which in the SCSI-3 case > should always > be 0 anyway) and use that as the LUN value; > if the iSCSI LUN field is not 0 then it should use that as > the LUN value. > > At first glance this rule seems to allow an initiator and/or a target > to interoperate with both SCSI-2 and SCSI-3 systems. From owner-ips@ece.cmu.edu Thu Feb 14 22:35: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 WAA17670 for ; Thu, 14 Feb 2002 22:35:33 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1F2ma028208 for ips-outgoing; Thu, 14 Feb 2002 21:48:36 -0500 (EST) 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 g1F2mYj28204 for ; Thu, 14 Feb 2002 21:48:34 -0500 (EST) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel13.hp.com (Postfix) with ESMTP id C3DDB40021B; Thu, 14 Feb 2002 18:48:28 -0800 (PST) Received: (from santoshr@localhost) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id SAA11941; Thu, 14 Feb 2002 18:48:24 -0800 (PST) From: Santosh Rao Message-Id: <200202150248.SAA11941@hpcuhe.cup.hp.com> Subject: Re: UNH Plugfest To: rdr@io.iol.unh.edu (Robert D. Russell) Date: Thu, 14 Feb 2002 18:48:23 -0800 (PST) Cc: Julian_Satran@il.ibm.com (Julian Satran), ips@ece.cmu.edu In-Reply-To: from "Robert D. Russell" at Feb 14, 2002 05:11:41 PM X-Mailer: ELM [version 2.5 PL2] 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 Bob & Rod, The LUN field in the SCSI CDB is not used in SCSI-2 devices either. It was used in SCSI-1 devices. SCSI-2 mandates the use of the IDENTIFY message (for parallel scsi) to identify the LUN for a given SCSI command. For other SCSI transports like FC, etc the LUN is encapsulated in the PDU or IU that carries the SCSI Command. (ex : FCP_CMD, iscsi scsi command pdu, SRP_CMD, etc). The SCSI LUN Addressing information for each SCSI command is conveyed from the SCSI ULP to the SCSI LLP in some per I/O control block passed down from the SCSI ULP to the SCSI LLP. (ex : scb, scsi_pkt, Srb, etc). Are there any O.S. SCSI implementations out there that do not do this and instead, send the LUN in the SCSI CDB (?). In any case, this sort of recommendation on where the LLP should get its LUN addressing information from should belong to the SCSI driver writer's guide of that O.S. and not in a protocol specification, IMHO. Regards, Santosh > > Julian: > > The last several days at the UNH plugfest have uncovered no major > issues relating to the standard. > > One thing that was observed was that a number of implementations are > dealing with SCSI-2 systems, because most of the world (i.e., Windows) > is still based on SCSI-2. The iSCSI standard clearly references the > SCSI-3 specifications. However, perhaps we should consider how iSCSI > could be used with SCSI-2. > > In particular, there is the issue of LUNs. Some implementers are > expecting some SCSI-2 CDBs to carry a LUN number in the 3 high-order > bits of byte 1 in the CDB, and are not setting/using the LUN field > in the iSCSI PDU. This is clearly wrong, although if both target and > initiator do it, then they interoperate with each other but not with > standard-conformant implementations. > > Of course, there may be (and probably are) additional issues (besides > the LUN issue) that may arise. However, it still might be useful to > warn implementers that this is an issue, and perhaps to suggest a > "conversion rule" that would allow SCSI-2 to interoperate with iSCSI. > > One possibility for such a rule follows: > > If an iSCSI initiator has to send a SCSI-2 PDU containing a LUN, > it should extract the LUN from the 3 high-order bits of CDB byte 1 > and send that in the iSCSI LUN field (unless, of course, it has some > other means of obtaining the LUN value independent of the CDB, in which > case it should send that value in the iSCSI LUN field). > > If an iSCSI target receives a SCSI-2 PDU containing a LUN, then if > the iSCSI LUN field is 0 it should extract the LUN value from the > 3 high-order bits of CDB byte 1 (which in the SCSI-3 case should always > be 0 anyway) and use that as the LUN value; > if the iSCSI LUN field is not 0 then it should use that as the LUN value. > > At first glance this rule seems to allow an initiator and/or a target > to interoperate with both SCSI-2 and SCSI-3 systems. > > Comments? > > > Bob Russell, UNH > Rod Harrison, Wind river > -- ################################## 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 Feb 15 04: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 EAA00724 for ; Fri, 15 Feb 2002 04:19:10 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1F8LR616118 for ips-outgoing; Fri, 15 Feb 2002 03:21:27 -0500 (EST) 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 g1F8LPj16110 for ; Fri, 15 Feb 2002 03:21:26 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id JAA08026 for ; Fri, 15 Feb 2002 09:21:19 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1F8Mwp81608 for ; Fri, 15 Feb 2002 09:22:58 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: UNH Plugfest X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 15 Feb 2002 10:22:54 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 15/02/2002 10:22:57, Serialize complete at 15/02/2002 10:22:57 Content-Type: multipart/alternative; boundary="=_alternative 002CDE8CC2256B61_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 002CDE8CC2256B61_= Content-Type: text/plain; charset="us-ascii" Bob, Thanks for the great work at the plugfest. As for the question at hand - I think you did see already two opinions, that I tend to agree with, that those poor souls that still rely on the the CDB LUN should fix their drivers. We tried hard to avoid having to look inside the CDB all over iSCSI (we don't even have to look inside to determine the length and that was considered too at a point) and I don't see any good reason to break this rule. Thanks, Julo "Robert D. Russell" 15-02-02 00:11 To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: UNH Plugfest Julian: The last several days at the UNH plugfest have uncovered no major issues relating to the standard. One thing that was observed was that a number of implementations are dealing with SCSI-2 systems, because most of the world (i.e., Windows) is still based on SCSI-2. The iSCSI standard clearly references the SCSI-3 specifications. However, perhaps we should consider how iSCSI could be used with SCSI-2. In particular, there is the issue of LUNs. Some implementers are expecting some SCSI-2 CDBs to carry a LUN number in the 3 high-order bits of byte 1 in the CDB, and are not setting/using the LUN field in the iSCSI PDU. This is clearly wrong, although if both target and initiator do it, then they interoperate with each other but not with standard-conformant implementations. Of course, there may be (and probably are) additional issues (besides the LUN issue) that may arise. However, it still might be useful to warn implementers that this is an issue, and perhaps to suggest a "conversion rule" that would allow SCSI-2 to interoperate with iSCSI. One possibility for such a rule follows: If an iSCSI initiator has to send a SCSI-2 PDU containing a LUN, it should extract the LUN from the 3 high-order bits of CDB byte 1 and send that in the iSCSI LUN field (unless, of course, it has some other means of obtaining the LUN value independent of the CDB, in which case it should send that value in the iSCSI LUN field). If an iSCSI target receives a SCSI-2 PDU containing a LUN, then if the iSCSI LUN field is 0 it should extract the LUN value from the 3 high-order bits of CDB byte 1 (which in the SCSI-3 case should always be 0 anyway) and use that as the LUN value; if the iSCSI LUN field is not 0 then it should use that as the LUN value. At first glance this rule seems to allow an initiator and/or a target to interoperate with both SCSI-2 and SCSI-3 systems. Comments? Bob Russell, UNH Rod Harrison, Wind river --=_alternative 002CDE8CC2256B61_= Content-Type: text/html; charset="us-ascii"
Bob,

Thanks for the great work at the plugfest.

As for the question at hand - I think you did see already two opinions, that I tend to agree with, that those poor souls that still rely on the the CDB LUN should fix their drivers.

We tried hard to avoid having to look inside the CDB all over iSCSI (we don't even have to look inside to determine the length and that was considered too at a point) and I don't see any good reason to break this rule.

Thanks,
Julo


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

15-02-02 00:11

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        Re: UNH Plugfest

       


Julian:

The last several days at the UNH plugfest have uncovered no major
issues relating to the standard.

One thing that was observed was that a number of implementations are
dealing with SCSI-2 systems, because most of the world (i.e., Windows)
is still based on SCSI-2.  The iSCSI standard clearly references the
SCSI-3 specifications.  However, perhaps we should consider how iSCSI
could be used with SCSI-2.

In particular, there is the issue of LUNs.  Some implementers are
expecting some SCSI-2 CDBs to carry a LUN number in the 3 high-order
bits of byte 1 in the CDB, and are not setting/using the LUN field
in the iSCSI PDU.  This is clearly wrong, although if both target and
initiator do it, then they interoperate with each other but not with
standard-conformant implementations.

Of course, there may be (and probably are) additional issues (besides
the LUN issue) that may arise.  However, it still might be useful to
warn implementers that this is an issue, and perhaps to suggest a
"conversion rule" that would allow SCSI-2 to interoperate with iSCSI.

One possibility for such a rule follows:

If an iSCSI initiator has to send a SCSI-2 PDU containing a LUN,
it should extract the LUN from the 3 high-order bits of CDB byte 1
and send that in the iSCSI LUN field (unless, of course, it has some
other means of obtaining the LUN value independent of the CDB, in which
case it should send that value in the iSCSI LUN field).

If an iSCSI target receives a SCSI-2 PDU containing a LUN, then if
the iSCSI LUN field is 0 it should extract the LUN value from the
3 high-order bits of CDB byte 1 (which in the SCSI-3 case should always
be 0 anyway) and use that as the LUN value;
if the iSCSI LUN field is not 0 then it should use that as the LUN value.

At first glance this rule seems to allow an initiator and/or a target
to interoperate with both SCSI-2 and SCSI-3 systems.

Comments?


Bob Russell, UNH
Rod Harrison, Wind river

--=_alternative 002CDE8CC2256B61_=-- From owner-ips@ece.cmu.edu Fri Feb 15 09: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 JAA06329 for ; Fri, 15 Feb 2002 09:19:00 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1FDXeD14961 for ips-outgoing; Fri, 15 Feb 2002 08:33:40 -0500 (EST) 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 g1FC2fj10138 for ; Fri, 15 Feb 2002 07:02:41 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02546; Fri, 15 Feb 2002 07:02:40 -0500 (EST) Message-Id: <200202151202.HAA02546@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-isns-08.txt Date: Fri, 15 Feb 2002 07:02:39 -0500 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 : Internet Storage Name Service (iSNS) Author(s) : J. Tseng, K. Gibbons et al. Filename : draft-ietf-ips-isns-08.txt Pages : 83 Date : 14-Feb-02 This document provides a generic framework centering around use of the iSNS for discovery and management of iSCSI and Fibre Channel (FCP) storage devices in an enterprise-scale IP storage network. iSNS is an application that stores iSCSI and FC device attributes and monitors their availability and reachability in an integrated IP storage network. Due to its role as a consolidated information repository, iSNS provides for more efficient and scalable management of storage devices in an IP network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-08.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-isns-08.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-isns-08.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: <20020214105830.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-isns-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-isns-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020214105830.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Fri Feb 15 09:19: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 JAA06355 for ; Fri, 15 Feb 2002 09:19:53 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1FDY3415007 for ips-outgoing; Fri, 15 Feb 2002 08:34:03 -0500 (EST) 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 g1FDSKj14624 for ; Fri, 15 Feb 2002 08:28:20 -0500 (EST) Received: from io.iol.unh.edu (IDENT:rdr@localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.2/8.12.2) with ESMTP id g1FDQBUj026269; Fri, 15 Feb 2002 08:26:11 -0500 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.2/8.12.1/Submit) with ESMTP id g1FDPvhQ026262; Fri, 15 Feb 2002 08:26:11 -0500 Date: Fri, 15 Feb 2002 08:25:57 -0500 (EST) From: "Robert D. Russell" To: Santosh Rao cc: Julian Satran , Subject: Re: UNH Plugfest In-Reply-To: <200202150248.SAA11941@hpcuhe.cup.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk > Are there any O.S. SCSI implementations out there that do not do this and > instead, send the LUN in the SCSI CDB (?). Apparently! Bob Russell From owner-ips@ece.cmu.edu Fri Feb 15 10:10: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 KAA07623 for ; Fri, 15 Feb 2002 10:10:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1FEJAb17533 for ips-outgoing; Fri, 15 Feb 2002 09:19:10 -0500 (EST) 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 g1FDdXj15341 for ; Fri, 15 Feb 2002 08:39:33 -0500 (EST) Received: from io.iol.unh.edu (IDENT:rdr@localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.2/8.12.2) with ESMTP id g1FDdRUj026961; Fri, 15 Feb 2002 08:39:27 -0500 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.2/8.12.1/Submit) with ESMTP id g1FDdRFB026958; Fri, 15 Feb 2002 08:39:27 -0500 Date: Fri, 15 Feb 2002 08:39:27 -0500 (EST) From: "Robert D. Russell" To: Julian Satran cc: ips@ece.cmu.edu Subject: Re: UNH Plugfest 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: > As for the question at hand - I think you did see already two opinions, > that I tend to agree with, that those poor souls that still rely on the > the CDB LUN should fix their drivers. > > We tried hard to avoid having to look inside the CDB all over iSCSI (we > don't even have to look inside to determine the length and that was > considered too at a point) and I don't see any good reason to break this > rule. I certainly agree that the spec does not need to be changed in any way to accommodate this. The thought was only that somewhere, perhaps in an appendix or maybe a separate document, the issue of dealing with legacy SCSI systems could be deal with so that everyone would do it the same way and thus be interoperable. But the spec as written is fine, and hopefully the operating systems still using the old SCSI specs will be upgraded in the near future (but there will always be users running older systems!) Bob Russell From owner-ips@ece.cmu.edu Fri Feb 15 10:55: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 KAA08958 for ; Fri, 15 Feb 2002 10:55:30 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1FF2S820730 for ips-outgoing; Fri, 15 Feb 2002 10:02:28 -0500 (EST) 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 g1FF2Qj20723 for ; Fri, 15 Feb 2002 10:02:26 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id <107NPHYD>; Fri, 15 Feb 2002 10:02:25 -0500 Message-ID: <25369470B6F0D41194820002B328BDD220276E@ATLOPS> From: Eddy Quicksall To: "ips@ece. cmu. edu (E-mail)" Subject: iSCSI: version 8 Date: Fri, 15 Feb 2002 10:02:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B631.C6A48CD0" 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_01C1B631.C6A48CD0 Content-Type: text/plain; charset="iso-8859-1" Is anyone going to release code to version 8? Eddy ------_=_NextPart_001_01C1B631.C6A48CD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Is anyone going to release code to version = 8?

 

=

Eddy=

------_=_NextPart_001_01C1B631.C6A48CD0-- From owner-ips@ece.cmu.edu Fri Feb 15 13:08: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 NAA14343 for ; Fri, 15 Feb 2002 13:08:14 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1FHi3203549 for ips-outgoing; Fri, 15 Feb 2002 12:44:03 -0500 (EST) 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 g1FHhwj03538 for ; Fri, 15 Feb 2002 12:43:59 -0500 (EST) Received: from london ([192.168.1.59]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id JAA19469; Fri, 15 Feb 2002 09:43:29 -0800 (PST) From: "Rod Harrison" To: "Robert D. Russell" , "Julian Satran" Cc: Subject: RE: UNH Plugfest Date: Fri, 15 Feb 2002 17:43:13 -0000 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ditto to what Bob said. This question arose because we saw implementations here at the plugfest ignoring the LUN field in the iSCSI PDUs in favour of the SCSI CDB LUN field. Clearly this is wrong but the spec doesn't say so, it is only implied because all SCSI references are to SAM-2. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Robert D. Russell Sent: Friday, February 15, 2002 1:39 PM To: Julian Satran Cc: ips@ece.cmu.edu Subject: Re: UNH Plugfest Julian: > As for the question at hand - I think you did see already two opinions, > that I tend to agree with, that those poor souls that still rely on the > the CDB LUN should fix their drivers. > > We tried hard to avoid having to look inside the CDB all over iSCSI (we > don't even have to look inside to determine the length and that was > considered too at a point) and I don't see any good reason to break this > rule. I certainly agree that the spec does not need to be changed in any way to accommodate this. The thought was only that somewhere, perhaps in an appendix or maybe a separate document, the issue of dealing with legacy SCSI systems could be deal with so that everyone would do it the same way and thus be interoperable. But the spec as written is fine, and hopefully the operating systems still using the old SCSI specs will be upgraded in the near future (but there will always be users running older systems!) Bob Russell From owner-ips@ece.cmu.edu Fri Feb 15 13:08: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 NAA14338 for ; Fri, 15 Feb 2002 13:08:09 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1FHSdw02265 for ips-outgoing; Fri, 15 Feb 2002 12:28:39 -0500 (EST) 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 g1FHSZj02253; Fri, 15 Feb 2002 12:28:36 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id SAA65892; Fri, 15 Feb 2002 18:28:26 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1FHU5p90898; Fri, 15 Feb 2002 18:30:05 +0100 To: "Chuck Micalizzi" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: DataACK SNACK X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 15 Feb 2002 19:30:00 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 15/02/2002 19:30:04, Serialize complete at 15/02/2002 19:30:04 Content-Type: multipart/alternative; boundary="=_alternative 005E4B07C2256B61_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005E4B07C2256B61_= Content-Type: text/plain; charset="us-ascii" DataACK is a "bulk ack". Answering the last (in case of several) is good enough. I fail to see your point. Julo "Chuck Micalizzi" Sent by: owner-ips@ece.cmu.edu 14-02-02 21:02 To: cc: Subject: iSCSI: DataACK SNACK All, I have a question regarding DataACK. Rev. 10 section 10.16.1 states: For a Data/R2T SNACK, the Initiator Task Tag MUST be set to the Initiator Task Tag of the referenced Command. Otherwise, it is reserved. it also states: The DataACK is used to free resources at the target and not to request or imply data retransmission. Is the target allowed to have more than one DataACK outstanding on a connection? If multiple outstanding DataACKs are allowed per connection then in my opinion the DataACK must have a valid task tag inorder for the target to associate the DataACK with the appropriate resources to be freed. chuck micalizzi Qlogic Corp. --=_alternative 005E4B07C2256B61_= Content-Type: text/html; charset="us-ascii"
DataACK is a "bulk ack". Answering the last (in case of several) is good enough.
I fail to see your point.

Julo


"Chuck Micalizzi" <chuck.micalizzi@qlogic.com>
Sent by: owner-ips@ece.cmu.edu

14-02-02 21:02

       
        To:        <ips@ece.cmu.edu>
        cc:        
        Subject:        iSCSI: DataACK SNACK

       


All,
   
   I have a question regarding DataACK.

   Rev. 10 section 10.16.1 states:

   For a Data/R2T SNACK, the Initiator Task Tag MUST be set
   to the Initiator Task Tag of the referenced Command.
   Otherwise, it is reserved.

   it also states:

   The DataACK is used to free resources at the target and
   not to request or imply data retransmission.

   Is the target allowed to have more than one DataACK
   outstanding on a connection?    

   If multiple outstanding DataACKs are allowed per connection
   then in my opinion the DataACK must have a valid task tag
   inorder for the target to associate the DataACK with the
   appropriate resources to be freed.
 

chuck micalizzi
Qlogic Corp.

--=_alternative 005E4B07C2256B61_=-- From owner-ips@ece.cmu.edu Fri Feb 15 13:10: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 NAA14421 for ; Fri, 15 Feb 2002 13:10:38 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1FHJ7d01480 for ips-outgoing; Fri, 15 Feb 2002 12:19:07 -0500 (EST) 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 g1FHJ5j01476 for ; Fri, 15 Feb 2002 12:19:05 -0500 (EST) Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel6.hp.com (Postfix) with ESMTP id 01BD2978; Fri, 15 Feb 2002 12:18:51 -0500 (EST) Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id CDCFC14F; Fri, 15 Feb 2002 12:18:40 -0500 (EST) Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2653.19) id <1D2TPPKJ>; Fri, 15 Feb 2002 12:18:40 -0500 Message-ID: <499DC368E25AD411B3F100902740AD6508E99F5F@xrose03.rose.hp.com> From: "ERICKSON,SHAWN (HP-Roseville,ex1)" To: "'Robert D. Russell'" , Santosh Rao Cc: Julian Satran , ips@ece.cmu.edu Subject: RE: UNH Plugfest Date: Fri, 15 Feb 2002 12:18:38 -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 If FC drivers have been implemented for them then a solution to the issue must exist. It is best left to the OS to fix or the HBA driver. -Shawn > -----Original Message----- > From: Robert D. Russell [mailto:rdr@io.iol.unh.edu] > Sent: Friday, February 15, 2002 5:26 AM > To: Santosh Rao > Cc: Julian Satran; ips@ece.cmu.edu > Subject: Re: UNH Plugfest > > > > > > Are there any O.S. SCSI implementations out there that do > not do this and > > instead, send the LUN in the SCSI CDB (?). > > Apparently! > > Bob Russell > From owner-ips@ece.cmu.edu Fri Feb 15 13:10: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 NAA14437 for ; Fri, 15 Feb 2002 13:10:49 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1FHHD001263 for ips-outgoing; Fri, 15 Feb 2002 12:17:13 -0500 (EST) 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 g1FHHBj01258 for ; Fri, 15 Feb 2002 12:17:11 -0500 (EST) Received: from xparelay2.corp.hp.com (xparelay2.corp.hp.com [15.58.137.112]) by palrel12.hp.com (Postfix) with ESMTP id EEBC56000B6; Fri, 15 Feb 2002 09:17:05 -0800 (PST) Received: from xpabh1.corp.hp.com (xpabh1.corp.hp.com [15.58.136.191]) by xparelay2.corp.hp.com (Postfix) with ESMTP id C28A4B7; Fri, 15 Feb 2002 09:17:00 -0800 (PST) Received: by xpabh1.corp.hp.com with Internet Mail Service (5.5.2653.19) id <17ZBB50N>; Fri, 15 Feb 2002 09:17:00 -0800 Message-ID: <499DC368E25AD411B3F100902740AD6508E99F5E@xrose03.rose.hp.com> From: "ERICKSON,SHAWN (HP-Roseville,ex1)" To: "'Elliott, Robert'" , ips@ece.cmu.edu Subject: RE: iSCSI UNH Plugfest Date: Fri, 15 Feb 2002 09:17:00 -0800 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 > -----Original Message----- > From: Elliott, Robert [mailto:Robert.Elliott@compaq.com] > Sent: Thursday, February 14, 2002 6:58 PM > To: ips@ece.cmu.edu > Subject: RE: iSCSI UNH Plugfest > > > Although those bits are often reserved, some commands use them (e.g. > SEND DIAGNOSTIC). It's not safe to guess that they contain a > 3 bit LUN > value. Correct. > The iSCSI initiator driver should clean up the CDB as needed > (your first > suggestion) and keep the wire protocol clean. If it's in an OS > generating old CDBs, it knows that and is best suited to fix them. > Don't burden the iSCSI targets with any of this. I second that! > The UNH test suite should check for compliance for this and > other basic [snip] > * logical units implement VPD pages 80h and 83h > * 80h unit serial number > * 83h NAA type IEEE Registered or IEEE Registered Extended Yes, please do. The world will be a better place for storage administrators, your customers will love you. > * initiators don't send TARGET RESETs Yes, please do. Disruptive in multi-initiator environments (which is mostly the domain of FC & iSCSI). > * initiators use logical unit VPD data to identify logical units, not > the dynamic fabric/bus address of the target YES, please do. Again your customers will love you! -Shawn > > -----Original Message----- > > From: Robert D. Russell [mailto:rdr@io.iol.unh.edu] > > Sent: Thursday, February 14, 2002 4:12 PM > > To: Julian Satran > > Cc: ips@ece.cmu.edu > > Subject: Re: UNH Plugfest > > > > > > Julian: > > > > The last several days at the UNH plugfest have uncovered no major > > issues relating to the standard. > > > > One thing that was observed was that a number of implementations are > > dealing with SCSI-2 systems, because most of the world > (i.e., Windows) > > is still based on SCSI-2. The iSCSI standard clearly references the > > SCSI-3 specifications. However, perhaps we should consider > how iSCSI > > could be used with SCSI-2. > > > > In particular, there is the issue of LUNs. Some implementers are > > expecting some SCSI-2 CDBs to carry a LUN number in the 3 high-order > > bits of byte 1 in the CDB, and are not setting/using the LUN field > > in the iSCSI PDU. This is clearly wrong, although if both > target and > > initiator do it, then they interoperate with each other but not with > > standard-conformant implementations. > > > > Of course, there may be (and probably are) additional > issues (besides > > the LUN issue) that may arise. However, it still might be useful to > > warn implementers that this is an issue, and perhaps to suggest a > > "conversion rule" that would allow SCSI-2 to interoperate > with iSCSI. > > > > One possibility for such a rule follows: > > > > If an iSCSI initiator has to send a SCSI-2 PDU containing a LUN, > > it should extract the LUN from the 3 high-order bits of CDB byte 1 > > and send that in the iSCSI LUN field (unless, of course, it has some > > other means of obtaining the LUN value independent of the > > CDB, in which > > case it should send that value in the iSCSI LUN field). > > > > If an iSCSI target receives a SCSI-2 PDU containing a LUN, then if > > the iSCSI LUN field is 0 it should extract the LUN value from the > > 3 high-order bits of CDB byte 1 (which in the SCSI-3 case > > should always > > be 0 anyway) and use that as the LUN value; > > if the iSCSI LUN field is not 0 then it should use that as > > the LUN value. > > > > At first glance this rule seems to allow an initiator > and/or a target > > to interoperate with both SCSI-2 and SCSI-3 systems. > > From owner-ips@ece.cmu.edu Fri Feb 15 14:13: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 OAA16152 for ; Fri, 15 Feb 2002 14:13:08 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1FHvP604616 for ips-outgoing; Fri, 15 Feb 2002 12:57:25 -0500 (EST) 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 g1FHvNj04608 for ; Fri, 15 Feb 2002 12:57:23 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id <107NPH6Q>; Fri, 15 Feb 2002 12:57:22 -0500 Message-ID: <25369470B6F0D41194820002B328BDD2202773@ATLOPS> From: Eddy Quicksall To: Julian Satran Cc: "ips@ece. cmu. edu (E-mail)" Subject: RE: FW: iSCSI: support value of ? Date: Fri, 15 Feb 2002 12:57:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B64A.37A65F90" 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_01C1B64A.37A65F90 Content-Type: text/plain; charset="iso-8859-1" Well, given that the initiator should know everything (unless I missed something below), what good is it other than for vendor specific? The reason I'm asking is because it seems silly to support it if it has no use. Can someone give me an example of where it is needed (other than for vendor specific). Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, February 15, 2002 12:30 PM To: Eddy Quicksall Subject: Re: FW: iSCSI: support value of ? The same value as Enquiry in SCSI. I heard no other comment than yours. Julo Eddy Quicksall 14-02-02 19:51 To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: FW: iSCSI: support value of ? I didn't see any responses on this. Is the "?" syntax of any good other than for vendor specific commands? Eddy -----Original Message----- From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] Sent: Wednesday, February 06, 2002 5:29 PM To: ips@ece. cmu. edu (E-mail) Subject: iSCSI: support value of ? Section 2.2.4 of draft 10 says: The value "?" with any key has the meaning of enquiry and should be answered with the current value or "NotUnderstood". What good is this? You should already know the answer as a result of login or text negotiations. Here are the only keys that can be used in FFP by the initiator: 1) SendTargets - we already have defined behavior for that key and those get the information anyway 2) TargetName - that is IO by initiator so he can't send that key anyway. Also, he has to already know the target. 3) TargetAlias - "this name MUST be communicated to the initiator during a Login". So that is already known. 4) InitiatorAlias - the initiator should already know his alias 5) TargetAddress - the target is the only one that can send this in a response 6) MaxRecvPDULength - this should be known from the negotiations 7) Vendor Specific - Could this be the reason? If so, lets say that so we don't have to add a lot of silly code. Or, lets say that the response to "?" can be "Reject" meaning that we don't support that syntax (currently, the definition of the "Reject value" does not fit this). Eddy ------_=_NextPart_001_01C1B64A.37A65F90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

W= ell, given that the initiator should know everything (unless I missed = something below), what good is it other than for vendor = specific?

<= ![if = !supportEmptyParas]> 

=

T= he reason I’m asking is because it seems silly to support it if it has no = use.

<= ![if !supportEmptyParas]> 

C= an someone give me an example of where it is needed (other than for vendor specific).

<= ![if = !supportEmptyParas]> 

=

E= ddy

<= ![if = !supportEmptyParas]> 

=

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, February = 15, 2002 12:30 PM
To: Eddy Quicksall
Subject: Re: FW: iSCSI: = support value of ?

 


The same value as Enquiry in = SCSI.  I heard no other comment than yours.

Julo

 

Eddy Quicksall <Eddy_Quicksall@ivivity.com> =

14-02-02 19:51 =

    =    
  =       To:        Julian = Satran/Haifa/IBM@IBMIL
  =       cc:        
  =       Subject:        FW: iSCSI: support value = of ?

      =  =



I didn't see any responses on this. Is = the "?" syntax of any good other than for vendor specific = commands? =

  =

Eddy =

  =

-----Original Message-----
From: Eddy Quicksall = [mailto:Eddy_Quicksall@ivivity.com]
Sent: Wednesday, February 06, 2002 5:29 PM
To: ips@ece. cmu. edu (E-mail)
Subject: iSCSI: support value of ?

  =

Section 2.2.4 = of draft 10 says: = =

  =

The value "?" with any key has the meaning of enquiry and should = be =

answered = with the current value or "NotUnderstood".

  =

What good is = this? =

  =

You should = already know the answer as a result of login or text = negotiations. =

  =

Here are the = only keys that can be used in FFP by the initiator:

  =

1) =       SendTargets – we already have defined behavior for that key and those get the = information anyway

2) =       TargetName – that is IO by initiator so he can't send that key anyway. Also, he has = to already know the target. =

3) =       TargetAlias –  "this name MUST be communicated to the initiator during a Login". So that is already known. =

4) =       InitiatorAlias – the initiator should already know his alias =

5) =       TargetAddress – the target is the only one that can send this in a response = =

6) =       MaxRecvPDULength – this should be known from the negotiations =

7) =       Vendor Specific – Could this be the reason? If so, lets say that so we = don't have to add a lot of silly code. Or, lets say that the response to = "?" can be "Reject" meaning that we don't support that syntax = (currently, the definition of the "Reject value" does not fit this). = =

  =

Eddy =

------_=_NextPart_001_01C1B64A.37A65F90-- From owner-ips@ece.cmu.edu Fri Feb 15 16: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 QAA19447 for ; Fri, 15 Feb 2002 16:01:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1FKLWn16403 for ips-outgoing; Fri, 15 Feb 2002 15:21:32 -0500 (EST) 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 g1FKLOj16393 for ; Fri, 15 Feb 2002 15:21:29 -0500 (EST) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel10.hp.com (Postfix) with ESMTP id D37E8C00532; Fri, 15 Feb 2002 12:21:18 -0800 (PST) Received: (from santoshr@localhost) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id MAA24157; Fri, 15 Feb 2002 12:21:13 -0800 (PST) From: Santosh Rao Message-Id: <200202152021.MAA24157@hpcuhe.cup.hp.com> Subject: Re: FW: iSCSI: support value of ? To: Eddy_Quicksall@ivivity.com (Eddy Quicksall) Date: Fri, 15 Feb 2002 12:21:13 -0800 (PST) Cc: Julian_Satran@il.ibm.com (Julian Satran), ips@ece.cmu.edu ("ips@ece. cmu. edu (E-mail)") In-Reply-To: <25369470B6F0D41194820002B328BDD2202773@ATLOPS> from "Eddy Quicksall" at Feb 15, 2002 12:57:22 PM X-Mailer: ELM [version 2.5 PL2] 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 Eddy, The '?' was originally proposed as a form of Enquiry analogous to something like a PDISC for Fibre Channel ports. However, an Enquiry is more useful if it is a scheme to query the target for all its supported capabilities, rather than its current value. A query for the current negotiated value was of some use in the older login negotiation model wherein each side independently computed the login negotiation result. In such a model, the '?' could be used by initiators to verify that its negotiation result was in-sync with that of the target. With the new login negotiation model, wherein, the target computes the result of the negotiation and sends it back to the initiator, the initiator knows the current negotiated values anyway. Hence, what is more useful is a scheme to query the target for its supported capabilities. IMO, the '?' semantics should be modified to return the target's supported capabilities and not its current negotiatied value. Regards, Santosh > > Well, given that the initiator should know everything (unless I missed > something below), what good is it other than for vendor specific? > > The reason I'm asking is because it seems silly to support it if it has no > use. > > Can someone give me an example of where it is needed (other than for vendor > specific). > > Eddy > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Friday, February 15, 2002 12:30 PM > To: Eddy Quicksall > Subject: Re: FW: iSCSI: support value of ? > > > The same value as Enquiry in SCSI. I heard no other comment than yours. > > Julo > > > > > Eddy Quicksall > 14-02-02 19:51 > > To: Julian Satran/Haifa/IBM@IBMIL > cc: > Subject: FW: iSCSI: support value of ? > > > > > I didn't see any responses on this. Is the "?" syntax of any good other than > for vendor specific commands? > > Eddy > > -----Original Message----- > From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] > Sent: Wednesday, February 06, 2002 5:29 PM > To: ips@ece. cmu. edu (E-mail) > Subject: iSCSI: support value of ? > > Section 2.2.4 of draft 10 says: > > The value "?" with any key has the meaning of enquiry and should be > answered with the current value or "NotUnderstood". > > What good is this? > > You should already know the answer as a result of login or text > negotiations. > > Here are the only keys that can be used in FFP by the initiator: > > 1) SendTargets - we already have defined behavior for that key and > those get the information anyway > 2) TargetName - that is IO by initiator so he can't send that key > anyway. Also, he has to already know the target. > 3) TargetAlias - "this name MUST be communicated to the initiator > during a Login". So that is already known. > 4) InitiatorAlias - the initiator should already know his alias > 5) TargetAddress - the target is the only one that can send this in a > response > 6) MaxRecvPDULength - this should be known from the negotiations > 7) Vendor Specific - Could this be the reason? If so, lets say that so > we don't have to add a lot of silly code. Or, lets say that the response to > "?" can be "Reject" meaning that we don't support that syntax (currently, > the definition of the "Reject value" does not fit this). > > Eddy > > ------_=_NextPart_001_01C1B64A.37A65F90 > Content-Type: text/html; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > xmlns=3D"http://www.w3.org/TR/REC-html40"> > > > charset=3Diso-8859-1"> > > > > > > > > > > > > >
> >

color=3Dnavy face=3DArial> style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>W= > ell, > given that the initiator should know everything (unless I missed = > something > below), what good is it other than for vendor = > specific?

> >

color=3Dnavy face=3DArial> style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><= > ![if = > !supportEmptyParas]> 

= > > >

color=3Dnavy face=3DArial> style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>T= > he reason > I’m asking is because it seems silly to support it if it has no = > use.

> >

color=3Dnavy face=3DArial> style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><= > ![if !supportEmptyParas]>  >

> >

color=3Dnavy face=3DArial> style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>C= > an > someone give me an example of where it is needed (other than for vendor > specific).

> >

color=3Dnavy face=3DArial> style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><= > ![if = > !supportEmptyParas]> 

= > > >

color=3Dnavy face=3DArial> style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>E= > ddy

> >

color=3Dnavy face=3DArial> style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><= > ![if = > !supportEmptyParas]> 

= > > >

color=3Dblack > face=3DTahoma> style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original > Message-----
> From: Julian Satran > [mailto:Julian_Satran@il.ibm.com]
> Sent: Friday, February = > 15, 2002 > 12:30 PM
> To: Eddy Quicksall
> Subject: Re: FW: iSCSI: = > support > value of ?

> >

face=3D"Times New Roman"> style=3D'font-size:12.0pt'> !supportEmptyParas]> 

> >

style=3D'mso-margin-top-alt:0in;margin-right:0in;margin-bottom: > 12.0pt;margin-left:.5in'> Roman"> style=3D'font-size:12.0pt;color:black'>
> style=3D'font-size: > 10.0pt;font-family:sans-serif;color:black'>The same value as Enquiry in = > SCSI.  I > heard no other comment than yours. color=3Dblack> style=3D'color:black'>
>
> style=3D'font-size: > 10.0pt;font-family:sans-serif;color:black'>Julo color=3Dblack> style=3D'color:black'>
>
style=3D'mso-special-character:line-break'> > style=3D'color:black;mso-color-alt: > windowtext'>

> > style=3D'width:100.0%;mso-cellspacing: > 1.5pt;margin-left:.5in'> > > > > > >
>

  size=3D3 > color=3Dblack face=3D"Times New Roman"> style=3D'font-size:12.0pt;color:black; > mso-color-alt:windowtext'>

> 		>

face=3Dsans-serif> = > style=3D'font-size:7.5pt;font-family:sans-serif;color:black;font-weight:= > bold'>Eddy > Quicksall <Eddy_Quicksall@ivivity.com> color=3Dblack> color=3Dblack> = > style=3D'color:black;mso-color-alt:windowtext'>= >

>

style=3D'font-size:7.5pt; > font-family:sans-serif;color:black'>14-02-02 19:51 color=3Dblack> color=3Dblack> = > style=3D'color:black;mso-color-alt:windowtext'>= >

> 		>

style=3D'font-size:7.5pt;font-family:Arial;color:black'>    = >   >   style=3D'color:black'>
> style=3D'font-size:7.5pt;font-family:sans-serif;color:black'>  = >     >   To:        Julian = > Satran/Haifa/IBM@IBMIL color=3Dblack>
> style=3D'font-size:7.5pt;font-family:sans-serif;color:black'>  = >     >   cc:         color=3Dblack> style=3D'color:black'>
> style=3D'font-size:7.5pt;font-family:sans-serif;color:black'>  = >     >   Subject:        FW: iSCSI: support value = > of ? color=3Dblack>
>
> style=3D'font-size: > 7.5pt;font-family:Arial;color:black'>      = >   color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

>
> >

color=3Dblack > face=3D"Times New Roman"> style=3D'font-size:12.0pt;color:black'>
>
> style=3D'font-size:10.0pt; > font-family:Arial;color:navy'>I didn't see any responses on this. Is = > the > "?" syntax of any good other than for vendor specific = > commands? color=3Dblack> color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:navy'>  ont> color=3Dblack> color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Eddy t> color=3Dblack> color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:navy'>  ont> color=3Dblack> color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DTahoma> style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original > Message-----
> From: Eddy Quicksall = > [mailto:Eddy_Quicksall@ivivity.com] style=3D'font-weight:bold'>
> Sent: Wednesday, February 06, 2002 5:29 PM style=3D'font-weight: > bold'>
> To: ips@ece. cmu. edu (E-mail) style=3D'font-weight:bold'>
> Subject: iSCSI: support value of ? color=3Dblack> style=3D'color:black'> style=3D'color:black; > mso-color-alt:windowtext'>

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>  font> color=3Dblack> color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>Section 2.2.4 = > of draft > 10 says: = > color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>  font> color=3Dblack> color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DCourier> style=3D'font-size:12.0pt;font-family:Courier;color:black'>The value > "?" with any key has the meaning of enquiry and should = > be color=3Dblack> color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DCourier> style=3D'font-size:12.0pt;font-family:Courier;color:black'>answered = > with the > current value or "NotUnderstood". color=3Dblack> style=3D'color:black'> style=3D'color:black; > mso-color-alt:windowtext'>

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>  font> color=3Dblack> color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>What good is = > this? color=3Dblack> color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>  font> color=3Dblack> color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>You should = > already know > the answer as a result of login or text = > negotiations. color=3Dblack> color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>  font> color=3Dblack> color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>Here are the = > only keys > that can be used in FFP by the initiator: color=3Dblack> style=3D'color:black'> style=3D'color:black; > mso-color-alt:windowtext'>

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>  font> color=3Dblack> color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>1) > size=3D1 color=3Dblack> = >     >   style=3D'color:black'>SendTargets – > we already have defined behavior for that key and those get the = > information > anyway style=3D'color:black;mso-color-alt: > windowtext'>

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>2) > size=3D1 color=3Dblack> = >     >   style=3D'color:black'>TargetName – > that is IO by initiator so he can't send that key anyway. Also, he has = > to > already know the target. style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>3) > size=3D1 color=3Dblack> = >     >   style=3D'color:black'>TargetAlias – >  "this name MUST be communicated to the initiator during a > Login". So that is already known. color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>4) > size=3D1 color=3Dblack> = >     >   style=3D'color:black'>InitiatorAlias > – the initiator should already know his alias color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>5) > size=3D1 color=3Dblack> = >     >   style=3D'color:black'>TargetAddress > – the target is the only one that can send this in a response = > color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>6) > size=3D1 color=3Dblack> = >     >   style=3D'color:black'>MaxRecvPDULength > – this should be known from the negotiations color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>7) > size=3D1 color=3Dblack> = >     >   style=3D'color:black'>Vendor > Specific – Could this be the reason? If so, lets say that so we = > don't have to > add a lot of silly code. Or, lets say that the response to = > "?" can be > "Reject" meaning that we don't support that syntax = > (currently, the > definition of the "Reject value" does not fit this). = > color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>  font> color=3Dblack> color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>Eddy nt> color=3Dblack> color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >
> > > > > > ------_=_NextPart_001_01C1B64A.37A65F90-- > -- ################################## 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 Feb 15 16:04: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 QAA19543 for ; Fri, 15 Feb 2002 16:04:50 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1FKA7k15518 for ips-outgoing; Fri, 15 Feb 2002 15:10:07 -0500 (EST) 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 g1FKA5j15508 for ; Fri, 15 Feb 2002 15:10:05 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel9.hp.com (Postfix) with ESMTP id 15A028050EB for ; Fri, 15 Feb 2002 15:09:49 -0500 (EST) Received: from rose.hp.com (hpsil34.rose.hp.com [15.43.211.225]) by core.rose.hp.com with ESMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id MAA10086 for ; Fri, 15 Feb 2002 12:11:28 -0800 (PST) Message-Id: <200202152011.MAA10086@core.rose.hp.com> Date: Fri, 15 Feb 2002 12:24:10 -0800 From: "Mallikarjun C." Reply-To: cbm@rose.hp.com Organization: Hewlett-Packard, Roseville X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.10.20 9000/715) X-Accept-Language: en MIME-Version: 1.0 To: ips Subject: Re: iSCSI: DataACK SNACK 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, Since the DataACK mechanism is based on DataSNs and hence per-task, I think Chuck is suggesting changing: "For a Data/R2T SNACK, the Initiator Task Tag MUST be set to the Initi- ator Task Tag of the referenced Command. Otherwise, it is reserved." to something like: "For Status SNACK, the Initiator Task Tag is reserved. In all other cases, the Initiator Task Tag field MUST be set to the Initiator Task Tag of the referenced command." I think the change is required. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Julian Satran wrote: > > DataACK is a "bulk ack". Answering the last (in case of several) is > good enough. > I fail to see your point. > > Julo > > "Chuck Micalizzi" > To: > Sent by: owner-ips@ece.cmu.edu > cc: > 14-02-02 21:02 Subject: > iSCSI: DataACK SNACK > > > > All, > > I have a question regarding DataACK. > > Rev. 10 section 10.16.1 states: > > For a Data/R2T SNACK, the Initiator Task Tag MUST be set > to the Initiator Task Tag of the referenced Command. > Otherwise, it is reserved. > > it also states: > > The DataACK is used to free resources at the target and > not to request or imply data retransmission. > > Is the target allowed to have more than one DataACK > outstanding on a connection? > > If multiple outstanding DataACKs are allowed per connection > then in my opinion the DataACK must have a valid task tag > inorder for the target to associate the DataACK with the > appropriate resources to be freed. > > > chuck micalizzi > Qlogic Corp. From owner-ips@ece.cmu.edu Fri Feb 15 17:17: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 RAA21493 for ; Fri, 15 Feb 2002 17:17:33 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1FLD7b20583 for ips-outgoing; Fri, 15 Feb 2002 16:13:07 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from AVEXCH01.qlogic.org (216-231-2-2.qlc.com [216.231.2.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1FLD3j20579 for ; Fri, 15 Feb 2002 16:13:03 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B665.C966E380" Subject: RE: iSCSI: DataACK SNACK Date: Fri, 15 Feb 2002 13:14:43 -0800 Message-ID: Thread-Topic: iSCSI: DataACK SNACK Thread-Index: AcG2RnwIRcfkHp0PRvi1brIqAU24bgAGdJCQ From: "Chuck Micalizzi" To: "Julian Satran" Cc: Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C1B665.C966E380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Julian, =20 Thank you for the response.=20 =20 Let me try to be more direct. If a target has been issued multiple read commands, with transfer counts that exceed the negotiated maxBurstSize. After the target sends a data sequence for one of = these commands must it wait for a DataACK before sending a data sequence for another command. Or is it free to send a data sequence for each = outstanding command? =20 If the target can have a data sequence in flight for each active = command then it must expect a DataACK for each sequence sent with the Acknowledge bit set. If the DataACK SNACK doesn't include a task Tag the target = can't be certain as to which data sequence the initiator is acknowledging. = So how can the target determine which resources to free or which sequence to = send next? =20 chuck =20 =20 =20 =20 =20 =20 -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, February 15, 2002 9:30 AM To: Chuck Micalizzi Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: DataACK SNACK DataACK is a "bulk ack". Answering the last (in case of several) is good = enough.=20 I fail to see your point.=20 Julo=20 "Chuck Micalizzi" =20 Sent by: owner-ips@ece.cmu.edu=20 14-02-02 21:02=20 =20 To: =20 cc: =20 Subject: iSCSI: DataACK SNACK=20 =20 All, =20 I have a question regarding DataACK. Rev. 10 section 10.16.1 states: For a Data/R2T SNACK, the Initiator Task Tag MUST be set to the Initiator Task Tag of the referenced Command. Otherwise, it is reserved. it also states: The DataACK is used to free resources at the target and=20 not to request or imply data retransmission. Is the target allowed to have more than one DataACK outstanding on a connection? =20 If multiple outstanding DataACKs are allowed per connection then in my opinion the DataACK must have a valid task tag inorder for the target to associate the DataACK with the appropriate resources to be freed. =20 chuck micalizzi Qlogic Corp. ------_=_NextPart_001_01C1B665.C966E380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Julian,
 
    Thank you for the response. =
 
    Let me try to be  more direct. If a = target has=20 been issued multiple
    read commands, with transfer counts=20 that exceed the negotiated
    maxBurstSize. After the target sends a data = sequence=20 for one of these
    commands must it wait for a DataACK before = sending a=20 data sequence
    for another command. Or is it free to = send a data=20 sequence for each outstanding
    command?
 
    If the target can have a data sequence in = flight for each=20 active command then
    it must expect a DataACK for each sequence = sent with=20 the Acknowledge
    bit set. If the DataACK SNACK doesn't include a = task Tag=20 the target can't be
    certain as to which data sequence the = initiator is=20 acknowledging.  So how can
    the target determine which resources to free or = which=20 sequence to send next?
 
chuck
 
   
 
   
 
   
-----Original Message-----
From: Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, February 15, = 2002=20 9:30 AM
To: Chuck Micalizzi
Cc: ips@ece.cmu.edu;=20 owner-ips@ece.cmu.edu
Subject: Re: iSCSI: DataACK=20 SNACK


DataACK = is a "bulk=20 ack". Answering the last (in case of several) is good enough. =
I fail to see your point. =

Julo


"Chuck Micalizzi"=20 <chuck.micalizzi@qlogic.com>
Sent by: owner-ips@ece.cmu.edu=20

14-02-02 21:02 =

        =
        To: =    =20    <ips@ece.cmu.edu>
        cc:      =20  
    =  =20   Subject:        iSCSI: DataACK = SNACK=20

     =20  


All,
   
   I have a question = regarding=20 DataACK.

   Rev. 10 section 10.16.1 = states:

 =20  For a Data/R2T SNACK, the Initiator Task Tag MUST be = set
 =20  to the Initiator Task Tag of the referenced Command.
 =20  Otherwise, it is reserved.

   it also=20 states:

   The DataACK is used to free resources at = the=20 target and
   not to request or imply data=20 retransmission.

   Is the target allowed to have more = than=20 one DataACK
   outstanding on a connection?  =20  

   If multiple outstanding DataACKs are = allowed per=20 connection
   then in my opinion the DataACK must have a = valid=20 task tag
   inorder for the target to associate the = DataACK with=20 the
   appropriate resources to be freed.
  =

chuck=20 micalizzi
Qlogic = Corp.


------_=_NextPart_001_01C1B665.C966E380-- From owner-ips@ece.cmu.edu Fri Feb 15 20:15: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 UAA24209 for ; Fri, 15 Feb 2002 20:15:36 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1G0Sm406332 for ips-outgoing; Fri, 15 Feb 2002 19:28:48 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lakemtao04.cox.net (mtao4.east.cox.net [68.1.17.241]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1G0Sjj06321 for ; Fri, 15 Feb 2002 19:28:45 -0500 (EST) Received: from CX418298C ([68.5.217.92]) by lakemtao04.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020216002841.FENG1289.lakemtao04.cox.net@CX418298C> for ; Fri, 15 Feb 2002 19:28:41 -0500 From: "Murali Rajagopal" To: Subject: FCIP: Minutes from 2-13-02 teleconference Date: Fri, 15 Feb 2002 16:28:50 -0800 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.50.4807.1700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Minutes submitted by Venkat Rangan, Rhapsody Networks Inc. Attendees: Elizabeth Rodriguez Dave Peterson Don Fraser Murali Rajagopal Bob Snively Anil Rijhsinghani Bill Krieg Venkat Rangan Agenda: 1. Last call items 2. Authors Issue Minutes: Last call items: Bill Krieg: All his changes are in the latest draft (rev 8a). Dave Peterson brought up the following issue: Link state needs to be addressed, and is likely a FC-BB-2 issue. A change in link state due to TCP Connection failure or GigE link failure should be treated by FC-BB-2 (VE_Port). This is being actively solved in FC-BB-2 framework. Author's Issue: Title page has: Ralph, Murali, Elizabeth with no company affiliation, and their roles in IPS/FCIP. Following table of contents: There is a section titled "Acknowledgements" with Contributors listed along with their contributions listed. This includes present and past future contributors. This section will be worked upon by the authors to produce the text that reflects the individual's contributors. Conference next week: May not be needed, but we will decide on Tuesday. Elizabeth to send out a note on Tuesday, to check if we need the call. From owner-ips@ece.cmu.edu Fri Feb 15 20:26: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 UAA24340 for ; Fri, 15 Feb 2002 20:26:57 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1G0SmG06333 for ips-outgoing; Fri, 15 Feb 2002 19:28:48 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1FNP7j01817 for ; Fri, 15 Feb 2002 18:25:07 -0500 (EST) Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.50 2002/02/08 23:45:02 root Exp $) with SMTP id XAA13961 for ; Fri, 15 Feb 2002 23:25:01 GMT Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.1.16) with SMTP id M2002021515300919051 ; Fri, 15 Feb 2002 15:30:09 -0800 Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id <1YPK3QWC>; Fri, 15 Feb 2002 15:25:01 -0800 Message-ID: From: "Vigil, Travis A" To: "Zamer, Ahmad" , "'Eddy_Quicksall@ivivity.com'" Cc: "'ips@ece.cmu.edu'" Subject: RE: iSCSI: version 8 Date: Fri, 15 Feb 2002 15:24:56 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B677.FA7AA670" 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_01C1B677.FA7AA670 Content-Type: text/plain; charset="iso-8859-1" Intel will release its first iSCSI HBA to support both 0.6+ and 0.8 of the iSCSI draft standard. http://www.intel.com/network/connectivity/products/iscsi/index.htm?iid=Homep age+Spot2_Head_020205& -----Original Message----- From: Zamer, Ahmad Sent: Friday, February 15, 2002 9:32 AM To: Vigil, Travis A; Zachem, Jeff Subject: FW: iSCSI: version 8 Please feel free to respond. Ahmad Zamer Intel Corporation voice: 512-407-2155 mail: ahmad.zamer@intel.com -----Original Message----- From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] Sent: Friday, February 15, 2002 9:02 AM To: ips@ece. cmu. edu (E-mail) Subject: iSCSI: version 8 Is anyone going to release code to version 8? Eddy ------_=_NextPart_001_01C1B677.FA7AA670 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Intel=20 will release its first iSCSI HBA to support both 0.6+ and 0.8 of the = iSCSI draft=20 standard.
http://www.intel.com/network/connectivity/products/iscsi/index.= htm?iid=3DHomepage+Spot2_Head_020205&
 
 -----Original=20 Message-----
From: Zamer, Ahmad
Sent: Friday, = February=20 15, 2002 9:32 AM
To: Vigil, Travis A; Zachem,=20 Jeff
Subject: FW: iSCSI: version = 8

Please=20 feel free to respond.

 

Ahmad=20 Zamer

Intel=20 Corporation

voice:=20 512-407-2155

mail:=20 ahmad.zamer@intel.com

 

-----Original=20 Message-----
From: = Eddy=20 Quicksall [mailto:Eddy_Quicksall@ivivity.com]
Sent: Friday,=20 February 15, 2002=20 9:02=20 AM
To: ips@ece. cmu. edu=20 (E-mail)
Subject: = iSCSI:=20 version 8

 

Is anyone going to release code = to version=20 8?

 

Eddy

------_=_NextPart_001_01C1B677.FA7AA670-- From owner-ips@ece.cmu.edu Sat Feb 16 01: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 BAA00059 for ; Sat, 16 Feb 2002 01:10:57 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1G5HkV22282 for ips-outgoing; Sat, 16 Feb 2002 00:17:46 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (IDENT:root@ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1G5Hej22275 for ; Sat, 16 Feb 2002 00:17:45 -0500 (EST) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g1G5E8n20325 for ; Sat, 16 Feb 2002 00:14:08 -0500 Message-ID: <3C6DEB73.F1B68989@splentec.com> Date: Sat, 16 Feb 2002 00:17:39 -0500 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: iSCSI Subject: [iSCSI][Q+RFC] login response, tsid Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit From an implementation point of view: 1. TSID is implicitly defined to be an unsigned 16-bit integer. TSID is only mentioned to be a ``tag'', ``null'', ``0'', ``1'', ``2'', ``entity'' and ``component''. [NDT] defines ISID, but not TSID. There need to be a definition of what kind of object TSID is. _That_ will define the operations which can be performed on it, not the other way around. iSCSIv10, 9.1.2 talks only about TSID namespace segregation, while a TSID object's definition is implicit. A word on TSID generation MAY be mentioned as well. 2. Login response PDU, status-class, status-detail. Wouldn't it be better to use one 16-bit unsigned integer for this information, call it ``status'' Then this ``status'' can be _logically_ split into ``class'' (8 MSb) and ``detail'' (8 LSb). But an implementation (HBA, software, etc) will use it as a 16-bit unsigned integer. Comments? -- Luben From owner-ips@ece.cmu.edu Sat Feb 16 03: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 DAA09218 for ; Sat, 16 Feb 2002 03:42:30 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1G7obY29926 for ips-outgoing; Sat, 16 Feb 2002 02:50:37 -0500 (EST) 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 g1G7oaj29922 for ; Sat, 16 Feb 2002 02:50:36 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id IAA16556; Sat, 16 Feb 2002 08:50:29 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1G7q9r75576; Sat, 16 Feb 2002 08:52:10 +0100 To: "Chuck Micalizzi" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: DataACK SNACK X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 16 Feb 2002 09:52:06 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 16/02/2002 09:52:09, Serialize complete at 16/02/2002 09:52:09 Content-Type: multipart/alternative; boundary="=_alternative 00298ED9C2256B62_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00298ED9C2256B62_= Content-Type: text/plain; charset="us-ascii" Chuck, The Initiator Task Tag is thhe only reliable indicator the protocol provides today. If nobody shouts against it we might let the target provide a Target Transfer Task for Data-In PDUs that have the A bit set to be returned with the ACK for target convenience. Julo "Chuck Micalizzi" 15-02-02 23:14 To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: iSCSI: DataACK SNACK Julian, Thank you for the response. Let me try to be more direct. If a target has been issued multiple read commands, with transfer counts that exceed the negotiated maxBurstSize. After the target sends a data sequence for one of these commands must it wait for a DataACK before sending a data sequence for another command. Or is it free to send a data sequence for each outstanding command? If the target can have a data sequence in flight for each active command then it must expect a DataACK for each sequence sent with the Acknowledge bit set. If the DataACK SNACK doesn't include a task Tag the target can't be certain as to which data sequence the initiator is acknowledging. So how can the target determine which resources to free or which sequence to send next? chuck -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, February 15, 2002 9:30 AM To: Chuck Micalizzi Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: DataACK SNACK DataACK is a "bulk ack". Answering the last (in case of several) is good enough. I fail to see your point. Julo "Chuck Micalizzi" Sent by: owner-ips@ece.cmu.edu 14-02-02 21:02 To: cc: Subject: iSCSI: DataACK SNACK All, I have a question regarding DataACK. Rev. 10 section 10.16.1 states: For a Data/R2T SNACK, the Initiator Task Tag MUST be set to the Initiator Task Tag of the referenced Command. Otherwise, it is reserved. it also states: The DataACK is used to free resources at the target and not to request or imply data retransmission. Is the target allowed to have more than one DataACK outstanding on a connection? If multiple outstanding DataACKs are allowed per connection then in my opinion the DataACK must have a valid task tag inorder for the target to associate the DataACK with the appropriate resources to be freed. chuck micalizzi Qlogic Corp. --=_alternative 00298ED9C2256B62_= Content-Type: text/html; charset="us-ascii"
Chuck,

The Initiator Task Tag is thhe only reliable indicator the protocol provides today.
If nobody shouts against it we might let the target provide a Target Transfer Task for Data-In PDUs that have the A bit set
to be returned with the ACK for target convenience.

Julo




"Chuck Micalizzi" <chuck.micalizzi@qlogic.com>

15-02-02 23:14

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        <ips@ece.cmu.edu>
        Subject:        RE: iSCSI: DataACK SNACK

       


Julian,
 
    Thank you for the response.
 
    Let me try to be  more direct. If a target has been issued multiple
    read commands, with transfer counts that exceed the negotiated
    maxBurstSize. After the target sends a data sequence for one of these
    commands must it wait for a DataACK before sending a data sequence
    for another command. Or is it free to send a data sequence for each outstanding
    command?
 
    If the target can have a data sequence in flight for each active command then
    it must expect a DataACK for each sequence sent with the Acknowledge
    bit set. If the DataACK SNACK doesn't include a task Tag the target can't be
    certain as to which data sequence the initiator is acknowledging.  So how can
    the target determine which resources to free or which sequence to send next?
 
chuck
 
   
 
   
 
   
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, February 15, 2002 9:30 AM
To: Chuck Micalizzi
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iSCSI: DataACK SNACK

DataACK is a "bulk ack". Answering the last (in case of several) is good enough.
I fail to see your point.

Julo

"Chuck Micalizzi" <chuck.micalizzi@qlogic.com>
Sent by: owner-ips@ece.cmu.edu

14-02-02 21:02

       
       To:        <ips@ece.cmu.edu>
       cc:        
       Subject:        iSCSI: DataACK SNACK

     



All,
 
  I have a question regarding DataACK.

  Rev. 10 section 10.16.1 states:

  For a Data/R2T SNACK, the Initiator Task Tag MUST be set
  to the Initiator Task Tag of the referenced Command.
  Otherwise, it is reserved.

  it also states:

  The DataACK is used to free resources at the target and
  not to request or imply data retransmission.

  Is the target allowed to have more than one DataACK
  outstanding on a connection?    

  If multiple outstanding DataACKs are allowed per connection
  then in my opinion the DataACK must have a valid task tag
  inorder for the target to associate the DataACK with the
  appropriate resources to be freed.
 

chuck micalizzi
Qlogic Corp.

--=_alternative 00298ED9C2256B62_=-- From owner-ips@ece.cmu.edu Sat Feb 16 13:31: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 NAA15187 for ; Sat, 16 Feb 2002 13:31:07 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1GHsib12149 for ips-outgoing; Sat, 16 Feb 2002 12:54:44 -0500 (EST) 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 g1GHsgj12142 for ; Sat, 16 Feb 2002 12:54:43 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id <107NP2FD>; Sat, 16 Feb 2002 12:54:40 -0500 Message-ID: <25369470B6F0D41194820002B328BDD2202784@ATLOPS> From: Eddy Quicksall To: Santosh Rao Cc: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: FW: iSCSI: support value of ? Date: Sat, 16 Feb 2002 12:54:39 -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 Santosh, Thanks for your response. I agree with you. However, if we don't want to go to that extent at this late date, can we just say it is used for vendor specific keys only? Eddy -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Friday, February 15, 2002 3:21 PM To: Eddy_Quicksall@ivivity.com Cc: Julian_Satran@il.ibm.com; ips@ece.cmu.edu Subject: Re: FW: iSCSI: support value of ? Eddy, The '?' was originally proposed as a form of Enquiry analogous to something like a PDISC for Fibre Channel ports. However, an Enquiry is more useful if it is a scheme to query the target for all its supported capabilities, rather than its current value. A query for the current negotiated value was of some use in the older login negotiation model wherein each side independently computed the login negotiation result. In such a model, the '?' could be used by initiators to verify that its negotiation result was in-sync with that of the target. With the new login negotiation model, wherein, the target computes the result of the negotiation and sends it back to the initiator, the initiator knows the current negotiated values anyway. Hence, what is more useful is a scheme to query the target for its supported capabilities. IMO, the '?' semantics should be modified to return the target's supported capabilities and not its current negotiatied value. Regards, Santosh > > Well, given that the initiator should know everything (unless I missed > something below), what good is it other than for vendor specific? > > The reason I'm asking is because it seems silly to support it if it has no > use. > > Can someone give me an example of where it is needed (other than for vendor > specific). > > Eddy > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Friday, February 15, 2002 12:30 PM > To: Eddy Quicksall > Subject: Re: FW: iSCSI: support value of ? > > > The same value as Enquiry in SCSI. I heard no other comment than yours. > > Julo > > > > > Eddy Quicksall > 14-02-02 19:51 > > To: Julian Satran/Haifa/IBM@IBMIL > cc: > Subject: FW: iSCSI: support value of ? > > > > > I didn't see any responses on this. Is the "?" syntax of any good other than > for vendor specific commands? > > Eddy > > -----Original Message----- > From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] > Sent: Wednesday, February 06, 2002 5:29 PM > To: ips@ece. cmu. edu (E-mail) > Subject: iSCSI: support value of ? > > Section 2.2.4 of draft 10 says: > > The value "?" with any key has the meaning of enquiry and should be > answered with the current value or "NotUnderstood". > > What good is this? > > You should already know the answer as a result of login or text > negotiations. > > Here are the only keys that can be used in FFP by the initiator: > > 1) SendTargets - we already have defined behavior for that key and > those get the information anyway > 2) TargetName - that is IO by initiator so he can't send that key > anyway. Also, he has to already know the target. > 3) TargetAlias - "this name MUST be communicated to the initiator > during a Login". So that is already known. > 4) InitiatorAlias - the initiator should already know his alias > 5) TargetAddress - the target is the only one that can send this in a > response > 6) MaxRecvPDULength - this should be known from the negotiations > 7) Vendor Specific - Could this be the reason? If so, lets say that so > we don't have to add a lot of silly code. Or, lets say that the response to > "?" can be "Reject" meaning that we don't support that syntax (currently, > the definition of the "Reject value" does not fit this). > > Eddy > > ------_=_NextPart_001_01C1B64A.37A65F90 > Content-Type: text/html; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > xmlns=3D"http://www.w3.org/TR/REC-html40"> > > > charset=3Diso-8859-1"> > > > > > > > > > > > > >
> >

color=3Dnavy face=3DArial> style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>W= > ell, > given that the initiator should know everything (unless I missed = > something > below), what good is it other than for vendor = > specific?

> >

color=3Dnavy face=3DArial> style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><= > ![if = > !supportEmptyParas]> 

= > > >

color=3Dnavy face=3DArial> style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>T= > he reason > I’m asking is because it seems silly to support it if it has no = > use.

> >

color=3Dnavy face=3DArial> style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><= > ![if !supportEmptyParas]>  >

> >

color=3Dnavy face=3DArial> style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>C= > an > someone give me an example of where it is needed (other than for vendor > specific).

> >

color=3Dnavy face=3DArial> style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><= > ![if = > !supportEmptyParas]> 

= > > >

color=3Dnavy face=3DArial> style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>E= > ddy

> >

color=3Dnavy face=3DArial> style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><= > ![if = > !supportEmptyParas]> 

= > > >

color=3Dblack > face=3DTahoma> style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original > Message-----
> From: Julian Satran > [mailto:Julian_Satran@il.ibm.com]
> Sent: Friday, February = > 15, 2002 > 12:30 PM
> To: Eddy Quicksall
> Subject: Re: FW: iSCSI: = > support > value of ?

> >

face=3D"Times New Roman"> style=3D'font-size:12.0pt'> !supportEmptyParas]> 

> >

style=3D'mso-margin-top-alt:0in;margin-right:0in;margin-bottom: > 12.0pt;margin-left:.5in'> Roman"> style=3D'font-size:12.0pt;color:black'>
> style=3D'font-size: > 10.0pt;font-family:sans-serif;color:black'>The same value as Enquiry in = > SCSI.  I > heard no other comment than yours. color=3Dblack> style=3D'color:black'>
>
> style=3D'font-size: > 10.0pt;font-family:sans-serif;color:black'>Julo color=3Dblack> style=3D'color:black'>
>
style=3D'mso-special-character:line-break'> > style=3D'color:black;mso-color-alt: > windowtext'>

> > style=3D'width:100.0%;mso-cellspacing: > 1.5pt;margin-left:.5in'> > > > > > >
>

  size=3D3 > color=3Dblack face=3D"Times New Roman"> style=3D'font-size:12.0pt;color:black; > mso-color-alt:windowtext'>

> 		>

face=3Dsans-serif> = > style=3D'font-size:7.5pt;font-family:sans-serif;color:black;font-weight:= > bold'>Eddy > Quicksall <Eddy_Quicksall@ivivity.com> color=3Dblack> color=3Dblack> = > style=3D'color:black;mso-color-alt:windowtext'>= >

>

style=3D'font-size:7.5pt; > font-family:sans-serif;color:black'>14-02-02 19:51 color=3Dblack> color=3Dblack> = > style=3D'color:black;mso-color-alt:windowtext'>= >

> 		>

style=3D'font-size:7.5pt;font-family:Arial;color:black'>    = >   >   style=3D'color:black'>
> style=3D'font-size:7.5pt;font-family:sans-serif;color:black'>  = >     >   To:        Julian = > Satran/Haifa/IBM@IBMIL color=3Dblack>
> style=3D'font-size:7.5pt;font-family:sans-serif;color:black'>  = >     >   cc:         color=3Dblack> style=3D'color:black'>
> style=3D'font-size:7.5pt;font-family:sans-serif;color:black'>  = >     >   Subject:        FW: iSCSI: support value = > of ? color=3Dblack>
>
> style=3D'font-size: > 7.5pt;font-family:Arial;color:black'>      = >   color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

>
> >

color=3Dblack > face=3D"Times New Roman"> style=3D'font-size:12.0pt;color:black'>
>
> style=3D'font-size:10.0pt; > font-family:Arial;color:navy'>I didn't see any responses on this. Is = > the > "?" syntax of any good other than for vendor specific = > commands? color=3Dblack> color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:navy'>  ont> color=3Dblack> color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Eddy t> color=3Dblack> color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:navy'>  ont> color=3Dblack> color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DTahoma> style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original > Message-----
> From: Eddy Quicksall = > [mailto:Eddy_Quicksall@ivivity.com] style=3D'font-weight:bold'>
> Sent: Wednesday, February 06, 2002 5:29 PM style=3D'font-weight: > bold'>
> To: ips@ece. cmu. edu (E-mail) style=3D'font-weight:bold'>
> Subject: iSCSI: support value of ? color=3Dblack> style=3D'color:black'> style=3D'color:black; > mso-color-alt:windowtext'>

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>  font> color=3Dblack> color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>Section 2.2.4 = > of draft > 10 says: = > color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>  font> color=3Dblack> color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DCourier> style=3D'font-size:12.0pt;font-family:Courier;color:black'>The value > "?" with any key has the meaning of enquiry and should = > be color=3Dblack> color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DCourier> style=3D'font-size:12.0pt;font-family:Courier;color:black'>answered = > with the > current value or "NotUnderstood". color=3Dblack> style=3D'color:black'> style=3D'color:black; > mso-color-alt:windowtext'>

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>  font> color=3Dblack> color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>What good is = > this? color=3Dblack> color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>  font> color=3Dblack> color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>You should = > already know > the answer as a result of login or text = > negotiations. color=3Dblack> color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>  font> color=3Dblack> color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>Here are the = > only keys > that can be used in FFP by the initiator: color=3Dblack> style=3D'color:black'> style=3D'color:black; > mso-color-alt:windowtext'>

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>  font> color=3Dblack> color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>1) > size=3D1 color=3Dblack> = >     >   style=3D'color:black'>SendTargets – > we already have defined behavior for that key and those get the = > information > anyway style=3D'color:black;mso-color-alt: > windowtext'>

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>2) > size=3D1 color=3Dblack> = >     >   style=3D'color:black'>TargetName – > that is IO by initiator so he can't send that key anyway. Also, he has = > to > already know the target. style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>3) > size=3D1 color=3Dblack> = >     >   style=3D'color:black'>TargetAlias – >  "this name MUST be communicated to the initiator during a > Login". So that is already known. color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>4) > size=3D1 color=3Dblack> = >     >   style=3D'color:black'>InitiatorAlias > – the initiator should already know his alias color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>5) > size=3D1 color=3Dblack> = >     >   style=3D'color:black'>TargetAddress > – the target is the only one that can send this in a response = > color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>6) > size=3D1 color=3Dblack> = >     >   style=3D'color:black'>MaxRecvPDULength > – this should be known from the negotiations color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>7) > size=3D1 color=3Dblack> = >     >   style=3D'color:black'>Vendor > Specific – Could this be the reason? If so, lets say that so we = > don't have to > add a lot of silly code. Or, lets say that the response to = > "?" can be > "Reject" meaning that we don't support that syntax = > (currently, the > definition of the "Reject value" does not fit this). = > color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>  font> color=3Dblack> color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >

face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:black'>Eddy nt> color=3Dblack> color=3Dblack> style=3D'color:black;mso-color-alt:windowtext'>= >

> >
> > > > > > ------_=_NextPart_001_01C1B64A.37A65F90-- > -- ################################## 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 Sat Feb 16 13:31: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 NAA15203 for ; Sat, 16 Feb 2002 13:31:48 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1GHlu811753 for ips-outgoing; Sat, 16 Feb 2002 12:47:56 -0500 (EST) 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 g1GHlsj11748 for ; Sat, 16 Feb 2002 12:47:54 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id <107NP2FB>; Sat, 16 Feb 2002 12:47:53 -0500 Message-ID: <25369470B6F0D41194820002B328BDD2202782@ATLOPS> From: Eddy Quicksall To: Julian Satran , Chuck Micalizzi , cbm@rose.hp.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK Date: Sat, 16 Feb 2002 12:47:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B712.0EC1F0D0" 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_01C1B712.0EC1F0D0 Content-Type: text/plain; charset="iso-8859-1" Because of what Chuck pointed out, my feeling is that the TTT should be provided when the A bit is set. It also makes the association faster since the ITT would require a search by the target. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, February 16, 2002 2:52 AM To: Chuck Micalizzi Cc: ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK Chuck, The Initiator Task Tag is thhe only reliable indicator the protocol provides today. If nobody shouts against it we might let the target provide a Target Transfer Task for Data-In PDUs that have the A bit set to be returned with the ACK for target convenience. Julo "Chuck Micalizzi" 15-02-02 23:14 To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: iSCSI: DataACK SNACK Julian, Thank you for the response. Let me try to be more direct. If a target has been issued multiple read commands, with transfer counts that exceed the negotiated maxBurstSize. After the target sends a data sequence for one of these commands must it wait for a DataACK before sending a data sequence for another command. Or is it free to send a data sequence for each outstanding command? If the target can have a data sequence in flight for each active command then it must expect a DataACK for each sequence sent with the Acknowledge bit set. If the DataACK SNACK doesn't include a task Tag the target can't be certain as to which data sequence the initiator is acknowledging. So how can the target determine which resources to free or which sequence to send next? chuck -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, February 15, 2002 9:30 AM To: Chuck Micalizzi Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: DataACK SNACK DataACK is a "bulk ack". Answering the last (in case of several) is good enough. I fail to see your point. Julo "Chuck Micalizzi" Sent by: owner-ips@ece.cmu.edu 14-02-02 21:02 To: cc: Subject: iSCSI: DataACK SNACK All, I have a question regarding DataACK. Rev. 10 section 10.16.1 states: For a Data/R2T SNACK, the Initiator Task Tag MUST be set to the Initiator Task Tag of the referenced Command. Otherwise, it is reserved. it also states: The DataACK is used to free resources at the target and not to request or imply data retransmission. Is the target allowed to have more than one DataACK outstanding on a connection? If multiple outstanding DataACKs are allowed per connection then in my opinion the DataACK must have a valid task tag inorder for the target to associate the DataACK with the appropriate resources to be freed. chuck micalizzi Qlogic Corp. ------_=_NextPart_001_01C1B712.0EC1F0D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

B= ecause of what Chuck pointed out, my feeling is that the TTT should be provided = when the A bit is set. It also makes the association faster since the ITT would = require a search by the target.

<= ![if = !supportEmptyParas]> 

=

E= ddy

<= ![if = !supportEmptyParas]> 

=

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, February = 16, 2002 2:52 AM
To: Chuck Micalizzi
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: = DataACK SNACK

 


Chuck,

The Initiator Task Tag is = thhe only reliable indicator the protocol provides today.
If nobody shouts against it = we might let the target provide a Target Transfer Task for Data-In PDUs that = have the A bit set =
to be returned with the ACK = for target convenience.

Julo



 

"Chuck Micalizzi" = <chuck.micalizzi@qlogic.com> =

15-02-02 23:14 =

    =    
  =       To:        Julian = Satran/Haifa/IBM@IBMIL
  =       cc:       =  <ips@ece.cmu.edu>
  =       Subject:        RE: iSCSI: DataACK = SNACK

      =  =



Julian,
 
    Thank you for the response. =
 
    Let me try to be  more = direct. If a target has been issued multiple
    read commands, with = transfer counts that exceed the negotiated
    maxBurstSize. After the = target sends a data sequence for one of these
    commands must it wait for a = DataACK before sending a data sequence
    for another command. Or is = it free to send a data sequence for each outstanding
    command?
 
    If the target = can have a data sequence in flight for each active command then
    it must expect a DataACK = for each sequence sent with the Acknowledge
    bit set. If the = DataACK SNACK doesn't include a task Tag the target can't be
    certain as to which data = sequence the initiator is acknowledging.  So how can
    the target = determine which resources to free or which sequence to send = next?
 
chuck
 
   
 
   
 
   
-----Original Message-----
From: Julian Satran = [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, February 15, 2002 9:30 AM
To: Chuck Micalizzi
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iSCSI: DataACK SNACK


DataACK is a "bulk ack". Answering the last (in case of = several) is good enough.
I fail to see your point.

Julo = =

 

"Chuck Micalizzi" = <chuck.micalizzi@qlogic.com>
Sent by: owner-ips@ece.cmu.edu

14-02-02 21:02 =

    =    
       To:       =  <ips@ece.cmu.edu>
       cc:       =  
       Subject:        iSCSI: = DataACK SNACK =

     




All,
 
  I have a question regarding DataACK.

  Rev. 10 section 10.16.1 states:

  For a Data/R2T SNACK, the Initiator Task Tag MUST be set
  to the Initiator Task Tag of the referenced Command.
  Otherwise, it is reserved.

  it also states:

  The DataACK is used to free resources at the target and
  not to request or imply data retransmission.

  Is the target allowed to have more than one DataACK
  outstanding on a connection?    

  If multiple outstanding DataACKs are allowed per connection
  then in my opinion the DataACK must have a valid task tag
  inorder for the target to associate the DataACK with the
  appropriate resources to be freed.
 

chuck micalizzi
Qlogic Corp.


------_=_NextPart_001_01C1B712.0EC1F0D0-- From owner-ips@ece.cmu.edu Sat Feb 16 13:33: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 NAA15247 for ; Sat, 16 Feb 2002 13:33:32 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1GHd1B11260 for ips-outgoing; Sat, 16 Feb 2002 12:39:01 -0500 (EST) 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 g1GH0qj08984 for ; Sat, 16 Feb 2002 12:00:52 -0500 (EST) Received: from io.iol.unh.edu (IDENT:rdr@localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.2/8.12.2) with ESMTP id g1GH0nUj023740; Sat, 16 Feb 2002 12:00:49 -0500 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.2/8.12.1/Submit) with ESMTP id g1GH0kJu023737; Sat, 16 Feb 2002 12:00:49 -0500 Date: Sat, 16 Feb 2002 12:00:46 -0500 (EST) From: "Robert D. Russell" To: Luben Tuikov cc: iSCSI Subject: Re: [iSCSI][Q+RFC] login response, tsid In-Reply-To: <3C6DEB73.F1B68989@splentec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Luben: > 2. Login response PDU, status-class, status-detail. > > Wouldn't it be better to use one 16-bit unsigned integer > for this information, call it ``status'' > > Then this ``status'' can be _logically_ split into > ``class'' (8 MSb) and ``detail'' (8 LSb). > > But an implementation (HBA, software, etc) will use > it as a 16-bit unsigned integer. > > Comments? I see no reason to combine the status class and status detail fields into 1 field if the implementation just has to split them apart again. What benefit is there to combining them? I vote against this idea. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Sat Feb 16 16:02: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 QAA16562 for ; Sat, 16 Feb 2002 16:02:58 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1GKDYp20345 for ips-outgoing; Sat, 16 Feb 2002 15:13:34 -0500 (EST) 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 g1GKDVj20337 for ; Sat, 16 Feb 2002 15:13:31 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id VAA22902; Sat, 16 Feb 2002 21:13:15 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1GKEmr40492; Sat, 16 Feb 2002 21:14:48 +0100 To: Eddy Quicksall Cc: cbm@rose.hp.com, Chuck Micalizzi , ips@ece.cmu.edu Importance: High MIME-Version: 1.0 Subject: RE: iSCSI: DataACK SNACK X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 16 Feb 2002 22:14:45 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 16/02/2002 22:14:56, Serialize complete at 16/02/2002 22:14:56 Content-Type: multipart/alternative; boundary="=_alternative 006D8B0BC2256B62_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 006D8B0BC2256B62_= Content-Type: text/plain; charset="us-ascii" I agree but let's hear arguments against if they are any. Julo Eddy Quicksall 16-02-02 19:47 To: Julian Satran/Haifa/IBM@IBMIL, Chuck Micalizzi , cbm@rose.hp.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK Because of what Chuck pointed out, my feeling is that the TTT should be provided when the A bit is set. It also makes the association faster since the ITT would require a search by the target. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, February 16, 2002 2:52 AM To: Chuck Micalizzi Cc: ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK Chuck, The Initiator Task Tag is thhe only reliable indicator the protocol provides today. If nobody shouts against it we might let the target provide a Target Transfer Task for Data-In PDUs that have the A bit set to be returned with the ACK for target convenience. Julo "Chuck Micalizzi" 15-02-02 23:14 To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: iSCSI: DataACK SNACK Julian, Thank you for the response. Let me try to be more direct. If a target has been issued multiple read commands, with transfer counts that exceed the negotiated maxBurstSize. After the target sends a data sequence for one of these commands must it wait for a DataACK before sending a data sequence for another command. Or is it free to send a data sequence for each outstanding command? If the target can have a data sequence in flight for each active command then it must expect a DataACK for each sequence sent with the Acknowledge bit set. If the DataACK SNACK doesn't include a task Tag the target can't be certain as to which data sequence the initiator is acknowledging. So how can the target determine which resources to free or which sequence to send next? chuck -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, February 15, 2002 9:30 AM To: Chuck Micalizzi Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: DataACK SNACK DataACK is a "bulk ack". Answering the last (in case of several) is good enough. I fail to see your point. Julo "Chuck Micalizzi" Sent by: owner-ips@ece.cmu.edu 14-02-02 21:02 To: cc: Subject: iSCSI: DataACK SNACK All, I have a question regarding DataACK. Rev. 10 section 10.16.1 states: For a Data/R2T SNACK, the Initiator Task Tag MUST be set to the Initiator Task Tag of the referenced Command. Otherwise, it is reserved. it also states: The DataACK is used to free resources at the target and not to request or imply data retransmission. Is the target allowed to have more than one DataACK outstanding on a connection? If multiple outstanding DataACKs are allowed per connection then in my opinion the DataACK must have a valid task tag inorder for the target to associate the DataACK with the appropriate resources to be freed. chuck micalizzi Qlogic Corp. --=_alternative 006D8B0BC2256B62_= Content-Type: text/html; charset="us-ascii"
I agree but let's hear arguments against if they are any. Julo


Eddy Quicksall <Eddy_Quicksall@ivivity.com>

16-02-02 19:47

       
        To:        Julian Satran/Haifa/IBM@IBMIL, Chuck Micalizzi <chuck.micalizzi@qlogic.com>, cbm@rose.hp.com
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: DataACK SNACK

       


Because of what Chuck pointed out, my feeling is that the TTT should be provided when the A bit is set. It also makes the association faster since the ITT would require a search by the target.

 

Eddy

 

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, February 16, 2002 2:52 AM
To: Chuck Micalizzi
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: DataACK SNACK

 


Chuck,

The Initiator Task Tag is thhe only reliable indicator the protocol provides today.
If nobody shouts against it we might let the target provide a Target Transfer Task for Data-In PDUs that have the A bit set
to be returned with the ACK for target convenience.

Julo


  "Chuck Micalizzi" <chuck.micalizzi@qlogic.com>

15-02-02 23:14

       
       To:        Julian Satran/Haifa/IBM@IBMIL
       cc:        <ips@ece.cmu.edu>
       Subject:        RE: iSCSI: DataACK SNACK

     



Julian,
 
   Thank you for the response.
 
   Let me try to be  more direct. If a target has been issued multiple
   read commands, with transfer counts that exceed the negotiated
   maxBurstSize. After the target sends a data sequence for one of these
   commands must it wait for a DataACK before sending a data sequence
   for another command. Or is it free to send a data sequence for each outstanding
   command?
 
   If the target can have a data sequence in flight for each active command then
   it must expect a DataACK for each sequence sent with the Acknowledge
   bit set. If the DataACK SNACK doesn't include a task Tag the target can't be
   certain as to which data sequence the initiator is acknowledging.  So how can
   the target determine which resources to free or which sequence to send next?
 
chuck
 
   
 
   
 
   
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, February 15, 2002 9:30 AM
To: Chuck Micalizzi
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iSCSI: DataACK SNACK


DataACK is a "bulk ack". Answering the last (in case of several) is good enough.
I fail to see your point.

Julo

  "Chuck Micalizzi" <chuck.micalizzi@qlogic.com>
Sent by: owner-ips@ece.cmu.edu

14-02-02 21:02

       
      To:        <ips@ece.cmu.edu>
      cc:        
      Subject:        iSCSI: DataACK SNACK

     




All,
 
 I have a question regarding DataACK.

 Rev. 10 section 10.16.1 states:

 For a Data/R2T SNACK, the Initiator Task Tag MUST be set
 to the Initiator Task Tag of the referenced Command.
 Otherwise, it is reserved.

 it also states:

 The DataACK is used to free resources at the target and
 not to request or imply data retransmission.

 Is the target allowed to have more than one DataACK
 outstanding on a connection?    

 If multiple outstanding DataACKs are allowed per connection
 then in my opinion the DataACK must have a valid task tag
 inorder for the target to associate the DataACK with the
 appropriate resources to be freed.


chuck micalizzi
Qlogic Corp.

--=_alternative 006D8B0BC2256B62_=-- From owner-ips@ece.cmu.edu Sat Feb 16 16:56: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 QAA16563 for ; Sat, 16 Feb 2002 16:02:58 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1GKXAN21441 for ips-outgoing; Sat, 16 Feb 2002 15:33:10 -0500 (EST) 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 g1GKX8j21432 for ; Sat, 16 Feb 2002 15:33:08 -0500 (EST) Received: from amirdesktop (dhcp62 [172.21.2.62]) by astutenetworks.com (8.11.6/8.11.2) with SMTP id g1GKVi810702; Sat, 16 Feb 2002 12:31:44 -0800 From: "Amir Shalit" To: "Eddy Quicksall" , "Julian Satran" , "Chuck Micalizzi" , Cc: Subject: RE: iSCSI: DataACK SNACK Date: Sat, 16 Feb 2002 12:31:44 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A1_01C1B6E5.E4C2C420" 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.50.4807.1700 In-Reply-To: <25369470B6F0D41194820002B328BDD2202782@ATLOPS> Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00A1_01C1B6E5.E4C2C420 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit True (unless ITT is hashed) Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Eddy Quicksall Sent: Saturday, February 16, 2002 9:48 AM To: Julian Satran; Chuck Micalizzi; cbm@rose.hp.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK Because of what Chuck pointed out, my feeling is that the TTT should be provided when the A bit is set. It also makes the association faster since the ITT would require a search by the target. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, February 16, 2002 2:52 AM To: Chuck Micalizzi Cc: ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK Chuck, The Initiator Task Tag is thhe only reliable indicator the protocol provides today. If nobody shouts against it we might let the target provide a Target Transfer Task for Data-In PDUs that have the A bit set to be returned with the ACK for target convenience. Julo "Chuck Micalizzi" 15-02-02 23:14 To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: iSCSI: DataACK SNACK Julian, Thank you for the response. Let me try to be more direct. If a target has been issued multiple read commands, with transfer counts that exceed the negotiated maxBurstSize. After the target sends a data sequence for one of these commands must it wait for a DataACK before sending a data sequence for another command. Or is it free to send a data sequence for each outstanding command? If the target can have a data sequence in flight for each active command then it must expect a DataACK for each sequence sent with the Acknowledge bit set. If the DataACK SNACK doesn't include a task Tag the target can't be certain as to which data sequence the initiator is acknowledging. So how can the target determine which resources to free or which sequence to send next? chuck -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, February 15, 2002 9:30 AM To: Chuck Micalizzi Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: DataACK SNACK DataACK is a "bulk ack". Answering the last (in case of several) is good enough. I fail to see your point. Julo "Chuck Micalizzi" Sent by: owner-ips@ece.cmu.edu 14-02-02 21:02 To: cc: Subject: iSCSI: DataACK SNACK All, I have a question regarding DataACK. Rev. 10 section 10.16.1 states: For a Data/R2T SNACK, the Initiator Task Tag MUST be set to the Initiator Task Tag of the referenced Command. Otherwise, it is reserved. it also states: The DataACK is used to free resources at the target and not to request or imply data retransmission. Is the target allowed to have more than one DataACK outstanding on a connection? If multiple outstanding DataACKs are allowed per connection then in my opinion the DataACK must have a valid task tag inorder for the target to associate the DataACK with the appropriate resources to be freed. chuck micalizzi Qlogic Corp. ------=_NextPart_000_00A1_01C1B6E5.E4C2C420 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

True=20 (unless ITT is hashed)
 
Amir
-----Original Message-----
From: = owner-ips@ece.cmu.edu=20 [mailto:owner-ips@ece.cmu.edu]On Behalf Of Eddy=20 Quicksall
Sent: Saturday, February 16, 2002 9:48 = AM
To:=20 Julian Satran; Chuck Micalizzi; cbm@rose.hp.com
Cc:=20 ips@ece.cmu.edu
Subject: RE: iSCSI: DataACK=20 SNACK

Because=20 of what Chuck pointed out, my feeling is that the TTT should be = provided when=20 the A bit is set. It also makes the association faster since the ITT = would=20 require a search by the target.

 

Eddy

 

-----Original=20 Message-----
From: = Julian=20 Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, February 16, = 2002 2:52=20 AM
To: Chuck=20 Micalizzi
Cc:=20 ips@ece.cmu.edu
Subject: RE:=20 iSCSI: DataACK SNACK

 


Chuck, =

The = Initiator=20 Task Tag is thhe only reliable indicator the protocol provides=20 today.=20
If = nobody=20 shouts against it we might let the target provide a Target Transfer = Task for=20 Data-In PDUs that have the A bit set
to=20 be returned with the ACK for target convenience. =

Julo

 

"Chuck=20 Micalizzi" = <chuck.micalizzi@qlogic.com>

15-02-02=20 23:14=20

   =20    
 =20       To:        Julian=20 Satran/Haifa/IBM@IBMIL
 =20       cc:      =20  <ips@ece.cmu.edu>
 =20       Subject:        RE: = iSCSI:=20 DataACK SNACK=20

   =20    



Julian,
  =
  =   Thank=20 you for the response.
 
 =20   Let me try to be  more direct. If a target has been issued = multiple=20
  =   read=20 commands, with transfer counts that exceed the = negotiated
  =  =20 maxBurstSize. After the target sends a data sequence for one of=20 these=20
  =  =20 commands must it wait for a DataACK before sending a data=20 sequence=20
  =   for=20 another command. Or is it free to send a data sequence for each=20 outstanding=20
  =  =20 command?
 =20
    If the = target can=20 have a data sequence in flight for each active command = then
  =   it must=20 expect a DataACK for each sequence sent with the=20 Acknowledge=20
    bit set. If = the=20 DataACK SNACK doesn't include a task Tag the target can't=20 be=20
  =   certain=20 as to which data sequence the initiator is acknowledging.  So how = can =
 =20   the target = determine=20 which resources to free or which sequence to send = next?
  =
chuck
 
  =  =20
 
   
 
  =  =20
-----Original=20 Message-----
From: = Julian=20 Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, February 15, = 2002 9:30=20 AM
To: Chuck=20 Micalizzi
Cc:=20 ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iSCSI: DataACK = SNACK


DataACK is=20 a "bulk ack". Answering the last (in case of several) is good=20 enough. =
I = fail to=20 see your point.=20

Julo

 

"Chuck=20 Micalizzi" = <chuck.micalizzi@qlogic.com>
Sent=20 by: owner-ips@ece.cmu.edu

14-02-02=20 21:02=20

   =20    
 =20      To:      =20  <ips@ece.cmu.edu>
 =20      cc:       =  
 =20      Subject:        iSCSI: = DataACK=20 SNACK=20

 =20    




All,
 =20
  I have a question regarding DataACK.

  Rev. 10 = section=20 10.16.1 states:

  For a Data/R2T SNACK, the Initiator Task = Tag=20 MUST be set
  to the Initiator Task Tag of the referenced=20 Command.
  Otherwise, it is reserved.

  it also=20 states:

  The DataACK is used to free resources at the = target and=20
  not to request or imply data retransmission.

  = Is the=20 target allowed to have more than one DataACK
  outstanding on = a=20 connection?    

  If multiple outstanding = DataACKs are=20 allowed per connection
  then in my opinion the DataACK must = have a=20 valid task tag
  inorder for the target to associate the = DataACK with=20 the
  appropriate resources to be = freed.
 

chuck=20 micalizzi
Qlogic Corp.

------=_NextPart_000_00A1_01C1B6E5.E4C2C420-- From owner-ips@ece.cmu.edu Sun Feb 17 02:38: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 CAA02572 for ; Sun, 17 Feb 2002 02:38:33 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1H6iNd25487 for ips-outgoing; Sun, 17 Feb 2002 01:44:23 -0500 (EST) 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 g1H6iKj25482 for ; Sun, 17 Feb 2002 01:44:20 -0500 (EST) Received: from london ([147.11.45.213]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id WAA17957; Sat, 16 Feb 2002 22:43:29 -0800 (PST) From: "Rod Harrison" To: "Julian Satran" , "Eddy Quicksall" Cc: , "Chuck Micalizzi" , Subject: RE: iSCSI: DataACK SNACK Date: Sun, 17 Feb 2002 06:43:16 -0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C1B77E.61337890" 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.00.2314.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C1B77E.61337890 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit No objections here. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Saturday, February 16, 2002 8:15 PM To: Eddy Quicksall Cc: cbm@rose.hp.com; Chuck Micalizzi; ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK Importance: High I agree but let's hear arguments against if they are any. Julo Eddy Quicksall 16-02-02 19:47 To: Julian Satran/Haifa/IBM@IBMIL, Chuck Micalizzi , cbm@rose.hp.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK Because of what Chuck pointed out, my feeling is that the TTT should be provided when the A bit is set. It also makes the association faster since the ITT would require a search by the target. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, February 16, 2002 2:52 AM To: Chuck Micalizzi Cc: ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK Chuck, The Initiator Task Tag is thhe only reliable indicator the protocol provides today. If nobody shouts against it we might let the target provide a Target Transfer Task for Data-In PDUs that have the A bit set to be returned with the ACK for target convenience. Julo "Chuck Micalizzi" 15-02-02 23:14 To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: iSCSI: DataACK SNACK Julian, Thank you for the response. Let me try to be more direct. If a target has been issued multiple read commands, with transfer counts that exceed the negotiated maxBurstSize. After the target sends a data sequence for one of these commands must it wait for a DataACK before sending a data sequence for another command. Or is it free to send a data sequence for each outstanding command? If the target can have a data sequence in flight for each active command then it must expect a DataACK for each sequence sent with the Acknowledge bit set. If the DataACK SNACK doesn't include a task Tag the target can't be certain as to which data sequence the initiator is acknowledging. So how can the target determine which resources to free or which sequence to send next? chuck -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, February 15, 2002 9:30 AM To: Chuck Micalizzi Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: DataACK SNACK DataACK is a "bulk ack". Answering the last (in case of several) is good enough. I fail to see your point. Julo "Chuck Micalizzi" Sent by: owner-ips@ece.cmu.edu 14-02-02 21:02 To: cc: Subject: iSCSI: DataACK SNACK All, I have a question regarding DataACK. Rev. 10 section 10.16.1 states: For a Data/R2T SNACK, the Initiator Task Tag MUST be set to the Initiator Task Tag of the referenced Command. Otherwise, it is reserved. it also states: The DataACK is used to free resources at the target and not to request or imply data retransmission. Is the target allowed to have more than one DataACK outstanding on a connection? If multiple outstanding DataACKs are allowed per connection then in my opinion the DataACK must have a valid task tag inorder for the target to associate the DataACK with the appropriate resources to be freed. chuck micalizzi Qlogic Corp. ------=_NextPart_000_000E_01C1B77E.61337890 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
No=20 objections here.
 
-=20 Rod
-----Original Message-----
From: = owner-ips@ece.cmu.edu=20 [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian=20 Satran
Sent: Saturday, February 16, 2002 8:15 = PM
To: Eddy=20 Quicksall
Cc: cbm@rose.hp.com; Chuck Micalizzi;=20 ips@ece.cmu.edu
Subject: RE: iSCSI: DataACK=20 SNACK
Importance: High


I agree but let's hear arguments against if they are any. = Julo=20


Eddy Quicksall=20 <Eddy_Quicksall@ivivity.com>=20

16-02-02 19:47 =

        =
        To: =    =20    Julian Satran/Haifa/IBM@IBMIL, Chuck Micalizzi=20 <chuck.micalizzi@qlogic.com>, cbm@rose.hp.com =
        cc: =    =20    ips@ece.cmu.edu
        Subject:     =  =20  RE: iSCSI: DataACK SNACK

      =  


Because of what Chuck pointed = out, my feeling=20 is that the TTT should be provided when the A bit is set. It also = makes the=20 association faster since the ITT would require a search by the = target.=20

 =20

Eddy=20

 =20

-----Original = Message-----
From: Julian=20 Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, = February=20 16, 2002 2:52 AM
To: Chuck Micalizzi
Cc:=20 ips@ece.cmu.edu
Subject: RE: iSCSI: DataACK SNACK=20

 =20


Chuck,

The = Initiator Task Tag is=20 thhe only reliable indicator the protocol provides today.
If=20 nobody shouts against it we might let the target provide a Target = Transfer=20 Task for Data-In PDUs that have the A bit set
to be=20 returned with the ACK for target convenience.

Julo =


 =20 "Chuck = Micalizzi"=20 <chuck.micalizzi@qlogic.com>

15-02-02 23:14

      =  =20
      =  To:=20        Julian = Satran/Haifa/IBM@IBMIL
       cc:       =  <ips@ece.cmu.edu>=20
      =  Subject:        RE: iSCSI: DataACK=20 SNACK =

      =



Julian,=20
 
  =  Thank you=20 for the response.
 
 =20  Let me try to be  more direct. If a target has been issued=20 multiple
   read commands, with transfer = counts that=20 exceed the negotiated =
   maxBurstSize. = After the target=20 sends a data sequence for one of these
  =  commands=20 must it wait for a DataACK before sending a data sequence
   for another command. Or is it free to send a = data=20 sequence for each outstanding=20
 =20  command? =
 
 =20  If the target = can have a data=20 sequence in flight for each active command then
   it must expect a DataACK for each sequence = sent with=20 the Acknowledge =
 =20  bit set. If the = DataACK SNACK=20 doesn't include a task Tag the target can't be
   certain as to which data sequence the = initiator is=20 acknowledging.  So how can=20
   the = target=20 determine which resources to free or which sequence to send = next?
 
chuck=20
 
   
 
  =  
 
   
-----Original Message-----
From: Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, February 15, = 2002=20 9:30 AM
To: Chuck Micalizzi
Cc: ips@ece.cmu.edu;=20 owner-ips@ece.cmu.edu
Subject: Re: iSCSI: DataACK = SNACK


DataACK is a "bulk ack". Answering the last (in case = of=20 several) is good enough.=20
I fail to see your = point.

Julo =

 =20 "Chuck = Micalizzi"=20 <chuck.micalizzi@qlogic.com>
Sent by: owner-ips@ece.cmu.edu

14-02-02 21:02

      =  =20
      = To:  =20      <ips@ece.cmu.edu>
      cc:      =20   =
      Subject: =    =20    iSCSI: DataACK SNACK

  =  =20  




All,
 
 I have a question regarding=20 DataACK.

 Rev. 10 section 10.16.1 states:

 For = a=20 Data/R2T SNACK, the Initiator Task Tag MUST be set
 to the = Initiator=20 Task Tag of the referenced Command.
 Otherwise, it is=20 reserved.

 it also states:

 The DataACK is = used to=20 free resources at the target and
 not to request or imply = data=20 retransmission.

 Is the target allowed to have more than = one=20 DataACK
 outstanding on a connection?   =  

 If=20 multiple outstanding DataACKs are allowed per connection
 then = in my=20 opinion the DataACK must have a valid task tag
 inorder for = the target=20 to associate the DataACK with the
 appropriate resources to be = freed.


chuck micalizzi
Qlogic Corp.

------=_NextPart_000_000E_01C1B77E.61337890-- From owner-ips@ece.cmu.edu Sun Feb 17 09:35: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 JAA06341 for ; Sun, 17 Feb 2002 09:35:10 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1HDkI826306 for ips-outgoing; Sun, 17 Feb 2002 08:46:18 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from BEASLEY.il.sangate.com (Sungate-2.ser.netvision.net.il [212.143.108.74]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1HDkGj26298 for ; Sun, 17 Feb 2002 08:46:16 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: remove MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 17 Feb 2002 15:46:10 +0200 Message-ID: Thread-Topic: FCIP: Minutes from 2-13-02 teleconference Thread-Index: AcG2hMz0N7IG9AE6RDiYUjCtxzJSIwBNKPYQ From: "Roi Cohen" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g1HDkHj26302 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit remove From owner-ips@ece.cmu.edu Mon Feb 18 00:43: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 AAA18945 for ; Mon, 18 Feb 2002 00:43:50 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1I4lKw11426 for ips-outgoing; Sun, 17 Feb 2002 23:47:20 -0500 (EST) 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 g1I4lIj11422 for ; Sun, 17 Feb 2002 23:47:18 -0500 (EST) Received: from splentec.com ([24.43.3.134]) by fep03-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.04.06 201-253-122-122-106-20020109) with ESMTP id <20020218044712.ODQV5932.fep03-mail.bloor.is.net.cable.rogers.com@splentec.com> for ; Sun, 17 Feb 2002 23:47:12 -0500 Message-ID: <3C708748.46B075CB@splentec.com> Date: Sun, 17 Feb 2002 23:47:04 -0500 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: iSCSI Subject: Re: [iSCSI][Q+RFC] login response, tsid References: 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.3.134] using ID at Sun, 17 Feb 2002 23:47:12 -0500 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit "Robert D. Russell" wrote: > > Luben: > > > 2. Login response PDU, status-class, status-detail. > > > > Wouldn't it be better to use one 16-bit unsigned integer > > for this information, call it ``status'' > > > > Then this ``status'' can be _logically_ split into > > ``class'' (8 MSb) and ``detail'' (8 LSb). > > > > But an implementation (HBA, software, etc) will use > > it as a 16-bit unsigned integer. > > > > Comments? > > I see no reason to combine the status class and status detail > fields into 1 field if the implementation just has to split > them apart again. What benefit is there to combining them? > I vote against this idea. The reason was that an implementation can manipulate it easier and as the table on the next page shows it is one field. It can be fetched off the packet in just one operation and then if an interpretation is needed it can then be split __logically__ by whoever needs to know it. The table next page in the draft (pp. 151-152, v10) does seem to represent it as _one_ 16 bit number with suitable description and status. I.e. the separation is only logical and for all practical purposes IT IS one field as the table clearly shows. P.S. My suggestion is exactly what happened to the ISID field (pp. 145, 147, v10). -- Luben From owner-ips@ece.cmu.edu Mon Feb 18 11:00: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 LAA05906 for ; Mon, 18 Feb 2002 11:00:00 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1IF6FU18489 for ips-outgoing; Mon, 18 Feb 2002 10:06:15 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from erie.mcdata.com (mcjekyll.mcdata.com [144.49.6.25]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1IF6Dj18480 for ; Mon, 18 Feb 2002 10:06:13 -0500 (EST) Received: from erie.mcdata.com ([172.18.1.35]) by erie.mcdata.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DXFNMLL6; Mon, 18 Feb 2002 08:06:06 -0700 Received: from 144.49.154.169 by erie.mcdata.com (InterScan E-Mail VirusWall NT); Mon, 18 Feb 2002 08:06:05 -0700 Received: by grizzly.mcdata.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Feb 2002 10:06:00 -0500 Message-ID: <1B8A58D6C376FE4DB329408E2701384250C99E@grizzly.mcdata.com> From: Ernest Dainow To: "'Bernard Aboba'" Cc: ips@ece.cmu.edu Subject: Underlying IPSec requirements Date: Mon, 18 Feb 2002 10:05:59 -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 The IP Storage security requirements are specified in the iSCSI and FCIP draft RFCs and are repeated and elaborated in the Security paper. This is beneficial in that it provides a comprehensive summary of IPSec and it clarifies the "subset" of IPSec that is required. However, it is not clear the extent to which IPSec specifications not explicitly mentioned in the IPS Security paper must be supported. For example, IKE supports the negotiation of a lifetime for the Security Association. This can be either in seconds or kilobytes. My interpretation is that this must be supported, but other people I have talked to have not reached the same conclusion. If the intent is that IPSec requirements not specifically mentioned in the IPS drafts must be supported, a statement to this effect should be added to the documents. A clear summary of the requirements for all configurable IPsec parameters should be provided. Following is a list of these parameters. Most are well summarized; are few are not. An * indicates those that are not well covered by the IPS drafts: IPSec end points: Connection: Source IP:Port, Destination IP:Port Protocol: TCP/UDP Tunnel or Transport mode Tunnel mode: destination address for source machine *protected addresses for gateway machine IKE Negotiation options: ESP or AH ESP: acceptable hash algorithms, encryption algorithms AH: acceptable hash algorithms Authentication method: Shared secret/Certificates Action on sequence number wrap (anti-replay) Perfect Forward Secrecy *Lifetime: seconds/kilobytes *ESP padding Tunnel mode protected addresses: An important IPSec requirement is that the receiving end must check all IP packets against the security policy and drop the packet if security is required. In order to do this on a gateway machine, the machine must know which destinations behind the gateway require security and which do not. The method of specifying host addresses, subnet addresses, etc. has been an area of major interoperability problems in IPSec. ESP padding: IPSec supports the option of adding a variable amount of padding to the ESP payload, for the purposes of impeding traffic analysis by size of packets. Most IPSec implementation seem to ignore this option and do not make it available to the user. From owner-ips@ece.cmu.edu Mon Feb 18 11:33: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 LAA07719 for ; Mon, 18 Feb 2002 11:33:34 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1IFqvx21848 for ips-outgoing; Mon, 18 Feb 2002 10:52:57 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from erie.mcdata.com (mcjekyll.mcdata.com [144.49.6.25]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1IFqsj21837 for ; Mon, 18 Feb 2002 10:52:54 -0500 (EST) Received: from erie.mcdata.com ([172.18.1.35]) by erie.mcdata.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DXFNMLWG; Mon, 18 Feb 2002 08:52:47 -0700 Received: from 144.49.154.169 by erie.mcdata.com (InterScan E-Mail VirusWall NT); Mon, 18 Feb 2002 08:52:46 -0700 Received: by grizzly.mcdata.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Feb 2002 10:52:41 -0500 Message-ID: <1B8A58D6C376FE4DB329408E2701384250C99F@grizzly.mcdata.com> From: Ernest Dainow To: "'Bernard Aboba'" Cc: "'ips@ece.cmu.edu'" Subject: Separate SA for each TCP connection Date: Mon, 18 Feb 2002 10:52:41 -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 I think that the requirement that every TCP connection must have its own SA (Security Association) has a number of problems. First of all, it is difficult to enforce on the receiving side, if the sending end does not comply with this requirement and uses an existing SA for a second TCP connection. When IPSec receives a packet with a valid SPI, it cannot discover that the packet was sent on a different port number than the SA was set up for until after the security processing. To meet this requirement, extra checking must be done to compare every packet to the SPD (Security Policy Database) after security processing. If this is done, then various interoperability problems may occur when communicating with an end device that is using standard IPSec. The SPD is configured with Source IP:Port, Destination IP:Port. When an administrator configures this, the source port is not known and so a wild card is usually used. In standard IPSec implementations, this means that multiple connections to the same destination address:port will travel down the same SA. Interoperability between standard IPSec and IPS IPSec may be needed in a number of situations: 1. Using tunnel mode to connect to a storage device behind a gateway, such as a firewall (which terminates the IPSec connection). 2. Connections to an iSNS or SLP server which likely will be implemented on an industry standard OS that uses standard IPSec. 3. If the IP/IPSec stack on the IPS device is used as a TCP offload engine for traffic other than storage. Common uses might be for management such as telnet. The only reason for this requirement that I could find is in Section 5.8.3 of draft-ietf-ips-security-09.txt. "IPsec implementations that only support machine authentication typically have no way to distinguish between user traffic within the kernel. As a result, where machine authentication is used, once an Ipsec SA is opened, another user on a multi-user machine may be able to send traffic down the IPsec SA. To limit the potential vulnerability, iSCSI, iFCP or FCIP security implementations MUST negotiate a separate IPsec Phase 2 SA for each connection, with descriptors specific to that connection." This is a general feature/limitation of IPSec. IPSec by definition operates at the network layer. If application layer authentication is desired, it should be done by the application. iSCSI has the option to use SRP or other authentication methods. Proposals have been made for FCIP to provide an option for user authentication based on SRP, consistent with iSCSI, but current direction has been to favor a Fibre Channel based authentication scheme (yet to be defined). The potential interoperability problems resulting from the requirement to have a separate SA for each TCP connection is not worth the attempt to "limit" this vulnerability, when other clean ways exist to establish user authentication. Ernie Dainow From owner-ips@ece.cmu.edu Mon Feb 18 11:36: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 LAA07814 for ; Mon, 18 Feb 2002 11:36:14 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1IG6kZ22874 for ips-outgoing; Mon, 18 Feb 2002 11:06:46 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f107.pav2.hotmail.com [64.4.37.107]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1IFgdj21083 for ; Mon, 18 Feb 2002 10:42:39 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 18 Feb 2002 07:42:33 -0800 Received: from 64.38.134.103 by pv2fd.pav2.hotmail.msn.com with HTTP; Mon, 18 Feb 2002 15:42:33 GMT X-Originating-IP: [64.38.134.103] From: "Bernard Aboba" To: Ernest.Dainow@mcdata.com Cc: ips@ece.cmu.edu Subject: Re: Underlying IPSec requirements Date: Mon, 18 Feb 2002 07:42:33 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Feb 2002 15:42:33.0860 (UTC) FILETIME=[E1F2B440:01C1B892] Sender: owner-ips@ece.cmu.edu Precedence: bulk > *protected addresses for gateway machine > *Lifetime: seconds/kilobytes > *ESP padding Are you volunteering to write up suggested text for these items? We had it on a list of "things to do" but haven't gotten to it :( >The method of specifying host addresses, subnet addresses, etc. has >been >an area of major interoperability problems in IPSec. Yes, and I fear that the draft is not yet specific enough to avoid these problems in IPS usage. Care to suggest improvements? _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From owner-ips@ece.cmu.edu Mon Feb 18 12:45: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 MAA10805 for ; Mon, 18 Feb 2002 12:45:41 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1IGxJP26806 for ips-outgoing; Mon, 18 Feb 2002 11:59:19 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail15a.boca15-verio.com (mail15a.boca15-verio.com [208.55.91.57]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g1IGxHj26802 for ; Mon, 18 Feb 2002 11:59:17 -0500 (EST) Received: from www1509.boca15-verio.com (208.55.91.90) by mail15a.boca15-verio.com (RS ver 1.0.60s) with SMTP id 031138964; Mon, 18 Feb 2002 11:58:07 -0500 (EST) From: "Joseph D. Harwood" To: "Ernest Dainow" , "'Bernard Aboba'" Cc: Subject: RE: Separate SA for each TCP connection Date: Mon, 18 Feb 2002 08:58:36 -0800 Message-ID: <000501c1b89d$815e4620$c7d0fea9@vesta> 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 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <1B8A58D6C376FE4DB329408E2701384250C99F@grizzly.mcdata.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Loop-Detect: 1 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello, A couple of comments below. Best Regards, Joseph D. Harwood (408) 838-9434 jharwood@vesta-corp.com www.vesta-corp.com > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Ernest Dainow > Sent: Monday, February 18, 2002 7:53 AM > To: 'Bernard Aboba' > Cc: 'ips@ece.cmu.edu' > Subject: Separate SA for each TCP connection > > > > I think that the requirement that every TCP connection must have > its own SA > (Security Association) has a number of problems. > > First of all, it is difficult to enforce on the receiving side, if the > sending end does not comply with this requirement and uses an existing SA > for a second TCP connection. When IPSec receives a packet with a > valid SPI, > it cannot discover that the packet was sent on a different port > number than > the SA was set up for until after the security processing. > > To meet this requirement, extra checking must be done to compare every > packet to the SPD (Security Policy Database) after security processing. If > this is done, then various interoperability problems may occur when > communicating with an end device that is using standard IPSec. This checking on inbound traffic is a required part of IPsec (RFC2401, Section 5.2.1). > > The SPD is configured with Source IP:Port, Destination IP:Port. When an > administrator configures this, the source port is not known and so a wild > card is usually used. In standard IPSec implementations, this means that > multiple connections to the same destination address:port will travel down > the same SA. > > Interoperability between standard IPSec and IPS IPSec may be needed in a > number of situations: > 1. Using tunnel mode to connect to a storage device behind a gateway, such > as a firewall (which terminates the IPSec connection). > 2. Connections to an iSNS or SLP server which likely will be > implemented on > an industry standard OS that uses standard IPSec. > 3. If the IP/IPSec stack on the IPS device is used as a TCP offload engine > for traffic other than storage. Common uses might be for > management such as > telnet. > > The only reason for this requirement that I could find is in Section 5.8.3 > of draft-ietf-ips-security-09.txt. > > "IPsec implementations that only support machine authentication typically > have no way to distinguish between user traffic within the kernel. As a > result, where machine authentication is used, once an Ipsec SA is opened, > another user on a multi-user machine may be able to send traffic down the > IPsec SA. To limit the potential vulnerability, iSCSI, iFCP or > FCIP security > implementations MUST negotiate a separate IPsec Phase 2 SA for each > connection, with descriptors specific to that connection." How does requiring each connection to have its own Phase 2 SA mitigate the vulnerability in this scenario? > > This is a general feature/limitation of IPSec. IPSec by > definition operates > at the network layer. If application layer authentication is desired, it > should be done by the application. iSCSI has the option to use > SRP or other > authentication methods. Proposals have been made for FCIP to provide an > option for user authentication based on SRP, consistent with iSCSI, but > current direction has been to favor a Fibre Channel based authentication > scheme (yet to be defined). > > The potential interoperability problems resulting from the requirement to > have a separate SA for each TCP connection is not worth the attempt to > "limit" this vulnerability, when other clean ways exist to establish user > authentication. > > Ernie Dainow > From owner-ips@ece.cmu.edu Mon Feb 18 12:46: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 MAA10897 for ; Mon, 18 Feb 2002 12:46:47 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1IHGrG28023 for ips-outgoing; Mon, 18 Feb 2002 12:16:53 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from AVEXCH01.qlogic.org (216-231-2-2.qlc.com [216.231.2.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1IHGpj28015 for ; Mon, 18 Feb 2002 12:16:51 -0500 (EST) content-class: urn:content-classes:message Subject: RE: iSCSI: DataACK SNACK MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B8A0.4684C40E" Date: Mon, 18 Feb 2002 09:18:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: Thread-Topic: iSCSI: DataACK SNACK Thread-Index: AcG2vuQgQQLUNiFiTr+IR4gBl4w91AB34+mA From: "Chuck Micalizzi" To: "Julian Satran" Cc: Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C1B8A0.4684C40E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Julian, =20 I agree with your suggestion. =20 Thank you for the prompt attention. =20 chuck =20 -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, February 15, 2002 11:52 PM To: Chuck Micalizzi Cc: ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK Chuck,=20 The Initiator Task Tag is thhe only reliable indicator the protocol = provides today.=20 If nobody shouts against it we might let the target provide a Target = Transfer Task for Data-In PDUs that have the A bit set=20 to be returned with the ACK for target convenience.=20 Julo=20 "Chuck Micalizzi" =20 15-02-02 23:14=20 =20 To: Julian Satran/Haifa/IBM@IBMIL=20 cc: =20 Subject: RE: iSCSI: DataACK SNACK=20 =20 Julian,=20 =20 Thank you for the response.=20 =20 Let me try to be more direct. If a target has been issued multiple=20 read commands, with transfer counts that exceed the negotiated=20 maxBurstSize. After the target sends a data sequence for one of = these=20 commands must it wait for a DataACK before sending a data sequence=20 for another command. Or is it free to send a data sequence for each = outstanding=20 command?=20 =20 If the target can have a data sequence in flight for each active = command then=20 it must expect a DataACK for each sequence sent with the Acknowledge = bit set. If the DataACK SNACK doesn't include a task Tag the target = can't be=20 certain as to which data sequence the initiator is acknowledging. = So how can=20 the target determine which resources to free or which sequence to = send next?=20 =20 chuck=20 =20 =20 =20 =20 =20 =20 -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, February 15, 2002 9:30 AM To: Chuck Micalizzi Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: DataACK SNACK DataACK is a "bulk ack". Answering the last (in case of several) is good = enough.=20 I fail to see your point.=20 Julo=20 "Chuck Micalizzi" =20 Sent by: owner-ips@ece.cmu.edu=20 14-02-02 21:02=20 =20 To: =20 cc: =20 Subject: iSCSI: DataACK SNACK=20 =20 All, =20 I have a question regarding DataACK. Rev. 10 section 10.16.1 states: For a Data/R2T SNACK, the Initiator Task Tag MUST be set to the Initiator Task Tag of the referenced Command. Otherwise, it is reserved. it also states: The DataACK is used to free resources at the target and=20 not to request or imply data retransmission. Is the target allowed to have more than one DataACK outstanding on a connection? =20 If multiple outstanding DataACKs are allowed per connection then in my opinion the DataACK must have a valid task tag inorder for the target to associate the DataACK with the appropriate resources to be freed. =20 chuck micalizzi Qlogic Corp. ------_=_NextPart_001_01C1B8A0.4684C40E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Julian,
   
    I agree with your = suggestion.
 
    Thank you for the prompt = attention.
 
chuck  
-----Original Message-----
From: Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, February 15, = 2002=20 11:52 PM
To: Chuck Micalizzi
Cc:=20 ips@ece.cmu.edu
Subject: RE: iSCSI: DataACK = SNACK


Chuck, =

The Initiator Task Tag is thhe only = reliable indicator=20 the protocol provides today.
If nobody=20 shouts against it we might let the target provide a Target Transfer = Task for=20 Data-In PDUs that have the A bit set
to be returned with the ACK for target convenience.=20

Julo =




"Chuck Micalizzi"=20 <chuck.micalizzi@qlogic.com>=20

15-02-02 23:14 =

        =
        To: =    =20    Julian Satran/Haifa/IBM@IBMIL
        cc: =    =20    <ips@ece.cmu.edu>
        Subject:     =  =20  RE: iSCSI: DataACK SNACK

      =  


Julian,
 
   =20 Thank you for the response.
 
    Let=20 me try to be  more direct. If a target has been issued = multiple=20
    read = commands, with=20 transfer counts that exceed the negotiated
    maxBurstSize. After the target = sends a data=20 sequence for one of these
 =20   commands must it wait for a DataACK before sending a data=20 sequence
  =   for=20 another command. Or is it free to send a data sequence for each=20 outstanding
  =  =20 command?
 =20
    If the target can have a data sequence in flight = for each=20 active command then
 =20   it must expect a DataACK for each sequence sent with the=20 Acknowledge
  =  =20 bit set. If the = DataACK SNACK=20 doesn't include a task Tag the target can't be
    certain as to which data sequence = the=20 initiator is acknowledging.  So how can
    the target determine which resources to free or which = sequence to send=20 next?
  =
chuck
 
   =20
  =
   
 
   
-----Original=20 Message-----
From: Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, February 15, = 2002=20 9:30 AM
To: Chuck Micalizzi
Cc: ips@ece.cmu.edu;=20 owner-ips@ece.cmu.edu
Subject: Re: iSCSI: DataACK=20 SNACK


DataACK is a = "bulk ack".=20 Answering the last (in case of several) is good enough.
I fail=20 to see your point. =

Julo=20

"Chuck = Micalizzi"=20 <chuck.micalizzi@qlogic.com>
Sent by: owner-ips@ece.cmu.edu

14-02-02 21:02

      =  =20
      =  To:=20        <ips@ece.cmu.edu>
       cc:       =   =
      =  Subject:  =20      iSCSI: DataACK SNACK

      =



All,
 
  I have a question regarding=20 DataACK.

  Rev. 10 section 10.16.1 states:

  = For a=20 Data/R2T SNACK, the Initiator Task Tag MUST be set
  to the = Initiator=20 Task Tag of the referenced Command.
  Otherwise, it is=20 reserved.

  it also states:

  The DataACK is = used to=20 free resources at the target and
  not to request or imply = data=20 retransmission.

  Is the target allowed to have more than = one=20 DataACK
  outstanding on a connection?   =  

  If=20 multiple outstanding DataACKs are allowed per connection
  = then in my=20 opinion the DataACK must have a valid task tag
  inorder for = the=20 target to associate the DataACK with the
  appropriate = resources to be=20 freed.
 

chuck micalizzi
Qlogic Corp.



------_=_NextPart_001_01C1B8A0.4684C40E-- From owner-ips@ece.cmu.edu Tue Feb 19 04:45: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 EAA13201 for ; Tue, 19 Feb 2002 04:45:56 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1J8hvI01573 for ips-outgoing; Tue, 19 Feb 2002 03:43:57 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1J8huj01569 for ; Tue, 19 Feb 2002 03:43:56 -0500 (EST) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id <190QSFJF>; Tue, 19 Feb 2002 03:43:51 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E03D02BB6@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: Huntington Beach presentations! Date: Tue, 19 Feb 2002 03:43:49 -0500 Importance: high X-Priority: 1 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 Perhaps in Minneapolis, I'll have the foresight to ask for these on floppies during/after the meeting ;-). In any case, would everyone who presented in Huntington Beach, please send me your slides if you have not already done so. Thanks in advance, --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 Feb 19 05:38: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 FAA13794 for ; Tue, 19 Feb 2002 05:38:14 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1J9i7g04541 for ips-outgoing; Tue, 19 Feb 2002 04:44:07 -0500 (EST) 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 g1J9i6j04536 for ; Tue, 19 Feb 2002 04:44:06 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id EAA54390; Tue, 19 Feb 2002 04:40:52 -0500 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1J9i3w48122; Tue, 19 Feb 2002 02:44:04 -0700 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: DataACK SNACK To: "Julian Satran" Cc: "Chuck Micalizzi" , ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Tue, 19 Feb 2002 01:43:06 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 02/19/2002 02:44:03 AM 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 g1J9i6j04537 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Julian, If you include the TTT in the Data-In PDU, you will need to change the format of the Data-In PDU. The TTT is usually placed at displacement 20-23, if you do that, you will have to reformat the Data-In PDU. Perhaps the best thing to do is to move the residual count to displacement 44-47. This is the same displacement that is used by the SCSI Response PDU for the residual count for Bidirectional reads. The other PDU that has a residual count, is the SCSI Response PDU and it also has residual in bytes 20-23, so there is no perfect solution. What do you plan to do? If this change worth it? . . . 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 Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 02/15/2002 11:52:06 PM Sent by: owner-ips@ece.cmu.edu To: "Chuck Micalizzi" cc: ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK Chuck, The Initiator Task Tag is thhe only reliable indicator the protocol provides today. If nobody shouts against it we might let the target provide a Target Transfer Task for Data-In PDUs that have the A bit set to be returned with the ACK for target convenience. Julo "Chuck Micalizzi" Satran/Haifa/IBM@IBMIL         cc: 15-02-02 23:14         Subject:        RE: iSCSI: DataACK SNACK Julian,     Thank you for the response.     Let me try to be  more direct. If a target has been issued multiple     read commands, with transfer counts that exceed the negotiated     maxBurstSize. After the target sends a data sequence for one of these     commands must it wait for a DataACK before sending a data sequence     for another command. Or is it free to send a data sequence for each outstanding     command?     If the target can have a data sequence in flight for each active command then     it must expect a DataACK for each sequence sent with the Acknowledge     bit set. If the DataACK SNACK doesn't include a task Tag the target can't be     certain as to which data sequence the initiator is acknowledging.  So how can     the target determine which resources to free or which sequence to send next? chuck -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, February 15, 2002 9:30 AM To: Chuck Micalizzi Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: DataACK SNACK DataACK is a "bulk ack". Answering the last (in case of several) is good enough. I fail to see your point. Julo "Chuck Micalizzi"        To: Sent by: owner-ips@ece.cmu.edu        cc: 14-02-02 21:02        Subject: iSCSI: DataACK SNACK All,   I have a question regarding DataACK.   Rev. 10 section 10.16.1 states:   For a Data/R2T SNACK, the Initiator Task Tag MUST be set   to the Initiator Task Tag of the referenced Command.   Otherwise, it is reserved.   it also states:   The DataACK is used to free resources at the target and   not to request or imply data retransmission.   Is the target allowed to have more than one DataACK   outstanding on a connection?   If multiple outstanding DataACKs are allowed per connection   then in my opinion the DataACK must have a valid task tag   inorder for the target to associate the DataACK with the   appropriate resources to be freed. chuck micalizzi Qlogic Corp. From owner-ips@ece.cmu.edu Tue Feb 19 16:19: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 QAA05860 for ; Tue, 19 Feb 2002 16:19:25 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1JKVxu02342 for ips-outgoing; Tue, 19 Feb 2002 15:31:59 -0500 (EST) 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 g1JKVtj02334 for ; Tue, 19 Feb 2002 15:31:55 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id <107NP28R>; Tue, 19 Feb 2002 15:31:50 -0500 Message-ID: <25369470B6F0D41194820002B328BDD22027A2@ATLOPS> From: Eddy Quicksall To: "ips@ece. cmu. edu (E-mail)" Cc: "julian_satran@il. ibm. com (E-mail)" Subject: RE: FW: FW: iSCSI: support value of ? Date: Tue, 19 Feb 2002 15:31:49 -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 -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com] Sent: Tuesday, February 19, 2002 3:19 PM To: Eddy Quicksall Subject: Re: FW: FW: iSCSI: support value of ? Eddy, [ Sorry, I was off on long weekend. ] I tend to concur with you guys. I do not see a good usage scenario for "?" at the moment. If we add in the support in MIB (if it isn't there already) for querying the default capabilities of an iSCSI entity, that should be completely adequate to retire the "?" feature. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Eddy Quicksall wrote: > > Mallikarjun, > > I am thinking that the value of the "?" syntax is very limited and appears > to me as though it could be something that got left in from past needs. > > Do you think it has any use other than for vendor specifics? Can you give me > an example of where it would be needed? > > Eddy > > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Friday, February 15, 2002 3:21 PM > To: Eddy_Quicksall@ivivity.com > Cc: Julian_Satran@il.ibm.com; ips@ece.cmu.edu > Subject: Re: FW: iSCSI: support value of ? > > Eddy, > > The '?' was originally proposed as a form of Enquiry analogous to something > like a PDISC for Fibre Channel ports. > > However, an Enquiry is more useful if it is a scheme to query the target for > all its supported capabilities, rather than its current value. > > A query for the current negotiated value was of some use in the older login > negotiation model wherein each side independently computed the login > negotiation result. In such a model, the '?' could be used by initiators to > verify that its negotiation result was in-sync with that of the target. > > With the new login negotiation model, wherein, the target computes the > result > of the negotiation and sends it back to the initiator, the initiator knows > the > current negotiated values anyway. Hence, what is more useful is a scheme to > query the target for its supported capabilities. > > IMO, the '?' semantics should be modified to return the target's supported > capabilities and not its current negotiatied value. > > Regards, > Santosh > > > > > Well, given that the initiator should know everything (unless I missed > > something below), what good is it other than for vendor specific? > > > > The reason I'm asking is because it seems silly to support it if it has no > > use. > > > > Can someone give me an example of where it is needed (other than for > vendor > > specific). > > > > Eddy > > > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Friday, February 15, 2002 12:30 PM > > To: Eddy Quicksall > > Subject: Re: FW: iSCSI: support value of ? > > > > > > The same value as Enquiry in SCSI. I heard no other comment than yours. > > > > Julo > > > > > > > > > > Eddy Quicksall > > 14-02-02 19:51 > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: > > Subject: FW: iSCSI: support value of ? > > > > > > > > > > I didn't see any responses on this. Is the "?" syntax of any good other > than > > for vendor specific commands? > > > > Eddy > > > > -----Original Message----- > > From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] > > Sent: Wednesday, February 06, 2002 5:29 PM > > To: ips@ece. cmu. edu (E-mail) > > Subject: iSCSI: support value of ? > > > > Section 2.2.4 of draft 10 says: > > > > The value "?" with any key has the meaning of enquiry and should be > > answered with the current value or "NotUnderstood". > > > > What good is this? > > > > You should already know the answer as a result of login or text > > negotiations. > > > > Here are the only keys that can be used in FFP by the initiator: > > > > 1) SendTargets - we already have defined behavior for that key and > > those get the information anyway > > 2) TargetName - that is IO by initiator so he can't send that key > > anyway. Also, he has to already know the target. > > 3) TargetAlias - "this name MUST be communicated to the initiator > > during a Login". So that is already known. > > 4) InitiatorAlias - the initiator should already know his alias > > 5) TargetAddress - the target is the only one that can send this in > a > > response > > 6) MaxRecvPDULength - this should be known from the negotiations > > 7) Vendor Specific - Could this be the reason? If so, lets say that > so > > we don't have to add a lot of silly code. Or, lets say that the response > to > > "?" can be "Reject" meaning that we don't support that syntax (currently, > > the definition of the "Reject value" does not fit this). > > > > Eddy > > > > ------_=_NextPart_001_01C1B64A.37A65F90 > > Content-Type: text/html; > > charset="iso-8859-1" > > Content-Transfer-Encoding: quoted-printable > > > > > xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > > xmlns=3D"http://www.w3.org/TR/REC-html40"> > > > > > > > charset=3Diso-8859-1"> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > >

> color=3Dnavy face=3DArial> > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>W= > > ell, > > given that the initiator should know everything (unless I missed = > > something > > below), what good is it other than for vendor = > > specific?

> > > >

> color=3Dnavy face=3DArial> > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><= > > ![if = > > !supportEmptyParas]> 

= > > > > > >

> color=3Dnavy face=3DArial> > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>T= > > he reason > > I’m asking is because it seems silly to support it if it has no = > > use.

> > > >

> color=3Dnavy face=3DArial> > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><= > > ![if !supportEmptyParas]>  > >

> > > >

> color=3Dnavy face=3DArial> > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>C= > > an > > someone give me an example of where it is needed (other than for vendor > > specific).

> > > >

> color=3Dnavy face=3DArial> > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><= > > ![if = > > !supportEmptyParas]> 

= > > > > > >

> color=3Dnavy face=3DArial> > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>E= > > ddy

> > > >

> color=3Dnavy face=3DArial> > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><= > > ![if = > > !supportEmptyParas]> 

= > > > > > >

> color=3Dblack > > face=3DTahoma> > style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original > > Message-----
> > From: Julian Satran > > [mailto:Julian_Satran@il.ibm.com]
> > Sent: Friday, February = > > 15, 2002 > > 12:30 PM
> > To: Eddy Quicksall
> > Subject: Re: FW: iSCSI: = > > support > > value of ?

> > > >

> face=3D"Times New Roman"> > style=3D'font-size:12.0pt'> > !supportEmptyParas]> 

> > > >

> style=3D'mso-margin-top-alt:0in;margin-right:0in;margin-bottom: > > 12.0pt;margin-left:.5in'> > Roman"> > style=3D'font-size:12.0pt;color:black'>
> > > style=3D'font-size: > > 10.0pt;font-family:sans-serif;color:black'>The same value as Enquiry in = > > SCSI.  I > > heard no other comment than yours. > color=3Dblack> > style=3D'color:black'>
> >
> > > style=3D'font-size: > > 10.0pt;font-family:sans-serif;color:black'>Julo > color=3Dblack> > style=3D'color:black'>
> >
> style=3D'mso-special-character:line-break'> > > > style=3D'color:black;mso-color-alt: > > windowtext'>

> > > > > style=3D'width:100.0%;mso-cellspacing: > > 1.5pt;margin-left:.5in'> > > > > > > > > > > > >
> >

  > size=3D3 > > color=3Dblack face=3D"Times New Roman"> > style=3D'font-size:12.0pt;color:black; > > mso-color-alt:windowtext'>

> > 		> >

> face=3Dsans-serif> > = > > style=3D'font-size:7.5pt;font-family:sans-serif;color:black;font-weight:= > > bold'>Eddy > > Quicksall <Eddy_Quicksall@ivivity.com> > color=3Dblack> > color=3Dblack> > = > > style=3D'color:black;mso-color-alt:windowtext'>= > >

> >

> style=3D'font-size:7.5pt; > > font-family:sans-serif;color:black'>14-02-02 19:51 > color=3Dblack> > color=3Dblack> > = > > style=3D'color:black;mso-color-alt:windowtext'>= > >

> > 		> >

> style=3D'font-size:7.5pt;font-family:Arial;color:black'>    = > >   > >   > style=3D'color:black'>
> > > style=3D'font-size:7.5pt;font-family:sans-serif;color:black'>  = > >     > >   To:        Julian = > > Satran/Haifa/IBM@IBMIL > color=3Dblack>
> > > style=3D'font-size:7.5pt;font-family:sans-serif;color:black'>  = > >     > >   cc:         > color=3Dblack> > style=3D'color:black'>
> > > style=3D'font-size:7.5pt;font-family:sans-serif;color:black'>  = > >     > >   Subject:        FW: iSCSI: support value = > > of ? > color=3Dblack>
> >
> > > style=3D'font-size: > > 7.5pt;font-family:Arial;color:black'>      = > >   > color=3Dblack> > style=3D'color:black;mso-color-alt:windowtext'>= > >

> >
> > > >

> color=3Dblack > > face=3D"Times New Roman"> > style=3D'font-size:12.0pt;color:black'>
> >
> > > style=3D'font-size:10.0pt; > > font-family:Arial;color:navy'>I didn't see any responses on this. Is = > > the > > "?" syntax of any good other than for vendor specific = > > commands? > color=3Dblack> > color=3Dblack> > style=3D'color:black;mso-color-alt:windowtext'>= > >

> > > >

> face=3DArial> > style=3D'font-size:10.0pt;font-family:Arial;color:navy'>  > ont> > color=3Dblack> > color=3Dblack> > style=3D'color:black;mso-color-alt:windowtext'>= > >

> > > >

> face=3DArial> > style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Eddy > t> > color=3Dblack> > color=3Dblack> > style=3D'color:black;mso-color-alt:windowtext'>= > >

> > > >

> face=3DArial> > style=3D'font-size:10.0pt;font-family:Arial;color:navy'>  > ont> > color=3Dblack> > color=3Dblack> > style=3D'color:black;mso-color-alt:windowtext'>= > >

> > > >

> face=3DTahoma> > style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original > > Message-----
> > From: Eddy Quicksall = > > [mailto:Eddy_Quicksall@ivivity.com] > style=3D'font-weight:bold'>
> > Sent: Wednesday, February 06, 2002 5:29 PM > style=3D'font-weight: > > bold'>
> > To: ips@ece. cmu. edu (E-mail) > style=3D'font-weight:bold'>
> > Subject: iSCSI: support value of ? > color=3Dblack> > style=3D'color:black'> > style=3D'color:black; > > mso-color-alt:windowtext'>

> > > >

> face=3DArial> > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > font> > color=3Dblack> > color=3Dblack> > style=3D'color:black;mso-color-alt:windowtext'>= > >

> > > >

> face=3DArial> > style=3D'font-size:10.0pt;font-family:Arial;color:black'>Section 2.2.4 = > > of draft > > 10 says: = > > > color=3Dblack> > style=3D'color:black;mso-color-alt:windowtext'>= > >

> > > >

> face=3DArial> > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > font> > color=3Dblack> > color=3Dblack> > style=3D'color:black;mso-color-alt:windowtext'>= > >

> > > >

> face=3DCourier> > style=3D'font-size:12.0pt;font-family:Courier;color:black'>The value > > "?" with any key has the meaning of enquiry and should = > > be > color=3Dblack> > color=3Dblack> > style=3D'color:black;mso-color-alt:windowtext'>= > >

> > > >

> face=3DCourier> > style=3D'font-size:12.0pt;font-family:Courier;color:black'>answered = > > with the > > current value or "NotUnderstood". > color=3Dblack> > style=3D'color:black'> > style=3D'color:black; > > mso-color-alt:windowtext'>

> > > >

> face=3DArial> > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > font> > color=3Dblack> > color=3Dblack> > style=3D'color:black;mso-color-alt:windowtext'>= > >

> > > >

> face=3DArial> > style=3D'font-size:10.0pt;font-family:Arial;color:black'>What good is = > > this? > color=3Dblack> > color=3Dblack> > style=3D'color:black;mso-color-alt:windowtext'>= > >

> > > >

> face=3DArial> > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > font> > color=3Dblack> > color=3Dblack> > style=3D'color:black;mso-color-alt:windowtext'>= > >

> > > >

> face=3DArial> > style=3D'font-size:10.0pt;font-family:Arial;color:black'>You should = > > already know > > the answer as a result of login or text = > > negotiations. > color=3Dblack> > color=3Dblack> > style=3D'color:black;mso-color-alt:windowtext'>= > >

> > > >

> face=3DArial> > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > font> > color=3Dblack> > color=3Dblack> > style=3D'color:black;mso-color-alt:windowtext'>= > >

> > > >

> face=3DArial> > style=3D'font-size:10.0pt;font-family:Arial;color:black'>Here are the = > > only keys > > that can be used in FFP by the initiator: > color=3Dblack> > style=3D'color:black'> > style=3D'color:black; > > mso-color-alt:windowtext'>

> > > >

> face=3DArial> > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > font> > color=3Dblack> > color=3Dblack> > style=3D'color:black;mso-color-alt:windowtext'>= > >

> > > >

> face=3DArial> > style=3D'font-size:10.0pt;font-family:Arial;color:black'>1) > > > size=3D1 color=3Dblack> = > >     > >   > style=3D'color:black'>SendTargets – > > we already have defined behavior for that key and those get the = > > information > > anyway > style=3D'color:black;mso-color-alt: > > windowtext'>

> > > >

> face=3DArial> > style=3D'font-size:10.0pt;font-family:Arial;color:black'>2) > > > size=3D1 color=3Dblack> = > >     > >   > style=3D'color:black'>TargetName – > > that is IO by initiator so he can't send that key anyway. Also, he has = > > to > > already know the target. > style=3D'color:black;mso-color-alt:windowtext'>= > >

> > > >

> face=3DArial> > style=3D'font-size:10.0pt;font-family:Arial;color:black'>3) > > > size=3D1 color=3Dblack> = > >     > >   > style=3D'color:black'>TargetAlias – > >  "this name MUST be communicated to the initiator during a > > Login". So that is already known. > color=3Dblack> > style=3D'color:black;mso-color-alt:windowtext'>= > >

> > > >

> face=3DArial> > style=3D'font-size:10.0pt;font-family:Arial;color:black'>4) > > > size=3D1 color=3Dblack> = > >     > >   > style=3D'color:black'>InitiatorAlias > > – the initiator should already know his alias > color=3Dblack> > style=3D'color:black;mso-color-alt:windowtext'>= > >

> > > >

> face=3DArial> > style=3D'font-size:10.0pt;font-family:Arial;color:black'>5) > > > size=3D1 color=3Dblack> = > >     > >   > style=3D'color:black'>TargetAddress > > – the target is the only one that can send this in a response = > > > color=3Dblack> > style=3D'color:black;mso-color-alt:windowtext'>= > >

> > > >

> face=3DArial> > style=3D'font-size:10.0pt;font-family:Arial;color:black'>6) > > > size=3D1 color=3Dblack> = > >     > >   > style=3D'color:black'>MaxRecvPDULength > > – this should be known from the negotiations > color=3Dblack> > style=3D'color:black;mso-color-alt:windowtext'>= > >

> > > >

> face=3DArial> > style=3D'font-size:10.0pt;font-family:Arial;color:black'>7) > > > size=3D1 color=3Dblack> = > >     > >   > style=3D'color:black'>Vendor > > Specific – Could this be the reason? If so, lets say that so we = > > don't have to > > add a lot of silly code. Or, lets say that the response to = > > "?" can be > > "Reject" meaning that we don't support that syntax = > > (currently, the > > definition of the "Reject value" does not fit this). = > > > color=3Dblack> > style=3D'color:black;mso-color-alt:windowtext'>= > >

> > > >

> face=3DArial> > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > font> > color=3Dblack> > color=3Dblack> > style=3D'color:black;mso-color-alt:windowtext'>= > >

> > > >

> face=3DArial> > style=3D'font-size:10.0pt;font-family:Arial;color:black'>Eddy > nt> > color=3Dblack> > color=3Dblack> > style=3D'color:black;mso-color-alt:windowtext'>= > >

> > > >
> > > > > > > > > > > > ------_=_NextPart_001_01C1B64A.37A65F90-- > > > > -- > ################################## > 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 Tue Feb 19 18:31: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 SAA08401 for ; Tue, 19 Feb 2002 18:31:40 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1JMomf13660 for ips-outgoing; Tue, 19 Feb 2002 17:50:48 -0500 (EST) 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 g1JMojj13655 for ; Tue, 19 Feb 2002 17:50:46 -0500 (EST) Message-ID: <20020219225045.32674.qmail@web13702.mail.yahoo.com> Received: from [192.52.58.4] by web13702.mail.yahoo.com via HTTP; Tue, 19 Feb 2002 14:50:45 PST Date: Tue, 19 Feb 2002 14:50:45 -0800 (PST) From: Martins Krikis Subject: FMarker, RFMarkInt and SFMarkInt negotiation To: ips@ece.cmu.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Dear list members, I seem to be having problems (or at least mild surprises) reading A.3.1 to A.3.3 of draft 10. Would you mind answering a few questions and hearing out some beginner's ideas? Many thanks in advance. Is it true that RFMarkInt when used by initiator means the intervals for the T->I direction, while this same key used by target refers to the I->T direction? Similarly (well, dually) for SFMarkInt? That is, if initiator starts the negotiation and sends FMarker=receive; RFMarkInt=17,51 the target should answer with something like FMarker=send; SFMarkInt=34 (the numbers used are just examples). I'm not sure that RFMarker is properly negotiated if the answer for it comes with the key "SFMarker"... The fact that FMarker=receive by originator is the same as FMarker=send by responder isn't pretty either, but at least the given example leaves no doubt. Or does it? What if send/receive is always with respect to the target? It would contradict the general principle that most everything in iSCSI is named with respect to initiator, but no example eliminates this possibility... May I suggest that we use something like ITFMarkInt and TIFMarkInt to unambiguously show which direction is being talked about? I would also love to tinker with FMarker values a bit, ideally get rid of it (thus getting rid of a clear parameter dependency), and use ITFMarkInt=0 and TIFMarker=0 to denote that markers are not in use in the respective direction. Any comments will be greatly appreciated. Martins Krikis P.S. I am not really a fan of features that are useless for software implementations and that break protocol layering, but would like to at least understand how they are to be negotiated... __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com From owner-ips@ece.cmu.edu Tue Feb 19 18:34: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 SAA08423 for ; Tue, 19 Feb 2002 18:34:22 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1JMg1512946 for ips-outgoing; Tue, 19 Feb 2002 17:42:01 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cleitus.hosting.pacbell.net (cleitus.hosting.pacbell.net [216.100.99.17]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1JMfwj12938 for ; Tue, 19 Feb 2002 17:41:59 -0500 (EST) Received: from gwendal.corp.silverbacksystems.com ([65.172.158.93]) by cleitus.hosting.pacbell.net id RAA25146; Tue, 19 Feb 2002 17:41:51 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Content-Type: text/plain; charset="iso-8859-1" From: Gwendal Grignou To: iSCSI Subject: iSCSI : Reject PDU reserved fields. Date: Tue, 19 Feb 2002 14:40:11 -0800 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <0202191440111F.09327@gwendal.corp.silverbacksystems.com> Content-Transfer-Encoding: 8bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hello, I wonder if it would be possible to have the 4 bytes word at offset 16-19 set to 0xFFFFFFFF in case of a Reject PDU. All iSCSI PDU either carries a valid ITT or 0xFFFFFFFF. Only Reject PDU carries an invalid ITT which will not be 0xFFFFFFFF - most probably 0x00000000. As of today, an initiator has to be sure the PDU is not a Reject PDU to interpret the ITT. By setting the ITT to 0xFFFFFFFF, we avoid this test. Gwendal. From owner-ips@ece.cmu.edu Tue Feb 19 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 TAA08792 for ; Tue, 19 Feb 2002 19:02:48 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1JNL8Z15826 for ips-outgoing; Tue, 19 Feb 2002 18:21:08 -0500 (EST) 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 g1JNL7j15822 for ; Tue, 19 Feb 2002 18:21:07 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id <107NP209>; Tue, 19 Feb 2002 18:21:06 -0500 Message-ID: <25369470B6F0D41194820002B328BDD22027AE@ATLOPS> From: Eddy Quicksall To: John Hufferd , Julian Satran Cc: Chuck Micalizzi , ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK Date: Tue, 19 Feb 2002 18:21:03 -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 How about moving bi-di to 40 and residual count to 44? Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Tuesday, February 19, 2002 4:43 AM To: Julian Satran Cc: Chuck Micalizzi; ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK Julian, If you include the TTT in the Data-In PDU, you will need to change the format of the Data-In PDU. The TTT is usually placed at displacement 20-23, if you do that, you will have to reformat the Data-In PDU. Perhaps the best thing to do is to move the residual count to displacement 44-47. This is the same displacement that is used by the SCSI Response PDU for the residual count for Bidirectional reads. The other PDU that has a residual count, is the SCSI Response PDU and it also has residual in bytes 20-23, so there is no perfect solution. What do you plan to do? If this change worth it? . . . 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 Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 02/15/2002 11:52:06 PM Sent by: owner-ips@ece.cmu.edu To: "Chuck Micalizzi" cc: ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK Chuck, The Initiator Task Tag is thhe only reliable indicator the protocol provides today. If nobody shouts against it we might let the target provide a Target Transfer Task for Data-In PDUs that have the A bit set to be returned with the ACK for target convenience. Julo "Chuck Micalizzi" Satran/Haifa/IBM@IBMIL cc: 15-02-02 23:14 Subject: RE: iSCSI: DataACK SNACK Julian, Thank you for the response. Let me try to be more direct. If a target has been issued multiple read commands, with transfer counts that exceed the negotiated maxBurstSize. After the target sends a data sequence for one of these commands must it wait for a DataACK before sending a data sequence for another command. Or is it free to send a data sequence for each outstanding command? If the target can have a data sequence in flight for each active command then it must expect a DataACK for each sequence sent with the Acknowledge bit set. If the DataACK SNACK doesn't include a task Tag the target can't be certain as to which data sequence the initiator is acknowledging. So how can the target determine which resources to free or which sequence to send next? chuck -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, February 15, 2002 9:30 AM To: Chuck Micalizzi Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: DataACK SNACK DataACK is a "bulk ack". Answering the last (in case of several) is good enough. I fail to see your point. Julo "Chuck Micalizzi" To: Sent by: owner-ips@ece.cmu.edu cc: 14-02-02 21:02 Subject: iSCSI: DataACK SNACK All, I have a question regarding DataACK. Rev. 10 section 10.16.1 states: For a Data/R2T SNACK, the Initiator Task Tag MUST be set to the Initiator Task Tag of the referenced Command. Otherwise, it is reserved. it also states: The DataACK is used to free resources at the target and not to request or imply data retransmission. Is the target allowed to have more than one DataACK outstanding on a connection? If multiple outstanding DataACKs are allowed per connection then in my opinion the DataACK must have a valid task tag inorder for the target to associate the DataACK with the appropriate resources to be freed. chuck micalizzi Qlogic Corp. From owner-ips@ece.cmu.edu Tue Feb 19 21:19: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 VAA10422 for ; Tue, 19 Feb 2002 21:19:13 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1K1MkR23864 for ips-outgoing; Tue, 19 Feb 2002 20:22:46 -0500 (EST) 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 g1K1Mij23856 for ; Tue, 19 Feb 2002 20:22:44 -0500 (EST) Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel6.hp.com (Postfix) with ESMTP id 3CDDA17A for ; Tue, 19 Feb 2002 20:22:39 -0500 (EST) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 3677D10B for ; Tue, 19 Feb 2002 20:22:39 -0500 (EST) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2653.19) id <10FRTNP3>; Tue, 19 Feb 2002 20:22:39 -0500 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF3CB@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "Ips Reflector (E-mail)" Subject: iSCSI: key negotiation - Unrecognized value? Date: Tue, 19 Feb 2002 20:22:37 -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 What is the proper response if you recognize a key, but are offered a value that you don't recognize? For instance, what if MaxConnections=yes is offered? Where is that specified in the document? Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard tel: +1 916 785 2656 fax: +1 916 785 0391 email: marjorie_krueger@hp.com From owner-ips@ece.cmu.edu Tue Feb 19 22:46: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 WAA13373 for ; Tue, 19 Feb 2002 22:46:05 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1K2r7Y29527 for ips-outgoing; Tue, 19 Feb 2002 21:53:07 -0500 (EST) 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 g1K2r5j29522 for ; Tue, 19 Feb 2002 21:53:05 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id VAA40682; Tue, 19 Feb 2002 21:49:49 -0500 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.99.140.13]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1K2qub228804; Tue, 19 Feb 2002 19:52:56 -0700 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: DataACK SNACK To: Eddy Quicksall Cc: "Julian Satran" , Chuck Micalizzi , ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Tue, 19 Feb 2002 18:52:03 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 02/19/2002 07:53:01 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk That would be possible. Your suggestion changes two PDUs, OK, and keeps things somewhat more consistent The question is do we want to change two PDUs, or Change 1 PDU . . . . 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 Eddy Quicksall @ece.cmu.edu on 02/19/2002 03:21:03 PM Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS, Julian Satran/Haifa/IBM@IBMIL cc: Chuck Micalizzi , ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK How about moving bi-di to 40 and residual count to 44? Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Tuesday, February 19, 2002 4:43 AM To: Julian Satran Cc: Chuck Micalizzi; ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK Julian, If you include the TTT in the Data-In PDU, you will need to change the format of the Data-In PDU. The TTT is usually placed at displacement 20-23, if you do that, you will have to reformat the Data-In PDU. Perhaps the best thing to do is to move the residual count to displacement 44-47. This is the same displacement that is used by the SCSI Response PDU for the residual count for Bidirectional reads. The other PDU that has a residual count, is the SCSI Response PDU and it also has residual in bytes 20-23, so there is no perfect solution. What do you plan to do? If this change worth it? . . . 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 Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 02/15/2002 11:52:06 PM Sent by: owner-ips@ece.cmu.edu To: "Chuck Micalizzi" cc: ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK Chuck, The Initiator Task Tag is thhe only reliable indicator the protocol provides today. If nobody shouts against it we might let the target provide a Target Transfer Task for Data-In PDUs that have the A bit set to be returned with the ACK for target convenience. Julo "Chuck Micalizzi" Satran/Haifa/IBM@IBMIL cc: 15-02-02 23:14 Subject: RE: iSCSI: DataACK SNACK Julian, Thank you for the response. Let me try to be more direct. If a target has been issued multiple read commands, with transfer counts that exceed the negotiated maxBurstSize. After the target sends a data sequence for one of these commands must it wait for a DataACK before sending a data sequence for another command. Or is it free to send a data sequence for each outstanding command? If the target can have a data sequence in flight for each active command then it must expect a DataACK for each sequence sent with the Acknowledge bit set. If the DataACK SNACK doesn't include a task Tag the target can't be certain as to which data sequence the initiator is acknowledging. So how can the target determine which resources to free or which sequence to send next? chuck -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, February 15, 2002 9:30 AM To: Chuck Micalizzi Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: DataACK SNACK DataACK is a "bulk ack". Answering the last (in case of several) is good enough. I fail to see your point. Julo "Chuck Micalizzi" To: Sent by: owner-ips@ece.cmu.edu cc: 14-02-02 21:02 Subject: iSCSI: DataACK SNACK All, I have a question regarding DataACK. Rev. 10 section 10.16.1 states: For a Data/R2T SNACK, the Initiator Task Tag MUST be set to the Initiator Task Tag of the referenced Command. Otherwise, it is reserved. it also states: The DataACK is used to free resources at the target and not to request or imply data retransmission. Is the target allowed to have more than one DataACK outstanding on a connection? If multiple outstanding DataACKs are allowed per connection then in my opinion the DataACK must have a valid task tag inorder for the target to associate the DataACK with the appropriate resources to be freed. chuck micalizzi Qlogic Corp. From owner-ips@ece.cmu.edu Wed Feb 20 03:25: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 DAA24875 for ; Wed, 20 Feb 2002 03:25:37 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1K7hP517439 for ips-outgoing; Wed, 20 Feb 2002 02:43:25 -0500 (EST) 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 g1K7hNj17433 for ; Wed, 20 Feb 2002 02:43:23 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id IAA46546 for ; Wed, 20 Feb 2002 08:43:16 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1K7isY63838 for ; Wed, 20 Feb 2002 08:44:55 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI : Reject PDU reserved fields. X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 20 Feb 2002 09:44:59 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 20/02/2002 09:45:01, Serialize complete at 20/02/2002 09:45:01 Content-Type: multipart/alternative; boundary="=_alternative 0029A7D5C2256B66_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0029A7D5C2256B66_= Content-Type: text/plain; charset="us-ascii" I think we may want to do this. Julo Gwendal Grignou Sent by: owner-ips@ece.cmu.edu 20-02-02 00:40 To: iSCSI cc: Subject: iSCSI : Reject PDU reserved fields. Hello, I wonder if it would be possible to have the 4 bytes word at offset 16-19 set to 0xFFFFFFFF in case of a Reject PDU. All iSCSI PDU either carries a valid ITT or 0xFFFFFFFF. Only Reject PDU carries an invalid ITT which will not be 0xFFFFFFFF - most probably 0x00000000. As of today, an initiator has to be sure the PDU is not a Reject PDU to interpret the ITT. By setting the ITT to 0xFFFFFFFF, we avoid this test. Gwendal. --=_alternative 0029A7D5C2256B66_= Content-Type: text/html; charset="us-ascii"
I think we may want to do this.

Julo


Gwendal Grignou <ggrignou@silverbacksystems.com>
Sent by: owner-ips@ece.cmu.edu

20-02-02 00:40

       
        To:        iSCSI <ips@ece.cmu.edu>
        cc:        
        Subject:        iSCSI : Reject PDU reserved fields.

       


Hello,

I wonder if it would be possible to have the 4 bytes word at offset 16-19 set
to 0xFFFFFFFF in case of a Reject PDU.
All iSCSI PDU either carries a valid ITT or 0xFFFFFFFF. Only Reject PDU
carries an invalid ITT which will not be 0xFFFFFFFF - most probably
0x00000000.
As of today, an initiator has to be sure the PDU is not a Reject PDU to
interpret the ITT. By setting the ITT to 0xFFFFFFFF, we avoid this test.

Gwendal.

--=_alternative 0029A7D5C2256B66_=-- From owner-ips@ece.cmu.edu Wed Feb 20 03:30: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 DAA24954 for ; Wed, 20 Feb 2002 03:30:55 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1K899d18901 for ips-outgoing; Wed, 20 Feb 2002 03:09:09 -0500 (EST) 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 g1K897j18896; Wed, 20 Feb 2002 03:09:07 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id JAA33300; Wed, 20 Feb 2002 09:09:00 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1K8Agh72168; Wed, 20 Feb 2002 09:10:45 +0100 To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" Cc: "Ips Reflector (E-mail)" , owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: key negotiation - Unrecognized value? X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 20 Feb 2002 10:10:40 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 20/02/2002 10:10:45, Serialize complete at 20/02/2002 10:10:45 Content-Type: multipart/alternative; boundary="=_alternative 002BC7C4C2256B66_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 002BC7C4C2256B66_= Content-Type: text/plain; charset="us-ascii" If it is not a list element the it is Reject. If it is a list element and you recognize others then ignore the "bad" value else "Reject". Regards, Julo "KRUEGER,MARJORIE (HP-Roseville,ex1)" Sent by: owner-ips@ece.cmu.edu 20-02-02 03:22 To: "Ips Reflector (E-mail)" cc: Subject: iSCSI: key negotiation - Unrecognized value? What is the proper response if you recognize a key, but are offered a value that you don't recognize? For instance, what if MaxConnections=yes is offered? Where is that specified in the document? Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard tel: +1 916 785 2656 fax: +1 916 785 0391 email: marjorie_krueger@hp.com --=_alternative 002BC7C4C2256B66_= Content-Type: text/html; charset="us-ascii"
If it is not a list element the it is Reject. If it is a list element and you recognize others then ignore the "bad" value else "Reject".

Regards,
Julo


"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
Sent by: owner-ips@ece.cmu.edu

20-02-02 03:22

       
        To:        "Ips Reflector (E-mail)" <ips@ece.cmu.edu>
        cc:        
        Subject:        iSCSI: key negotiation - Unrecognized value?

       


What is the proper response if you recognize a key, but are offered a value
that you don't recognize?  For instance, what if MaxConnections=yes is
offered?

Where is that specified in the document?  

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com


--=_alternative 002BC7C4C2256B66_=-- From owner-ips@ece.cmu.edu Wed Feb 20 10:26: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 KAA03564 for ; Wed, 20 Feb 2002 10:26:55 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1KEkD723611 for ips-outgoing; Wed, 20 Feb 2002 09:46:13 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from arctic.twire.com ([216.235.246.86]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1IND5j26320 for ; Mon, 18 Feb 2002 18:13:05 -0500 (EST) Received: from mail pickup service by arctic.twire.com with Microsoft SMTPSVC; Mon, 18 Feb 2002 18:11:25 -0500 From: "TidalWire" To: Subject: SAN Switch Topology Options: A Free White Paper from TidalWire Date: Mon, 18 Feb 2002 18:11:25 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_6F84_01C1B8A7.AD849100" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 18 Feb 2002 23:11:25.0500 (UTC) FILETIME=[9674D7C0:01C1B8D1] Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_6F84_01C1B8A7.AD849100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit SAN Topology Options for Switches and Directors Free white paper from TidalWire SAN Switches and Directors are very different types of products geared to very different user environments. Common wisdom tells us that switches are designed for smaller SANs, directors are designed for larger. Is this always the case? This new paper by storage author and consultant, Marc Farley, discusses basic SAN topologies that can be built with switches and directors while contrasting their relative advantages. Enhance your Switch vs Director knowledge today by downloading SAN Topology Options for Switches and Directors . The paper is free and available now, only from TidalWire. As your total SAN distribution partner, TidalWire features a wide variety of switches and directors as well as other products and services from top industry vendors. For more information, call 877-574-7600 or go to http://www.tidalwire.com. TidalWire Worldwide Sales, Toll-free: 877-574-7600 sales@tidalwire.com www.tidalwire.com If you received this email as a forward and would like to be added to our email list, please respond to webmaster@tidalwire.com with "SUBSCRIBE" in the subject line. If you wish to stop receiving future emails from TidalWire, please respond to webmaster@tidalwire.com with "REMOVE" in the subject line. ------=_NextPart_000_6F84_01C1B8A7.AD849100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
SAN Topology Options for Switches = and Directors
Free white = paper from TidalWire

SAN Switches and Directors are very different types of products = geared to very different user environments. Common wisdom tells us that = switches are designed for smaller SANs, directors are designed for = larger. Is this always the case?

=20

This new paper by storage author and consultant, Marc Farley, = discusses basic SAN topologies that can be built with switches and = directors while contrasting their relative advantages.

=20

Enhance your Switch vs Director knowledge today by downloading SAN Topology Options for = Switches and Directors. The paper is free and available now, only = from TidalWire.

As your total SAN distribution partner, TidalWire features a wide = variety of switches and directors as well as other products and services = from top industry vendors. For more information, call 877-574-7600 or go = to http://www.tidalwire.com.




3D"TidalWire"
Worldwide Sales, Toll-free: 877-574-7600
sales@tidalwire.com
www.tidalwire.com


If you received this email as a forward and would like to be added to = our email list, please respond to webmaster@tidalwire.com with "SUBSCRIBE" in the subject line.

If you wish to stop receiving future emails from TidalWire, please = respond to webmaster@tidalwire.com with "REMOVE" in the subject line.
------=_NextPart_000_6F84_01C1B8A7.AD849100-- From owner-ips@ece.cmu.edu Wed Feb 20 10:29: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 KAA03630 for ; Wed, 20 Feb 2002 10:29:54 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1KEcnB23037 for ips-outgoing; Wed, 20 Feb 2002 09:38:49 -0500 (EST) 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 g1KEclj23030 for ; Wed, 20 Feb 2002 09:38:47 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id <107NPJHD>; Wed, 20 Feb 2002 09:38:46 -0500 Message-ID: <25369470B6F0D41194820002B328BDD22027C0@ATLOPS> From: Eddy Quicksall To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" Cc: "ips@ece. cmu. edu (E-mail)" Subject: RE: iSCSI: key negotiation - Unrecognized value? Date: Wed, 20 Feb 2002 09:38:46 -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 Marjorie, Thanks for bringing this up again. I asked it once under "Re: iSCSI: invalid key value" but unfortunately I asked it in a "list context". As I remember, I got about 3 different opinions. Hopefully, we can get an answer this time. IMHO, I think we should allow "reject" to be used (but now it is for list items only). I know that some people are using "reject". Eddy -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie_krueger@hp.com] Sent: Tuesday, February 19, 2002 8:23 PM To: Ips Reflector (E-mail) Subject: iSCSI: key negotiation - Unrecognized value? What is the proper response if you recognize a key, but are offered a value that you don't recognize? For instance, what if MaxConnections=yes is offered? Where is that specified in the document? Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard tel: +1 916 785 2656 fax: +1 916 785 0391 email: marjorie_krueger@hp.com From owner-ips@ece.cmu.edu Wed Feb 20 10:32: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 KAA03802 for ; Wed, 20 Feb 2002 10:32:03 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1KEVDP22452 for ips-outgoing; Wed, 20 Feb 2002 09:31:13 -0500 (EST) 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 g1KEVBj22445 for ; Wed, 20 Feb 2002 09:31:11 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id <107NPJHA>; Wed, 20 Feb 2002 09:31:10 -0500 Message-ID: <25369470B6F0D41194820002B328BDD22027BF@ATLOPS> From: Eddy Quicksall To: John Hufferd Cc: Julian Satran , Chuck Micalizzi , ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK Date: Wed, 20 Feb 2002 09:31:10 -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 My feeling is to bight the bullet now and keep the consistency. Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Tuesday, February 19, 2002 9:52 PM To: Eddy Quicksall Cc: Julian Satran; Chuck Micalizzi; ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK That would be possible. Your suggestion changes two PDUs, OK, and keeps things somewhat more consistent The question is do we want to change two PDUs, or Change 1 PDU . . . . 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 Eddy Quicksall @ece.cmu.edu on 02/19/2002 03:21:03 PM Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS, Julian Satran/Haifa/IBM@IBMIL cc: Chuck Micalizzi , ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK How about moving bi-di to 40 and residual count to 44? Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Tuesday, February 19, 2002 4:43 AM To: Julian Satran Cc: Chuck Micalizzi; ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK Julian, If you include the TTT in the Data-In PDU, you will need to change the format of the Data-In PDU. The TTT is usually placed at displacement 20-23, if you do that, you will have to reformat the Data-In PDU. Perhaps the best thing to do is to move the residual count to displacement 44-47. This is the same displacement that is used by the SCSI Response PDU for the residual count for Bidirectional reads. The other PDU that has a residual count, is the SCSI Response PDU and it also has residual in bytes 20-23, so there is no perfect solution. What do you plan to do? If this change worth it? . . . 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 Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 02/15/2002 11:52:06 PM Sent by: owner-ips@ece.cmu.edu To: "Chuck Micalizzi" cc: ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK Chuck, The Initiator Task Tag is thhe only reliable indicator the protocol provides today. If nobody shouts against it we might let the target provide a Target Transfer Task for Data-In PDUs that have the A bit set to be returned with the ACK for target convenience. Julo "Chuck Micalizzi" Satran/Haifa/IBM@IBMIL cc: 15-02-02 23:14 Subject: RE: iSCSI: DataACK SNACK Julian, Thank you for the response. Let me try to be more direct. If a target has been issued multiple read commands, with transfer counts that exceed the negotiated maxBurstSize. After the target sends a data sequence for one of these commands must it wait for a DataACK before sending a data sequence for another command. Or is it free to send a data sequence for each outstanding command? If the target can have a data sequence in flight for each active command then it must expect a DataACK for each sequence sent with the Acknowledge bit set. If the DataACK SNACK doesn't include a task Tag the target can't be certain as to which data sequence the initiator is acknowledging. So how can the target determine which resources to free or which sequence to send next? chuck -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, February 15, 2002 9:30 AM To: Chuck Micalizzi Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: DataACK SNACK DataACK is a "bulk ack". Answering the last (in case of several) is good enough. I fail to see your point. Julo "Chuck Micalizzi" To: Sent by: owner-ips@ece.cmu.edu cc: 14-02-02 21:02 Subject: iSCSI: DataACK SNACK All, I have a question regarding DataACK. Rev. 10 section 10.16.1 states: For a Data/R2T SNACK, the Initiator Task Tag MUST be set to the Initiator Task Tag of the referenced Command. Otherwise, it is reserved. it also states: The DataACK is used to free resources at the target and not to request or imply data retransmission. Is the target allowed to have more than one DataACK outstanding on a connection? If multiple outstanding DataACKs are allowed per connection then in my opinion the DataACK must have a valid task tag inorder for the target to associate the DataACK with the appropriate resources to be freed. chuck micalizzi Qlogic Corp. From owner-ips@ece.cmu.edu Wed Feb 20 11:50: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 LAA06206 for ; Wed, 20 Feb 2002 11:50:15 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1KGTan02421 for ips-outgoing; Wed, 20 Feb 2002 11:29:36 -0500 (EST) 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 g1KGNjj01923 for ; Wed, 20 Feb 2002 11:23:45 -0500 (EST) Received: from io.iol.unh.edu (IDENT:rdr@localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.2/8.12.2) with ESMTP id g1KGNdUj016104; Wed, 20 Feb 2002 11:23:39 -0500 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.2/8.12.1/Submit) with ESMTP id g1KGNaav016101; Wed, 20 Feb 2002 11:23:36 -0500 Date: Wed, 20 Feb 2002 11:23:36 -0500 (EST) From: "Robert D. Russell" To: Eddy Quicksall cc: John Hufferd , Julian Satran , Chuck Micalizzi , Subject: RE: iSCSI: DataACK SNACK In-Reply-To: <25369470B6F0D41194820002B328BDD22027BF@ATLOPS> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk I agree with Eddy -- if we want a Target Transfer Tag in the DataIn PDU, then it is better to do whatever is needed to keep consistency in the location of fields across all PDUs, even if it means changing 2 PDUs to do so. The final result is a much better, easier to comprehend and easier to implement spec. Just imagine trying to justify the inconsistency a year from now :) Bob Russell On Wed, 20 Feb 2002, Eddy Quicksall wrote: > My feeling is to bight the bullet now and keep the consistency. > > Eddy > > -----Original Message----- > From: John Hufferd [mailto:hufferd@us.ibm.com] > Sent: Tuesday, February 19, 2002 9:52 PM > To: Eddy Quicksall > Cc: Julian Satran; Chuck Micalizzi; ips@ece.cmu.edu > Subject: RE: iSCSI: DataACK SNACK > > > That would be possible. Your suggestion changes two PDUs, OK, and keeps > things somewhat more consistent > > The question is do we want to change two PDUs, > or > Change 1 PDU . > > > . > . > . > 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 > > > Eddy Quicksall @ece.cmu.edu on 02/19/2002 > 03:21:03 PM > > Sent by: owner-ips@ece.cmu.edu > > > To: John Hufferd/San Jose/IBM@IBMUS, Julian Satran/Haifa/IBM@IBMIL > cc: Chuck Micalizzi , ips@ece.cmu.edu > Subject: RE: iSCSI: DataACK SNACK > > > > How about moving bi-di to 40 and residual count to 44? > > Eddy > > -----Original Message----- > From: John Hufferd [mailto:hufferd@us.ibm.com] > Sent: Tuesday, February 19, 2002 4:43 AM > To: Julian Satran > Cc: Chuck Micalizzi; ips@ece.cmu.edu > Subject: RE: iSCSI: DataACK SNACK > > > Julian, > If you include the TTT in the Data-In PDU, you will need to change the > format of the Data-In PDU. The TTT is usually placed at displacement > 20-23, if you do that, you will have to reformat the Data-In PDU. Perhaps > the best thing to do is to move the residual count to displacement 44-47. > This is the same displacement that is used by the SCSI Response PDU for the > residual count for Bidirectional reads. The other PDU that has a residual > count, is the SCSI Response PDU and it also has residual in bytes 20-23, so > there is no perfect solution. What do you plan to do? > > If this change worth it? > > . > . > . > 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 > > > Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 02/15/2002 11:52:06 PM > > Sent by: owner-ips@ece.cmu.edu > > > To: "Chuck Micalizzi" > cc: ips@ece.cmu.edu > Subject: RE: iSCSI: DataACK SNACK > > > > > Chuck, > > The Initiator Task Tag is thhe only reliable indicator the protocol > provides today. > If nobody shouts against it we might let the target provide a Target > Transfer Task for Data-In PDUs that have the A bit set > to be returned with the ACK for target convenience. > > Julo > > > > > > "Chuck Micalizzi" > m> Satran/Haifa/IBM@IBMIL > cc: > 15-02-02 23:14 > Subject: RE: iSCSI: > DataACK SNACK > > > > > > > Julian, > > Thank you for the response. > > Let me try to be more direct. If a target has been issued multiple > read commands, with transfer counts that exceed the negotiated > maxBurstSize. After the target sends a data sequence for one of these > commands must it wait for a DataACK before sending a data sequence > for another command. Or is it free to send a data sequence for each > outstanding > command? > > If the target can have a data sequence in flight for each active > command then > it must expect a DataACK for each sequence sent with the Acknowledge > bit set. If the DataACK SNACK doesn't include a task Tag the target > can't be > certain as to which data sequence the initiator is acknowledging. So > how can > the target determine which resources to free or which sequence to send > next? > > chuck > > > > > > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Friday, February 15, 2002 9:30 AM > To: Chuck Micalizzi > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu > Subject: Re: iSCSI: DataACK SNACK > > > DataACK is a "bulk ack". Answering the last (in case of several) is good > enough. > I fail to see your point. > > Julo > > > "Chuck Micalizzi" > To: > Sent by: owner-ips@ece.cmu.edu > cc: > 14-02-02 21:02 Subject: > iSCSI: DataACK SNACK > > > > > > > > All, > > I have a question regarding DataACK. > > Rev. 10 section 10.16.1 states: > > For a Data/R2T SNACK, the Initiator Task Tag MUST be set > to the Initiator Task Tag of the referenced Command. > Otherwise, it is reserved. > > it also states: > > The DataACK is used to free resources at the target and > not to request or imply data retransmission. > > Is the target allowed to have more than one DataACK > outstanding on a connection? > > If multiple outstanding DataACKs are allowed per connection > then in my opinion the DataACK must have a valid task tag > inorder for the target to associate the DataACK with the > appropriate resources to be freed. > > > chuck micalizzi > Qlogic Corp. > > > > > > From owner-ips@ece.cmu.edu Wed Feb 20 11:58: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 LAA06478 for ; Wed, 20 Feb 2002 11:58:03 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1KGOmt02006 for ips-outgoing; Wed, 20 Feb 2002 11:24:48 -0500 (EST) 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 g1KGOkj02002 for ; Wed, 20 Feb 2002 11:24:46 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id <107NPJJB>; Wed, 20 Feb 2002 11:24:46 -0500 Message-ID: <25369470B6F0D41194820002B328BDD22027C9@ATLOPS> From: Eddy Quicksall To: Chuck Micalizzi , John Hufferd Cc: Julian Satran , ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK Date: Wed, 20 Feb 2002 11:24:44 -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 Yes, which means BegRun should be moved so the TTT can be in a consistent place (20). Since it would be nice to have BegRun and RunLength contiguous, maybe BegRun and RunLength could be moved to 40 and 44. Eddy -----Original Message----- From: Chuck Micalizzi [mailto:chuck.micalizzi@qlogic.com] Sent: Wednesday, February 20, 2002 11:07 AM To: 'Eddy Quicksall'; John Hufferd Cc: Julian Satran; ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK Eddy, John, I assume the DataACK SNACK PDU will also have to change to include the TTT. chuck -----Original Message----- From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] Sent: Wednesday, February 20, 2002 6:31 AM To: John Hufferd Cc: Julian Satran; Chuck Micalizzi; ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK My feeling is to bight the bullet now and keep the consistency. Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Tuesday, February 19, 2002 9:52 PM To: Eddy Quicksall Cc: Julian Satran; Chuck Micalizzi; ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK That would be possible. Your suggestion changes two PDUs, OK, and keeps things somewhat more consistent The question is do we want to change two PDUs, or Change 1 PDU . . . . 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 Eddy Quicksall @ece.cmu.edu on 02/19/2002 03:21:03 PM Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS, Julian Satran/Haifa/IBM@IBMIL cc: Chuck Micalizzi , ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK How about moving bi-di to 40 and residual count to 44? Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Tuesday, February 19, 2002 4:43 AM To: Julian Satran Cc: Chuck Micalizzi; ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK Julian, If you include the TTT in the Data-In PDU, you will need to change the format of the Data-In PDU. The TTT is usually placed at displacement 20-23, if you do that, you will have to reformat the Data-In PDU. Perhaps the best thing to do is to move the residual count to displacement 44-47. This is the same displacement that is used by the SCSI Response PDU for the residual count for Bidirectional reads. The other PDU that has a residual count, is the SCSI Response PDU and it also has residual in bytes 20-23, so there is no perfect solution. What do you plan to do? If this change worth it? . . . 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 Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 02/15/2002 11:52:06 PM Sent by: owner-ips@ece.cmu.edu To: "Chuck Micalizzi" cc: ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK Chuck, The Initiator Task Tag is thhe only reliable indicator the protocol provides today. If nobody shouts against it we might let the target provide a Target Transfer Task for Data-In PDUs that have the A bit set to be returned with the ACK for target convenience. Julo "Chuck Micalizzi" Satran/Haifa/IBM@IBMIL cc: 15-02-02 23:14 Subject: RE: iSCSI: DataACK SNACK Julian, Thank you for the response. Let me try to be more direct. If a target has been issued multiple read commands, with transfer counts that exceed the negotiated maxBurstSize. After the target sends a data sequence for one of these commands must it wait for a DataACK before sending a data sequence for another command. Or is it free to send a data sequence for each outstanding command? If the target can have a data sequence in flight for each active command then it must expect a DataACK for each sequence sent with the Acknowledge bit set. If the DataACK SNACK doesn't include a task Tag the target can't be certain as to which data sequence the initiator is acknowledging. So how can the target determine which resources to free or which sequence to send next? chuck -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, February 15, 2002 9:30 AM To: Chuck Micalizzi Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: DataACK SNACK DataACK is a "bulk ack". Answering the last (in case of several) is good enough. I fail to see your point. Julo "Chuck Micalizzi" To: Sent by: owner-ips@ece.cmu.edu cc: 14-02-02 21:02 Subject: iSCSI: DataACK SNACK All, I have a question regarding DataACK. Rev. 10 section 10.16.1 states: For a Data/R2T SNACK, the Initiator Task Tag MUST be set to the Initiator Task Tag of the referenced Command. Otherwise, it is reserved. it also states: The DataACK is used to free resources at the target and not to request or imply data retransmission. Is the target allowed to have more than one DataACK outstanding on a connection? If multiple outstanding DataACKs are allowed per connection then in my opinion the DataACK must have a valid task tag inorder for the target to associate the DataACK with the appropriate resources to be freed. chuck micalizzi Qlogic Corp. From owner-ips@ece.cmu.edu Wed Feb 20 11:58: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 LAA06491 for ; Wed, 20 Feb 2002 11:58:05 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1KFuBf29612 for ips-outgoing; Wed, 20 Feb 2002 10:56:11 -0500 (EST) 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 g1KFu9j29608 for ; Wed, 20 Feb 2002 10:56:09 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id <107NPJ23>; Wed, 20 Feb 2002 10:56:09 -0500 Message-ID: <25369470B6F0D41194820002B328BDD22027C7@ATLOPS> From: Eddy Quicksall To: ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK Date: Wed, 20 Feb 2002 10:56:08 -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 Oops - I mean "bite". -----Original Message----- From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] Sent: Wednesday, February 20, 2002 9:31 AM To: John Hufferd Cc: Julian Satran; Chuck Micalizzi; ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK My feeling is to bight the bullet now and keep the consistency. Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Tuesday, February 19, 2002 9:52 PM To: Eddy Quicksall Cc: Julian Satran; Chuck Micalizzi; ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK That would be possible. Your suggestion changes two PDUs, OK, and keeps things somewhat more consistent The question is do we want to change two PDUs, or Change 1 PDU . . . . 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 Eddy Quicksall @ece.cmu.edu on 02/19/2002 03:21:03 PM Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS, Julian Satran/Haifa/IBM@IBMIL cc: Chuck Micalizzi , ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK How about moving bi-di to 40 and residual count to 44? Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Tuesday, February 19, 2002 4:43 AM To: Julian Satran Cc: Chuck Micalizzi; ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK Julian, If you include the TTT in the Data-In PDU, you will need to change the format of the Data-In PDU. The TTT is usually placed at displacement 20-23, if you do that, you will have to reformat the Data-In PDU. Perhaps the best thing to do is to move the residual count to displacement 44-47. This is the same displacement that is used by the SCSI Response PDU for the residual count for Bidirectional reads. The other PDU that has a residual count, is the SCSI Response PDU and it also has residual in bytes 20-23, so there is no perfect solution. What do you plan to do? If this change worth it? . . . 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 Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 02/15/2002 11:52:06 PM Sent by: owner-ips@ece.cmu.edu To: "Chuck Micalizzi" cc: ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK Chuck, The Initiator Task Tag is thhe only reliable indicator the protocol provides today. If nobody shouts against it we might let the target provide a Target Transfer Task for Data-In PDUs that have the A bit set to be returned with the ACK for target convenience. Julo "Chuck Micalizzi" Satran/Haifa/IBM@IBMIL cc: 15-02-02 23:14 Subject: RE: iSCSI: DataACK SNACK Julian, Thank you for the response. Let me try to be more direct. If a target has been issued multiple read commands, with transfer counts that exceed the negotiated maxBurstSize. After the target sends a data sequence for one of these commands must it wait for a DataACK before sending a data sequence for another command. Or is it free to send a data sequence for each outstanding command? If the target can have a data sequence in flight for each active command then it must expect a DataACK for each sequence sent with the Acknowledge bit set. If the DataACK SNACK doesn't include a task Tag the target can't be certain as to which data sequence the initiator is acknowledging. So how can the target determine which resources to free or which sequence to send next? chuck -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, February 15, 2002 9:30 AM To: Chuck Micalizzi Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: DataACK SNACK DataACK is a "bulk ack". Answering the last (in case of several) is good enough. I fail to see your point. Julo "Chuck Micalizzi" To: Sent by: owner-ips@ece.cmu.edu cc: 14-02-02 21:02 Subject: iSCSI: DataACK SNACK All, I have a question regarding DataACK. Rev. 10 section 10.16.1 states: For a Data/R2T SNACK, the Initiator Task Tag MUST be set to the Initiator Task Tag of the referenced Command. Otherwise, it is reserved. it also states: The DataACK is used to free resources at the target and not to request or imply data retransmission. Is the target allowed to have more than one DataACK outstanding on a connection? If multiple outstanding DataACKs are allowed per connection then in my opinion the DataACK must have a valid task tag inorder for the target to associate the DataACK with the appropriate resources to be freed. chuck micalizzi Qlogic Corp. From owner-ips@ece.cmu.edu Wed Feb 20 11:58: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 LAA06508 for ; Wed, 20 Feb 2002 11:58:10 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1KG2jF00147 for ips-outgoing; Wed, 20 Feb 2002 11:02:45 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail15b.boca15-verio.com (mail15b.boca15-verio.com [208.55.91.59]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g1KG2gj00134 for ; Wed, 20 Feb 2002 11:02:42 -0500 (EST) Received: from www1509.boca15-verio.com (208.55.91.90) by mail15b.boca15-verio.com (RS ver 1.0.60s) with SMTP id 030338493; Wed, 20 Feb 2002 11:02:34 -0500 (EST) From: "Joseph D. Harwood" To: "Bernard Aboba" , Cc: Subject: RE: Review of -10 security draft Date: Wed, 20 Feb 2002 08:01:47 -0800 Message-ID: <001701c1ba27$e6a8d640$c7d0fea9@vesta> 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 8.5, Build 4.71.2173.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-Loop-Detect: 1 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > Sent: Tuesday, February 19, 2002 2:42 PM > To: jharwood@vesta-corp.com; Ernest.Dainow@mcdata.com > Cc: ips@ece.cmu.edu > Subject: Review of -10 security draft > > > >How does requiring each connection to have its own Phase 2 SA > mitigate >the > >vulnerability in this scenario? > > IPsec doesn't protect against this at all, and the text needs to > make this > clear. > > Please take a look at the latest -10 security draft in progress to see if > this addresses the issue: > > http://www.drizzle.com/~aboba/RDMA/draft-ietf-ips-security-10.txt > It does, thanks! Best Regards, Joseph D. Harwood (408) 838-9434 jharwood@vesta-corp.com www.vesta-corp.com From owner-ips@ece.cmu.edu Wed Feb 20 11:58: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 LAA06526 for ; Wed, 20 Feb 2002 11:58:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1KG1dQ00040 for ips-outgoing; Wed, 20 Feb 2002 11:01:39 -0500 (EST) 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 g1KFqgj29336 for ; Wed, 20 Feb 2002 10:52:42 -0500 (EST) Received: from io.iol.unh.edu (IDENT:rdr@localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.2/8.12.2) with ESMTP id g1KFqaUj014880; Wed, 20 Feb 2002 10:52:36 -0500 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.2/8.12.1/Submit) with ESMTP id g1KFqZQe014877; Wed, 20 Feb 2002 10:52:35 -0500 Date: Wed, 20 Feb 2002 10:52:35 -0500 (EST) From: "Robert D. Russell" To: Eddy Quicksall cc: "ips@ece. cmu. edu (E-mail)" , "julian_satran@il. ibm. com (E-mail)" Subject: RE: FW: FW: iSCSI: support value of ? In-Reply-To: <25369470B6F0D41194820002B328BDD22027A2@ATLOPS> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian: I first brought up the subject of eliminating ? last December. Your reply is attached below. Perhaps this latest round of e-mail postings is enough to support my contention that ? should be eliminated?? Thanks, Bob Russell > > From Julian_Satran@il.ibm.com Sat Dec 22 01:57:36 2001 > To: "Robert D. Russell" > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: enquiry key > > Bob, > > "Robert D. Russell" wrote on 20-12-2001 12:48:31: > > > Julian: > > > ... snip snip ... > > > > My personal opinion is that "key=?" seems fairly useless -- if they > are > > to operate correctly, both sides of a connection really have to know > the > > values of all the keys at all times, and the rules for negotiation > make > > it clear how and when these values change. The only real "enquiry" > > situation is when an initiator is attempting to discover targets, and > > this is handled completely differently by the use of "SendTargets". > > So when is there a use for either side to send "key=?". Unless there > > is a clear example where this is useful, we should eliminate it and > thus > > remove another special case during parameter processing. > > > I am not sure that we have all the use scenarios to afford removing it On Tue, 19 Feb 2002, Eddy Quicksall wrote: > > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Tuesday, February 19, 2002 3:19 PM > To: Eddy Quicksall > Subject: Re: FW: FW: iSCSI: support value of ? > > Eddy, > > [ Sorry, I was off on long weekend. ] > > I tend to concur with you guys. I do not see > a good usage scenario for "?" at the moment. > If we add in the support in MIB (if it isn't > there already) for querying the default capabilities > of an iSCSI entity, that should be completely > adequate to retire the "?" feature. > > Regards. > -- > Mallikarjun > > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > > Eddy Quicksall wrote: > > > > Mallikarjun, > > > > I am thinking that the value of the "?" syntax is very limited and appears > > to me as though it could be something that got left in from past needs. > > > > Do you think it has any use other than for vendor specifics? Can you give > me > > an example of where it would be needed? > > > > Eddy > > > > -----Original Message----- > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > Sent: Friday, February 15, 2002 3:21 PM > > To: Eddy_Quicksall@ivivity.com > > Cc: Julian_Satran@il.ibm.com; ips@ece.cmu.edu > > Subject: Re: FW: iSCSI: support value of ? > > > > Eddy, > > > > The '?' was originally proposed as a form of Enquiry analogous to > something > > like a PDISC for Fibre Channel ports. > > > > However, an Enquiry is more useful if it is a scheme to query the target > for > > all its supported capabilities, rather than its current value. > > > > A query for the current negotiated value was of some use in the older > login > > negotiation model wherein each side independently computed the login > > negotiation result. In such a model, the '?' could be used by initiators > to > > verify that its negotiation result was in-sync with that of the target. > > > > With the new login negotiation model, wherein, the target computes the > > result > > of the negotiation and sends it back to the initiator, the initiator knows > > the > > current negotiated values anyway. Hence, what is more useful is a scheme > to > > query the target for its supported capabilities. > > > > IMO, the '?' semantics should be modified to return the target's supported > > capabilities and not its current negotiatied value. > > > > Regards, > > Santosh > > > > > > > > Well, given that the initiator should know everything (unless I missed > > > something below), what good is it other than for vendor specific? > > > > > > The reason I'm asking is because it seems silly to support it if it has > no > > > use. > > > > > > Can someone give me an example of where it is needed (other than for > > vendor > > > specific). > > > > > > Eddy > > > > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Friday, February 15, 2002 12:30 PM > > > To: Eddy Quicksall > > > Subject: Re: FW: iSCSI: support value of ? > > > > > > > > > The same value as Enquiry in SCSI. I heard no other comment than yours. > > > > > > Julo > > > > > > > > > > > > > > > Eddy Quicksall > > > 14-02-02 19:51 > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > > cc: > > > Subject: FW: iSCSI: support value of ? > > > > > > > > > > > > > > > I didn't see any responses on this. Is the "?" syntax of any good other > > than > > > for vendor specific commands? > > > > > > Eddy > > > > > > -----Original Message----- > > > From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] > > > Sent: Wednesday, February 06, 2002 5:29 PM > > > To: ips@ece. cmu. edu (E-mail) > > > Subject: iSCSI: support value of ? > > > > > > Section 2.2.4 of draft 10 says: > > > > > > The value "?" with any key has the meaning of enquiry and should be > > > answered with the current value or "NotUnderstood". > > > > > > What good is this? > > > > > > You should already know the answer as a result of login or text > > > negotiations. > > > > > > Here are the only keys that can be used in FFP by the initiator: > > > > > > 1) SendTargets - we already have defined behavior for that key and > > > those get the information anyway > > > 2) TargetName - that is IO by initiator so he can't send that key > > > anyway. Also, he has to already know the target. > > > 3) TargetAlias - "this name MUST be communicated to the initiator > > > during a Login". So that is already known. > > > 4) InitiatorAlias - the initiator should already know his alias > > > 5) TargetAddress - the target is the only one that can send this > in > > a > > > response > > > 6) MaxRecvPDULength - this should be known from the negotiations > > > 7) Vendor Specific - Could this be the reason? If so, lets say > that > > so > > > we don't have to add a lot of silly code. Or, lets say that the response > > to > > > "?" can be "Reject" meaning that we don't support that syntax > (currently, > > > the definition of the "Reject value" does not fit this). > > > > > > Eddy > > > > > > ------_=_NextPart_001_01C1B64A.37A65F90 > > > Content-Type: text/html; > > > charset="iso-8859-1" > > > Content-Transfer-Encoding: quoted-printable > > > > > > > > xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > > > xmlns=3D"http://www.w3.org/TR/REC-html40"> > > > > > > > > > > > charset=3Diso-8859-1"> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>W= > > > ell, > > > given that the initiator should know everything (unless I missed = > > > something > > > below), what good is it other than for vendor = > > > specific?

> > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><= > > > ![if = > > > > !supportEmptyParas]> 

= > > > > > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>T= > > > he reason > > > I’m asking is because it seems silly to support it if it has no = > > > use.

> > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><= > > > ![if > !supportEmptyParas]>  > > >

> > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>C= > > > an > > > someone give me an example of where it is needed (other than for vendor > > > specific).

> > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><= > > > ![if = > > > > !supportEmptyParas]> 

= > > > > > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>E= > > > ddy

> > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><= > > > ![if = > > > > !supportEmptyParas]> 

= > > > > > > > > >

> > color=3Dblack > > > face=3DTahoma> > > style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original > > > Message-----
> > > From: Julian Satran > > > [mailto:Julian_Satran@il.ibm.com]
> > > Sent: Friday, February = > > > 15, 2002 > > > 12:30 PM
> > > To: Eddy Quicksall
> > > Subject: Re: FW: iSCSI: = > > > support > > > value of ?

> > > > > >

> > face=3D"Times New Roman"> > > style=3D'font-size:12.0pt'> > > !supportEmptyParas]> 

> > > > > >

> > style=3D'mso-margin-top-alt:0in;margin-right:0in;margin-bottom: > > > 12.0pt;margin-left:.5in'> = > > > Roman"> > > style=3D'font-size:12.0pt;color:black'>
> > > > > style=3D'font-size: > > > 10.0pt;font-family:sans-serif;color:black'>The same value as Enquiry in > = > > > SCSI.  I > > > heard no other comment than yours. > > color=3Dblack> > > style=3D'color:black'>
> > >
> > > > > style=3D'font-size: > > > 10.0pt;font-family:sans-serif;color:black'>Julo > > color=3Dblack> > > style=3D'color:black'>
> > >
> > style=3D'mso-special-character:line-break'> > > > > > style=3D'color:black;mso-color-alt: > > > windowtext'>

> > > > > > > > style=3D'width:100.0%;mso-cellspacing: > > > 1.5pt;margin-left:.5in'> > > > > > > > > > > > > > > > > > >
> > >

  > > size=3D3 > > > color=3Dblack face=3D"Times New Roman"> > > style=3D'font-size:12.0pt;color:black; > > > mso-color-alt:windowtext'>

> > > 		> > >

> > face=3Dsans-serif> > > = > > > > style=3D'font-size:7.5pt;font-family:sans-serif;color:black;font-weight:= > > > bold'>Eddy > > > Quicksall <Eddy_Quicksall@ivivity.com> > > color=3Dblack> > > color=3Dblack> > > = > > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > >

> > style=3D'font-size:7.5pt; > > > font-family:sans-serif;color:black'>14-02-02 19:51 > > color=3Dblack> > > color=3Dblack> > > = > > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > 		> > >

> > style=3D'font-size:7.5pt;font-family:Arial;color:black'>    > = > > >   > > >   > > style=3D'color:black'>
> > > > > style=3D'font-size:7.5pt;font-family:sans-serif;color:black'>  = > > >     > > >   To:        Julian = > > > Satran/Haifa/IBM@IBMIL > > color=3Dblack>
> > > > > style=3D'font-size:7.5pt;font-family:sans-serif;color:black'>  = > > >     > > >   cc:         > > color=3Dblack> > > style=3D'color:black'>
> > > > > style=3D'font-size:7.5pt;font-family:sans-serif;color:black'>  = > > >     > > >   Subject:        FW: iSCSI: support value = > > > of ? > > color=3Dblack>
> > >
> > > > > style=3D'font-size: > > > 7.5pt;font-family:Arial;color:black'>      = > > >   > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > >
> > > > > >

> > color=3Dblack > > > face=3D"Times New Roman"> > > style=3D'font-size:12.0pt;color:black'>
> > >
> > > > > style=3D'font-size:10.0pt; > > > font-family:Arial;color:navy'>I didn't see any responses on this. Is = > > > the > > > "?" syntax of any good other than for vendor specific = > > > commands? > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:navy'>  > > ont> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Eddy > > t> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:navy'>  > > ont> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DTahoma> > > style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original > > > Message-----
> > > From: Eddy Quicksall = > > > [mailto:Eddy_Quicksall@ivivity.com] > > style=3D'font-weight:bold'>
> > > Sent: Wednesday, February 06, 2002 5:29 PM > > style=3D'font-weight: > > > bold'>
> > > To: ips@ece. cmu. edu (E-mail) > > style=3D'font-weight:bold'>
> > > Subject: iSCSI: support value of ? > > color=3Dblack> > > style=3D'color:black'> > > style=3D'color:black; > > > mso-color-alt:windowtext'>

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>Section 2.2.4 = > > > of draft > > > 10 says: = > > > > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DCourier> > > style=3D'font-size:12.0pt;font-family:Courier;color:black'>The value > > > "?" with any key has the meaning of enquiry and should = > > > be > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DCourier> > > style=3D'font-size:12.0pt;font-family:Courier;color:black'>answered = > > > with the > > > current value or "NotUnderstood". > > color=3Dblack> > > style=3D'color:black'> > > style=3D'color:black; > > > mso-color-alt:windowtext'>

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>What good is = > > > this? > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>You should = > > > already know > > > the answer as a result of login or text = > > > negotiations. > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>Here are the = > > > only keys > > > that can be used in FFP by the initiator: > > color=3Dblack> > > style=3D'color:black'> > > style=3D'color:black; > > > mso-color-alt:windowtext'>

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>1) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>SendTargets – > > > we already have defined behavior for that key and those get the = > > > information > > > anyway > > style=3D'color:black;mso-color-alt: > > > windowtext'>

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>2) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>TargetName – > > > that is IO by initiator so he can't send that key anyway. Also, he has = > > > to > > > already know the target. > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>3) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>TargetAlias – > > >  "this name MUST be communicated to the initiator during a > > > Login". So that is already known. > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>4) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>InitiatorAlias > > > – the initiator should already know his alias = > > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>5) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>TargetAddress > > > – the target is the only one that can send this in a response = > > > > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>6) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>MaxRecvPDULength > > > – this should be known from the negotiations > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>7) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>Vendor > > > Specific – Could this be the reason? If so, lets say that so we = > > > don't have to > > > add a lot of silly code. Or, lets say that the response to = > > > "?" can be > > > "Reject" meaning that we don't support that syntax = > > > (currently, the > > > definition of the "Reject value" does not fit this). = > > > > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>Eddy > > nt> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >
> > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C1B64A.37A65F90-- > > > > > > > -- > > ################################## > > 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 Wed Feb 20 12:43: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 MAA10640 for ; Wed, 20 Feb 2002 12:43:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1KGmWO04029 for ips-outgoing; Wed, 20 Feb 2002 11:48:32 -0500 (EST) 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 g1KGmTj04017 for ; Wed, 20 Feb 2002 11:48:29 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id B61842E1F; Wed, 20 Feb 2002 09:48:28 -0700 (MST) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 9290E139; Wed, 20 Feb 2002 09:48:28 -0700 (MST) Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id <17QZ11WX>; Wed, 20 Feb 2002 09:48:28 -0700 Message-ID: <9F8400020EC5D311AF62009027C3961605F26882@axcs09.cos.agilent.com> From: "LEMAY,KEVIN (A-Roseville,ex1)" To: "'Julian Satran'" , ips@ece.cmu.edu Subject: RE: FW: FW: iSCSI: support value of ? Date: Wed, 20 Feb 2002 09:48:27 -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 No objection here to kill it. I have yet to see anyone one use it at any of the plugfests and I have no use for it. Kevin Lemay Agilent Technologies -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, February 20, 2002 8:38 AM To: ips@ece.cmu.edu Subject: RE: FW: FW: iSCSI: support value of ? Importance: High If nobody speaks up I will terminate the use of ? Julo ----- Forwarded by Julian Satran/Haifa/IBM on 20-02-02 18:34 ----- "Robert D. Russell" 20-02-02 17:52 To: Eddy Quicksall cc: "ips@ece. cmu. edu (E-mail)" , Julian Satran/Haifa/IBM@IBMIL Subject: RE: FW: FW: iSCSI: support value of ? Julian: I first brought up the subject of eliminating ? last December. Your reply is attached below. Perhaps this latest round of e-mail postings is enough to support my contention that ? should be eliminated?? Thanks, Bob Russell > > From Julian_Satran@il.ibm.com Sat Dec 22 01:57:36 2001 > To: "Robert D. Russell" > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: enquiry key > > Bob, > > "Robert D. Russell" wrote on 20-12-2001 12:48:31: > > > Julian: > > > ... snip snip ... > > > > My personal opinion is that "key=?" seems fairly useless -- if they > are > > to operate correctly, both sides of a connection really have to know > the > > values of all the keys at all times, and the rules for negotiation > make > > it clear how and when these values change. The only real "enquiry" > > situation is when an initiator is attempting to discover targets, and > > this is handled completely differently by the use of "SendTargets". > > So when is there a use for either side to send "key=?". Unless there > > is a clear example where this is useful, we should eliminate it and > thus > > remove another special case during parameter processing. > > > I am not sure that we have all the use scenarios to afford removing it On Tue, 19 Feb 2002, Eddy Quicksall wrote: > > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Tuesday, February 19, 2002 3:19 PM > To: Eddy Quicksall > Subject: Re: FW: FW: iSCSI: support value of ? > > Eddy, > > [ Sorry, I was off on long weekend. ] > > I tend to concur with you guys. I do not see > a good usage scenario for "?" at the moment. > If we add in the support in MIB (if it isn't > there already) for querying the default capabilities > of an iSCSI entity, that should be completely > adequate to retire the "?" feature. > > Regards. > -- > Mallikarjun > > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > > Eddy Quicksall wrote: > > > > Mallikarjun, > > > > I am thinking that the value of the "?" syntax is very limited and appears > > to me as though it could be something that got left in from past needs. > > > > Do you think it has any use other than for vendor specifics? Can you give > me > > an example of where it would be needed? > > > > Eddy > > > > -----Original Message----- > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > Sent: Friday, February 15, 2002 3:21 PM > > To: Eddy_Quicksall@ivivity.com > > Cc: Julian_Satran@il.ibm.com; ips@ece.cmu.edu > > Subject: Re: FW: iSCSI: support value of ? > > > > Eddy, > > > > The '?' was originally proposed as a form of Enquiry analogous to > something > > like a PDISC for Fibre Channel ports. > > > > However, an Enquiry is more useful if it is a scheme to query the target > for > > all its supported capabilities, rather than its current value. > > > > A query for the current negotiated value was of some use in the older > login > > negotiation model wherein each side independently computed the login > > negotiation result. In such a model, the '?' could be used by initiators > to > > verify that its negotiation result was in-sync with that of the target. > > > > With the new login negotiation model, wherein, the target computes the > > result > > of the negotiation and sends it back to the initiator, the initiator knows > > the > > current negotiated values anyway. Hence, what is more useful is a scheme > to > > query the target for its supported capabilities. > > > > IMO, the '?' semantics should be modified to return the target's supported > > capabilities and not its current negotiatied value. > > > > Regards, > > Santosh > > > > > > > > Well, given that the initiator should know everything (unless I missed > > > something below), what good is it other than for vendor specific? > > > > > > The reason I'm asking is because it seems silly to support it if it has > no > > > use. > > > > > > Can someone give me an example of where it is needed (other than for > > vendor > > > specific). > > > > > > Eddy > > > > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Friday, February 15, 2002 12:30 PM > > > To: Eddy Quicksall > > > Subject: Re: FW: iSCSI: support value of ? > > > > > > > > > The same value as Enquiry in SCSI. I heard no other comment than yours. > > > > > > Julo > > > > > > > > > > > > > > > Eddy Quicksall > > > 14-02-02 19:51 > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > > cc: > > > Subject: FW: iSCSI: support value of ? > > > > > > > > > > > > > > > I didn't see any responses on this. Is the "?" syntax of any good other > > than > > > for vendor specific commands? > > > > > > Eddy > > > > > > -----Original Message----- > > > From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] > > > Sent: Wednesday, February 06, 2002 5:29 PM > > > To: ips@ece. cmu. edu (E-mail) > > > Subject: iSCSI: support value of ? > > > > > > Section 2.2.4 of draft 10 says: > > > > > > The value "?" with any key has the meaning of enquiry and should be > > > answered with the current value or "NotUnderstood". > > > > > > What good is this? > > > > > > You should already know the answer as a result of login or text > > > negotiations. > > > > > > Here are the only keys that can be used in FFP by the initiator: > > > > > > 1) SendTargets - we already have defined behavior for that key and > > > those get the information anyway > > > 2) TargetName - that is IO by initiator so he can't send that key > > > anyway. Also, he has to already know the target. > > > 3) TargetAlias - "this name MUST be communicated to the initiator > > > during a Login". So that is already known. > > > 4) InitiatorAlias - the initiator should already know his alias > > > 5) TargetAddress - the target is the only one that can send this > in > > a > > > response > > > 6) MaxRecvPDULength - this should be known from the negotiations > > > 7) Vendor Specific - Could this be the reason? If so, lets say > that > > so > > > we don't have to add a lot of silly code. Or, lets say that the response > > to > > > "?" can be "Reject" meaning that we don't support that syntax > (currently, > > > the definition of the "Reject value" does not fit this). > > > > > > Eddy > > > > > > ------_=_NextPart_001_01C1B64A.37A65F90 > > > Content-Type: text/html; > > > charset="iso-8859-1" > > > Content-Transfer-Encoding: quoted-printable > > > > > > > > xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > > > xmlns=3D"http://www.w3.org/TR/REC-html40"> > > > > > > > > > > > charset=3Diso-8859-1"> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>W= > > > ell, > > > given that the initiator should know everything (unless I missed = > > > something > > > below), what good is it other than for vendor = > > > specific?

> > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><= > > > ![if = > > > > !supportEmptyParas]> 

= > > > > > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>T= > > > he reason > > > I’m asking is because it seems silly to support it if it has no = > > > use.

> > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><= > > > ![if > !supportEmptyParas]>  > > >

> > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>C= > > > an > > > someone give me an example of where it is needed (other than for vendor > > > specific).

> > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><= > > > ![if = > > > > !supportEmptyParas]> 

= > > > > > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>E= > > > ddy

> > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><= > > > ![if = > > > > !supportEmptyParas]> 

= > > > > > > > > >

> > color=3Dblack > > > face=3DTahoma> > > style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original > > > Message-----
> > > From: Julian Satran > > > [mailto:Julian_Satran@il.ibm.com]
> > > Sent: Friday, February = > > > 15, 2002 > > > 12:30 PM
> > > To: Eddy Quicksall
> > > Subject: Re: FW: iSCSI: = > > > support > > > value of ?

> > > > > >

> > face=3D"Times New Roman"> > > style=3D'font-size:12.0pt'> > > !supportEmptyParas]> 

> > > > > >

> > style=3D'mso-margin-top-alt:0in;margin-right:0in;margin-bottom: > > > 12.0pt;margin-left:.5in'> = > > > Roman"> > > style=3D'font-size:12.0pt;color:black'>
> > > > > style=3D'font-size: > > > 10.0pt;font-family:sans-serif;color:black'>The same value as Enquiry in > = > > > SCSI.  I > > > heard no other comment than yours. > > color=3Dblack> > > style=3D'color:black'>
> > >
> > > > > style=3D'font-size: > > > 10.0pt;font-family:sans-serif;color:black'>Julo > > color=3Dblack> > > style=3D'color:black'>
> > >
> > style=3D'mso-special-character:line-break'> > > > > > style=3D'color:black;mso-color-alt: > > > windowtext'>

> > > > > > > > style=3D'width:100.0%;mso-cellspacing: > > > 1.5pt;margin-left:.5in'> > > > > > > > > > > > > > > > > > >
> > >

  > > size=3D3 > > > color=3Dblack face=3D"Times New Roman"> > > style=3D'font-size:12.0pt;color:black; > > > mso-color-alt:windowtext'>

> > > 		> > >

> > face=3Dsans-serif> > > = > > > > style=3D'font-size:7.5pt;font-family:sans-serif;color:black;font-weight:= > > > bold'>Eddy > > > Quicksall <Eddy_Quicksall@ivivity.com> > > color=3Dblack> > > color=3Dblack> > > = > > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > >

> > style=3D'font-size:7.5pt; > > > font-family:sans-serif;color:black'>14-02-02 19:51 > > color=3Dblack> > > color=3Dblack> > > = > > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > 		> > >

> > style=3D'font-size:7.5pt;font-family:Arial;color:black'>    > = > > >   > > >   > > style=3D'color:black'>
> > > > > style=3D'font-size:7.5pt;font-family:sans-serif;color:black'>  = > > >     > > >   To:        Julian = > > > Satran/Haifa/IBM@IBMIL > > color=3Dblack>
> > > > > style=3D'font-size:7.5pt;font-family:sans-serif;color:black'>  = > > >     > > >   cc:         > > color=3Dblack> > > style=3D'color:black'>
> > > > > style=3D'font-size:7.5pt;font-family:sans-serif;color:black'>  = > > >     > > >   Subject:        FW: iSCSI: support value = > > > of ? > > color=3Dblack>
> > >
> > > > > style=3D'font-size: > > > 7.5pt;font-family:Arial;color:black'>      = > > >   > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > >
> > > > > >

> > color=3Dblack > > > face=3D"Times New Roman"> > > style=3D'font-size:12.0pt;color:black'>
> > >
> > > > > style=3D'font-size:10.0pt; > > > font-family:Arial;color:navy'>I didn't see any responses on this. Is = > > > the > > > "?" syntax of any good other than for vendor specific = > > > commands? > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:navy'>  > > ont> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Eddy > > t> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:navy'>  > > ont> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DTahoma> > > style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original > > > Message-----
> > > From: Eddy Quicksall = > > > [mailto:Eddy_Quicksall@ivivity.com] > > style=3D'font-weight:bold'>
> > > Sent: Wednesday, February 06, 2002 5:29 PM > > style=3D'font-weight: > > > bold'>
> > > To: ips@ece. cmu. edu (E-mail) > > style=3D'font-weight:bold'>
> > > Subject: iSCSI: support value of ? > > color=3Dblack> > > style=3D'color:black'> > > style=3D'color:black; > > > mso-color-alt:windowtext'>

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>Section 2.2.4 = > > > of draft > > > 10 says: = > > > > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DCourier> > > style=3D'font-size:12.0pt;font-family:Courier;color:black'>The value > > > "?" with any key has the meaning of enquiry and should = > > > be > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DCourier> > > style=3D'font-size:12.0pt;font-family:Courier;color:black'>answered = > > > with the > > > current value or "NotUnderstood". > > color=3Dblack> > > style=3D'color:black'> > > style=3D'color:black; > > > mso-color-alt:windowtext'>

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>What good is = > > > this? > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>You should = > > > already know > > > the answer as a result of login or text = > > > negotiations. > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>Here are the = > > > only keys > > > that can be used in FFP by the initiator: > > color=3Dblack> > > style=3D'color:black'> > > style=3D'color:black; > > > mso-color-alt:windowtext'>

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>1) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>SendTargets – > > > we already have defined behavior for that key and those get the = > > > information > > > anyway > > style=3D'color:black;mso-color-alt: > > > windowtext'>

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>2) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>TargetName – > > > that is IO by initiator so he can't send that key anyway. Also, he has = > > > to > > > already know the target. > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>3) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>TargetAlias – > > >  "this name MUST be communicated to the initiator during a > > > Login". So that is already known. > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>4) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>InitiatorAlias > > > – the initiator should already know his alias = > > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>5) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>TargetAddress > > > – the target is the only one that can send this in a response = > > > > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>6) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>MaxRecvPDULength > > > – this should be known from the negotiations > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>7) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>Vendor > > > Specific – Could this be the reason? If so, lets say that so we = > > > don't have to > > > add a lot of silly code. Or, lets say that the response to = > > > "?" can be > > > "Reject" meaning that we don't support that syntax = > > > (currently, the > > > definition of the "Reject value" does not fit this). = > > > > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>Eddy > > nt> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >
> > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C1B64A.37A65F90-- > > > > > > > -- > > ################################## > > 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 Wed Feb 20 12:49: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 MAA10940 for ; Wed, 20 Feb 2002 12:49:26 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1KGaTp02964 for ips-outgoing; Wed, 20 Feb 2002 11:36:29 -0500 (EST) 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 g1KGaQj02958 for ; Wed, 20 Feb 2002 11:36:26 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id RAA21422 for ; Wed, 20 Feb 2002 17:36:18 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1KGc2h50336 for ; Wed, 20 Feb 2002 17:38:03 +0100 To: ips@ece.cmu.edu Importance: High MIME-Version: 1.0 Subject: RE: FW: FW: iSCSI: support value of ? X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 20 Feb 2002 18:37:59 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 20/02/2002 18:38:03, Serialize complete at 20/02/2002 18:38:03 Content-Type: multipart/alternative; boundary="=_alternative 005B1F98C2256B66_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005B1F98C2256B66_= Content-Type: text/plain; charset="us-ascii" If nobody speaks up I will terminate the use of ? Julo ----- Forwarded by Julian Satran/Haifa/IBM on 20-02-02 18:34 ----- "Robert D. Russell" 20-02-02 17:52 To: Eddy Quicksall cc: "ips@ece. cmu. edu (E-mail)" , Julian Satran/Haifa/IBM@IBMIL Subject: RE: FW: FW: iSCSI: support value of ? Julian: I first brought up the subject of eliminating ? last December. Your reply is attached below. Perhaps this latest round of e-mail postings is enough to support my contention that ? should be eliminated?? Thanks, Bob Russell > > From Julian_Satran@il.ibm.com Sat Dec 22 01:57:36 2001 > To: "Robert D. Russell" > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: enquiry key > > Bob, > > "Robert D. Russell" wrote on 20-12-2001 12:48:31: > > > Julian: > > > ... snip snip ... > > > > My personal opinion is that "key=?" seems fairly useless -- if they > are > > to operate correctly, both sides of a connection really have to know > the > > values of all the keys at all times, and the rules for negotiation > make > > it clear how and when these values change. The only real "enquiry" > > situation is when an initiator is attempting to discover targets, and > > this is handled completely differently by the use of "SendTargets". > > So when is there a use for either side to send "key=?". Unless there > > is a clear example where this is useful, we should eliminate it and > thus > > remove another special case during parameter processing. > > > I am not sure that we have all the use scenarios to afford removing it On Tue, 19 Feb 2002, Eddy Quicksall wrote: > > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Tuesday, February 19, 2002 3:19 PM > To: Eddy Quicksall > Subject: Re: FW: FW: iSCSI: support value of ? > > Eddy, > > [ Sorry, I was off on long weekend. ] > > I tend to concur with you guys. I do not see > a good usage scenario for "?" at the moment. > If we add in the support in MIB (if it isn't > there already) for querying the default capabilities > of an iSCSI entity, that should be completely > adequate to retire the "?" feature. > > Regards. > -- > Mallikarjun > > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > > Eddy Quicksall wrote: > > > > Mallikarjun, > > > > I am thinking that the value of the "?" syntax is very limited and appears > > to me as though it could be something that got left in from past needs. > > > > Do you think it has any use other than for vendor specifics? Can you give > me > > an example of where it would be needed? > > > > Eddy > > > > -----Original Message----- > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > Sent: Friday, February 15, 2002 3:21 PM > > To: Eddy_Quicksall@ivivity.com > > Cc: Julian_Satran@il.ibm.com; ips@ece.cmu.edu > > Subject: Re: FW: iSCSI: support value of ? > > > > Eddy, > > > > The '?' was originally proposed as a form of Enquiry analogous to > something > > like a PDISC for Fibre Channel ports. > > > > However, an Enquiry is more useful if it is a scheme to query the target > for > > all its supported capabilities, rather than its current value. > > > > A query for the current negotiated value was of some use in the older > login > > negotiation model wherein each side independently computed the login > > negotiation result. In such a model, the '?' could be used by initiators > to > > verify that its negotiation result was in-sync with that of the target. > > > > With the new login negotiation model, wherein, the target computes the > > result > > of the negotiation and sends it back to the initiator, the initiator knows > > the > > current negotiated values anyway. Hence, what is more useful is a scheme > to > > query the target for its supported capabilities. > > > > IMO, the '?' semantics should be modified to return the target's supported > > capabilities and not its current negotiatied value. > > > > Regards, > > Santosh > > > > > > > > Well, given that the initiator should know everything (unless I missed > > > something below), what good is it other than for vendor specific? > > > > > > The reason I'm asking is because it seems silly to support it if it has > no > > > use. > > > > > > Can someone give me an example of where it is needed (other than for > > vendor > > > specific). > > > > > > Eddy > > > > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Friday, February 15, 2002 12:30 PM > > > To: Eddy Quicksall > > > Subject: Re: FW: iSCSI: support value of ? > > > > > > > > > The same value as Enquiry in SCSI. I heard no other comment than yours. > > > > > > Julo > > > > > > > > > > > > > > > Eddy Quicksall > > > 14-02-02 19:51 > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > > cc: > > > Subject: FW: iSCSI: support value of ? > > > > > > > > > > > > > > > I didn't see any responses on this. Is the "?" syntax of any good other > > than > > > for vendor specific commands? > > > > > > Eddy > > > > > > -----Original Message----- > > > From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] > > > Sent: Wednesday, February 06, 2002 5:29 PM > > > To: ips@ece. cmu. edu (E-mail) > > > Subject: iSCSI: support value of ? > > > > > > Section 2.2.4 of draft 10 says: > > > > > > The value "?" with any key has the meaning of enquiry and should be > > > answered with the current value or "NotUnderstood". > > > > > > What good is this? > > > > > > You should already know the answer as a result of login or text > > > negotiations. > > > > > > Here are the only keys that can be used in FFP by the initiator: > > > > > > 1) SendTargets - we already have defined behavior for that key and > > > those get the information anyway > > > 2) TargetName - that is IO by initiator so he can't send that key > > > anyway. Also, he has to already know the target. > > > 3) TargetAlias - "this name MUST be communicated to the initiator > > > during a Login". So that is already known. > > > 4) InitiatorAlias - the initiator should already know his alias > > > 5) TargetAddress - the target is the only one that can send this > in > > a > > > response > > > 6) MaxRecvPDULength - this should be known from the negotiations > > > 7) Vendor Specific - Could this be the reason? If so, lets say > that > > so > > > we don't have to add a lot of silly code. Or, lets say that the response > > to > > > "?" can be "Reject" meaning that we don't support that syntax > (currently, > > > the definition of the "Reject value" does not fit this). > > > > > > Eddy > > > > > > ------_=_NextPart_001_01C1B64A.37A65F90 > > > Content-Type: text/html; > > > charset="iso-8859-1" > > > Content-Transfer-Encoding: quoted-printable > > > > > > > > xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > > > xmlns=3D"http://www.w3.org/TR/REC-html40"> > > > > > > > > > > > charset=3Diso-8859-1"> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>W= > > > ell, > > > given that the initiator should know everything (unless I missed = > > > something > > > below), what good is it other than for vendor = > > > specific?

> > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><= > > > ![if = > > > > !supportEmptyParas]> 

= > > > > > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>T= > > > he reason > > > I’m asking is because it seems silly to support it if it has no = > > > use.

> > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><= > > > ![if > !supportEmptyParas]>  > > >

> > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>C= > > > an > > > someone give me an example of where it is needed (other than for vendor > > > specific).

> > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><= > > > ![if = > > > > !supportEmptyParas]> 

= > > > > > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>E= > > > ddy

> > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><= > > > ![if = > > > > !supportEmptyParas]> 

= > > > > > > > > >

> > color=3Dblack > > > face=3DTahoma> > > style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original > > > Message-----
> > > From: Julian Satran > > > [mailto:Julian_Satran@il.ibm.com]
> > > Sent: Friday, February = > > > 15, 2002 > > > 12:30 PM
> > > To: Eddy Quicksall
> > > Subject: Re: FW: iSCSI: = > > > support > > > value of ?

> > > > > >

> > face=3D"Times New Roman"> > > style=3D'font-size:12.0pt'> > > !supportEmptyParas]> 

> > > > > >

> > style=3D'mso-margin-top-alt:0in;margin-right:0in;margin-bottom: > > > 12.0pt;margin-left:.5in'> = > > > Roman"> > > style=3D'font-size:12.0pt;color:black'>
> > > > > style=3D'font-size: > > > 10.0pt;font-family:sans-serif;color:black'>The same value as Enquiry in > = > > > SCSI.  I > > > heard no other comment than yours. > > color=3Dblack> > > style=3D'color:black'>
> > >
> > > > > style=3D'font-size: > > > 10.0pt;font-family:sans-serif;color:black'>Julo > > color=3Dblack> > > style=3D'color:black'>
> > >
> > style=3D'mso-special-character:line-break'> > > > > > style=3D'color:black;mso-color-alt: > > > windowtext'>

> > > > > > > > style=3D'width:100.0%;mso-cellspacing: > > > 1.5pt;margin-left:.5in'> > > > > > > > > > > > > > > > > > >
> > >

  > > size=3D3 > > > color=3Dblack face=3D"Times New Roman"> > > style=3D'font-size:12.0pt;color:black; > > > mso-color-alt:windowtext'>

> > > 		> > >

> > face=3Dsans-serif> > > = > > > > style=3D'font-size:7.5pt;font-family:sans-serif;color:black;font-weight:= > > > bold'>Eddy > > > Quicksall <Eddy_Quicksall@ivivity.com> > > color=3Dblack> > > color=3Dblack> > > = > > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > >

> > style=3D'font-size:7.5pt; > > > font-family:sans-serif;color:black'>14-02-02 19:51 > > color=3Dblack> > > color=3Dblack> > > = > > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > 		> > >

> > style=3D'font-size:7.5pt;font-family:Arial;color:black'>    > = > > >   > > >   > > style=3D'color:black'>
> > > > > style=3D'font-size:7.5pt;font-family:sans-serif;color:black'>  = > > >     > > >   To:        Julian = > > > Satran/Haifa/IBM@IBMIL > > color=3Dblack>
> > > > > style=3D'font-size:7.5pt;font-family:sans-serif;color:black'>  = > > >     > > >   cc:         > > color=3Dblack> > > style=3D'color:black'>
> > > > > style=3D'font-size:7.5pt;font-family:sans-serif;color:black'>  = > > >     > > >   Subject:        FW: iSCSI: support value = > > > of ? > > color=3Dblack>
> > >
> > > > > style=3D'font-size: > > > 7.5pt;font-family:Arial;color:black'>      = > > >   > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > >
> > > > > >

> > color=3Dblack > > > face=3D"Times New Roman"> > > style=3D'font-size:12.0pt;color:black'>
> > >
> > > > > style=3D'font-size:10.0pt; > > > font-family:Arial;color:navy'>I didn't see any responses on this. Is = > > > the > > > "?" syntax of any good other than for vendor specific = > > > commands? > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:navy'>  > > ont> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Eddy > > t> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:navy'>  > > ont> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DTahoma> > > style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original > > > Message-----
> > > From: Eddy Quicksall = > > > [mailto:Eddy_Quicksall@ivivity.com] > > style=3D'font-weight:bold'>
> > > Sent: Wednesday, February 06, 2002 5:29 PM > > style=3D'font-weight: > > > bold'>
> > > To: ips@ece. cmu. edu (E-mail) > > style=3D'font-weight:bold'>
> > > Subject: iSCSI: support value of ? > > color=3Dblack> > > style=3D'color:black'> > > style=3D'color:black; > > > mso-color-alt:windowtext'>

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>Section 2.2.4 = > > > of draft > > > 10 says: = > > > > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DCourier> > > style=3D'font-size:12.0pt;font-family:Courier;color:black'>The value > > > "?" with any key has the meaning of enquiry and should = > > > be > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DCourier> > > style=3D'font-size:12.0pt;font-family:Courier;color:black'>answered = > > > with the > > > current value or "NotUnderstood". > > color=3Dblack> > > style=3D'color:black'> > > style=3D'color:black; > > > mso-color-alt:windowtext'>

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>What good is = > > > this? > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>You should = > > > already know > > > the answer as a result of login or text = > > > negotiations. > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>Here are the = > > > only keys > > > that can be used in FFP by the initiator: > > color=3Dblack> > > style=3D'color:black'> > > style=3D'color:black; > > > mso-color-alt:windowtext'>

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>1) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>SendTargets – > > > we already have defined behavior for that key and those get the = > > > information > > > anyway > > style=3D'color:black;mso-color-alt: > > > windowtext'>

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>2) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>TargetName – > > > that is IO by initiator so he can't send that key anyway. Also, he has = > > > to > > > already know the target. > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>3) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>TargetAlias – > > >  "this name MUST be communicated to the initiator during a > > > Login". So that is already known. > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>4) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>InitiatorAlias > > > – the initiator should already know his alias = > > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>5) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>TargetAddress > > > – the target is the only one that can send this in a response = > > > > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>6) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>MaxRecvPDULength > > > – this should be known from the negotiations > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>7) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>Vendor > > > Specific – Could this be the reason? If so, lets say that so we = > > > don't have to > > > add a lot of silly code. Or, lets say that the response to = > > > "?" can be > > > "Reject" meaning that we don't support that syntax = > > > (currently, the > > > definition of the "Reject value" does not fit this). = > > > > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>Eddy > > nt> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >
> > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C1B64A.37A65F90-- > > > > > > > -- > > ################################## > > Santosh Rao > > Software Design Engineer, > > HP-UX iSCSI Driver Team, > > Hewlett Packard, Cupertino. > > email : santoshr@cup.hp.com > > Phone : 408-447-3751 > > ################################## > --=_alternative 005B1F98C2256B66_= Content-Type: text/html; charset="us-ascii"
If nobody speaks up I will terminate the use of ?  Julo
----- Forwarded by Julian Satran/Haifa/IBM on 20-02-02 18:34 -----
"Robert D. Russell" <rdr@io.iol.unh.edu>

20-02-02 17:52

       
        To:        Eddy Quicksall <Eddy_Quicksall@ivivity.com>
        cc:        "ips@ece. cmu. edu (E-mail)" <ips@ece.cmu.edu>, Julian Satran/Haifa/IBM@IBMIL
        Subject:        RE: FW: FW: iSCSI: support value of ?

       


Julian:

I first brought up the subject of eliminating ? last December.
Your reply is attached below.
Perhaps this latest round of e-mail postings is enough to
support my contention that ? should be eliminated??
Thanks,
Bob Russell

>
> From Julian_Satran@il.ibm.com  Sat Dec 22 01:57:36 2001
> To: "Robert D. Russell" <rdr@io.iol.unh.edu>
> Cc: ips@ece.cmu.edu
> Subject: Re: iSCSI: enquiry key
>
> Bob,
>
> "Robert D. Russell" <rdr@io.iol.unh.edu> wrote on 20-12-2001 12:48:31:
>
> > Julian:
> >
> ... snip snip ...
> >
> >    My personal opinion is that "key=?" seems fairly useless -- if they
> are
> >    to operate correctly, both sides of a connection really have to know
> the
> >    values of all the keys at all times, and the rules for negotiation
> make
> >    it clear how and when these values change.  The only real "enquiry"
> >    situation is when an initiator is attempting to discover targets, and
> >    this is handled completely differently by the use of "SendTargets".
> >    So when is there a use for either side to send "key=?".  Unless there
> >    is a clear example where this is useful, we should eliminate it and
> thus
> >    remove another special case during parameter processing.
> >
> I am not sure that we have all the use scenarios to afford removing it



On Tue, 19 Feb 2002, Eddy Quicksall wrote:

>
>
> -----Original Message-----
> From: Mallikarjun C. [mailto:cbm@rose.hp.com]
> Sent: Tuesday, February 19, 2002 3:19 PM
> To: Eddy Quicksall
> Subject: Re: FW: FW: iSCSI: support value of ?
>
> Eddy,
>
> [ Sorry, I was off on long weekend. ]
>
> I tend to concur with you guys.  I do not see
> a good usage scenario for "?" at the moment.
> If we add in the support in MIB (if it isn't
> there already) for querying the default capabilities
> of an iSCSI entity, that should be completely
> adequate to retire the "?" feature.
>
> Regards.
> --
> Mallikarjun
>
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> MS 5668 Hewlett-Packard, Roseville.
> cbm@rose.hp.com
>
>
> Eddy Quicksall wrote:
> >
> > Mallikarjun,
> >
> > I am thinking that the value of the "?" syntax is very limited and appears
> > to me as though it could be something that got left in from past needs.
> >
> > Do you think it has any use other than for vendor specifics? Can you give
> me
> > an example of where it would be needed?
> >
> > Eddy
> >
> > -----Original Message-----
> > From: Santosh Rao [mailto:santoshr@cup.hp.com]
> > Sent: Friday, February 15, 2002 3:21 PM
> > To: Eddy_Quicksall@ivivity.com
> > Cc: Julian_Satran@il.ibm.com; ips@ece.cmu.edu
> > Subject: Re: FW: iSCSI: support value of ?
> >
> > Eddy,
> >
> > The '?' was originally proposed as a form of Enquiry analogous to
> something
> > like a PDISC for Fibre Channel ports.
> >
> > However, an Enquiry is more useful if it is a scheme to query the target
> for
> > all its supported capabilities, rather than its current value.
> >
> > A query for the current negotiated value was of some use in the older
> login
> > negotiation model wherein each side independently computed the login
> > negotiation result. In such a model, the '?' could be used by initiators
> to
> > verify that its negotiation result was in-sync with that of the target.
> >
> > With the new login negotiation model, wherein, the target computes the
> > result
> > of the negotiation and sends it back to the initiator, the initiator knows
> > the
> > current negotiated values anyway. Hence, what is more useful is a scheme
> to
> > query the target for its supported capabilities.
> >
> > IMO, the '?' semantics should be modified to return the target's supported
> > capabilities and not its current negotiatied value.
> >
> > Regards,
> > Santosh
> >
> > >
> > > Well, given that the initiator should know everything (unless I missed
> > > something below), what good is it other than for vendor specific?
> > >
> > > The reason I'm asking is because it seems silly to support it if it has
> no
> > > use.
> > >
> > > Can someone give me an example of where it is needed (other than for
> > vendor
> > > specific).
> > >
> > > Eddy
> > >
> > > -----Original Message-----
> > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > > Sent: Friday, February 15, 2002 12:30 PM
> > > To: Eddy Quicksall
> > > Subject: Re: FW: iSCSI: support value of ?
> > >
> > >
> > > The same value as Enquiry in SCSI.  I heard no other comment than yours.
> > >
> > > Julo
> > >
> > >
> > >
> > >
> > > Eddy Quicksall <Eddy_Quicksall@ivivity.com>
> > > 14-02-02 19:51
> > >
> > >         To:        Julian Satran/Haifa/IBM@IBMIL
> > >         cc:
> > >         Subject:        FW: iSCSI: support value of ?
> > >
> > >
> > >
> > >
> > > I didn't see any responses on this. Is the "?" syntax of any good other
> > than
> > > for vendor specific commands?
> > >
> > > Eddy
> > >
> > > -----Original Message-----
> > > From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com]
> > > Sent: Wednesday, February 06, 2002 5:29 PM
> > > To: ips@ece. cmu. edu (E-mail)
> > > Subject: iSCSI: support value of ?
> > >
> > > Section 2.2.4 of draft 10 says:
> > >
> > > The value "?" with any key has the meaning of enquiry and should be
> > > answered with the current value or "NotUnderstood".
> > >
> > > What good is this?
> > >
> > > You should already know the answer as a result of login or text
> > > negotiations.
> > >
> > > Here are the only keys that can be used in FFP by the initiator:
> > >
> > > 1)       SendTargets - we already have defined behavior for that key and
> > > those get the information anyway
> > > 2)       TargetName - that is IO by initiator so he can't send that key
> > > anyway. Also, he has to already know the target.
> > > 3)       TargetAlias -  "this name MUST be communicated to the initiator
> > > during a Login". So that is already known.
> > > 4)       InitiatorAlias - the initiator should already know his alias
> > > 5)       TargetAddress - the target is the only one that can send this
> in
> > a
> > > response
> > > 6)       MaxRecvPDULength - this should be known from the negotiations
> > > 7)       Vendor Specific - Could this be the reason? If so, lets say
> that
> > so
> > > we don't have to add a lot of silly code. Or, lets say that the response
> > to
> > > "?" can be "Reject" meaning that we don't support that syntax
> (currently,
> > > the definition of the "Reject value" does not fit this).
> > >
> > > Eddy
> > >
> > > ------_=_NextPart_001_01C1B64A.37A65F90
> > > Content-Type: text/html;
> > >       charset="iso-8859-1"
> > > Content-Transfer-Encoding: quoted-printable
> > >
> > > <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
> > > xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
> > > xmlns=3D"http://www.w3.org/TR/REC-html40">
> > >
> > > <head>
> > > <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> > > charset=3Diso-8859-1">
> > >
> > >
> > > <meta name=3DProgId content=3DWord.Document>
> > > <meta name=3DGenerator content=3D"Microsoft Word 9">
> > > <meta name=3DOriginator content=3D"Microsoft Word 9">
> > > <link rel=3DFile-List href=3D"cid:filelist.xml@01C1B620.0DD66E50">
> > > <!--[if gte mso 9]><xml> > > >  <o:OfficeDocumentSettings> > > >   <o:DoNotRelyOnCSS/> > > >  </o:OfficeDocumentSettings> > > > </xml><![endif]--><!--[if gte mso 9]><xml> > > >  <w:WordDocument> > > >   <w:Zoom>0</w:Zoom> > > >   <w:DocumentKind>DocumentEmail</w:DocumentKind> > > >   <w:EnvelopeVis/> > > >  </w:WordDocument> > > > </xml><![endif]-->
> > > <style>
> > > <!-- > > >  /* Font Definitions */
> > > @font-face
> > >       {font-family:Courier;
> > >       panose-1:0 0 0 0 0 0 0 0 0 0;
> > >       mso-font-charset:0;
> > >       mso-generic-font-family:modern;
> > >       mso-font-format:other;
> > >       mso-font-pitch:fixed;
> > >       mso-font-signature:3 0 0 0 1 0;}
> > > @font-face
> > >       {font-family:Tahoma;
> > >       panose-1:2 11 6 4 3 5 4 4 2 4;
> > >       mso-font-charset:0;
> > >       mso-generic-font-family:swiss;
> > >       mso-font-pitch:variable;
> > >       mso-font-signature:553679495 -2147483648 8 0 66047 0;}
> > > @font-face
> > >       {font-family:sans-serif;
> > >       panose-1:0 0 0 0 0 0 0 0 0 0;
> > >       mso-font-alt:"Times New Roman";
> > >       mso-font-charset:0;
> > >       mso-generic-font-family:roman;
> > >       mso-font-format:other;
> > >       mso-font-pitch:auto;
> > >       mso-font-signature:0 0 0 0 0 0;}
> > >  /* Style Definitions */
> > > p.MsoNormal, li.MsoNormal, div.MsoNormal
> > >       {mso-style-parent:"";
> > >       margin:0in;
> > >       margin-bottom:.0001pt;
> > >       mso-pagination:widow-orphan;
> > >       font-size:12.0pt;
> > >       font-family:"Times New Roman";
> > >       mso-fareast-font-family:"Times New Roman";}
> > > p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
> > >       {margin:0in;
> > >       margin-bottom:.0001pt;
> > >       mso-pagination:widow-orphan;
> > >       font-size:12.0pt;
> > >       font-family:"Times New Roman";
> > >       mso-fareast-font-family:"Times New Roman";}
> > > p
> > >       {margin-right:0in;
> > >       mso-margin-top-alt:auto;
> > >       mso-margin-bottom-alt:auto;
> > >       margin-left:0in;
> > >       mso-pagination:widow-orphan;
> > >       font-size:12.0pt;
> > >       font-family:"Times New Roman";
> > >       mso-fareast-font-family:"Times New Roman";}
> > > span.EmailStyle16
> > >       {mso-style-type:personal-reply;
> > >       mso-ansi-font-size:10.0pt;
> > >       mso-ascii-font-family:Arial;
> > >       mso-hansi-font-family:Arial;
> > >       mso-bidi-font-family:Arial;
> > >       color:navy;}
> > > span.CourierNew
> > >       {mso-style-name:"Courier New";
> > >       mso-ascii-font-family:"Courier New";
> > >       mso-hansi-font-family:"Courier New";
> > >       mso-bidi-font-family:"Courier New";}
> > > @page Section1
> > >       {size:8.5in 11.0in;
> > >       margin:1.0in 1.25in 1.0in 1.25in;
> > >       mso-header-margin:.5in;
> > >       mso-footer-margin:.5in;
> > >       mso-paper-source:0;}
> > > div.Section1
> > >       {page:Section1;}
> > > -->
> > > </style>
> > > </head>
> > >
> > > <body lang=3DEN-US style=3D'tab-interval:.5in'>
> > >
> > > <div class=3DSection1>
> > >
> > > <p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
> > > color=3Dnavy face=3DArial><span
> > >
> style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>W=
> > > ell,
> > > given that the initiator should know everything (unless I missed =
> > > something
> > > below), what good is it other than for vendor =
> > > specific?<o:p></o:p></span></font></span></p>
> > >
> > > <p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
> > > color=3Dnavy face=3DArial><span
> > >
> style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
> > > ![if =
> > >
> !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=
> > >
> > >
> > > <p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
> > > color=3Dnavy face=3DArial><span
> > >
> style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>T=
> > > he reason
> > > I&#8217;m asking is because it seems silly to support it if it has no =
> > > use.<o:p></o:p></span></font></span></p>
> > >
> > > <p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
> > > color=3Dnavy face=3DArial><span
> > >
> style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
> > > ![if
> !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span=
> > > ></p>
> > >
> > > <p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
> > > color=3Dnavy face=3DArial><span
> > >
> style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>C=
> > > an
> > > someone give me an example of where it is needed (other than for vendor
> > > specific).<o:p></o:p></span></font></span></p>
> > >
> > > <p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
> > > color=3Dnavy face=3DArial><span
> > >
> style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
> > > ![if =
> > >
> !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=
> > >
> > >
> > > <p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
> > > color=3Dnavy face=3DArial><span
> > >
> style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>E=
> > > ddy<o:p></o:p></span></font></span></p>
> > >
> > > <p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
> > > color=3Dnavy face=3DArial><span
> > >
> style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
> > > ![if =
> > >
> !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=
> > >
> > >
> > > <p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
> > > color=3Dblack
> > > face=3DTahoma><span =
> > > style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original
> > > Message-----<br>
> > > <b><span style=3D'font-weight:bold'>From:</span></b> Julian Satran
> > > [mailto:Julian_Satran@il.ibm.com]<br>
> > > <b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, February =
> > > 15, 2002
> > > 12:30 PM<br>
> > > <b><span style=3D'font-weight:bold'>To:</span></b> Eddy Quicksall<br>
> > > <b><span style=3D'font-weight:bold'>Subject:</span></b> Re: FW: iSCSI: =
> > > support
> > > value of ?</span></font></p>
> > >
> > > <p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
> > > face=3D"Times New Roman"><span
> > > style=3D'font-size:12.0pt'><![if =
> > > !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></p>
> > >
> > > <p class=3DMsoNormal =
> > > style=3D'mso-margin-top-alt:0in;margin-right:0in;margin-bottom:
> > > 12.0pt;margin-left:.5in'><font size=3D3 color=3Dblack face=3D"Times New
> =
> > > Roman"><span
> > > style=3D'font-size:12.0pt;color:black'><br>
> > > </span></font><font size=3D2 color=3Dblack face=3Dsans-serif><span =
> > > style=3D'font-size:
> > > 10.0pt;font-family:sans-serif;color:black'>The same value as Enquiry in
> =
> > > SCSI. &nbsp;I
> > > heard no other comment than yours.</span></font><font =
> > > color=3Dblack><span
> > > style=3D'color:black'> <br>
> > > <br>
> > > </span></font><font size=3D2 color=3Dblack face=3Dsans-serif><span =
> > > style=3D'font-size:
> > > 10.0pt;font-family:sans-serif;color:black'>Julo</span></font><font =
> > > color=3Dblack><span
> > > style=3D'color:black'> <br style=3D'mso-special-character:line-break'>
> > > <![if !supportLineBreakNewLine]><br =
> > > style=3D'mso-special-character:line-break'>
> > > <![endif]></span></font><font color=3Dblack><span =
> > > style=3D'color:black;mso-color-alt:
> > > windowtext'><o:p></o:p></span></font></p>
> > >
> > > <table border=3D0 cellpadding=3D0 width=3D"100%" =
> > > style=3D'width:100.0%;mso-cellspacing:
> > >  1.5pt;margin-left:.5in'>
> > >  <tr>
> > >   <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
> > >   <p class=3DMsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><font =
> > > size=3D3
> > >   color=3Dblack face=3D"Times New Roman"><span =
> > > style=3D'font-size:12.0pt;color:black;
> > >   mso-color-alt:windowtext'><o:p></o:p></span></font></p>
> > >   </td>
> > >   <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
> > >   <p class=3DMsoNormal><b><font size=3D1 color=3Dblack =
> > > face=3Dsans-serif><span
> > >   =
> > >
> style=3D'font-size:7.5pt;font-family:sans-serif;color:black;font-weight:=
> > > bold'>Eddy
> > >   Quicksall &lt;Eddy_Quicksall@ivivity.com&gt;</span></font></b><font
> > >   color=3Dblack><span style=3D'color:black'> </span></font><font =
> > > color=3Dblack><span
> > >   =
> > >
> style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
> > > </p>
> > >   <p><font size=3D1 color=3Dblack face=3Dsans-serif><span =
> > > style=3D'font-size:7.5pt;
> > >   font-family:sans-serif;color:black'>14-02-02 19:51</span></font><font
> > >   color=3Dblack><span style=3D'color:black'> </span></font><font =
> > > color=3Dblack><span
> > >   =
> > >
> style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
> > > </p>
> > >   </td>
> > >   <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
> > >   <p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DArial><span
> > >   style=3D'font-size:7.5pt;font-family:Arial;color:black'>&nbsp; &nbsp;
> =
> > > &nbsp;
> > >   &nbsp; </span></font><font color=3Dblack><span =
> > > style=3D'color:black'><br>
> > >   </span></font><font size=3D1 color=3Dblack face=3Dsans-serif><span
> > >   style=3D'font-size:7.5pt;font-family:sans-serif;color:black'>&nbsp; =
> > > &nbsp; &nbsp;
> > >   &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;Julian =
> > > Satran/Haifa/IBM@IBMIL</span></font><font
> > >   color=3Dblack><span style=3D'color:black'> <br>
> > >   </span></font><font size=3D1 color=3Dblack face=3Dsans-serif><span
> > >   style=3D'font-size:7.5pt;font-family:sans-serif;color:black'>&nbsp; =
> > > &nbsp; &nbsp;
> > >   &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;</span></font><font =
> > > color=3Dblack><span
> > >   style=3D'color:black'> <br>
> > >   </span></font><font size=3D1 color=3Dblack face=3Dsans-serif><span
> > >   style=3D'font-size:7.5pt;font-family:sans-serif;color:black'>&nbsp; =
> > > &nbsp; &nbsp;
> > >   &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;FW: iSCSI: support value =
> > > of ?</span></font><font
> > >   color=3Dblack><span style=3D'color:black'> <br>
> > >   <br>
> > >   </span></font><font size=3D1 color=3Dblack face=3DArial><span =
> > > style=3D'font-size:
> > >   7.5pt;font-family:Arial;color:black'>&nbsp; &nbsp; &nbsp; =
> > > &nbsp;</span></font><font
> > >   color=3Dblack><span =
> > >
> style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
> > > </p>
> > >   </td>
> > >  </tr>
> > > </table>
> > >
> > > <p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
> > > color=3Dblack
> > > face=3D"Times New Roman"><span =
> > > style=3D'font-size:12.0pt;color:black'><br>
> > > <br>
> > > </span></font><font size=3D2 color=3Dnavy face=3DArial><span =
> > > style=3D'font-size:10.0pt;
> > > font-family:Arial;color:navy'>I didn't see any responses on this. Is =
> > > the
> > > &quot;?&quot; syntax of any good other than for vendor specific =
> > > commands?</span></font><font
> > > color=3Dblack><span style=3D'color:black'> </span></font><font =
> > > color=3Dblack><span
> > >
> style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
> > > </p>
> > >
> > > <p style=3D'margin-left:.5in'><font size=3D2 color=3Dnavy =
> > > face=3DArial><span
> > >
> style=3D'font-size:10.0pt;font-family:Arial;color:navy'>&nbsp;</span></f=
> > > ont><font
> > > color=3Dblack><span style=3D'color:black'> </span></font><font =
> > > color=3Dblack><span
> > >
> style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
> > > </p>
> > >
> > > <p style=3D'margin-left:.5in'><font size=3D2 color=3Dnavy =
> > > face=3DArial><span
> > >
> style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Eddy</span></fon=
> > > t><font
> > > color=3Dblack><span style=3D'color:black'> </span></font><font =
> > > color=3Dblack><span
> > >
> style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
> > > </p>
> > >
> > > <p style=3D'margin-left:.5in'><font size=3D2 color=3Dnavy =
> > > face=3DArial><span
> > >
> style=3D'font-size:10.0pt;font-family:Arial;color:navy'>&nbsp;</span></f=
> > > ont><font
> > > color=3Dblack><span style=3D'color:black'> </span></font><font =
> > > color=3Dblack><span
> > >
> style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
> > > </p>
> > >
> > > <p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack =
> > > face=3DTahoma><span
> > > style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original
> > > Message-----<b><span style=3D'font-weight:bold'><br>
> > > From:</span></b> Eddy Quicksall =
> > > [mailto:Eddy_Quicksall@ivivity.com]<b><span
> > > style=3D'font-weight:bold'><br>
> > > Sent:</span></b> Wednesday, February 06, 2002 5:29 PM<b><span =
> > > style=3D'font-weight:
> > > bold'><br>
> > > To:</span></b> ips@ece. cmu. edu (E-mail)<b><span =
> > > style=3D'font-weight:bold'><br>
> > > Subject:</span></b> iSCSI: support value of ?</span></font><font =
> > > color=3Dblack><span
> > > style=3D'color:black'> </span></font><font color=3Dblack><span =
> > > style=3D'color:black;
> > > mso-color-alt:windowtext'><o:p></o:p></span></font></p>
> > >
> > > <p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack =
> > > face=3DArial><span
> > >
> style=3D'font-size:10.0pt;font-family:Arial;color:black'>&nbsp;</span></=
> > > font><font
> > > color=3Dblack><span style=3D'color:black'> </span></font><font =
> > > color=3Dblack><span
> > >
> style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
> > > </p>
> > >
> > > <p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack =
> > > face=3DArial><span
> > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>Section 2.2.4 =
> > > of draft
> > > 10 says:</span></font><font color=3Dblack><span style=3D'color:black'> =
> > > </span></font><font
> > > color=3Dblack><span =
> > >
> style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
> > > </p>
> > >
> > > <p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack =
> > > face=3DArial><span
> > >
> style=3D'font-size:10.0pt;font-family:Arial;color:black'>&nbsp;</span></=
> > > font><font
> > > color=3Dblack><span style=3D'color:black'> </span></font><font =
> > > color=3Dblack><span
> > >
> style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
> > > </p>
> > >
> > > <p style=3D'margin-left:.5in'><font size=3D3 color=3Dblack =
> > > face=3DCourier><span
> > > style=3D'font-size:12.0pt;font-family:Courier;color:black'>The value
> > > &quot;?&quot; with any key has the meaning of enquiry and should =
> > > be</span></font><font
> > > color=3Dblack><span style=3D'color:black'> </span></font><font =
> > > color=3Dblack><span
> > >
> style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
> > > </p>
> > >
> > > <p style=3D'margin-left:.5in'><font size=3D3 color=3Dblack =
> > > face=3DCourier><span
> > > style=3D'font-size:12.0pt;font-family:Courier;color:black'>answered =
> > > with the
> > > current value or &quot;NotUnderstood&quot;.</span></font><font =
> > > color=3Dblack><span
> > > style=3D'color:black'> </span></font><font color=3Dblack><span =
> > > style=3D'color:black;
> > > mso-color-alt:windowtext'><o:p></o:p></span></font></p>
> > >
> > > <p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack =
> > > face=3DArial><span
> > >
> style=3D'font-size:10.0pt;font-family:Arial;color:black'>&nbsp;</span></=
> > > font><font
> > > color=3Dblack><span style=3D'color:black'> </span></font><font =
> > > color=3Dblack><span
> > >
> style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
> > > </p>
> > >
> > > <p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack =
> > > face=3DArial><span
> > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>What good is =
> > > this?</span></font><font
> > > color=3Dblack><span style=3D'color:black'> </span></font><font =
> > > color=3Dblack><span
> > >
> style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
> > > </p>
> > >
> > > <p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack =
> > > face=3DArial><span
> > >
> style=3D'font-size:10.0pt;font-family:Arial;color:black'>&nbsp;</span></=
> > > font><font
> > > color=3Dblack><span style=3D'color:black'> </span></font><font =
> > > color=3Dblack><span
> > >
> style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
> > > </p>
> > >
> > > <p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack =
> > > face=3DArial><span
> > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>You should =
> > > already know
> > > the answer as a result of login or text =
> > > negotiations.</span></font><font
> > > color=3Dblack><span style=3D'color:black'> </span></font><font =
> > > color=3Dblack><span
> > >
> style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
> > > </p>
> > >
> > > <p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack =
> > > face=3DArial><span
> > >
> style=3D'font-size:10.0pt;font-family:Arial;color:black'>&nbsp;</span></=
> > > font><font
> > > color=3Dblack><span style=3D'color:black'> </span></font><font =
> > > color=3Dblack><span
> > >
> style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
> > > </p>
> > >
> > > <p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack =
> > > face=3DArial><span
> > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>Here are the =
> > > only keys
> > > that can be used in FFP by the initiator:</span></font><font =
> > > color=3Dblack><span
> > > style=3D'color:black'> </span></font><font color=3Dblack><span =
> > > style=3D'color:black;
> > > mso-color-alt:windowtext'><o:p></o:p></span></font></p>
> > >
> > > <p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack =
> > > face=3DArial><span
> > >
> style=3D'font-size:10.0pt;font-family:Arial;color:black'>&nbsp;</span></=
> > > font><font
> > > color=3Dblack><span style=3D'color:black'> </span></font><font =
> > > color=3Dblack><span
> > >
> style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
> > > </p>
> > >
> > > <p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack =
> > > face=3DArial><span
> > >
> style=3D'font-size:10.0pt;font-family:Arial;color:black'>1)</span></font=
> > > ><font
> > > size=3D1 color=3Dblack><span style=3D'font-size:7.5pt;color:black'> =
> > > &nbsp; &nbsp;
> > > &nbsp; </span></font><font color=3Dblack><span =
> > > style=3D'color:black'>SendTargets &#8211;
> > > we already have defined behavior for that key and those get the =
> > > information
> > > anyway </span></font><font color=3Dblack><span =
> > > style=3D'color:black;mso-color-alt:
> > > windowtext'><o:p></o:p></span></font></p>
> > >
> > > <p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack =
> > > face=3DArial><span
> > >
> style=3D'font-size:10.0pt;font-family:Arial;color:black'>2)</span></font=
> > > ><font
> > > size=3D1 color=3Dblack><span style=3D'font-size:7.5pt;color:black'> =
> > > &nbsp; &nbsp;
> > > &nbsp; </span></font><font color=3Dblack><span =
> > > style=3D'color:black'>TargetName &#8211;
> > > that is IO by initiator so he can't send that key anyway. Also, he has =
> > > to
> > > already know the target. </span></font><font color=3Dblack><span
> > >
> style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
> > > </p>
> > >
> > > <p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack =
> > > face=3DArial><span
> > >
> style=3D'font-size:10.0pt;font-family:Arial;color:black'>3)</span></font=
> > > ><font
> > > size=3D1 color=3Dblack><span style=3D'font-size:7.5pt;color:black'> =
> > > &nbsp; &nbsp;
> > > &nbsp; </span></font><font color=3Dblack><span =
> > > style=3D'color:black'>TargetAlias &#8211;
> > > &nbsp;&quot;this name MUST be communicated to the initiator during a
> > > Login&quot;. So that is already known. </span></font><font =
> > > color=3Dblack><span
> > >
> style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
> > > </p>
> > >
> > > <p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack =
> > > face=3DArial><span
> > >
> style=3D'font-size:10.0pt;font-family:Arial;color:black'>4)</span></font=
> > > ><font
> > > size=3D1 color=3Dblack><span style=3D'font-size:7.5pt;color:black'> =
> > > &nbsp; &nbsp;
> > > &nbsp; </span></font><font color=3Dblack><span =
> > > style=3D'color:black'>InitiatorAlias
> > > &#8211; the initiator should already know his alias </span></font><font
> =
> > > color=3Dblack><span
> > >
> style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
> > > </p>
> > >
> > > <p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack =
> > > face=3DArial><span
> > >
> style=3D'font-size:10.0pt;font-family:Arial;color:black'>5)</span></font=
> > > ><font
> > > size=3D1 color=3Dblack><span style=3D'font-size:7.5pt;color:black'> =
> > > &nbsp; &nbsp;
> > > &nbsp; </span></font><font color=3Dblack><span =
> > > style=3D'color:black'>TargetAddress
> > > &#8211; the target is the only one that can send this in a response =
> > > </span></font><font
> > > color=3Dblack><span =
> > >
> style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
> > > </p>
> > >
> > > <p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack =
> > > face=3DArial><span
> > >
> style=3D'font-size:10.0pt;font-family:Arial;color:black'>6)</span></font=
> > > ><font
> > > size=3D1 color=3Dblack><span style=3D'font-size:7.5pt;color:black'> =
> > > &nbsp; &nbsp;
> > > &nbsp; </span></font><font color=3Dblack><span =
> > > style=3D'color:black'>MaxRecvPDULength
> > > &#8211; this should be known from the negotiations </span></font><font =
> > > color=3Dblack><span
> > >
> style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
> > > </p>
> > >
> > > <p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack =
> > > face=3DArial><span
> > >
> style=3D'font-size:10.0pt;font-family:Arial;color:black'>7)</span></font=
> > > ><font
> > > size=3D1 color=3Dblack><span style=3D'font-size:7.5pt;color:black'> =
> > > &nbsp; &nbsp;
> > > &nbsp; </span></font><font color=3Dblack><span =
> > > style=3D'color:black'>Vendor
> > > Specific &#8211; Could this be the reason? If so, lets say that so we =
> > > don't have to
> > > add a lot of silly code. Or, lets say that the response to =
> > > &quot;?&quot; can be
> > > &quot;Reject&quot; meaning that we don't support that syntax =
> > > (currently, the
> > > definition of the &quot;Reject value&quot; does not fit this). =
> > > </span></font><font
> > > color=3Dblack><span =
> > >
> style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
> > > </p>
> > >
> > > <p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack =
> > > face=3DArial><span
> > >
> style=3D'font-size:10.0pt;font-family:Arial;color:black'>&nbsp;</span></=
> > > font><font
> > > color=3Dblack><span style=3D'color:black'> </span></font><font =
> > > color=3Dblack><span
> > >
> style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
> > > </p>
> > >
> > > <p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack =
> > > face=3DArial><span
> > >
> style=3D'font-size:10.0pt;font-family:Arial;color:black'>Eddy</span></fo=
> > > nt><font
> > > color=3Dblack><span style=3D'color:black'> </span></font><font =
> > > color=3Dblack><span
> > >
> style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
> > > </p>
> > >
> > > </div>
> > >
> > > </body>
> > >
> > > </html>
> > >
> > > ------_=_NextPart_001_01C1B64A.37A65F90--
> > >
> >
> > --
> > ##################################
> > Santosh Rao
> > Software Design Engineer,
> > HP-UX iSCSI Driver Team,
> > Hewlett Packard, Cupertino.
> > email : santoshr@cup.hp.com
> > Phone : 408-447-3751
> > ##################################
>
--=_alternative 005B1F98C2256B66_=-- From owner-ips@ece.cmu.edu Wed Feb 20 12:57: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 LAA06207 for ; Wed, 20 Feb 2002 11:50:15 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1KG5ES00411 for ips-outgoing; Wed, 20 Feb 2002 11:05:14 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ntmail.qlc.com (216-231-2-8.qlc.com [216.231.2.8]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1KG5Cj00406 for ; Wed, 20 Feb 2002 11:05:12 -0500 (EST) Received: by ntmail.qlc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Feb 2002 08:03:14 -0800 Message-ID: From: Chuck Micalizzi To: "'Eddy Quicksall'" , John Hufferd Cc: Julian Satran , ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK Date: Wed, 20 Feb 2002 08:06:35 -0800 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, John, I assume the DataACK SNACK PDU will also have to change to include the TTT. chuck -----Original Message----- From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] Sent: Wednesday, February 20, 2002 6:31 AM To: John Hufferd Cc: Julian Satran; Chuck Micalizzi; ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK My feeling is to bight the bullet now and keep the consistency. Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Tuesday, February 19, 2002 9:52 PM To: Eddy Quicksall Cc: Julian Satran; Chuck Micalizzi; ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK That would be possible. Your suggestion changes two PDUs, OK, and keeps things somewhat more consistent The question is do we want to change two PDUs, or Change 1 PDU . . . . 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 Eddy Quicksall @ece.cmu.edu on 02/19/2002 03:21:03 PM Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS, Julian Satran/Haifa/IBM@IBMIL cc: Chuck Micalizzi , ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK How about moving bi-di to 40 and residual count to 44? Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Tuesday, February 19, 2002 4:43 AM To: Julian Satran Cc: Chuck Micalizzi; ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK Julian, If you include the TTT in the Data-In PDU, you will need to change the format of the Data-In PDU. The TTT is usually placed at displacement 20-23, if you do that, you will have to reformat the Data-In PDU. Perhaps the best thing to do is to move the residual count to displacement 44-47. This is the same displacement that is used by the SCSI Response PDU for the residual count for Bidirectional reads. The other PDU that has a residual count, is the SCSI Response PDU and it also has residual in bytes 20-23, so there is no perfect solution. What do you plan to do? If this change worth it? . . . 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 Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 02/15/2002 11:52:06 PM Sent by: owner-ips@ece.cmu.edu To: "Chuck Micalizzi" cc: ips@ece.cmu.edu Subject: RE: iSCSI: DataACK SNACK Chuck, The Initiator Task Tag is thhe only reliable indicator the protocol provides today. If nobody shouts against it we might let the target provide a Target Transfer Task for Data-In PDUs that have the A bit set to be returned with the ACK for target convenience. Julo "Chuck Micalizzi" Satran/Haifa/IBM@IBMIL cc: 15-02-02 23:14 Subject: RE: iSCSI: DataACK SNACK Julian, Thank you for the response. Let me try to be more direct. If a target has been issued multiple read commands, with transfer counts that exceed the negotiated maxBurstSize. After the target sends a data sequence for one of these commands must it wait for a DataACK before sending a data sequence for another command. Or is it free to send a data sequence for each outstanding command? If the target can have a data sequence in flight for each active command then it must expect a DataACK for each sequence sent with the Acknowledge bit set. If the DataACK SNACK doesn't include a task Tag the target can't be certain as to which data sequence the initiator is acknowledging. So how can the target determine which resources to free or which sequence to send next? chuck -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, February 15, 2002 9:30 AM To: Chuck Micalizzi Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: DataACK SNACK DataACK is a "bulk ack". Answering the last (in case of several) is good enough. I fail to see your point. Julo "Chuck Micalizzi" To: Sent by: owner-ips@ece.cmu.edu cc: 14-02-02 21:02 Subject: iSCSI: DataACK SNACK All, I have a question regarding DataACK. Rev. 10 section 10.16.1 states: For a Data/R2T SNACK, the Initiator Task Tag MUST be set to the Initiator Task Tag of the referenced Command. Otherwise, it is reserved. it also states: The DataACK is used to free resources at the target and not to request or imply data retransmission. Is the target allowed to have more than one DataACK outstanding on a connection? If multiple outstanding DataACKs are allowed per connection then in my opinion the DataACK must have a valid task tag inorder for the target to associate the DataACK with the appropriate resources to be freed. chuck micalizzi Qlogic Corp. From owner-ips@ece.cmu.edu Wed Feb 20 13:24: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 NAA13003 for ; Wed, 20 Feb 2002 13:24:44 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1KHUg607335 for ips-outgoing; Wed, 20 Feb 2002 12:30:42 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from erie.mcdata.com (mcjekyll.mcdata.com [144.49.6.25]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1KHUdj07325 for ; Wed, 20 Feb 2002 12:30:39 -0500 (EST) Received: from erie.mcdata.com ([172.18.1.35]) by erie.mcdata.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DXFNNCH9; Wed, 20 Feb 2002 10:30:28 -0700 Received: from 144.49.154.169 by erie.mcdata.com (InterScan E-Mail VirusWall NT); Wed, 20 Feb 2002 10:30:27 -0700 Received: by grizzly.mcdata.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Feb 2002 12:30:18 -0500 Message-ID: <1B8A58D6C376FE4DB329408E2701384250C9B3@grizzly.mcdata.com> From: Ernest Dainow To: "'Joseph D. Harwood'" , Bernard Aboba , Ernest Dainow Cc: ips@ece.cmu.edu Subject: RE: Review of -10 security draft Date: Wed, 20 Feb 2002 12:30:13 -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 Can you confirm that draft 10 removes the requirement that every TCP connection must have a separate IKE Phase 2 SA? Some sections of the document seem to have been modified to reflect this, but I did notice an exception, in Section 1.2 (iFCP) "Each IPsec SA established by IKE protects a single TCP connection". If this requirement has in fact been removed, it needs to be removed from the other draft documents, such as FCIP and iSCSI. -----Original Message----- From: Joseph D. Harwood [mailto:jharwood@vesta-corp.com] Sent: Wednesday, February 20, 2002 11:02 AM To: Bernard Aboba; Ernest.Dainow@mcdata.com Cc: ips@ece.cmu.edu Subject: RE: Review of -10 security draft > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > Sent: Tuesday, February 19, 2002 2:42 PM > To: jharwood@vesta-corp.com; Ernest.Dainow@mcdata.com > Cc: ips@ece.cmu.edu > Subject: Review of -10 security draft > > > >How does requiring each connection to have its own Phase 2 SA > mitigate >the > >vulnerability in this scenario? > > IPsec doesn't protect against this at all, and the text needs to > make this > clear. > > Please take a look at the latest -10 security draft in progress to see if > this addresses the issue: > > http://www.drizzle.com/~aboba/RDMA/draft-ietf-ips-security-10.txt > It does, thanks! Best Regards, Joseph D. Harwood (408) 838-9434 jharwood@vesta-corp.com www.vesta-corp.com From owner-ips@ece.cmu.edu Wed Feb 20 15:01: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 PAA18247 for ; Wed, 20 Feb 2002 15:01:37 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1KIoDW13650 for ips-outgoing; Wed, 20 Feb 2002 13:50:13 -0500 (EST) 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 g1KIoBj13644 for ; Wed, 20 Feb 2002 13:50:11 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 501C3313F; Wed, 20 Feb 2002 11:50:05 -0700 (MST) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id E3F24440; Wed, 20 Feb 2002 11:50:03 -0700 (MST) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 20 Feb 2002 11:50:03 -0700 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Feb 2002 11:50:03 -0700 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00A512B10@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: BHS inconsistency Date: Wed, 20 Feb 2002 11:49:57 -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 Julian, There is an inconsistency in draft 10 between the definition of the Basic Header Segment in 10.2.1 and the sections defining PDU format for specific opcodes. 10.2.1 says "The Opcode, TotalAHSLength, and DataSegmentLength fields appear in all iSCSI PDUs." However, for most opcodes, the location of TotalAHSLength is marked reserved. For some opcodes such as Task Management Function Request and Response and R2T, both length fields are marked reserved. If these fields are reserved, then the Opcode would have to be interpreted inorder to perform operations handling the PDU such as putting headers and data portion into buffers or finding the start of the following PDU because a receiver is required to ignore the contents of reserved fields. This is an unnecessary complication of the initial PDU processing in the receiver. The draft should be made consistant with 10.2.1 by marking the fields as TotalAHSLength and DataSegmentLength for all opcodes. For opcodes that cannot carry an AHS or a data segment, there can be a statement "TotalAHSLength MUST be 0x00." or "TotalAHSLength MUST be 0x000000." This allows the receiver to use the fields to locate PDU boundaries regardless of opcode. Regards, Pat From owner-ips@ece.cmu.edu Wed Feb 20 15:47: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 PAA19569 for ; Wed, 20 Feb 2002 15:47:11 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1KKLQ621028 for ips-outgoing; Wed, 20 Feb 2002 15:21:26 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (IDENT:root@ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1KKLNj21021 for ; Wed, 20 Feb 2002 15:21:23 -0500 (EST) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g1KKHXn22614; Wed, 20 Feb 2002 15:17:33 -0500 Message-ID: <3C74053C.C3270C91@splentec.com> Date: Wed, 20 Feb 2002 15:21:16 -0500 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" CC: "Ips Reflector (E-mail)" , Julian Satran Subject: Re: iSCSI: key negotiation - Unrecognized value? References: <6BD67FFB937FD411A04F00D0B74FE87805CCF3CB@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 "KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote: > > What is the proper response if you recognize a key, but are offered a value > that you don't recognize? For instance, what if MaxConnections=yes is > offered? > > Where is that specified in the document? v10, pg 34, top: Any other 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. v10, pg 33, middle: If a responder does not support or is not allowed to use all of the offered options with a specific originator, it may use the constant "Reject". Comments? -- Luben Tuikov, Senior Software Engineer, Splentec Ltd. Bus: +1-905-707-1954x112, 9-5 EST. Fax: +1-905-707-1974. From owner-ips@ece.cmu.edu Wed Feb 20 15:47: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 PAA19591 for ; Wed, 20 Feb 2002 15:47:22 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1KKX4821949 for ips-outgoing; Wed, 20 Feb 2002 15:33:04 -0500 (EST) 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 g1KKX2j21944 for ; Wed, 20 Feb 2002 15:33:02 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id D09BB2B49; Wed, 20 Feb 2002 13:32:58 -0700 (MST) Received: from axcsbh5.cos.agilent.com (axcsbh5.cos.agilent.com [130.29.152.150]) by msgrel1.cos.agilent.com (Postfix) with SMTP id C70D84CC; Wed, 20 Feb 2002 13:32:56 -0700 (MST) Received: from 130.29.152.150 by axcsbh5.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 20 Feb 2002 13:32:56 -0700 Received: by axcsbh5.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Feb 2002 13:32:55 -0700 Message-ID: <9F8400020EC5D311AF62009027C3961605F26888@axcs09.cos.agilent.com> From: "LEMAY,KEVIN (A-Roseville,ex1)" To: "'Luben Tuikov'" , "KRUEGER,MARJORIE (HP-Roseville,ex1)" Cc: "Ips Reflector (E-mail)" , Julian Satran Subject: RE: iSCSI: key negotiation - Unrecognized value? Date: Wed, 20 Feb 2002 13:32:47 -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 My impression was that "notUnderstood" was used if the key name itself could not be decoded. I believe that the correct behavior in the specific case should be: Originator-> MaxConnections=yes Responder-> MaxConnections=reject (with a login response of "Initiator error") The reason being, is that this key is clearly defined as a numeric field with specific ranges of values. To send a non-numeric value for this key would be an initiator error and should be treated as such. Although processing as "notunderstood" may allow the login to continue, it will also "cover up" the error allowing bad code to continue live on. Do we really want to make it easy for people to not even follow the spec? Kevin Lemay -----Original Message----- From: Luben Tuikov [mailto:luben@splentec.com] Sent: Wednesday, February 20, 2002 12:17 PM To: KRUEGER,MARJORIE (HP-Roseville,ex1) Cc: Ips Reflector (E-mail); Julian Satran Subject: Re: iSCSI: key negotiation - Unrecognized value? Marjorie, Julian, all, When a value doesn't belong to the valid set of assignable values to a key, but is offered, as Marjorie's example, shouldn't the following take place: Originator-> MaxConnections=yes Responder-> MaxConnections=NotUnderstood Also, isn't ``Reject'' used for a valid, assignable value, but for which the responder has no resources: Originator-> MaxConnections=4294967296 Responder-> MaxConnections=Reject I.e. the responder cannot allow 2^32 connections, since the OS will not allow it in the first place... (If your OS allows it, replace the number with 1e3000 above ;-) ? P.S. The ``NotUnderstood'' reply above would also be semantically correct. -- Luben Tuikov, Senior Software Engineer, Splentec Ltd. Bus: +1-905-707-1954x112, 9-5 EST. Fax: +1-905-707-1974. From owner-ips@ece.cmu.edu Wed Feb 20 15:48: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 PAA19642 for ; Wed, 20 Feb 2002 15:48:36 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1KJx1219303 for ips-outgoing; Wed, 20 Feb 2002 14:59:01 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from relay1.softcomca.com (relay.softcomca.com [168.144.1.67] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1KJwwj19295 for ; Wed, 20 Feb 2002 14:58:58 -0500 (EST) Received: from m2w027 ([168.144.108.27]) by relay1.softcomca.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 20 Feb 2002 14:59:03 -0500 X-Originating-IP: 64.170.220.19 X-URL: http://www.mail2web.com/ Subject: RE: RE: FW: FW: iSCSI: support value of ? From: "rakesh@qpackets.com" Date: Wed, 20 Feb 2002 14:59:36 -0500 To: "rdr@io.iol.unh.edu" , "eddy_quicksall@ivivity.com" , "ips@ece.cmu.edu" , "julian_satran@il.ibm.com" Reply-To: rakesh@qpackets.com X-Priority: 3 X-MSMail-Priority: Normal MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: JMail 3.7.0 by Dimac (www.dimac.net) Message-ID: X-OriginalArrivalTime: 20 Feb 2002 19:59:03.0340 (UTC) FILETIME=[0B9E7EC0:01C1BA49] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by ece.cmu.edu id g1KJwwj19296 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Just to highlight some of the issues that I have in my bag. I tend to agree with Bob on this with a *if*. Anytime in a negotiation kind of environment the ideal steps to follow are - I->T: proposal T->I: accept or reject This kind of leads into a situation that the initiator relies on the intelligence of the target to accept or reject the proposal. The cases of reject should be qualified with substantial reasons for the initiator to conduct a postmortem. Since there is no built in integrity checks for the Login PDU's (as in FFP) I believe a comprehensive reject reason would be of great help. One more reason the query capabilities should be dispensed off would be security concerns that it could generate. But sometimes the capability of query does help for eg: in the case(s) of a SNMP/DMI agent. - Rakesh Original Message: ----------------- From: Robert D. Russell rdr@io.iol.unh.edu Date: Wed, 20 Feb 2002 10:52:35 -0500 (EST) To: Eddy_Quicksall@ivivity.com, ips@ece.cmu.edu, julian_satran@il.ibm.com Subject: RE: FW: FW: iSCSI: support value of ? Julian: I first brought up the subject of eliminating ? last December. Your reply is attached below. Perhaps this latest round of e-mail postings is enough to support my contention that ? should be eliminated?? Thanks, Bob Russell > > From Julian_Satran@il.ibm.com Sat Dec 22 01:57:36 2001 > To: "Robert D. Russell" > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: enquiry key > > Bob, > > "Robert D. Russell" wrote on 20-12-2001 12:48:31: > > > Julian: > > > ... snip snip ... > > > > My personal opinion is that "key=?" seems fairly useless -- if they > are > > to operate correctly, both sides of a connection really have to know > the > > values of all the keys at all times, and the rules for negotiation > make > > it clear how and when these values change. The only real "enquiry" > > situation is when an initiator is attempting to discover targets, and > > this is handled completely differently by the use of "SendTargets". > > So when is there a use for either side to send "key=?". Unless there > > is a clear example where this is useful, we should eliminate it and > thus > > remove another special case during parameter processing. > > > I am not sure that we have all the use scenarios to afford removing it On Tue, 19 Feb 2002, Eddy Quicksall wrote: > > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Tuesday, February 19, 2002 3:19 PM > To: Eddy Quicksall > Subject: Re: FW: FW: iSCSI: support value of ? > > Eddy, > > [ Sorry, I was off on long weekend. ] > > I tend to concur with you guys. I do not see > a good usage scenario for "?" at the moment. > If we add in the support in MIB (if it isn't > there already) for querying the default capabilities > of an iSCSI entity, that should be completely > adequate to retire the "?" feature. > > Regards. > -- > Mallikarjun > > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > > Eddy Quicksall wrote: > > > > Mallikarjun, > > > > I am thinking that the value of the "?" syntax is very limited and appears > > to me as though it could be something that got left in from past needs. > > > > Do you think it has any use other than for vendor specifics? Can you give > me > > an example of where it would be needed? > > > > Eddy > > > > -----Original Message----- > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > Sent: Friday, February 15, 2002 3:21 PM > > To: Eddy_Quicksall@ivivity.com > > Cc: Julian_Satran@il.ibm.com; ips@ece.cmu.edu > > Subject: Re: FW: iSCSI: support value of ? > > > > Eddy, > > > > The '?' was originally proposed as a form of Enquiry analogous to > something > > like a PDISC for Fibre Channel ports. > > > > However, an Enquiry is more useful if it is a scheme to query the target > for > > all its supported capabilities, rather than its current value. > > > > A query for the current negotiated value was of some use in the older > login > > negotiation model wherein each side independently computed the login > > negotiation result. In such a model, the '?' could be used by initiators > to > > verify that its negotiation result was in-sync with that of the target. > > > > With the new login negotiation model, wherein, the target computes the > > result > > of the negotiation and sends it back to the initiator, the initiator knows > > the > > current negotiated values anyway. Hence, what is more useful is a scheme > to > > query the target for its supported capabilities. > > > > IMO, the '?' semantics should be modified to return the target's supported > > capabilities and not its current negotiatied value. > > > > Regards, > > Santosh > > > > > > > > Well, given that the initiator should know everything (unless I missed > > > something below), what good is it other than for vendor specific? > > > > > > The reason I'm asking is because it seems silly to support it if it has > no > > > use. > > > > > > Can someone give me an example of where it is needed (other than for > > vendor > > > specific). > > > > > > Eddy > > > > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Friday, February 15, 2002 12:30 PM > > > To: Eddy Quicksall > > > Subject: Re: FW: iSCSI: support value of ? > > > > > > > > > The same value as Enquiry in SCSI. I heard no other comment than yours. > > > > > > Julo > > > > > > > > > > > > > > > Eddy Quicksall > > > 14-02-02 19:51 > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > > cc: > > > Subject: FW: iSCSI: support value of ? > > > > > > > > > > > > > > > I didn't see any responses on this. Is the "?" syntax of any good other > > than > > > for vendor specific commands? > > > > > > Eddy > > > > > > -----Original Message----- > > > From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] > > > Sent: Wednesday, February 06, 2002 5:29 PM > > > To: ips@ece. cmu. edu (E-mail) > > > Subject: iSCSI: support value of ? > > > > > > Section 2.2.4 of draft 10 says: > > > > > > The value "?" with any key has the meaning of enquiry and should be > > > answered with the current value or "NotUnderstood". > > > > > > What good is this? > > > > > > You should already know the answer as a result of login or text > > > negotiations. > > > > > > Here are the only keys that can be used in FFP by the initiator: > > > > > > 1) SendTargets - we already have defined behavior for that key and > > > those get the information anyway > > > 2) TargetName - that is IO by initiator so he can't send that key > > > anyway. Also, he has to already know the target. > > > 3) TargetAlias - "this name MUST be communicated to the initiator > > > during a Login". So that is already known. > > > 4) InitiatorAlias - the initiator should already know his alias > > > 5) TargetAddress - the target is the only one that can send this > in > > a > > > response > > > 6) MaxRecvPDULength - this should be known from the negotiations > > > 7) Vendor Specific - Could this be the reason? If so, lets say > that > > so > > > we don't have to add a lot of silly code. Or, lets say that the response > > to > > > "?" can be "Reject" meaning that we don't support that syntax > (currently, > > > the definition of the "Reject value" does not fit this). > > > > > > Eddy > > > > > > ------_=_NextPart_001_01C1B64A.37A65F90 > > > Content-Type: text/html; > > > charset="iso-8859-1" > > > Content-Transfer-Encoding: quoted-printable > > > > > > > > xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > > > xmlns=3D"http://www.w3.org/TR/REC-html40"> > > > > > > > > > > > charset=3Diso-8859-1"> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>W= > > > ell, > > > given that the initiator should know everything (unless I missed = > > > something > > > below), what good is it other than for vendor = > > > specific?

> > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><= > > > ![if = > > > > !supportEmptyParas]> 

= > > > > > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>T= > > > he reason > > > I’m asking is because it seems silly to support it if it has no = > > > use.

> > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><= > > > ![if > !supportEmptyParas]>  > > >

> > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>C= > > > an > > > someone give me an example of where it is needed (other than for vendor > > > specific).

> > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><= > > > ![if = > > > > !supportEmptyParas]> 

= > > > > > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>E= > > > ddy

> > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><= > > > ![if = > > > > !supportEmptyParas]> 

= > > > > > > > > >

> > color=3Dblack > > > face=3DTahoma> > > style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original > > > Message-----
> > > From: Julian Satran > > > [mailto:Julian_Satran@il.ibm.com]
> > > Sent: Friday, February = > > > 15, 2002 > > > 12:30 PM
> > > To: Eddy Quicksall
> > > Subject: Re: FW: iSCSI: = > > > support > > > value of ?

> > > > > >

> > face=3D"Times New Roman"> > > style=3D'font-size:12.0pt'> > > !supportEmptyParas]> 

> > > > > >

> > style=3D'mso-margin-top-alt:0in;margin-right:0in;margin-bottom: > > > 12.0pt;margin-left:.5in'> = > > > Roman"> > > style=3D'font-size:12.0pt;color:black'>
> > > > > style=3D'font-size: > > > 10.0pt;font-family:sans-serif;color:black'>The same value as Enquiry in > = > > > SCSI.  I > > > heard no other comment than yours. > > color=3Dblack> > > style=3D'color:black'>
> > >
> > > > > style=3D'font-size: > > > 10.0pt;font-family:sans-serif;color:black'>Julo > > color=3Dblack> > > style=3D'color:black'>
> > >
> > style=3D'mso-special-character:line-break'> > > > > > style=3D'color:black;mso-color-alt: > > > windowtext'>

> > > > > > > > style=3D'width:100.0%;mso-cellspacing: > > > 1.5pt;margin-left:.5in'> > > > > > > > > > > > > > > > > > >
> > >

  > > size=3D3 > > > color=3Dblack face=3D"Times New Roman"> > > style=3D'font-size:12.0pt;color:black; > > > mso-color-alt:windowtext'>

> > > 		> > >

> > face=3Dsans-serif> > > = > > > > style=3D'font-size:7.5pt;font-family:sans-serif;color:black;font-weight:= > > > bold'>Eddy > > > Quicksall > > color=3Dblack> > > color=3Dblack> > > = > > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > >

> > style=3D'font-size:7.5pt; > > > font-family:sans-serif;color:black'>14-02-02 19:51 > > color=3Dblack> > > color=3Dblack> > > = > > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > 		> > >

> > style=3D'font-size:7.5pt;font-family:Arial;color:black'>    > = > > >   > > >   > > style=3D'color:black'>
> > > > > style=3D'font-size:7.5pt;font-family:sans-serif;color:black'>  = > > >     > > >   To:        Julian = > > > Satran/Haifa/IBM@IBMIL > > color=3Dblack>
> > > > > style=3D'font-size:7.5pt;font-family:sans-serif;color:black'>  = > > >     > > >   cc:         > > color=3Dblack> > > style=3D'color:black'>
> > > > > style=3D'font-size:7.5pt;font-family:sans-serif;color:black'>  = > > >     > > >   Subject:        FW: iSCSI: support value = > > > of ? > > color=3Dblack>
> > >
> > > > > style=3D'font-size: > > > 7.5pt;font-family:Arial;color:black'>      = > > >   > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > >
> > > > > >

> > color=3Dblack > > > face=3D"Times New Roman"> > > style=3D'font-size:12.0pt;color:black'>
> > >
> > > > > style=3D'font-size:10.0pt; > > > font-family:Arial;color:navy'>I didn't see any responses on this. Is = > > > the > > > "?" syntax of any good other than for vendor specific = > > > commands? > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:navy'>  > > ont> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Eddy > > t> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:navy'>  > > ont> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DTahoma> > > style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original > > > Message-----
> > > From: Eddy Quicksall = > > > [mailto:Eddy_Quicksall@ivivity.com] > > style=3D'font-weight:bold'>
> > > Sent: Wednesday, February 06, 2002 5:29 PM > > style=3D'font-weight: > > > bold'>
> > > To: ips@ece. cmu. edu (E-mail) > > style=3D'font-weight:bold'>
> > > Subject: iSCSI: support value of ? > > color=3Dblack> > > style=3D'color:black'> > > style=3D'color:black; > > > mso-color-alt:windowtext'>

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>Section 2.2.4 = > > > of draft > > > 10 says: = > > > > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DCourier> > > style=3D'font-size:12.0pt;font-family:Courier;color:black'>The value > > > "?" with any key has the meaning of enquiry and should = > > > be > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DCourier> > > style=3D'font-size:12.0pt;font-family:Courier;color:black'>answered = > > > with the > > > current value or "NotUnderstood". > > color=3Dblack> > > style=3D'color:black'> > > style=3D'color:black; > > > mso-color-alt:windowtext'>

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>What good is = > > > this? > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>You should = > > > already know > > > the answer as a result of login or text = > > > negotiations. > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>Here are the = > > > only keys > > > that can be used in FFP by the initiator: > > color=3Dblack> > > style=3D'color:black'> > > style=3D'color:black; > > > mso-color-alt:windowtext'>

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>1) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>SendTargets – > > > we already have defined behavior for that key and those get the = > > > information > > > anyway > > style=3D'color:black;mso-color-alt: > > > windowtext'>

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>2) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>TargetName – > > > that is IO by initiator so he can't send that key anyway. Also, he has = > > > to > > > already know the target. > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>3) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>TargetAlias – > > >  "this name MUST be communicated to the initiator during a > > > Login". So that is already known. > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>4) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>InitiatorAlias > > > – the initiator should already know his alias = > > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>5) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>TargetAddress > > > – the target is the only one that can send this in a response = > > > > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>6) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>MaxRecvPDULength > > > – this should be known from the negotiations > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>7) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>Vendor > > > Specific – Could this be the reason? If so, lets say that so we = > > > don't have to > > > add a lot of silly code. Or, lets say that the response to = > > > "?" can be > > > "Reject" meaning that we don't support that syntax = > > > (currently, the > > > definition of the "Reject value" does not fit this). = > > > > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>Eddy > > nt> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >
> > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C1B64A.37A65F90-- > > > > > > > -- > > ################################## > > Santosh Rao > > Software Design Engineer, > > HP-UX iSCSI Driver Team, > > Hewlett Packard, Cupertino. > > email : santoshr@cup.hp.com > > Phone : 408-447-3751 > > ################################## > -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . From owner-ips@ece.cmu.edu Wed Feb 20 15:49: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 PAA19691 for ; Wed, 20 Feb 2002 15:49:30 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1KK5VE19770 for ips-outgoing; Wed, 20 Feb 2002 15:05:31 -0500 (EST) 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 g1KK5Sj19762 for ; Wed, 20 Feb 2002 15:05:29 -0500 (EST) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel10.hp.com (Postfix) with ESMTP id 3ED8BC0036A for ; Wed, 20 Feb 2002 12:05:23 -0800 (PST) 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 MAA05812 for ; Wed, 20 Feb 2002 12:05:15 -0800 (PST) Message-ID: <3C740231.E251C6F9@cup.hp.com> Date: Wed, 20 Feb 2002 12:08:17 -0800 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: IPS Reflector Subject: Re: iSCSI: key negotiation - Unrecognized value? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello, It seems like there are several possible responses on seeing a numeric key being offered with a non-numeric key value. (ex : "MaxBurstSize=yes", or "MaxConnections=yes"). 1) Target ignores the received key, without affecting basic function. It responds to the key with NotUnderstood. Login negotiation outcome is then initiator implementation dependent. Most likely, the initiator will terminate the TCP connection and error back to the caller indicating that it could not open an iscsi connection. 2) Target may respond with a Reject PDU response indicating a "protocol error". No login response is sent in this case (?). 3) Target responds with a login response pdu indicating a status_class_detail of 0x0207 (Missing Parameter). 4) Target may react to this error as a "format error" and close the TCP connection. In all the cases, the end result is TCP connection termination. However, the response (2) is the least desirable, since no long response is generated. I believe that (1) coupled with (3) is the most desirable behaviour. Regards, Santosh Julian Satran wrote: > > If it is not a list element the it is Reject. If it is a list element > and you recognize others then ignore the "bad" value else "Reject". > > Regards, > Julo > > "KRUEGER,MARJORIE (HP-Roseville,ex1)" > To: "Ips > Sent by: owner-ips@ece.cmu.edu Reflector (E-mail)" > > 20-02-02 03:22 cc: > Subject: iSCSI: > key negotiation - Unrecognized > value? > > > > What is the proper response if you recognize a key, but are offered a > value > that you don't recognize? For instance, what if MaxConnections=yes is > offered? > > Where is that specified in the document? > > Marjorie Krueger > Networked Storage Architecture > Networked Storage Solutions Org. > Hewlett-Packard > tel: +1 916 785 2656 > fax: +1 916 785 0391 > email: marjorie_krueger@hp.com -- ################################## 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 Wed Feb 20 15:51: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 PAA19726 for ; Wed, 20 Feb 2002 15:51:03 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1KK1D219440 for ips-outgoing; Wed, 20 Feb 2002 15:01:13 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1KK1Bj19436 for ; Wed, 20 Feb 2002 15:01:12 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1KK13h20290; Wed, 20 Feb 2002 15:01:03 -0500 (EST) Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1KK10W11085; Wed, 20 Feb 2002 15:01:00 -0500 (EST) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1QLTZDVW; Wed, 20 Feb 2002 15:00:59 -0500 Received: from travos-1.nortelnetworks.com (travos-1.us.nortel.com [47.16.69.109]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 10BC3KYQ; Wed, 20 Feb 2002 15:00:58 -0500 Message-Id: <5.1.0.14.2.20020220144517.04e1dea0@zbl6c002.corpeast.baynetworks.com> X-Sender: travos@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 20 Feb 2002 15:08:38 -0500 To: Ernest Dainow , "'Joseph D. Harwood'" , Bernard Aboba , Ernest Dainow From: Franco Travostino Subject: RE: Review of -10 security draft Cc: ips@ece.cmu.edu In-Reply-To: <1B8A58D6C376FE4DB329408E2701384250C9B3@grizzly.mcdata.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_197175563==_.ALT" Sender: owner-ips@ece.cmu.edu Precedence: bulk --=====================_197175563==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:30 PM 2/20/2002, Ernest Dainow wrote: >Can you confirm that draft 10 removes the requirement that every TCP >connection must have a separate IKE Phase 2 SA? > >Some sections of the document seem to have been modified to reflect this, >but I did notice an exception, in Section 1.2 (iFCP) "Each IPsec SA >established by IKE protects a single TCP connection". Good catch. Sections 1.2, 4.2, and the iFCP document still need to absorb this change in full. We will need an additional pass (10 for iFCP, and 11 for the security draft) to achieve full consistency across the board. thanks, -franco >If this requirement has in fact been removed, it needs to be removed from >the other draft documents, such as FCIP and iSCSI. > > >-----Original Message----- >From: Joseph D. Harwood [mailto:jharwood@vesta-corp.com] >Sent: Wednesday, February 20, 2002 11:02 AM >To: Bernard Aboba; Ernest.Dainow@mcdata.com >Cc: ips@ece.cmu.edu >Subject: RE: Review of -10 security draft > > > > > > -----Original Message----- > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > Sent: Tuesday, February 19, 2002 2:42 PM > > To: jharwood@vesta-corp.com; Ernest.Dainow@mcdata.com > > Cc: ips@ece.cmu.edu > > Subject: Review of -10 security draft > > > > > > >How does requiring each connection to have its own Phase 2 SA > > mitigate >the > > >vulnerability in this scenario? > > > > IPsec doesn't protect against this at all, and the text needs to > > make this > > clear. > > > > Please take a look at the latest -10 security draft in progress to see if > > this addresses the issue: > > > > http://www.drizzle.com/~aboba/RDMA/draft-ietf-ips-security-10.txt > > > >It does, thanks! > >Best Regards, >Joseph D. Harwood >(408) 838-9434 >jharwood@vesta-corp.com >www.vesta-corp.com Franco Travostino, Director Content Internetworking Lab Advanced Technology Nortel Networks, Inc. 600 Technology Park Billerica, MA 01821 USA Tel: 978 288 7708 Fax: 978 288 4690 email: travos@nortelnetworks.com --=====================_197175563==_.ALT Content-Type: text/html; charset="us-ascii" At 12:30 PM 2/20/2002, Ernest Dainow wrote:

Can you confirm that draft 10 removes the requirement that every TCP
connection must have a separate IKE Phase 2 SA?

Some sections of the document seem to have been modified to reflect this,
but I did notice an exception, in Section 1.2 (iFCP) "Each IPsec SA
established by IKE protects a single TCP connection".

Good catch. Sections 1.2, 4.2, and the iFCP document still need to absorb this change in full. We will need an additional pass (10 for iFCP, and 11 for the security draft) to achieve full consistency across the board.

thanks,
-franco


If this requirement has in fact been removed, it needs to be removed from
the other draft documents, such as FCIP and iSCSI.


-----Original Message-----
From: Joseph D. Harwood [mailto:jharwood@vesta-corp.com]
Sent: Wednesday, February 20, 2002 11:02 AM
To: Bernard Aboba; Ernest.Dainow@mcdata.com
Cc: ips@ece.cmu.edu
Subject: RE: Review of -10 security draft




> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
> Sent: Tuesday, February 19, 2002 2:42 PM
> To: jharwood@vesta-corp.com; Ernest.Dainow@mcdata.com
> Cc: ips@ece.cmu.edu
> Subject: Review of -10 security draft
>
>
> >How does requiring each connection to have its own Phase 2 SA
> mitigate >the
> >vulnerability in this scenario?
>
> IPsec doesn't protect against this at all, and the text needs to
> make this
> clear.
>
> Please take a look at the latest -10 security draft in progress to see if
> this addresses the issue:
>
> http://www.drizzle.com/~aboba/RDMA/draft-ietf-ips-security-10.txt
>

It does, thanks!

Best Regards,
Joseph D. Harwood
(408) 838-9434
jharwood@vesta-corp.com
www.vesta-corp.com


Franco Travostino, Director Content Internetworking Lab
Advanced Technology
Nortel Networks, Inc.
600 Technology Park
Billerica, MA 01821 USA
Tel: 978 288 7708 Fax: 978 288 4690
email: travos@nortelnetworks.com
 --=====================_197175563==_.ALT-- From owner-ips@ece.cmu.edu Wed Feb 20 15:55: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 PAA19946 for ; Wed, 20 Feb 2002 15:55:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1KKHTm20724 for ips-outgoing; Wed, 20 Feb 2002 15:17:29 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (IDENT:root@ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1KKHRj20720 for ; Wed, 20 Feb 2002 15:17:27 -0500 (EST) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g1KKDdn22584; Wed, 20 Feb 2002 15:13:40 -0500 Message-ID: <3C740452.97D39DC7@splentec.com> Date: Wed, 20 Feb 2002 15:17:22 -0500 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" CC: "Ips Reflector (E-mail)" , Julian Satran Subject: Re: iSCSI: key negotiation - Unrecognized value? References: <6BD67FFB937FD411A04F00D0B74FE87805CCF3CB@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, Julian, all, When a value doesn't belong to the valid set of assignable values to a key, but is offered, as Marjorie's example, shouldn't the following take place: Originator-> MaxConnections=yes Responder-> MaxConnections=NotUnderstood Also, isn't ``Reject'' used for a valid, assignable value, but for which the responder has no resources: Originator-> MaxConnections=4294967296 Responder-> MaxConnections=Reject I.e. the responder cannot allow 2^32 connections, since the OS will not allow it in the first place... (If your OS allows it, replace the number with 1e3000 above ;-) ? P.S. The ``NotUnderstood'' reply above would also be semantically correct. -- Luben Tuikov, Senior Software Engineer, Splentec Ltd. Bus: +1-905-707-1954x112, 9-5 EST. Fax: +1-905-707-1974. From owner-ips@ece.cmu.edu Wed Feb 20 16:42: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 PAA19581 for ; Wed, 20 Feb 2002 15:47:15 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1KJCZt15464 for ips-outgoing; Wed, 20 Feb 2002 14:12:35 -0500 (EST) 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 g1KJCXj15456 for ; Wed, 20 Feb 2002 14:12:33 -0500 (EST) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel11.hp.com (Postfix) with ESMTP id 813AD600724 for ; Wed, 20 Feb 2002 11:12:27 -0800 (PST) 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 LAA03235 for ; Wed, 20 Feb 2002 11:12:21 -0800 (PST) Message-ID: <3C73F5CA.23154D7A@cup.hp.com> Date: Wed, 20 Feb 2002 11:15:22 -0800 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: ips@ece.cmu.edu Subject: Re: iSCSI : Reject PDU reserved fields. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > All iSCSI PDU either carries a valid ITT or 0xFFFFFFFF. Only Reject > PDU > carries an invalid ITT which will not be 0xFFFFFFFF - most probably > 0x00000000. > As of today, an initiator has to be sure the PDU is not a Reject PDU > to > interpret the ITT. By setting the ITT to 0xFFFFFFFF, we avoid this > test. The above is'nt sufficient in itself. The word 4 (ITT position in other PDUs) in the Async PDU also does not contain the ITT field and is set to reserved. (0). If we're adding the ITT field (and requiring it to be 0xFFFFFFFF) in word 4 of the Reject PDU, it also needs to be added to the Async pdu. Regards, Santosh Julian Satran wrote: > > I think we may want to do this. > > Julo > > Gwendal Grignou > To: iSCSI > Sent by: owner-ips@ece.cmu.edu > cc: > 20-02-02 00:40 Subject: > iSCSI : Reject PDU > reserved fields. > > > > Hello, > > I wonder if it would be possible to have the 4 bytes word at offset > 16-19 set > to 0xFFFFFFFF in case of a Reject PDU. > All iSCSI PDU either carries a valid ITT or 0xFFFFFFFF. Only Reject > PDU > carries an invalid ITT which will not be 0xFFFFFFFF - most probably > 0x00000000. > As of today, an initiator has to be sure the PDU is not a Reject PDU > to > interpret the ITT. By setting the ITT to 0xFFFFFFFF, we avoid this > test. > > Gwendal. -- ################################## 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 Wed Feb 20 17: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 RAA22422 for ; Wed, 20 Feb 2002 17:31:51 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1KM9wg29049 for ips-outgoing; Wed, 20 Feb 2002 17:09:58 -0500 (EST) 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 g1KM9tj29044 for ; Wed, 20 Feb 2002 17:09:55 -0500 (EST) 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 g1KM9Xi31471; Wed, 20 Feb 2002 17:09:33 -0500 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with SMTP id g1KM9Wl29255; Wed, 20 Feb 2002 17:09:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15476.7835.884423.409221@pkoning.dev.equallogic.com> Date: Wed, 20 Feb 2002 17:09:31 -0500 (EST) From: Paul Koning To: luben@splentec.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: key negotiation - Unrecognized value? References: <6BD67FFB937FD411A04F00D0B74FE87805CCF3CB@xrose06.rose.hp.com> <3C740452.97D39DC7@splentec.com> X-Mailer: VM 6.75 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> Marjorie, Julian, all, When a value doesn't belong to the Luben> valid set of assignable values to a key, but is offered, as Luben> Marjorie's example, shouldn't the following take place: Luben> Originator-> MaxConnections=yes Luben> Responder-> MaxConnections=NotUnderstood That doesn't sound right, because the spec says that NotUnderstood applies to keys, not to values. The best fit is "reject" though the wording of the spec doesn't really say that. Actually, the spec is unconfortably fuzzy about all this stuff; for example, the fact that it says '...may use the constant "Reject"' is weird. I assume that should be "...MAY use..." but why does it say "may" -- what other alternative is there? For the case here, a single (non-list) key with a syntactically invalid value, I can't get particularly excited about the answer. Dealing elegantly with defective initiators isn't all that critical. Sure, if it's easy and reasonable (which it seems to be) let's generalize the wording for "Reject" so it clearly applies to this case. Luben> Also, isn't ``Reject'' used for a valid, assignable value, but Luben> for which the responder has no resources: Luben> Originator-> MaxConnections=4294967296 Luben> Responder-> MaxConnections=Reject I don't think so. That's a numeric negotiation, lower value wins. So the responder must pick a number it supports <= the value supplied by the originator. "Reject" would be valid if there is no such number. (That's not possible for this particular key.) A way to justify "reject" is with the argument that 4294967296 is not a valid integer string here because it is out of range. True, and that would justify treating it as no different from initiator saying "yes" for this key. Then again, I'd expect that a lot of responders would simply run the key through atoi(), observe that this worked, see that the value is too large, and reply with an acceptable value. paul From owner-ips@ece.cmu.edu Wed Feb 20 17:33: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 RAA22494 for ; Wed, 20 Feb 2002 17:33:55 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1KLm6X27514 for ips-outgoing; Wed, 20 Feb 2002 16:48:06 -0500 (EST) 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 g1KLm5j27510 for ; Wed, 20 Feb 2002 16:48:05 -0500 (EST) Received: from xparelay2.corp.hp.com (xparelay2.corp.hp.com [15.58.137.112]) by palrel11.hp.com (Postfix) with ESMTP id ADB3D6008C2; Wed, 20 Feb 2002 13:47:59 -0800 (PST) Received: from xpabh4.corp.hp.com (xpabh4.corp.hp.com [15.58.136.1]) by xparelay2.corp.hp.com (Postfix) with ESMTP id 794C095; Wed, 20 Feb 2002 13:47:54 -0800 (PST) Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Feb 2002 13:47:54 -0800 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF3D3@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Luben Tuikov'" Cc: "Ips Reflector (E-mail)" Subject: RE: iSCSI: key negotiation - Unrecognized value? Date: Wed, 20 Feb 2002 13:47:49 -0800 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 > When a value doesn't belong to the valid set of > assignable values to a key, but is offered, > as Marjorie's example, shouldn't the following > take place: > > Originator-> MaxConnections=yes > Responder-> MaxConnections=NotUnderstood I believe that behavior is in error, as there must be a difference in the response to an unrecognized key and an unrecognized "key value". > Also, isn't ``Reject'' used for a valid, assignable > value, but for which the responder has no resources: > > Originator-> MaxConnections=4294967296 > Responder-> MaxConnections=Reject Not as the spec is currently written. I believe Robert Russell has recommended the correct solution - the current draft doesn't specifically address the response when an invalid "key value" is offered. Marjorie From owner-ips@ece.cmu.edu Wed Feb 20 18:56: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 SAA24162 for ; Wed, 20 Feb 2002 18:56:57 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1KNY1s04702 for ips-outgoing; Wed, 20 Feb 2002 18:34:01 -0500 (EST) 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 g1KNY0j04698 for ; Wed, 20 Feb 2002 18:34:00 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id AA39A322D; Wed, 20 Feb 2002 16:33:59 -0700 (MST) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 93C6E2BA; Wed, 20 Feb 2002 16:33:58 -0700 (MST) Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id <17QZ188A>; Wed, 20 Feb 2002 16:33:58 -0700 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00A512C65@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: "LEMAY,KEVIN (A-Roseville,ex1)" , "'Luben Tuikov'" , "KRUEGER,MARJORIE (HP-Roseville,ex1)" Cc: "Ips Reflector (E-mail)" , Julian Satran Subject: RE: iSCSI: key negotiation - Unrecognized value? Date: Wed, 20 Feb 2002 16:33: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 2.2.4 says: "The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are reserved and must only be used as described here." NotUnderstood is for a key not understood by the responder. The draft doesn't say it is used for a value that is not understood. It currently describes Reject only in the context of list negotiation where it is used when none of the values in the offered list are acceptable. For the example Luben gives of a numerical negotiation (MaxConnections), Reject would never be a valid response. If the originator offers a higher valid value than the responder is willing to accept, the responder would respond with the lower number that it is willing to accept. So a valid negotiation for the case where the originator asks for a valid assignable value than the responder is willing to support would be something like: Originator-> MaxConnections=65535 Responder-> MaxConnections=3 In the example Luben gave, 4294967296 is not a valid value for MaxConnections because it is outside the range . The draft doesn't say what to do about out of range values and other invalid values. The draft does say that "selection of a value not admissible under the selection rules rules is considered a protocol error and is handled accordingly." The context for that statement appears to be the selection of a value offered by the responder, but that action would also make sense for responding to a value that is invalid for the key (wrong type of value or out of range). An implementation offering an invalid value is broken which makes proceeding with the negotiation a problem. Sending a "Reject" also would be a reasonable response to an invalid value but it seems that offering an invalid value is just as severe an error as the ones that currently are responded to with protocol errors. Regards, Pat -----Original Message----- From: LEMAY,KEVIN (A-Roseville,ex1) [mailto:kevin_lemay@agilent.com] Sent: Wednesday, February 20, 2002 12:33 PM To: 'Luben Tuikov'; KRUEGER,MARJORIE (HP-Roseville,ex1) Cc: Ips Reflector (E-mail); Julian Satran Subject: RE: iSCSI: key negotiation - Unrecognized value? My impression was that "notUnderstood" was used if the key name itself could not be decoded. I believe that the correct behavior in the specific case should be: Originator-> MaxConnections=yes Responder-> MaxConnections=reject (with a login response of "Initiator error") The reason being, is that this key is clearly defined as a numeric field with specific ranges of values. To send a non-numeric value for this key would be an initiator error and should be treated as such. Although processing as "notunderstood" may allow the login to continue, it will also "cover up" the error allowing bad code to continue live on. Do we really want to make it easy for people to not even follow the spec? Kevin Lemay -----Original Message----- From: Luben Tuikov [mailto:luben@splentec.com] Sent: Wednesday, February 20, 2002 12:17 PM To: KRUEGER,MARJORIE (HP-Roseville,ex1) Cc: Ips Reflector (E-mail); Julian Satran Subject: Re: iSCSI: key negotiation - Unrecognized value? Marjorie, Julian, all, When a value doesn't belong to the valid set of assignable values to a key, but is offered, as Marjorie's example, shouldn't the following take place: Originator-> MaxConnections=yes Responder-> MaxConnections=NotUnderstood Also, isn't ``Reject'' used for a valid, assignable value, but for which the responder has no resources: Originator-> MaxConnections=4294967296 Responder-> MaxConnections=Reject I.e. the responder cannot allow 2^32 connections, since the OS will not allow it in the first place... (If your OS allows it, replace the number with 1e3000 above ;-) ? P.S. The ``NotUnderstood'' reply above would also be semantically correct. -- Luben Tuikov, Senior Software Engineer, Splentec Ltd. Bus: +1-905-707-1954x112, 9-5 EST. Fax: +1-905-707-1974. From owner-ips@ece.cmu.edu Wed Feb 20 18:57: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 SAA24183 for ; Wed, 20 Feb 2002 18:57:54 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1KNCO803309 for ips-outgoing; Wed, 20 Feb 2002 18:12:24 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f76.pav2.hotmail.com [64.4.37.76]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1KIdFj12715 for ; Wed, 20 Feb 2002 13:39:15 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 20 Feb 2002 10:39:09 -0800 Received: from 64.38.134.105 by pv2fd.pav2.hotmail.msn.com with HTTP; Wed, 20 Feb 2002 18:39:09 GMT X-Originating-IP: [64.38.134.105] From: "Bernard Aboba" To: Ernest.Dainow@mcdata.com, jharwood@vesta-corp.com Cc: ips@ece.cmu.edu Subject: RE: Review of -10 security draft Date: Wed, 20 Feb 2002 10:39:09 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Feb 2002 18:39:09.0971 (UTC) FILETIME=[E28C6E30:01C1BA3D] Sender: owner-ips@ece.cmu.edu Precedence: bulk >Can you confirm that draft 10 removes the requirement that every TCP >connection must have a separate IKE Phase 2 SA? That's the intent, yes. >Some sections of the document seem to have been modified to reflect >this, >but I did notice an exception, in Section 1.2 (iFCP) "Each IPsec >SA >established by IKE protects a single TCP connection". Thanks for finding this. I'll remove that one too. >If this requirement has in fact been removed, it needs to be removed >from >the other draft documents, such as FCIP and iSCSI. Yes. Once we've finished with -10, we will probably need another sync up. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From owner-ips@ece.cmu.edu Wed Feb 20 20:06: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 UAA25307 for ; Wed, 20 Feb 2002 20:06:04 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1KNrgQ05757 for ips-outgoing; Wed, 20 Feb 2002 18:53:42 -0500 (EST) 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 g1KNrdj05751 for ; Wed, 20 Feb 2002 18:53:39 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA66936 for ; Wed, 20 Feb 2002 18:50:25 -0500 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.99.140.13]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1KNraE214632 for ; Wed, 20 Feb 2002 16:53:36 -0700 X-Priority: 1 (High) Importance: Normal Subject: RE: FW: FW: iSCSI: support value of ? To: "Julian Satran" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Wed, 20 Feb 2002 15:52:38 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 02/20/2002 04:53:35 PM 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 g1KNrej05753 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit There was a potential proposal for extracting the eui, from the host, or if you will -- the platform name, which might be used by a Gateway Device, and that was for the gateway to ask with a keyword followed by the "?". But we have not reached closure on any thing like that for now. . . . 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 Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 02/20/2002 08:37:59 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: RE: FW: FW: iSCSI: support value of ? If nobody speaks up I will terminate the use of ?  Julo ----- Forwarded by Julian Satran/Haifa/IBM on 20-02-02 18:34 ----- "Robert D. Russell"         To:        Eddy Quicksall 20-02-02 17:52         cc:        "ips@ece. cmu. edu (E-mail)" , Julian Satran/Haifa/IBM@IBMIL         Subject:        RE: FW: FW: iSCSI: support value of ? Julian: I first brought up the subject of eliminating ? last December. Your reply is attached below. Perhaps this latest round of e-mail postings is enough to support my contention that ? should be eliminated?? Thanks, Bob Russell > > From Julian_Satran@il.ibm.com  Sat Dec 22 01:57:36 2001 > To: "Robert D. Russell" > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: enquiry key > > Bob, > > "Robert D. Russell" wrote on 20-12-2001 12:48:31: > > > Julian: > > > ... snip snip ... > > > >    My personal opinion is that "key=?" seems fairly useless -- if they > are > >    to operate correctly, both sides of a connection really have to know > the > >    values of all the keys at all times, and the rules for negotiation > make > >    it clear how and when these values change.  The only real "enquiry" > >    situation is when an initiator is attempting to discover targets, and > >    this is handled completely differently by the use of "SendTargets". > >    So when is there a use for either side to send "key=?".  Unless there > >    is a clear example where this is useful, we should eliminate it and > thus > >    remove another special case during parameter processing. > > > I am not sure that we have all the use scenarios to afford removing it On Tue, 19 Feb 2002, Eddy Quicksall wrote: > > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Tuesday, February 19, 2002 3:19 PM > To: Eddy Quicksall > Subject: Re: FW: FW: iSCSI: support value of ? > > Eddy, > > [ Sorry, I was off on long weekend. ] > > I tend to concur with you guys.  I do not see > a good usage scenario for "?" at the moment. > If we add in the support in MIB (if it isn't > there already) for querying the default capabilities > of an iSCSI entity, that should be completely > adequate to retire the "?" feature. > > Regards. > -- > Mallikarjun > > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > > Eddy Quicksall wrote: > > > > Mallikarjun, > > > > I am thinking that the value of the "?" syntax is very limited and appears > > to me as though it could be something that got left in from past needs. > > > > Do you think it has any use other than for vendor specifics? Can you give > me > > an example of where it would be needed? > > > > Eddy > > > > -----Original Message----- > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > Sent: Friday, February 15, 2002 3:21 PM > > To: Eddy_Quicksall@ivivity.com > > Cc: Julian_Satran@il.ibm.com; ips@ece.cmu.edu > > Subject: Re: FW: iSCSI: support value of ? > > > > Eddy, > > > > The '?' was originally proposed as a form of Enquiry analogous to > something > > like a PDISC for Fibre Channel ports. > > > > However, an Enquiry is more useful if it is a scheme to query the target > for > > all its supported capabilities, rather than its current value. > > > > A query for the current negotiated value was of some use in the older > login > > negotiation model wherein each side independently computed the login > > negotiation result. In such a model, the '?' could be used by initiators > to > > verify that its negotiation result was in-sync with that of the target. > > > > With the new login negotiation model, wherein, the target computes the > > result > > of the negotiation and sends it back to the initiator, the initiator knows > > the > > current negotiated values anyway. Hence, what is more useful is a scheme > to > > query the target for its supported capabilities. > > > > IMO, the '?' semantics should be modified to return the target's supported > > capabilities and not its current negotiatied value. > > > > Regards, > > Santosh > > > > > > > > Well, given that the initiator should know everything (unless I missed > > > something below), what good is it other than for vendor specific? > > > > > > The reason I'm asking is because it seems silly to support it if it has > no > > > use. > > > > > > Can someone give me an example of where it is needed (other than for > > vendor > > > specific). > > > > > > Eddy > > > > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Friday, February 15, 2002 12:30 PM > > > To: Eddy Quicksall > > > Subject: Re: FW: iSCSI: support value of ? > > > > > > > > > The same value as Enquiry in SCSI.  I heard no other comment than yours. > > > > > > Julo > > > > > > > > > > > > > > > Eddy Quicksall > > > 14-02-02 19:51 > > > > > >         To:        Julian Satran/Haifa/IBM@IBMIL > > >         cc: > > >         Subject:        FW: iSCSI: support value of ? > > > > > > > > > > > > > > > I didn't see any responses on this. Is the "?" syntax of any good other > > than > > > for vendor specific commands? > > > > > > Eddy > > > > > > -----Original Message----- > > > From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] > > > Sent: Wednesday, February 06, 2002 5:29 PM > > > To: ips@ece. cmu. edu (E-mail) > > > Subject: iSCSI: support value of ? > > > > > > Section 2.2.4 of draft 10 says: > > > > > > The value "?" with any key has the meaning of enquiry and should be > > > answered with the current value or "NotUnderstood". > > > > > > What good is this? > > > > > > You should already know the answer as a result of login or text > > > negotiations. > > > > > > Here are the only keys that can be used in FFP by the initiator: > > > > > > 1)       SendTargets - we already have defined behavior for that key and > > > those get the information anyway > > > 2)       TargetName - that is IO by initiator so he can't send that key > > > anyway. Also, he has to already know the target. > > > 3)       TargetAlias -  "this name MUST be communicated to the initiator > > > during a Login". So that is already known. > > > 4)       InitiatorAlias - the initiator should already know his alias > > > 5)       TargetAddress - the target is the only one that can send this > in > > a > > > response > > > 6)       MaxRecvPDULength - this should be known from the negotiations > > > 7)       Vendor Specific - Could this be the reason? If so, lets say > that > > so > > > we don't have to add a lot of silly code. Or, lets say that the response > > to > > > "?" can be "Reject" meaning that we don't support that syntax > (currently, > > > the definition of the "Reject value" does not fit this). > > > > > > Eddy > > > > > > ------_=_NextPart_001_01C1B64A.37A65F90 > > > Content-Type: text/html; > > >       charset="iso-8859-1" > > > Content-Transfer-Encoding: quoted-printable > > > > > > > > xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > > > xmlns=3D"http://www.w3.org/TR/REC-html40"> > > > > > > > > > > > charset=3Diso-8859-1"> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >

> > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>W= > > > ell, > > > given that the initiator should know everything (unless I missed = > > > something > > > below), what good is it other than for vendor = > > > specific?

> > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><= > > > ![if = > > > > !supportEmptyParas]> 

= > > > > > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>T= > > > he reason > > > I’m asking is because it seems silly to support it if it has no = > > > use.

> > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><= > > > ![if > !supportEmptyParas]>  > > >

> > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>C= > > > an > > > someone give me an example of where it is needed (other than for vendor > > > specific).

> > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><= > > > ![if = > > > > !supportEmptyParas]> 

= > > > > > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>E= > > > ddy

> > > > > >

> > color=3Dnavy face=3DArial> > > > style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><= > > > ![if = > > > > !supportEmptyParas]> 

= > > > > > > > > >

> > color=3Dblack > > > face=3DTahoma> > > style=3D'font-size:10.0pt;font-family:Tahoma;color:black'> -----Original > > > Message-----
> > > From: Julian Satran > > > [mailto:Julian_Satran@il.ibm.com]
> > > Sent: Friday, February = > > > 15, 2002 > > > 12:30 PM
> > > To: Eddy Quicksall
> > > Subject: Re: FW: iSCSI: = > > > support > > > value of ?

> > > > > >

> > face=3D"Times New Roman"> > > style=3D'font-size:12.0pt'> > > !supportEmptyParas]> 

> > > > > >

> > style=3D'mso-margin-top-alt:0in;margin-right:0in;margin-bottom: > > > 12.0pt;margin-left:.5in'> = > > > Roman"> > > style=3D'font-size:12.0pt;color:black'>
> > > > > style=3D'font-size: > > > 10.0pt;font-family:sans-serif;color:black'>The same value as Enquiry in > = > > > SCSI.  I > > > heard no other comment than yours. > > color=3Dblack> > > style=3D'color:black'>
> > >
> > > > > style=3D'font-size: > > > 10.0pt;font-family:sans-serif;color:black'>Julo > > color=3Dblack> > > style=3D'color:black'>
> > >
> > style=3D'mso-special-character:line-break'> > > > > > style=3D'color:black;mso-color-alt: > > > windowtext'>

> > > > > > > > style=3D'width:100.0%;mso-cellspacing: > > >  1.5pt;margin-left:.5in'> > > >   > > >   > > >   > > >   > > >   > > >
> > >  

  > > size=3D3 > > >   color=3Dblack face=3D"Times New Roman"> > > style=3D'font-size:12.0pt;color:black; > > >   mso-color-alt:windowtext'>

> > >   		> > >  

> > face=3Dsans-serif> > >   = > > > > style=3D'font-size:7.5pt;font-family:sans-serif;color:black;font-weight:= > > > bold'>Eddy > > >   Quicksall <Eddy_Quicksall@ivivity.com> > >   color=3Dblack> > > color=3Dblack> > >   = > > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > >  

> > style=3D'font-size:7.5pt; > > >   font-family:sans-serif;color:black'>14-02-02 19:51 > >   color=3Dblack> > > color=3Dblack> > >   = > > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > >   		> > >  

> >   style=3D'font-size:7.5pt;font-family:Arial;color:black'>    > = > > >   > > >     > > style=3D'color:black'>
> > >   > >   style=3D'font-size:7.5pt;font-family:sans-serif;color:black'>  = > > >     > > >     To:        Julian = > > > Satran/Haifa/IBM@IBMIL > >   color=3Dblack>
> > >   > >   style=3D'font-size:7.5pt;font-family:sans-serif;color:black'>  = > > >     > > >     cc:         > > color=3Dblack> > >   style=3D'color:black'>
> > >   > >   style=3D'font-size:7.5pt;font-family:sans-serif;color:black'>  = > > >     > > >     Subject:        FW: iSCSI: support value = > > > of ? > >   color=3Dblack>
> > >  
> > >   > > style=3D'font-size: > > >   7.5pt;font-family:Arial;color:black'>      = > > >   > >   color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > >  
> > > > > >

> > color=3Dblack > > > face=3D"Times New Roman"> > > style=3D'font-size:12.0pt;color:black'>
> > >
> > > > > style=3D'font-size:10.0pt; > > > font-family:Arial;color:navy'>I didn't see any responses on this. Is = > > > the > > > "?" syntax of any good other than for vendor specific = > > > commands? > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:navy'>  > > ont> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Eddy > > t> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:navy'>  > > ont> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DTahoma> > > style=3D'font-size:10.0pt;font-family:Tahoma;color:black'> -----Original > > > Message-----
> > > From: Eddy Quicksall = > > > [mailto:Eddy_Quicksall@ivivity.com] > > style=3D'font-weight:bold'>
> > > Sent: Wednesday, February 06, 2002 5:29 PM > > style=3D'font-weight: > > > bold'>
> > > To: ips@ece. cmu. edu (E-mail) > > style=3D'font-weight:bold'>
> > > Subject: iSCSI: support value of ? > > color=3Dblack> > > style=3D'color:black'> > > style=3D'color:black; > > > mso-color-alt:windowtext'>

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>Section 2.2.4 = > > > of draft > > > 10 says: = > > > > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DCourier> > > style=3D'font-size:12.0pt;font-family:Courier;color:black'>The value > > > "?" with any key has the meaning of enquiry and should = > > > be > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DCourier> > > style=3D'font-size:12.0pt;font-family:Courier;color:black'>answered = > > > with the > > > current value or "NotUnderstood". > > color=3Dblack> > > style=3D'color:black'> > > style=3D'color:black; > > > mso-color-alt:windowtext'>

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>What good is = > > > this? > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>You should = > > > already know > > > the answer as a result of login or text = > > > negotiations. > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>Here are the = > > > only keys > > > that can be used in FFP by the initiator: > > color=3Dblack> > > style=3D'color:black'> > > style=3D'color:black; > > > mso-color-alt:windowtext'>

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>1) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>SendTargets – > > > we already have defined behavior for that key and those get the = > > > information > > > anyway > > style=3D'color:black;mso-color-alt: > > > windowtext'>

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>2) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>TargetName – > > > that is IO by initiator so he can't send that key anyway. Also, he has = > > > to > > > already know the target. > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>3) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>TargetAlias – > > >  "this name MUST be communicated to the initiator during a > > > Login". So that is already known. > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>4) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>InitiatorAlias > > > – the initiator should already know his alias = > > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>5) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>TargetAddress > > > – the target is the only one that can send this in a response = > > > > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>6) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>MaxRecvPDULength > > > – this should be known from the negotiations > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>7) > > > > > size=3D1 color=3Dblack> = > > >     > > >   > > style=3D'color:black'>Vendor > > > Specific – Could this be the reason? If so, lets say that so we = > > > don't have to > > > add a lot of silly code. Or, lets say that the response to = > > > "?" can be > > > "Reject" meaning that we don't support that syntax = > > > (currently, the > > > definition of the "Reject value" does not fit this). = > > > > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>  > > font> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >

> > face=3DArial> > > > style=3D'font-size:10.0pt;font-family:Arial;color:black'>Eddy > > nt> > > color=3Dblack> > > color=3Dblack> > > > style=3D'color:black;mso-color-alt:windowtext'>= > > >

> > > > > >
> > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C1B64A.37A65F90-- > > > > > > > -- > > ################################## > > 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 Wed Feb 20 20:28: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 UAA25553 for ; Wed, 20 Feb 2002 20:28:57 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1L0oiS08774 for ips-outgoing; Wed, 20 Feb 2002 19:50:44 -0500 (EST) 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 g1L0ogj08770 for ; Wed, 20 Feb 2002 19:50:42 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id C7B413164; Wed, 20 Feb 2002 17:50:41 -0700 (MST) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 8F7682BA; Wed, 20 Feb 2002 17:50:41 -0700 (MST) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 20 Feb 2002 17:50:41 -0700 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Feb 2002 17:50:41 -0700 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00A512C97@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: pat_thaler@agilent.com, kevin_lemay@agilent.com, luben@splentec.com, marjorie_krueger@hp.com Cc: ips@ece.cmu.edu, Julian_Satran@il.ibm.com Subject: RE: iSCSI: key negotiation - Unrecognized value? Date: Wed, 20 Feb 2002 17:50:32 -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 Thinking about this response further, "protocol error" should be replaced by "negotiation failure." 2.2.4 says that selection of an inadmissible value must be considered a protocol error and handled accordingly, but 7.8 Protocol Errors doesn't seem to say anything relevant to this type of error. Also during login one cannot send a reject PDU with a reason code of Protocol Error. 7.8 Negotiation Failures does contain relevant actions and should replace protocol error in 2.2.4. Pat -----Original Message----- From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@agilent.com] Sent: Wednesday, February 20, 2002 3:34 PM To: LEMAY,KEVIN (A-Roseville,ex1); 'Luben Tuikov'; KRUEGER,MARJORIE (HP-Roseville,ex1) Cc: Ips Reflector (E-mail); Julian Satran Subject: RE: iSCSI: key negotiation - Unrecognized value? 2.2.4 says: "The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are reserved and must only be used as described here." NotUnderstood is for a key not understood by the responder. The draft doesn't say it is used for a value that is not understood. It currently describes Reject only in the context of list negotiation where it is used when none of the values in the offered list are acceptable. For the example Luben gives of a numerical negotiation (MaxConnections), Reject would never be a valid response. If the originator offers a higher valid value than the responder is willing to accept, the responder would respond with the lower number that it is willing to accept. So a valid negotiation for the case where the originator asks for a valid assignable value than the responder is willing to support would be something like: Originator-> MaxConnections=65535 Responder-> MaxConnections=3 In the example Luben gave, 4294967296 is not a valid value for MaxConnections because it is outside the range . The draft doesn't say what to do about out of range values and other invalid values. The draft does say that "selection of a value not admissible under the selection rules rules is considered a protocol error and is handled accordingly." The context for that statement appears to be the selection of a value offered by the responder, but that action would also make sense for responding to a value that is invalid for the key (wrong type of value or out of range). An implementation offering an invalid value is broken which makes proceeding with the negotiation a problem. Sending a "Reject" also would be a reasonable response to an invalid value but it seems that offering an invalid value is just as severe an error as the ones that currently are responded to with protocol errors. Regards, Pat -----Original Message----- From: LEMAY,KEVIN (A-Roseville,ex1) [mailto:kevin_lemay@agilent.com] Sent: Wednesday, February 20, 2002 12:33 PM To: 'Luben Tuikov'; KRUEGER,MARJORIE (HP-Roseville,ex1) Cc: Ips Reflector (E-mail); Julian Satran Subject: RE: iSCSI: key negotiation - Unrecognized value? My impression was that "notUnderstood" was used if the key name itself could not be decoded. I believe that the correct behavior in the specific case should be: Originator-> MaxConnections=yes Responder-> MaxConnections=reject (with a login response of "Initiator error") The reason being, is that this key is clearly defined as a numeric field with specific ranges of values. To send a non-numeric value for this key would be an initiator error and should be treated as such. Although processing as "notunderstood" may allow the login to continue, it will also "cover up" the error allowing bad code to continue live on. Do we really want to make it easy for people to not even follow the spec? Kevin Lemay -----Original Message----- From: Luben Tuikov [mailto:luben@splentec.com] Sent: Wednesday, February 20, 2002 12:17 PM To: KRUEGER,MARJORIE (HP-Roseville,ex1) Cc: Ips Reflector (E-mail); Julian Satran Subject: Re: iSCSI: key negotiation - Unrecognized value? Marjorie, Julian, all, When a value doesn't belong to the valid set of assignable values to a key, but is offered, as Marjorie's example, shouldn't the following take place: Originator-> MaxConnections=yes Responder-> MaxConnections=NotUnderstood Also, isn't ``Reject'' used for a valid, assignable value, but for which the responder has no resources: Originator-> MaxConnections=4294967296 Responder-> MaxConnections=Reject I.e. the responder cannot allow 2^32 connections, since the OS will not allow it in the first place... (If your OS allows it, replace the number with 1e3000 above ;-) ? P.S. The ``NotUnderstood'' reply above would also be semantically correct. -- Luben Tuikov, Senior Software Engineer, Splentec Ltd. Bus: +1-905-707-1954x112, 9-5 EST. Fax: +1-905-707-1974. From owner-ips@ece.cmu.edu Wed Feb 20 20: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 UAA25607 for ; Wed, 20 Feb 2002 20:30:30 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1L0Zng07979 for ips-outgoing; Wed, 20 Feb 2002 19:35:49 -0500 (EST) 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 g1L0Zlj07975 for ; Wed, 20 Feb 2002 19:35:48 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 14124853; Wed, 20 Feb 2002 17:35:47 -0700 (MST) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 8562A2BA; Wed, 20 Feb 2002 17:35:43 -0700 (MST) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 20 Feb 2002 17:35:43 -0700 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Feb 2002 17:35:43 -0700 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00A512C92@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: luben@splentec.com, marjorie_krueger@hp.com Cc: ips@ece.cmu.edu, Julian_Satran@il.ibm.com Subject: RE: iSCSI: key negotiation - Unrecognized value? Date: Wed, 20 Feb 2002 17:35:42 -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 Commments in line with my initials: Pat -----Original Message----- From: Luben Tuikov [mailto:luben@splentec.com] Sent: Wednesday, February 20, 2002 12:21 PM To: KRUEGER,MARJORIE (HP-Roseville,ex1) Cc: Ips Reflector (E-mail); Julian Satran Subject: Re: iSCSI: key negotiation - Unrecognized value? "KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote: > > What is the proper response if you recognize a key, but are offered a value > that you don't recognize? For instance, what if MaxConnections=yes is > offered? > > Where is that specified in the document? v10, pg 34, top: Any other 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. That is for a key that is not understood, not for a value that is not understood or a value that is invalid. v10, pg 33, middle: If a responder does not support or is not allowed to use all of the offered options with a specific originator, it may use the constant "Reject". That is part of the text under "In literal list negotiation..." It doesn't apply to the other negotiation types (e.g. numerical) because the requester doesn't give offered options. For instance, in numerical negotiation, the requester gives a single value and the responder returns a response based upon a key specific rule such as return the lower of the request value and responder's maximum value. Comments? -- Luben Tuikov, Senior Software Engineer, Splentec Ltd. Bus: +1-905-707-1954x112, 9-5 EST. Fax: +1-905-707-1974. From owner-ips@ece.cmu.edu Wed Feb 20 21:18: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 VAA26172 for ; Wed, 20 Feb 2002 21:18:20 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1L1T4910702 for ips-outgoing; Wed, 20 Feb 2002 20:29:04 -0500 (EST) 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 g1L1T3j10698 for ; Wed, 20 Feb 2002 20:29:03 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 51E8F7B0 for ; Wed, 20 Feb 2002 18:29:02 -0700 (MST) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 359261D1 for ; Wed, 20 Feb 2002 18:29:02 -0700 (MST) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 20 Feb 2002 18:29:01 -0700 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Feb 2002 18:29:01 -0700 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00A512CA8@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: santoshr@cup.hp.com, ips@ece.cmu.edu Subject: RE: iSCSI: key negotiation - Unrecognized value? Date: Wed, 20 Feb 2002 18:29:00 -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 Santosh, If it is during Login Phase, then the target can't send a Reject PDU to indicate protocol error because only Login Request and Login Response PDUs are allowed. A Login Response with a status class of Initiator Error and a status detail of Initiator Error seems reasonable. None of the other status details seem to quite fit the description. An invalid value isn't a missing parameter. That would be consistant with the text on Negotiation Failures. I don't think it should respond to the key with not understood, but a response to the key of Reject would be reasonable and doing so might make it easier to debug the negotiation problem. Regards, Pat -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Wednesday, February 20, 2002 12:08 PM To: IPS Reflector Subject: Re: iSCSI: key negotiation - Unrecognized value? Hello, It seems like there are several possible responses on seeing a numeric key being offered with a non-numeric key value. (ex : "MaxBurstSize=yes", or "MaxConnections=yes"). 1) Target ignores the received key, without affecting basic function. It responds to the key with NotUnderstood. Login negotiation outcome is then initiator implementation dependent. Most likely, the initiator will terminate the TCP connection and error back to the caller indicating that it could not open an iscsi connection. 2) Target may respond with a Reject PDU response indicating a "protocol error". No login response is sent in this case (?). 3) Target responds with a login response pdu indicating a status_class_detail of 0x0207 (Missing Parameter). 4) Target may react to this error as a "format error" and close the TCP connection. In all the cases, the end result is TCP connection termination. However, the response (2) is the least desirable, since no long response is generated. I believe that (1) coupled with (3) is the most desirable behaviour. Regards, Santosh Julian Satran wrote: > > If it is not a list element the it is Reject. If it is a list element > and you recognize others then ignore the "bad" value else "Reject". > > Regards, > Julo > > "KRUEGER,MARJORIE (HP-Roseville,ex1)" > To: "Ips > Sent by: owner-ips@ece.cmu.edu Reflector (E-mail)" > > 20-02-02 03:22 cc: > Subject: iSCSI: > key negotiation - Unrecognized > value? > > > > What is the proper response if you recognize a key, but are offered a > value > that you don't recognize? For instance, what if MaxConnections=yes is > offered? > > Where is that specified in the document? > > Marjorie Krueger > Networked Storage Architecture > Networked Storage Solutions Org. > Hewlett-Packard > tel: +1 916 785 2656 > fax: +1 916 785 0391 > email: marjorie_krueger@hp.com -- ################################## 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 Wed Feb 20 23:49: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 XAA00570 for ; Wed, 20 Feb 2002 23:49:08 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1L3vhb18390 for ips-outgoing; Wed, 20 Feb 2002 22:57:43 -0500 (EST) 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 g1L3vej18385 for ; Wed, 20 Feb 2002 22:57:40 -0500 (EST) Received: (from mailgate@localhost) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id WAA03773 for ips@ece.cmu.edu; Wed, 20 Feb 2002 22:57:34 -0500 (EST) Received: from compuserve.com (dal-tgn-tvp-vty7.as.wcom.net [216.192.239.7]) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id WAA03756 for ; Wed, 20 Feb 2002 22:57:32 -0500 (EST) Message-ID: <3C747195.58794A73@compuserve.com> Date: Wed, 20 Feb 2002 22:03:33 -0600 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 Reflector Subject: FCIP rev 09 available Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit FCIP (aka): draft-ietf-ips-fcovertcpip-09.pdf, and draft-ietf-ips-fcovertcpip-09.txt Have been delivered to the Internet Drafts office. For those in a hurry to read them, they are also available at: ftp://ftp.t11.org/t11/member/incoming/02-125v0.pdf and ftp://ftp.t11.org/t11/member/incoming/02-125v0.pdf In a day or two they will move to: ftp://ftp.t11.org/t11/pub/fc/bb-2/02-125v0.pdf and ftp://ftp.t11.org/t11/pub/fc/bb-2/02-125v0.txt If you cannot find them one place try the other. The PDF version contains change bars from FCIP 09. As best as I can recall, all of the changes in FCIP 09 are editorial. Enjoy. Ralph... From owner-ips@ece.cmu.edu Thu Feb 21 00: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 AAA01240 for ; Thu, 21 Feb 2002 00:36:11 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1L4hMP20579 for ips-outgoing; Wed, 20 Feb 2002 23:43:22 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mc.va3.ummail.com (mc.va3.ummail.com [66.187.242.16]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1L4hJj20572 for ; Wed, 20 Feb 2002 23:43:19 -0500 (EST) Received: from hqmailweb.COMMSTOR.Crossroads.com (HQMailWeb.Crossroads.com [63.237.99.250:25]) by mc.va3.ummail.com with ESMTP id P0220-2342-3f6700; Thu, 21 Feb 2002 04:42:53 GMT Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 20 Feb 2002 22:42:52 -0600 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: RE: iSCSI: key negotiation - Unrecognized value? Date: Wed, 20 Feb 2002 22:42:50 -0600 Message-ID: Thread-Topic: iSCSI: key negotiation - Unrecognized value? Thread-Index: AcG6f5SmYYF2fJpOT1mDFQQ/nlkOJwAEOkhA From: "Buck Landry" To: , X-OriginalArrivalTime: 21 Feb 2002 04:42:52.0250 (UTC) FILETIME=[38B593A0:01C1BA92] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g1L4hJj20574 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit >>> If it is during Login Phase, then the target can't send a Reject PDU to indicate protocol error because only Login Request and Login Response PDUs are allowed. <<< Not to take this too far off track, but the exact phrase in the v10 draft, "Before the Full Feature Phase is established, only Login Request and Login Response PDUs are allowed" .. would seem to make Reject PDU reason code 0x01, "Full Feature Phase Command before login", fairly useless. --buck -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Wednesday, February 20, 2002 7:29 PM To: santoshr@cup.hp.com; ips@ece.cmu.edu Subject: RE: iSCSI: key negotiation - Unrecognized value? Santosh, If it is during Login Phase, then the target can't send a Reject PDU to indicate protocol error because only Login Request and Login Response PDUs are allowed. A Login Response with a status class of Initiator Error and a status detail of Initiator Error seems reasonable. None of the other status details seem to quite fit the description. An invalid value isn't a missing parameter. That would be consistant with the text on Negotiation Failures. I don't think it should respond to the key with not understood, but a response to the key of Reject would be reasonable and doing so might make it easier to debug the negotiation problem. Regards, Pat From owner-ips@ece.cmu.edu Thu Feb 21 02:11: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 CAA09973 for ; Thu, 21 Feb 2002 02:11:08 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1L6Ghj24642 for ips-outgoing; Thu, 21 Feb 2002 01:16:43 -0500 (EST) 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 g1L6Gej24637; Thu, 21 Feb 2002 01:16:40 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id HAA90830; Thu, 21 Feb 2002 07:16:26 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1L6I0m91414; Thu, 21 Feb 2002 07:18:04 +0100 To: Luben Tuikov Cc: "Ips Reflector (E-mail)" , "KRUEGER,MARJORIE (HP-Roseville,ex1)" , owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: key negotiation - Unrecognized value? X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 21 Feb 2002 08:18:04 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 21/02/2002 08:18:11, Serialize complete at 21/02/2002 08:18:11 Content-Type: multipart/alternative; boundary="=_alternative 0021E82FC2256B67_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0021E82FC2256B67_= Content-Type: text/plain; charset="us-ascii" Marjorie is correct - the text is (quite) explicit about requiring reject. As for you example - the value to be answered by the target is the maximum acceptable - see the rules for numeric negotiations. Julo Luben Tuikov Sent by: owner-ips@ece.cmu.edu 20-02-02 22:21 To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" cc: "Ips Reflector (E-mail)" , Julian Satran/Haifa/IBM@IBMIL Subject: Re: iSCSI: key negotiation - Unrecognized value? "KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote: > > What is the proper response if you recognize a key, but are offered a value > that you don't recognize? For instance, what if MaxConnections=yes is > offered? > > Where is that specified in the document? v10, pg 34, top: Any other 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. v10, pg 33, middle: If a responder does not support or is not allowed to use all of the offered options with a specific originator, it may use the constant "Reject". Comments? -- Luben Tuikov, Senior Software Engineer, Splentec Ltd. Bus: +1-905-707-1954x112, 9-5 EST. Fax: +1-905-707-1974. --=_alternative 0021E82FC2256B67_= Content-Type: text/html; charset="us-ascii"
Marjorie is correct - the text is (quite) explicit about requiring reject.
As for you example - the value to be answered by the target is the maximum acceptable - see the rules for numeric negotiations.

Julo


Luben Tuikov <luben@splentec.com>
Sent by: owner-ips@ece.cmu.edu

20-02-02 22:21

       
        To:        "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
        cc:        "Ips Reflector (E-mail)" <ips@ece.cmu.edu>, Julian Satran/Haifa/IBM@IBMIL
        Subject:        Re: iSCSI: key negotiation - Unrecognized value?

       


"KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote:
>
> What is the proper response if you recognize a key, but are offered a value
> that you don't recognize?  For instance, what if MaxConnections=yes is
> offered?
>
> Where is that specified in the document?

v10, pg 34, top:

Any other 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.

v10, pg 33, middle:

If a responder does not support or is not allowed to use
all of the offered options with a specific originator,
it may use the constant "Reject".


Comments?

--
Luben Tuikov, Senior Software Engineer, Splentec Ltd.
Bus: +1-905-707-1954x112, 9-5 EST. Fax: +1-905-707-1974.

--=_alternative 0021E82FC2256B67_=-- From owner-ips@ece.cmu.edu Thu Feb 21 02:59: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 CAA10443 for ; Thu, 21 Feb 2002 02:59:53 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1L7EnE27139 for ips-outgoing; Thu, 21 Feb 2002 02:14:49 -0500 (EST) 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 g1L7Ekj27132; Thu, 21 Feb 2002 02:14:46 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id IAA84978; Thu, 21 Feb 2002 08:14:34 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1L7GHU43310; Thu, 21 Feb 2002 08:16:17 +0100 To: "Buck Landry" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu, pat_thaler@agilent.com MIME-Version: 1.0 Subject: RE: iSCSI: key negotiation - Unrecognized value? X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 21 Feb 2002 09:16:14 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 21/02/2002 09:16:19, Serialize complete at 21/02/2002 09:16:19 Content-Type: multipart/alternative; boundary="=_alternative 00273829C2256B67_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00273829C2256B67_= Content-Type: text/plain; charset="us-ascii" Correct - I have removed it - Julo "Buck Landry" Sent by: owner-ips@ece.cmu.edu 21-02-02 06:42 To: , cc: Subject: RE: iSCSI: key negotiation - Unrecognized value? >>> If it is during Login Phase, then the target can't send a Reject PDU to indicate protocol error because only Login Request and Login Response PDUs are allowed. <<< Not to take this too far off track, but the exact phrase in the v10 draft, "Before the Full Feature Phase is established, only Login Request and Login Response PDUs are allowed" .. would seem to make Reject PDU reason code 0x01, "Full Feature Phase Command before login", fairly useless. --buck -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Wednesday, February 20, 2002 7:29 PM To: santoshr@cup.hp.com; ips@ece.cmu.edu Subject: RE: iSCSI: key negotiation - Unrecognized value? Santosh, If it is during Login Phase, then the target can't send a Reject PDU to indicate protocol error because only Login Request and Login Response PDUs are allowed. A Login Response with a status class of Initiator Error and a status detail of Initiator Error seems reasonable. None of the other status details seem to quite fit the description. An invalid value isn't a missing parameter. That would be consistant with the text on Negotiation Failures. I don't think it should respond to the key with not understood, but a response to the key of Reject would be reasonable and doing so might make it easier to debug the negotiation problem. Regards, Pat --=_alternative 00273829C2256B67_= Content-Type: text/html; charset="us-ascii"
Correct - I have removed it - Julo


"Buck Landry" <blandry@crossroads.com>
Sent by: owner-ips@ece.cmu.edu

21-02-02 06:42

       
        To:        <pat_thaler@agilent.com>, <ips@ece.cmu.edu>
        cc:        
        Subject:        RE: iSCSI: key negotiation - Unrecognized value?

       


>>>
If it is during Login Phase, then the target can't send a Reject PDU to
indicate protocol error because only Login Request and Login Response PDUs
are allowed.
<<<

Not to take this too far off track, but the exact phrase in the v10 draft,

"Before the Full Feature Phase is established, only Login Request and Login Response PDUs are allowed"

.. would seem to make Reject PDU reason code 0x01, "Full Feature Phase Command before login", fairly useless.

--buck

-----Original Message-----
From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]
Sent: Wednesday, February 20, 2002 7:29 PM
To: santoshr@cup.hp.com; ips@ece.cmu.edu
Subject: RE: iSCSI: key negotiation - Unrecognized value?


Santosh,

If it is during Login Phase, then the target can't send a Reject PDU to
indicate protocol error because only Login Request and Login Response PDUs
are allowed.

A Login Response with a status class of Initiator Error and a status detail
of Initiator Error seems reasonable. None of the other status details seem
to quite fit the description. An invalid value isn't a missing parameter.

That would be consistant with the text on Negotiation Failures.

I don't think it should respond to the key with not understood, but a
response to the key of Reject would be reasonable and doing so might make it
easier to debug the negotiation problem.

Regards,
Pat

<snip>

--=_alternative 00273829C2256B67_=-- From owner-ips@ece.cmu.edu Thu Feb 21 12:30: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 MAA25590 for ; Thu, 21 Feb 2002 12:30:11 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1LGRjo06072 for ips-outgoing; Thu, 21 Feb 2002 11:27:45 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (IDENT:root@ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1LGRgj06066; Thu, 21 Feb 2002 11:27:42 -0500 (EST) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g1LGMpn27332; Thu, 21 Feb 2002 11:22:51 -0500 Message-ID: <3C751FBB.173D8614@splentec.com> Date: Thu, 21 Feb 2002 11:26:35 -0500 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: Julian Satran CC: "Ips Reflector (E-mail)" , "KRUEGER,MARJORIE (HP-Roseville,ex1)" , owner-ips@ece.cmu.edu Subject: Re: iSCSI: key negotiation - Unrecognized value? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Oh, sorry! I guess I pay too much attention on semantics (meaning), rather than just read what the draft says and try not to interpret it. Julian Satran wrote: > > Marjorie is correct - the text is (quite) explicit about requiring reject. > As for you example - the value to be answered by the target is the maximum acceptable - see the > rules for numeric negotiations. > > Julo > > Luben Tuikov > Sent by: owner-ips@ece.cmu.edu To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" > > 20-02-02 22:21 cc: "Ips Reflector (E-mail)" > , Julian Satran/Haifa/IBM@IBMIL > Subject: Re: iSCSI: key negotiation - > Unrecognized value? > > > > "KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote: > > > > What is the proper response if you recognize a key, but are offered a value > > that you don't recognize? For instance, what if MaxConnections=yes is > > offered? > > > > Where is that specified in the document? > > v10, pg 34, top: > > Any other 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. > > v10, pg 33, middle: > > If a responder does not support or is not allowed to use > all of the offered options with a specific originator, > it may use the constant "Reject". > > Comments? > > -- > Luben Tuikov, Senior Software Engineer, Splentec Ltd. > Bus: +1-905-707-1954x112, 9-5 EST. Fax: +1-905-707-1974. -- Luben Tuikov, Senior Software Engineer, Splentec Ltd. Bus: +1-905-707-1954x112, 9-5 EST. Fax: +1-905-707-1974. From owner-ips@ece.cmu.edu Thu Feb 21 14:25: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 OAA00678 for ; Thu, 21 Feb 2002 14:25:52 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1LIPF015954 for ips-outgoing; Thu, 21 Feb 2002 13:25:15 -0500 (EST) 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 g1LIPDj15949 for ; Thu, 21 Feb 2002 13:25:13 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id <107NPJ5R>; Thu, 21 Feb 2002 13:24:57 -0500 Message-ID: <25369470B6F0D41194820002B328BDD22F559C@ATLOPS> From: Eddy Quicksall To: Julian Satran Cc: "KRUEGER,MARJORIE (HP-Roseville,ex1)" , "ips@ece. cmu. edu (E-mail)" Subject: RE: iSCSI: key negotiation - Unrecognized value? Date: Thu, 21 Feb 2002 13:24:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BB05.0F3E0D40" 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_01C1BB05.0F3E0D40 Content-Type: text/plain; charset="iso-8859-1" Julian, If we can use "reject" when it is not a list, can you please make that clear? Also can we allow it for boolean's too just for completeness? The rev 10 spec currently says: If a responder does not support or is not allowed to use all of the offered options with a specific originator, it may use the constant "Reject". That is in the discussion of list negotiations. And an EMAIL you sent on 2/6 (RE: iSCSI: Boolean value (yes, no) negotiation) said: --snip-- > Eddy is right - reject is not intended/valid for booleans. > > Julo Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, February 21, 2002 1:18 AM To: Luben Tuikov Cc: Ips Reflector (E-mail); KRUEGER,MARJORIE (HP-Roseville,ex1); owner-ips@ece.cmu.edu Subject: Re: iSCSI: key negotiation - Unrecognized value? Marjorie is correct - the text is (quite) explicit about requiring reject. As for you example - the value to be answered by the target is the maximum acceptable - see the rules for numeric negotiations. Julo Luben Tuikov Sent by: owner-ips@ece.cmu.edu 20-02-02 22:21 To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" cc: "Ips Reflector (E-mail)" , Julian Satran/Haifa/IBM@IBMIL Subject: Re: iSCSI: key negotiation - Unrecognized value? "KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote: > > What is the proper response if you recognize a key, but are offered a value > that you don't recognize? For instance, what if MaxConnections=yes is > offered? > > Where is that specified in the document? v10, pg 34, top: Any other 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. v10, pg 33, middle: If a responder does not support or is not allowed to use all of the offered options with a specific originator, it may use the constant "Reject". Comments? -- Luben Tuikov, Senior Software Engineer, Splentec Ltd. Bus: +1-905-707-1954x112, 9-5 EST. Fax: +1-905-707-1974. ------_=_NextPart_001_01C1BB05.0F3E0D40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

J= ulian,

<= ![if !supportEmptyParas]> 

I= f we can use “reject” when it is not a list, can you please make = that clear? Also can we allow it for boolean’s too just for = completeness?

&= nbsp;

T= he rev 10 spec currently says:

&= nbsp;

If a responder does not support or is not allowed to use

all of the offered options with a specific originator, it

may use the constant "Reject".

&= nbsp;

T= hat is in the discussion of list negotiations. And an EMAIL you sent on 2/6 (RE: = iSCSI: Boolean value (yes, no) negotiation) = said:

&= nbsp;

-= -snip--

> Eddy is right - reject is not intended/valid for = booleans.

>

> Julo

&= nbsp;

&= nbsp;

E= ddy

<= ![if = !supportEmptyParas]> 

=

<= ![if = !supportEmptyParas]> 

=

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, February = 21, 2002 1:18 AM
To: Luben Tuikov
Cc: Ips Reflector = (E-mail); KRUEGER,MARJORIE (HP-Roseville,ex1); owner-ips@ece.cmu.edu
Subject: Re: iSCSI: key negotiation - Unrecognized value?

 


Marjorie is correct - the = text is (quite) explicit about requiring reject.
As for you example - the = value to be answered by the target is the maximum acceptable - see the rules for = numeric negotiations.

Julo

 

Luben Tuikov <luben@splentec.com>
Sent by: owner-ips@ece.cmu.edu =

20-02-02 22:21 =

    =    
  =       To:        "KRUEGER,MARJORIE (HP-Roseville,ex1)" = <marjorie_krueger@hp.com>
  =       cc:        "Ips Reflector = (E-mail)" <ips@ece.cmu.edu>, Julian = Satran/Haifa/IBM@IBMIL
  =       Subject:        Re: iSCSI: key negotiation = - Unrecognized value?

      =  =



"KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote:
>
> What is the proper response if you recognize a key, but are = offered a value
> that you don't recognize?  For instance, what if = MaxConnections=3Dyes is
> offered?
>
> Where is that specified in the document?

v10, pg 34, top:

Any other 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=3DNotUnderstood.

v10, pg 33, middle:

If a responder does not support or is not allowed to use
all of the offered options with a specific originator,
it may use the constant "Reject".


Comments?

--
Luben Tuikov, Senior Software Engineer, Splentec Ltd.
Bus: +1-905-707-1954x112, 9-5 EST. Fax: +1-905-707-1974.

------_=_NextPart_001_01C1BB05.0F3E0D40-- From owner-ips@ece.cmu.edu Thu Feb 21 15:38: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 PAA03020 for ; Thu, 21 Feb 2002 15:38:49 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1LJleu22925 for ips-outgoing; Thu, 21 Feb 2002 14:47:40 -0500 (EST) 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 g1LJlbj22914 for ; Thu, 21 Feb 2002 14:47:38 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 546F133B8; Thu, 21 Feb 2002 12:47:36 -0700 (MST) Received: from axcsbh5.cos.agilent.com (axcsbh5.cos.agilent.com [130.29.152.150]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 5230D4F0; Thu, 21 Feb 2002 12:47:35 -0700 (MST) Received: from 130.29.152.150 by axcsbh5.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 21 Feb 2002 12:47:35 -0700 Received: by axcsbh5.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Feb 2002 12:47:35 -0700 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00A75450C@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Julian Satran , "Robert D. Russell" Cc: ips@ece.cmu.edu Subject: iSCSI: MaxBurstSize Date: Thu, 21 Feb 2002 12:47:34 -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 Julian, I still don't see the rational for MaxBurstSize. The initiator doesn't need it to limit its required resources. The initiator has to have its buffers allocated when it issues a command. It has to control the demand on its resources by limiting the commands it issues based upon its available resources. The target has FirstBurstSize and R2T's to control the demand on its resources. The other use of MaxBurstSize is to limit how often target may set the A bit, but the utility of this is unclear. Regards, Pat Thaler ---Original message---- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, February 12, 2002 12:33 AM To: Robert D. Russell Cc: ips@ece.cmu.edu Subject: Re: UNH Plugfest +++
3. Section 3.8.3 limits the value of the Desired Data Transfer Length in an R2T to at most MaxBurstSize. What is the rationale for this? An R2T is sent by the target to the initiator, so why can't the target specify any size it wants in the R2T? The target already uses R2Ts to control the flow of Data-Out PDUs from the initiator, so why impose this restriction on the R2Ts? Could someone please explain the benefit to this limitation on R2Ts? +++ Is this a plugfest question or one of your own? For your own questions the channels are always open. The MaxBurstSize is there to enable the initiator to share resources between several executing commands and limit the number of "pending buffers" a target will have to keep in case one of the Data Out PDUS is damaged and transfer to a device is not possible. +++ From owner-ips@ece.cmu.edu Thu Feb 21 17:06: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 RAA05827 for ; Thu, 21 Feb 2002 17:06:20 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1LKuPQ28865 for ips-outgoing; Thu, 21 Feb 2002 15:56:25 -0500 (EST) 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 g1LKuMj28855 for ; Thu, 21 Feb 2002 15:56:22 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1LKuFh05093 for ; Thu, 21 Feb 2002 12:56:15 -0800 (PST) Received: from cisco.com (58509@mbakke-lnx.cisco.com [161.44.68.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA09070 for ; Thu, 21 Feb 2002 12:56:13 -0800 (PST) Message-ID: <3C755B7F.2A5BF2CD@cisco.com> Date: Thu, 21 Feb 2002 14:41:35 -0600 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: IPS Subject: iSCSI: IPS Authentication MIB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit At the interim meeting, we decided that it was best to split out the authentication stuff (CHAP, SRP, IP address lists, etc) from the iSCSI MIB. We have created a new MIB for these called the IPS Authentication MIB. This MIB's first application is iSCSI, but it can be used for other storage protocols as well. The first draft (just submitted), the object model, and the plain mi2 file without the draft stuff added are available at: ftp://ftpeng.cisco.com/mbakke/ips/auth-mib/ Enjoy, Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Thu Feb 21 17:13: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 RAA05926 for ; Thu, 21 Feb 2002 17:13:03 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1LLWvd01784 for ips-outgoing; Thu, 21 Feb 2002 16:32:57 -0500 (EST) 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 g1LLWtj01778 for ; Thu, 21 Feb 2002 16:32:55 -0500 (EST) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel13.hp.com (Postfix) with ESMTP id 2DBF54004AD for ; Thu, 21 Feb 2002 13:32:49 -0800 (PST) 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 NAA19468 for ; Thu, 21 Feb 2002 13:32:44 -0800 (PST) Message-ID: <3C756835.A1583158@cup.hp.com> Date: Thu, 21 Feb 2002 13:35:49 -0800 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: ips@ece.cmu.edu Subject: Re: iSCSI: MaxBurstSize References: <1BEBA5E8600DD4119A50009027AF54A00A75450C@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, The MaxBurstSize login key is a don't care for iscsi initiators. It serves mostly an informational purpose, letting the initiator know at login time as to what is the maximum amount of data it can expect the target to request in 1 R2T request, or the maximum amount of data it can receive from the target in 1 data-in sequence. Most initiators should be negotiating this to the maximum possible value, thereby, indicating to the target to just return the maximum value it supports for MaxBurstSize. The MaxBurstSize itself is inherited as one of the tunables from the scsi Disconnect-Reconnect Mode Page as defined in SPC-2, which is to be re-defined for each SCSI transport as appropriate. IMO, the "MAXIMUM BURST SIZE" tunable of the disconnect-reconnect mode page makes sense in the parallel scsi context alone, where, either side (initiator or target) can specify how long the scsi bus can remain in the data phase before a disconnect must be done. In a fabric based SCSI transport, where, the data transfer does not cause any bus to be tied down, and the initiator's data buffers are allocated up-front before the SCSI command is sent to the target, I don't see any practical use of this key for initiators other than being informational, and allowing them to learn of the target's limits up-front at login time. I don't see why iSCSI needs to define this key, if its informational utility is of little or no value. I am also curious about what value FCP-2 initiators would find in this tunable. (?) Regards, Santosh "THALER,PAT (A-Roseville,ex1)" wrote: > > Julian, > > I still don't see the rational for MaxBurstSize. > > The initiator doesn't need it to limit its required resources. The initiator > has to have its buffers allocated when it issues a command. It has to > control the demand on its resources by limiting the commands it issues based > upon its available resources. > > The target has FirstBurstSize and R2T's to control the demand on its > resources. > > The other use of MaxBurstSize is to limit how often target may set the A > bit, but the utility of this is unclear. > > Regards, > Pat Thaler > > ---Original message---- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Tuesday, February 12, 2002 12:33 AM > To: Robert D. Russell > Cc: ips@ece.cmu.edu > Subject: Re: UNH Plugfest > +++ > >
> 3. Section 3.8.3 limits the value of the Desired Data Transfer Length in > an R2T to at most MaxBurstSize. What is the rationale for this? > An R2T is sent by the target to the initiator, so why can't the > target specify any size it wants in the R2T? The target already > uses R2Ts to control the flow of Data-Out PDUs from the initiator, > so why impose this restriction on the R2Ts? > > Could someone please explain the benefit to this limitation on R2Ts? > > +++ Is this a plugfest question or one of your own? For your own questions > the channels are always open. The MaxBurstSize is there to enable the > initiator to share resources between several executing commands and limit > the number of "pending buffers" a target will have to keep > in case one of the Data Out PDUS is damaged and transfer to a device is not > possible. > > +++ -- ################################## 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 Thu Feb 21 17: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 RAA06098 for ; Thu, 21 Feb 2002 17:26:40 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1LM5CA04364 for ips-outgoing; Thu, 21 Feb 2002 17:05:12 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1LM5Aj04357 for ; Thu, 21 Feb 2002 17:05:10 -0500 (EST) Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.110.250.124]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 140563DA7 for ; Thu, 21 Feb 2002 16:05:05 -0600 (CST) Received: from cceexc17.americas.cpqcorp.net ([16.110.250.84]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 21 Feb 2002 16:05:04 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: iSCSI: MaxBurstSize X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 21 Feb 2002 16:05:04 -0600 Message-ID: <78AF3C342AEAEF4BA33B35A8A15668C6019E21BA@cceexc17.americas.cpqcorp.net> Thread-Topic: iSCSI: MaxBurstSize Thread-Index: AcG7H4xuRH/lcfACQUGX0fwqq7XYVwAAApvg From: "Elliott, Robert" To: X-OriginalArrivalTime: 21 Feb 2002 22:05:04.0893 (UTC) FILETIME=[D111AAD0:01C1BB23] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g1LM5Bj04358 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit MaxBurstSize is probably helpful for protocol bridges (e.g. FCP to iSCSI). If a destination FCP device has a MaxBurstSize, but the source iSCSI device does not, the bridge may need to buffer lots of data as it breaks up the iSCSI sequences into FCP sequences. Being able to enforce the same limit on iSCSI makes this a bit easier. Another field called ConnectTimeLimit is the field that guarantees that parallel SCSI goes bus free. MaxBurstSize only limits time in data phase (in non-packetized mode) or the size of a data IU (in packetized mode. Without ConnectTimeLimit, the target could hold the bus in another phase (message, command, etc.) forever. ConnectTimeLimit has no value in fabrics and is not in iSCSI. --- Rob Elliott, Compaq Server Storage Robert.Elliott@compaq.com > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Thursday, February 21, 2002 3:36 PM > To: ips@ece.cmu.edu > Subject: Re: iSCSI: MaxBurstSize > > > Pat, > > The MaxBurstSize login key is a don't care for iscsi initiators. It > serves mostly an informational purpose, letting the initiator know at > login time as to what is the maximum amount of data it can expect the > target to request in 1 R2T request, or the maximum amount of > data it can > receive from the target in 1 data-in sequence. > > Most initiators should be negotiating this to the maximum possible > value, thereby, indicating to the target to just return the maximum > value it supports for MaxBurstSize. > > The MaxBurstSize itself is inherited as one of the tunables from the > scsi Disconnect-Reconnect Mode Page as defined in SPC-2, > which is to be > re-defined for each SCSI transport as appropriate. > > IMO, the "MAXIMUM BURST SIZE" tunable of the disconnect-reconnect mode > page makes sense in the parallel scsi context alone, where, > either side > (initiator or target) can specify how long the scsi bus can remain in > the data phase before a disconnect must be done. > > In a fabric based SCSI transport, where, the data transfer does not > cause any bus to be tied down, and the initiator's data buffers are > allocated up-front before the SCSI command is sent to the target, I > don't see any practical use of this key for initiators other > than being > informational, and allowing them to learn of the target's limits > up-front at login time. > > I don't see why iSCSI needs to define this key, if its informational > utility is of little or no value. I am also curious about what value > FCP-2 initiators would find in this tunable. (?) > > Regards, > Santosh > > > > "THALER,PAT (A-Roseville,ex1)" wrote: > > > > Julian, > > > > I still don't see the rational for MaxBurstSize. > > > > The initiator doesn't need it to limit its required > resources. The initiator > > has to have its buffers allocated when it issues a command. > It has to > > control the demand on its resources by limiting the > commands it issues based > > upon its available resources. > > > > The target has FirstBurstSize and R2T's to control the demand on its > > resources. > > > > The other use of MaxBurstSize is to limit how often target > may set the A > > bit, but the utility of this is unclear. > > > > Regards, > > Pat Thaler > > > > ---Original message---- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Tuesday, February 12, 2002 12:33 AM > > To: Robert D. Russell > > Cc: ips@ece.cmu.edu > > Subject: Re: UNH Plugfest > > +++ > > > >
> > 3. Section 3.8.3 limits the value of the Desired Data > Transfer Length in > > an R2T to at most MaxBurstSize. What is the rationale for this? > > An R2T is sent by the target to the initiator, so why can't the > > target specify any size it wants in the R2T? The target already > > uses R2Ts to control the flow of Data-Out PDUs from the initiator, > > so why impose this restriction on the R2Ts? > > > > Could someone please explain the benefit to this > limitation on R2Ts? > > > > +++ Is this a plugfest question or one of your own? For > your own questions > > the channels are always open. The MaxBurstSize is there to > enable the > > initiator to share resources between several executing > commands and limit > > the number of "pending buffers" a target will have to keep > > in case one of the Data Out PDUS is damaged and transfer to > a device is not > > possible. > > > > +++ > > -- > ################################## > 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 Thu Feb 21 18:19: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 SAA07141 for ; Thu, 21 Feb 2002 18:19:53 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1LMSRM06460 for ips-outgoing; Thu, 21 Feb 2002 17:28:27 -0500 (EST) 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 g1LMIXj05572 for ; Thu, 21 Feb 2002 17:18:33 -0500 (EST) Received: from io.iol.unh.edu (IDENT:rdr@localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.2/8.12.2) with ESMTP id g1LMISUj020751 for ; Thu, 21 Feb 2002 17:18:28 -0500 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.2/8.12.1/Submit) with ESMTP id g1LMIRw5020748 for ; Thu, 21 Feb 2002 17:18:28 -0500 Date: Thu, 21 Feb 2002 17:18:27 -0500 (EST) From: "Robert D. Russell" To: ips@ece.cmu.edu Subject: Re: iSCSI: key negotiation - Unrecognized value? (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian: I sent this message yesterday, but did not see it on the reflector, so I am sending it again -- my apologies to you and others if you receive it twice. Bob Russell ---------------------------- I agree that this is a good behavior to support, but draft 10 does not make this clear. The only reference to the use of "Reject" in the draft is in section 2.2.4 Text Mode Negotiation and is under that part which is discussing "literal list negotiation". There is no mention of the use of "Reject" in the following parts which discuss "numerical and single literal negotiations" and "Boolean negotiations". I would suggest eliminating the current sentence in draft 10 which introduces "Reject" under the "literal list negotiation" and instead add a modified version of the reply you wrote to Marjorie at the end of section 2.2.4, where items that apply to all types of negotiation are discussed. Thanks, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 On Wed, 20 Feb 2002, Julian Satran wrote: > If it is not a list element the it is Reject. If it is a list element and > you recognize others then ignore the "bad" value else "Reject". > > Regards, > Julo > > > > > "KRUEGER,MARJORIE (HP-Roseville,ex1)" > Sent by: owner-ips@ece.cmu.edu > 20-02-02 03:22 > > > To: "Ips Reflector (E-mail)" > cc: > Subject: iSCSI: key negotiation - Unrecognized value? > > > > What is the proper response if you recognize a key, but are offered a > value > that you don't recognize? For instance, what if MaxConnections=yes is > offered? > > Where is that specified in the document? > > Marjorie Krueger > Networked Storage Architecture > Networked Storage Solutions Org. > Hewlett-Packard > tel: +1 916 785 2656 > fax: +1 916 785 0391 > email: marjorie_krueger@hp.com > > > From owner-ips@ece.cmu.edu Thu Feb 21 19:02: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 TAA07702 for ; Thu, 21 Feb 2002 19:02:59 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1LN6tt09381 for ips-outgoing; Thu, 21 Feb 2002 18:06:55 -0500 (EST) 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 g1LN6rj09377 for ; Thu, 21 Feb 2002 18:06:53 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id E2758C4F for ; Thu, 21 Feb 2002 16:06:52 -0700 (MST) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id CBF2B23D for ; Thu, 21 Feb 2002 16:06:52 -0700 (MST) Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id <17QZGSCS>; Thu, 21 Feb 2002 16:06:52 -0700 Message-ID: <01A7DAF31F93D511AEE300D0B706ED9201BF477F@axcs13.cos.agilent.com> From: "CAVANNA,VICENTE V (A-Roseville,ex1)" To: "'ips@ece.cmu.edu'" Cc: "SHEEHY,DAVE (A-Americas,unix1)" , "CAVANNA,VICENTE V (A-Roseville,ex1)" , "THALER,PAT (A-Roseville,ex1)" Subject: is 1 Gbps a MUST? Date: Thu, 21 Feb 2002 16:06:51 -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 If my interpretation is correct, the current (and earlier ones too) security draft at http://www.drizzle.com/~aboba/RDMA/draft-ietf-ips-security-10.txt seems to say that an IPSec implementation MUST be capable of running at 1 Gbps. I quote from the draft: "Given current networking technology, IP block storage security solutions must be implementable at 1 Gbps in terms of CPU overhead and/or availability of suitable hardware implementations and should be implementable at 10 Gbps in the near future. 10 Gbps implementations are desirable but are not an absolute requirement as implementation feasibility at these speeds is not yet demonstrated. " On the other hand I hear a lot of talk about TOEs in hardware and IPSec in software. Given that, once IPSec is turned on, *every* incoming packet must be inspected to confirm compliance with the security policy, I find it hard to believe that a software implementation can be claimed to be compliant. In fact a software implementation implies introducing a bottleneck in front of the TOE. Am I misinterpreting the requirement or am I underestimating the potential performance of a software implementation? Vince Cavanna Agilent Technologies From owner-ips@ece.cmu.edu Thu Feb 21 20:08: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 UAA08417 for ; Thu, 21 Feb 2002 20:08:03 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1M0JSG14610 for ips-outgoing; Thu, 21 Feb 2002 19:19:28 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f216.pav2.hotmail.com [64.4.37.216]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1M0JPj14602 for ; Thu, 21 Feb 2002 19:19:26 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 21 Feb 2002 16:19:20 -0800 Received: from 207.46.137.8 by pv2fd.pav2.hotmail.msn.com with HTTP; Fri, 22 Feb 2002 00:19:20 GMT X-Originating-IP: [207.46.137.8] From: "Bernard Aboba" To: vince_cavanna@agilent.com, ips@ece.cmu.edu Cc: dave_sheehy@agilent.com, pat_thaler@agilent.com Subject: Re: is 1 Gbps a MUST? Date: Thu, 21 Feb 2002 16:19:20 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Feb 2002 00:19:20.0091 (UTC) FILETIME=[925756B0:01C1BB36] Sender: owner-ips@ece.cmu.edu Precedence: bulk >Am I misinterpreting the requirement or am I underestimating the >potential >performance of a software implementation? You're misinterpreting the requirement. It should probably just say something like "the security protocol should be capable of...", since the requirement doesn't apply to implementations. Feel free to go ahead and make your products as slow as you need to :) _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From owner-ips@ece.cmu.edu Thu Feb 21 20: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 UAA08455 for ; Thu, 21 Feb 2002 20:10:37 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1M0fno15991 for ips-outgoing; Thu, 21 Feb 2002 19:41:49 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1M0flj15986 for ; Thu, 21 Feb 2002 19:41:47 -0500 (EST) Received: from cceexg13.americas.cpqcorp.net (cceexg13.americas.cpqcorp.net [16.110.250.119]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 124743EAB; Thu, 21 Feb 2002 18:41:42 -0600 (CST) Received: from cceexc18.americas.cpqcorp.net ([16.110.250.64]) by cceexg13.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 21 Feb 2002 18:41:41 -0600 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: RE: is 1 Gbps a MUST? Date: Thu, 21 Feb 2002 18:41:41 -0600 Message-ID: <31891B757C09184BBFEC5275F85D5595104E38@cceexc18.americas.cpqcorp.net> Thread-Topic: is 1 Gbps a MUST? Thread-Index: AcG7LMPwZN4Fmzz6S4C+8Mys/ToQbQAA1etQ From: "Martin, Nick" To: "CAVANNA,VICENTE V (A-Roseville,ex1)" , Cc: "SHEEHY,DAVE (A-Americas,unix1)" , "THALER,PAT (A-Roseville,ex1)" X-OriginalArrivalTime: 22 Feb 2002 00:41:41.0808 (UTC) FILETIME=[B2111B00:01C1BB39] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g1M0flj15987 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Vince, I read this as limiting IP block storage security protocols for iSCSI to those which can be done at wire speed using some current technology. This does not mean that each implementation must do so, nor that it must be possible to do it both in hardware and also in software. It means to me, if no-one can make it run at wire speed using current technology, we must not select it. If neither software with acceptable CPU overhead, nor a suitable hardware implementation are possible, the protocol is disqualified. Thanks, Nick > -----Original Message----- > From: CAVANNA,VICENTE V (A-Roseville,ex1) > [mailto:vince_cavanna@agilent.com] > Sent: Thursday, February 21, 2002 5:07 PM > To: 'ips@ece.cmu.edu' > Cc: SHEEHY,DAVE (A-Americas,unix1); CAVANNA,VICENTE V > (A-Roseville,ex1); > THALER,PAT (A-Roseville,ex1) > Subject: is 1 Gbps a MUST? > > > If my interpretation is correct, the current (and earlier > ones too) security > draft at > http://www.drizzle.com/~aboba/RDMA/draft-ietf-ips-security-10.txt > seems to say that an IPSec implementation MUST be capable of > running at 1 > Gbps. I quote from the draft: > "Given current networking technology, IP block storage > security solutions > must be implementable at 1 Gbps in terms of CPU overhead > and/or availability > of suitable hardware implementations and should be > implementable at 10 Gbps > in the near future. 10 Gbps implementations are desirable but > are not an > absolute requirement as implementation feasibility at these > speeds is not > yet demonstrated. " > On the other hand I hear a lot of talk about TOEs in hardware > and IPSec in > software. Given that, once IPSec is turned on, *every* > incoming packet must > be inspected to confirm compliance with the security policy, > I find it hard > to believe that a software implementation can be claimed to > be compliant. In > fact a software implementation implies introducing a > bottleneck in front of > the TOE. > Am I misinterpreting the requirement or am I underestimating > the potential > performance of a software implementation? > Vince Cavanna > Agilent Technologies > > From owner-ips@ece.cmu.edu Thu Feb 21 23:20: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 XAA12875 for ; Thu, 21 Feb 2002 23:20:46 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1M3EBc24977 for ips-outgoing; Thu, 21 Feb 2002 22:14:11 -0500 (EST) 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 g1M3E9j24971 for ; Thu, 21 Feb 2002 22:14:09 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 6A2BD317D; Thu, 21 Feb 2002 20:14:08 -0700 (MST) Received: from axcsbh5.cos.agilent.com (axcsbh5.cos.agilent.com [130.29.152.150]) by msgrel1.cos.agilent.com (Postfix) with SMTP id DA583212; Thu, 21 Feb 2002 20:14:07 -0700 (MST) Received: from 130.29.152.150 by axcsbh5.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 21 Feb 2002 20:14:07 -0700 Received: by axcsbh5.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Feb 2002 20:14:07 -0700 Message-ID: <01A7DAF31F93D511AEE300D0B706ED9201BF4787@axcs13.cos.agilent.com> From: "CAVANNA,VICENTE V (A-Roseville,ex1)" To: "'ips@ece.cmu.edu'" Cc: "'Martin, Nick'" , "'Bernard Aboba'" , "SHEEHY,DAVE (A-Americas,unix1)" , "THALER,PAT (A-Roseville,ex1)" , "CAVANNA,VICENTE V (A-Roseville,ex1)" Subject: Re: is 1 Gbps a MUST? Date: Thu, 21 Feb 2002 20:14:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1BB4E.FC719570" 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_01C1BB4E.FC719570 Content-Type: text/plain; charset="ISO-8859-1" Thanks for the clarification. Something still bothers me however. If IPSec is a bottleneck (because the policy lookup is done in software) then the receiver may be forced to drop packets quite frequently. Such behavior could have a dramatic effect on performance as explained in a memo that Jonathan Stone posted on 2/5/02 (attached) and in my interpretation which I did not post on 2/6/02 (attached). Comments? Thanks. Vince Cavanna Agilent Technologies <> <> ------_=_NextPart_000_01C1BB4E.FC719570 Content-Type: message/rfc822 Content-Description: Re: iSCSI: No Framing Message-ID: <200202060317.g163HJP01042@Gregorio.Stanford.EDU> From: Jonathan Stone To: "Peglar, Robert" Cc: ips@ece.cmu.edu Subject: Re: iSCSI: No Framing Date: Tue, 5 Feb 2002 20:09:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" In message , "Peglar, Robert" writes: >The original thread began with a question (paraphrased) about '...what >applications could consume a 10G pipe for long periods of time'. I answered >that question - disk-disk backup and subsystem replication. Even disk-to-disk applications or backup applications really want approximately BW*RTT worth of buffering. Hugh Holbrook's recent Stanford PhD thesis traces the conventional wisdom back to an email from Van Jacobson to the e2e list in 1990. It's reasonably well-known in the TCP community that TCP slow-start generates spiky traffic. It leads to bursts of high buffer occupancy (e.g., at the point where the exponential rampup switches to congestion avoidance.) Indeed, that was the motivation behind TCP-Vegas, and the recent work on TCP pacing. The whole debate over framing/marking only makes sense if one views outboard NIC buffering of RTT*BW as very expensive (e.g., forcing a design from onchip RAM to external SRAM). Adding framing of iSCSI PDUs allows the NIC to continue doing direct data placement into host buffers, accomodating the BW*RTT of TCP buffering in "cheap" host RAM rather than "expensive" NIC RAM. But you can't get away from providing the buffers. Not unless you are also willing to artificially restrict throughput. If iSCSI doesn't provide some form of framing, then what can a NIC on a MAN with medium BW*RTT do, if it sees a drop? It has only a few choices: 1. start buffering data outboard, hoping that TCP fast-retransmit will send the missing segment(s) before the outboard buffers are exhausted; 2. Give up on direct data placment, and start delivering packets to host memory, any old how --at the cost of SW reassembly and alignment problems, and a software CRC, once the missing segment is recovered. 3. Start dropping packets, and pay a huge performance cost. There are some important caveats around the BW*RTT: if we can *guarantee* that the iSCSI NICs are never the bottleneck point, or that TCP never tries to reach the true link BW*RTT (due to undersized windows), then one can get away with less. (See Hugh Holbrook's thesis for more concrete details). But the lesson to take away is that even in relatively well-behaved LANs, TCP *by design* is always oscillating around overloading the available buffers, causing a drop, then backing off. See, for example, Figure 2 of the paper by Janey Hoe which introduced "New Reno"; or Fig. 2 and 3 of the paper by Floyd and Fall. New Reno avoids the long-timeouts between each drop, but the drops themselves still occur. Moral: TCP can require significant buffering even on quite modest networks. It __may__ be worth keeping framing, so that host NICs can do more of that buffering in host memory rather than outboard; and so they can continue performing DDP rather than software reassembly and software CRC checking. Storage devices are another issue again. References: Van Jacobson, modified TCP congestion avoidance algorithm. Email to end2end@isi.edu, April 1990. L Brakmo, , S O'Malley, L Peterson, TCP Vegas: new techniques for congestion detection and control, SIGCOMM 94. J Kulik, R Coulter, D Rockwell, and C Partridge, A simulation study of paced TCP. BBN TEchnical Memorandum 1218, BBN, August 1999. J Hoe, Improving the Startup Behaviour of a Congestion Control Scheme for TCP, ACM SIGCOMM 1996, S Floyd and K Fall, Simulation-based comparisons of Tahoe, Reno, and SACK TCP, Comp. COmm. Review no 6 v 3, April 1996. H Holbrook. A Channel Model for Multicast. PhD Dissertation. Department of Computer Science. Stanford University. August, 2001. http://dsg.stanford.edu/~holbrook/thesis.ps{,.gz}. (See Chapter 5.) (Holbrook cites Aggrawal, Savage, and Anderson, INFOCOMM 2000, on the downsides of TCP pacing; but I haven't read that. The PILC draft on link designs touch the same issue, but the throughput equations cited there factor out buffer size.) >FC is not sufficient. Storage-to-storage needs all the advantages as well >as that which iSCSI has to offer the host-storage model. But it will still need approximately BW*RTT of buffering, even for low-delay LANS. Or performance will fall off a cliff under "congestion" -- e.g., each time some other iSCSI flow starts up, begins competing for the same TCP endpoint buffers, on the same iSCSI device, and triggering a burst of TCP loss events for the storage-to-storage flow. ------_=_NextPart_000_01C1BB4E.FC719570 Content-Type: message/rfc822 Content-Description: RE: iSCSI: No Framing Message-ID: <01A7DAF31F93D511AEE300D0B706ED9201600F04@axcs13.cos.agilent.com> From: "CAVANNA,VICENTE V (A-Roseville,ex1)" To: 'Jonathan Stone' Cc: "CAVANNA,VICENTE V (A-Roseville,ex1)" Subject: RE: iSCSI: No Framing Date: Wed, 6 Feb 2002 15:25:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Hello Jonathan, Interesting and useful points! I would appreciate your opinion on the following observation. It seems to me that the cliff-like drop in performance that is a consequence of dropping packets is likely to result, as well, from any other bottleneck that may exist in the path to the buffers such as an IPSec engine that is not capable of link-speed throughput or large, even if occassional, latency in any internal shared medium that lies in the path to the buffers. It is easy for the IPSec engine to become a bottleneck (even without considering the crypto algorithms) since it has to perform a complex policy database lookup on every received packet, secured or not, to confirm that the packet was afforded the appropriate security as indicated by the configured security policy. The moral I took from your memo is that link speed throughput is necessary all the way to the buffers. Thanks, Vince Cavanna Agilent Technologies |-----Original Message----- |From: Jonathan Stone [mailto:jonathan@dsg.stanford.edu] |Sent: Tuesday, February 05, 2002 7:10 PM |To: Peglar, Robert |Cc: ips@ece.cmu.edu |Subject: Re: iSCSI: No Framing | | |In message |, |"Peglar, Robert" writes: | |>The original thread began with a question (paraphrased) about '...what |>applications could consume a 10G pipe for long periods of |time'. I answered |>that question - disk-disk backup and subsystem replication. | |Even disk-to-disk applications or backup applications really want |approximately BW*RTT worth of buffering. Hugh Holbrook's recent |Stanford PhD thesis traces the conventional wisdom back to an email |from Van Jacobson to the e2e list in 1990. | |It's reasonably well-known in the TCP community that TCP slow-start |generates spiky traffic. It leads to bursts of high buffer occupancy |(e.g., at the point where the exponential rampup switches to |congestion avoidance.) Indeed, that was the motivation behind |TCP-Vegas, and the recent work on TCP pacing. | |The whole debate over framing/marking only makes sense if one views |outboard NIC buffering of RTT*BW as very expensive (e.g., forcing a |design from onchip RAM to external SRAM). Adding framing of iSCSI PDUs |allows the NIC to continue doing direct data placement into host |buffers, accomodating the BW*RTT of TCP buffering in "cheap" host RAM |rather than "expensive" NIC RAM. | |But you can't get away from providing the buffers. Not unless you are |also willing to artificially restrict throughput. If iSCSI doesn't |provide some form of framing, then what can a NIC on a MAN with medium |BW*RTT do, if it sees a drop? It has only a few choices: | | 1. start buffering data outboard, hoping that TCP |fast-retransmit will | send the missing segment(s) before the outboard buffers |are exhausted; | | 2. Give up on direct data placment, and start delivering packets to | host memory, any old how --at the cost of SW reassembly |and alignment | problems, and a software CRC, once the missing segment is |recovered. | | 3. Start dropping packets, and pay a huge performance cost. | |There are some important caveats around the BW*RTT: if we can |*guarantee* that the iSCSI NICs are never the bottleneck point, or |that TCP never tries to reach the true link BW*RTT (due to undersized |windows), then one can get away with less. (See Hugh Holbrook's thesis |for more concrete details). | |But the lesson to take away is that even in relatively well-behaved |LANs, TCP *by design* is always oscillating around overloading the |available buffers, causing a drop, then backing off. See, for |example, Figure 2 of the paper by Janey Hoe which introduced "New |Reno"; or Fig. 2 and 3 of the paper by Floyd and Fall. New Reno avoids |the long-timeouts between each drop, but the drops themselves still |occur. | |Moral: TCP can require significant buffering even on quite modest |networks. It __may__ be worth keeping framing, so that host NICs can |do more of that buffering in host memory rather than outboard; and so |they can continue performing DDP rather than software reassembly and |software CRC checking. Storage devices are another issue again. | | | | | |References: | |Van Jacobson, modified TCP congestion avoidance algorithm. |Email to end2end@isi.edu, April 1990. | |L Brakmo, , S O'Malley, L Peterson, TCP Vegas: new techniques |for congestion |detection and control, SIGCOMM 94. | |J Kulik, R Coulter, D Rockwell, and C Partridge, A |simulation study of paced TCP. BBN TEchnical Memorandum 1218, BBN, |August 1999. | |J Hoe, Improving the Startup Behaviour of a Congestion Control Scheme |for TCP, ACM SIGCOMM 1996, | |S Floyd and K Fall, Simulation-based comparisons of Tahoe, |Reno, and SACK |TCP, Comp. COmm. Review no 6 v 3, April 1996. | |H Holbrook. A Channel Model for Multicast. PhD Dissertation. |Department of Computer Science. Stanford University. August, 2001. |http://dsg.stanford.edu/~holbrook/thesis.ps{,.gz}. (See Chapter 5.) | |(Holbrook cites Aggrawal, Savage, and Anderson, INFOCOMM 2000, on the |downsides of TCP pacing; but I haven't read that. The PILC draft on |link designs touch the same issue, but the throughput equations cited |there factor out buffer size.) | | | |>FC is not sufficient. Storage-to-storage needs all the |advantages as well |>as that which iSCSI has to offer the host-storage model. | |But it will still need approximately BW*RTT of buffering, even for |low-delay LANS. Or performance will fall off a cliff under |"congestion" -- e.g., each time some other iSCSI flow starts up, |begins competing for the same TCP endpoint buffers, on the same iSCSI |device, and triggering a burst of TCP loss events for the |storage-to-storage flow. | ------_=_NextPart_000_01C1BB4E.FC719570-- From owner-ips@ece.cmu.edu Fri Feb 22 00:53: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 AAA14815 for ; Fri, 22 Feb 2002 00:53:59 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1M5CIg01927 for ips-outgoing; Fri, 22 Feb 2002 00:12:18 -0500 (EST) 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 g1M5CFj01922 for ; Fri, 22 Feb 2002 00:12:15 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.us.ibm.com [9.99.140.23]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id AAA175610; Fri, 22 Feb 2002 00:08:45 -0500 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.99.140.13]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1M5BsS276668; Thu, 21 Feb 2002 22:11:54 -0700 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: MaxBurstSize To: Santosh Rao Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Thu, 21 Feb 2002 14:22:13 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 02/21/2002 10:11:53 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I believe, we need to consider this as issue with devices that can be both initiators and targets. Take for example a streaming tape; when it is reading the data from a Disk Storage Controller. Often these device start a long I/O streaming action and have less memory then will contain the data they are requesting. Through various double buffering techniques, they can keep the data coming in, and going out to tape, without back-hitching. So I believe MaxBurstSize has value, even if the disk storage folks think it is minimal. . . . 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 Santosh Rao @ece.cmu.edu on 02/21/2002 01:35:49 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: iSCSI: MaxBurstSize Pat, The MaxBurstSize login key is a don't care for iscsi initiators. It serves mostly an informational purpose, letting the initiator know at login time as to what is the maximum amount of data it can expect the target to request in 1 R2T request, or the maximum amount of data it can receive from the target in 1 data-in sequence. Most initiators should be negotiating this to the maximum possible value, thereby, indicating to the target to just return the maximum value it supports for MaxBurstSize. The MaxBurstSize itself is inherited as one of the tunables from the scsi Disconnect-Reconnect Mode Page as defined in SPC-2, which is to be re-defined for each SCSI transport as appropriate. IMO, the "MAXIMUM BURST SIZE" tunable of the disconnect-reconnect mode page makes sense in the parallel scsi context alone, where, either side (initiator or target) can specify how long the scsi bus can remain in the data phase before a disconnect must be done. In a fabric based SCSI transport, where, the data transfer does not cause any bus to be tied down, and the initiator's data buffers are allocated up-front before the SCSI command is sent to the target, I don't see any practical use of this key for initiators other than being informational, and allowing them to learn of the target's limits up-front at login time. I don't see why iSCSI needs to define this key, if its informational utility is of little or no value. I am also curious about what value FCP-2 initiators would find in this tunable. (?) Regards, Santosh "THALER,PAT (A-Roseville,ex1)" wrote: > > Julian, > > I still don't see the rational for MaxBurstSize. > > The initiator doesn't need it to limit its required resources. The initiator > has to have its buffers allocated when it issues a command. It has to > control the demand on its resources by limiting the commands it issues based > upon its available resources. > > The target has FirstBurstSize and R2T's to control the demand on its > resources. > > The other use of MaxBurstSize is to limit how often target may set the A > bit, but the utility of this is unclear. > > Regards, > Pat Thaler > > ---Original message---- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Tuesday, February 12, 2002 12:33 AM > To: Robert D. Russell > Cc: ips@ece.cmu.edu > Subject: Re: UNH Plugfest > +++ > >
> 3. Section 3.8.3 limits the value of the Desired Data Transfer Length in > an R2T to at most MaxBurstSize. What is the rationale for this? > An R2T is sent by the target to the initiator, so why can't the > target specify any size it wants in the R2T? The target already > uses R2Ts to control the flow of Data-Out PDUs from the initiator, > so why impose this restriction on the R2Ts? > > Could someone please explain the benefit to this limitation on R2Ts? > > +++ Is this a plugfest question or one of your own? For your own questions > the channels are always open. The MaxBurstSize is there to enable the > initiator to share resources between several executing commands and limit > the number of "pending buffers" a target will have to keep > in case one of the Data Out PDUS is damaged and transfer to a device is not > possible. > > +++ -- ################################## 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 Feb 22 00:54: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 AAA14835 for ; Fri, 22 Feb 2002 00:54:39 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1M5EIa02060 for ips-outgoing; Fri, 22 Feb 2002 00:14:18 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1M5EHj02056 for ; Fri, 22 Feb 2002 00:14:17 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.us.ibm.com [9.99.140.22]) by e33.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id AAA48788; Fri, 22 Feb 2002 00:11:03 -0500 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay01.boulder.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1M5Cwf235636; Thu, 21 Feb 2002 22:12:58 -0700 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: MaxBurstSize To: Santosh Rao Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Thu, 21 Feb 2002 14:22:13 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 02/21/2002 10:12:58 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I believe, we need to consider this as issue with devices that can be both initiators and targets. Take for example a streaming tape; when it is reading the data from a Disk Storage Controller. Often these device start a long I/O streaming action and have less memory then will contain the data they are requesting. Through various double buffering techniques, they can keep the data coming in, and going out to tape, without back-hitching. So I believe MaxBurstSize has value, even if the disk storage folks think it is minimal. . . . 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 Santosh Rao @ece.cmu.edu on 02/21/2002 01:35:49 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: iSCSI: MaxBurstSize Pat, The MaxBurstSize login key is a don't care for iscsi initiators. It serves mostly an informational purpose, letting the initiator know at login time as to what is the maximum amount of data it can expect the target to request in 1 R2T request, or the maximum amount of data it can receive from the target in 1 data-in sequence. Most initiators should be negotiating this to the maximum possible value, thereby, indicating to the target to just return the maximum value it supports for MaxBurstSize. The MaxBurstSize itself is inherited as one of the tunables from the scsi Disconnect-Reconnect Mode Page as defined in SPC-2, which is to be re-defined for each SCSI transport as appropriate. IMO, the "MAXIMUM BURST SIZE" tunable of the disconnect-reconnect mode page makes sense in the parallel scsi context alone, where, either side (initiator or target) can specify how long the scsi bus can remain in the data phase before a disconnect must be done. In a fabric based SCSI transport, where, the data transfer does not cause any bus to be tied down, and the initiator's data buffers are allocated up-front before the SCSI command is sent to the target, I don't see any practical use of this key for initiators other than being informational, and allowing them to learn of the target's limits up-front at login time. I don't see why iSCSI needs to define this key, if its informational utility is of little or no value. I am also curious about what value FCP-2 initiators would find in this tunable. (?) Regards, Santosh "THALER,PAT (A-Roseville,ex1)" wrote: > > Julian, > > I still don't see the rational for MaxBurstSize. > > The initiator doesn't need it to limit its required resources. The initiator > has to have its buffers allocated when it issues a command. It has to > control the demand on its resources by limiting the commands it issues based > upon its available resources. > > The target has FirstBurstSize and R2T's to control the demand on its > resources. > > The other use of MaxBurstSize is to limit how often target may set the A > bit, but the utility of this is unclear. > > Regards, > Pat Thaler > > ---Original message---- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Tuesday, February 12, 2002 12:33 AM > To: Robert D. Russell > Cc: ips@ece.cmu.edu > Subject: Re: UNH Plugfest > +++ > >
> 3. Section 3.8.3 limits the value of the Desired Data Transfer Length in > an R2T to at most MaxBurstSize. What is the rationale for this? > An R2T is sent by the target to the initiator, so why can't the > target specify any size it wants in the R2T? The target already > uses R2Ts to control the flow of Data-Out PDUs from the initiator, > so why impose this restriction on the R2Ts? > > Could someone please explain the benefit to this limitation on R2Ts? > > +++ Is this a plugfest question or one of your own? For your own questions > the channels are always open. The MaxBurstSize is there to enable the > initiator to share resources between several executing commands and limit > the number of "pending buffers" a target will have to keep > in case one of the Data Out PDUS is damaged and transfer to a device is not > possible. > > +++ -- ################################## 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 Feb 22 01:41: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 BAA15258 for ; Fri, 22 Feb 2002 01:41:08 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1M65f405148 for ips-outgoing; Fri, 22 Feb 2002 01:05:41 -0500 (EST) 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 g1M65dj05142 for ; Fri, 22 Feb 2002 01:05:39 -0500 (EST) Received: from FRED-W2K6.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1M65WE21069; Thu, 21 Feb 2002 22:05:32 -0800 (PST) Message-Id: <4.3.2.7.2.20020221204828.01bd8ee0@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Feb 2002 20:56:58 -0800 To: "CAVANNA,VICENTE V (A-Roseville,ex1)" From: Fred Baker Subject: Re: is 1 Gbps a MUST? Cc: "'ips@ece.cmu.edu'" , "SHEEHY,DAVE (A-Americas,unix1)" , "CAVANNA,VICENTE V (A-Roseville,ex1)" , "THALER,PAT (A-Roseville,ex1)" In-Reply-To: <01A7DAF31F93D511AEE300D0B706ED9201BF477F@axcs13.cos.agilen t.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ips@ece.cmu.edu Precedence: bulk At 03:06 PM 2/21/2002, CAVANNA,VICENTE V (A-Roseville,ex1) wrote: >If my interpretation is correct, the current (and earlier ones too) >security draft >at http://www.drizzle.com/~aboba/RDMA/draft-ietf-ips-security-10.txt >seems to say that an IPSec implementation MUST be capable of running at 1 Gbps. I won't respond to the wording of the draft, but to the sense that it must be intended to convey. If the wording doesn't convey this, it is the wording which must change. It seems to me that if the transfer of encrypted data at nominal link rates is expected, then encryption and decryption must be achieved at link rates. If 1 GBPS link rates are in view, guess what rates are important. If 10 GBPS... It seems to me that the question is not whether or not you are mandated to implement IPSEC in software, but what you need to do to accomplish link speed encryption and decryption. Hardware and software are duals; you can implement the algorithm either way, and the trade-off is money vs speed. We offer our customers both software and hardware options for IPSEC, and if the expected encryption rate is above certain speeds, we get fairly insistent on the latter. We call that "common sense". From owner-ips@ece.cmu.edu Fri Feb 22 01:44: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 BAA15305 for ; Fri, 22 Feb 2002 01:44:49 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1M61GT04886 for ips-outgoing; Fri, 22 Feb 2002 01:01:16 -0500 (EST) 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 g1M61Ej04881 for ; Fri, 22 Feb 2002 01:01:15 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id HAA13060 for ; Fri, 22 Feb 2002 07:01:04 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1M62i488552 for ; Fri, 22 Feb 2002 07:02:44 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: key negotiation - Unrecognized value? X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 22 Feb 2002 08:02:48 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 22/02/2002 08:02:50, Serialize complete at 22/02/2002 08:02:50 Content-Type: multipart/alternative; boundary="=_alternative 001FE3FCC2256B68_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001FE3FCC2256B68_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Eddy, This thread took way too much list space. I made it clear from the outset=20 that I'll fix the text. Julo Eddy Quicksall 21-02-02 20:24 =20 To: Julian Satran/Haifa/IBM@IBMIL cc: "KRUEGER,MARJORIE (HP-Roseville,ex1)" , "ips@ece.=20 cmu. edu (E-mail)" Subject: RE: iSCSI: key negotiation - Unrecognized value? =20 Julian, =20 If we can use "reject" when it is not a list, can you please make that=20 clear? Also can we allow it for boolean's too just for completeness? =20 The rev 10 spec currently says: =20 If a responder does not support or is not allowed to use=20 all of the offered options with a specific originator, it=20 may use the constant "Reject".=20 =20 That is in the discussion of list negotiations. And an EMAIL you sent on=20 2/6 (RE: iSCSI: Boolean value (yes, no) negotiation) said: =20 --snip-- > Eddy is right - reject is not intended/valid for booleans. > > Julo =20 =20 Eddy =20 =20 -----Original Message----- From: Julian Satran [mailto:Julian=5FSatran@il.ibm.com] Sent: Thursday, February 21, 2002 1:18 AM To: Luben Tuikov Cc: Ips Reflector (E-mail); KRUEGER,MARJORIE (HP-Roseville,ex1);=20 owner-ips@ece.cmu.edu Subject: Re: iSCSI: key negotiation - Unrecognized value? =20 Marjorie is correct - the text is (quite) explicit about requiring reject. = As for you example - the value to be answered by the target is the maximum = acceptable - see the rules for numeric negotiations.=20 Julo=20 =20 Luben Tuikov =20 Sent by: owner-ips@ece.cmu.edu=20 20-02-02 22:21=20 =20 To: "KRUEGER,MARJORIE (HP-Roseville,ex1)"=20 =20 cc: "Ips Reflector (E-mail)" , Julian=20 Satran/Haifa/IBM@IBMIL=20 Subject: Re: iSCSI: key negotiation - Unrecognized value?=20 =20 "KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote: >=20 > What is the proper response if you recognize a key, but are offered a=20 value > that you don't recognize? For instance, what if MaxConnections=3Dyes is > offered? >=20 > Where is that specified in the document? v10, pg 34, top: Any other 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=3DNotUnderstood. v10, pg 33, middle: If a responder does not support or is not allowed to use all of the offered options with a specific originator, it may use the constant "Reject". Comments? --=20 Luben Tuikov, Senior Software Engineer, Splentec Ltd. Bus: +1-905-707-1954x112, 9-5 EST. Fax: +1-905-707-1974. --=_alternative 001FE3FCC2256B68_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Eddy,

This thread took way too much list s= pace. I made it clear from the outset that I'll fix the text.

Julo


Eddy Quicksall <Eddy=5FQuicksa= ll@ivivity.com>

21-02-02 20:24

       
        To: &nbs= p;      Julian Satran/Haifa/IBM@IBMIL
        cc: &nbs= p;      "KRUEGER,MARJORIE (HP-Roseville,ex1)" <= marjorie=5Fkrueger@hp.com>, "ips@ece. cmu. edu (E-mail)" <i= ps@ece.cmu.edu>
        Subject:=        RE: iSCSI: key negotiation - Unrecognized value= ?

       


Julian,

 

If we can use "reject" whe= n it is not a list, can you please make that clear? Also can we allow it fo= r boolean's too just for completeness?

 

The rev 10 spec currently = says:

 
If a responder does= not support or is not allowed to use
all of the offered = options with a specific originator, it
may use the constan= t "Reject".

 

That is in the discussion = of list negotiations. And an EMAIL you sent on 2/6 (RE: iSCSI: Boolean valu= e (yes, no) negotiation) said:

 

--snip--

> Eddy is right -= reject is not intended/valid for booleans.

>

> Julo

 

 

Eddy

 

 

-----Original Message-----
From: Julian Satran [mailto:Julian=5FSatran@il.ibm.com]
Sent: Thursday, February 21, 2002 1:18 AM
To: Luben Tuikov
Cc: Ips Reflector (E-mail); KRUEGER,MARJORIE (HP-Roseville,ex1); owner-= ips@ece.cmu.edu
Subject: Re: iSCSI: key negotiation - Unrecognized value?

 


Marjorie is correct - the text is (quite) explicit about requiring reject.<= /font>
As for you example - the value to be answered by the target is the maximum = acceptable - see the rules for numeric negotiations.

Julo

  Luben Tuikov <lube= n@splentec.com>
Sent by: owner-ips@ece.cmu.edu20-02-02 22:21 		        <= /font>
       To:        "KRUEGER,MA= RJORIE (HP-Roseville,ex1)" <marjorie=5Fkrueger@hp.com>
       cc:        "Ips Reflec= tor (E-mail)" <ips@ece.cmu.edu>, Julian Satran/Haifa/IBM@IBMIL
       Subject:        Re: iSCSI: = key negotiation - Unrecognized value?

     



"KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote:
>
> What is the proper response if you recognize a key, but are offered a = value
> that you don't recognize?  For instance, what if MaxConnections= =3Dyes is
> offered?
>
> Where is that specified in the document?

v10, pg 34, top:

Any other 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=3DNotUnderstood.

v10, pg 33, middle:

If a responder does not support or is not allowed to use
all of the offered options with a specific originator,
it may use the constant "Reject".


Comments?

--
Luben Tuikov, Senior Software Engineer, Splentec Ltd.
Bus: +1-905-707-1954x112, 9-5 EST. Fax: +1-905-707-1974.



--=_alternative 001FE3FCC2256B68_=-- From owner-ips@ece.cmu.edu Fri Feb 22 05:08: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 FAA25890 for ; Fri, 22 Feb 2002 05:08:19 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1M9IlH15497 for ips-outgoing; Fri, 22 Feb 2002 04:18:47 -0500 (EST) 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 g1M9Ihj15490; Fri, 22 Feb 2002 04:18:43 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id KAA129624; Fri, 22 Feb 2002 10:18:29 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1M9KDR71028; Fri, 22 Feb 2002 10:20:13 +0100 To: "THALER,PAT (A-Roseville,ex1)" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu, "Robert D. Russell" MIME-Version: 1.0 Subject: Re: iSCSI: MaxBurstSize X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 22 Feb 2002 11:20:11 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 22/02/2002 11:20:15, Serialize complete at 22/02/2002 11:20:15 Content-Type: multipart/alternative; boundary="=_alternative 00226E74C2256B68_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00226E74C2256B68_= Content-Type: text/plain; charset="us-ascii" Pat, For the initiator it is mostly a design issue and you can do without it (it tells what to expect an R2T to be, how much to prefetch etc.). For the target it is the A bit interval and a turnaround opportunity for bi-directional. For bridges and gateways it is obviously helpful. Julo "THALER,PAT (A-Roseville,ex1)" Sent by: owner-ips@ece.cmu.edu 21-02-02 21:47 To: Julian Satran/Haifa/IBM@IBMIL, "Robert D. Russell" cc: ips@ece.cmu.edu Subject: iSCSI: MaxBurstSize Julian, I still don't see the rational for MaxBurstSize. The initiator doesn't need it to limit its required resources. The initiator has to have its buffers allocated when it issues a command. It has to control the demand on its resources by limiting the commands it issues based upon its available resources. The target has FirstBurstSize and R2T's to control the demand on its resources. The other use of MaxBurstSize is to limit how often target may set the A bit, but the utility of this is unclear. Regards, Pat Thaler ---Original message---- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, February 12, 2002 12:33 AM To: Robert D. Russell Cc: ips@ece.cmu.edu Subject: Re: UNH Plugfest +++

3. Section 3.8.3 limits the value of the Desired Data Transfer Length in an R2T to at most MaxBurstSize. What is the rationale for this? An R2T is sent by the target to the initiator, so why can't the target specify any size it wants in the R2T? The target already uses R2Ts to control the flow of Data-Out PDUs from the initiator, so why impose this restriction on the R2Ts? Could someone please explain the benefit to this limitation on R2Ts? +++ Is this a plugfest question or one of your own? For your own questions the channels are always open. The MaxBurstSize is there to enable the initiator to share resources between several executing commands and limit the number of "pending buffers" a target will have to keep in case one of the Data Out PDUS is damaged and transfer to a device is not possible. +++ --=_alternative 00226E74C2256B68_= Content-Type: text/html; charset="us-ascii"
Pat,

For the initiator it is mostly a design issue and you can do without it (it tells what to expect an R2T to be, how much to prefetch etc.). For the target it is the A bit interval and a turnaround opportunity for bi-directional. For bridges and gateways it is obviously helpful.  

Julo


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

21-02-02 21:47

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

       


Julian,

I still don't see the rational for MaxBurstSize.

The initiator doesn't need it to limit its required resources. The initiator
has to have its buffers allocated when it issues a command. It has to
control the demand on its resources by limiting the commands it issues based
upon its available resources.

The target has FirstBurstSize and R2T's to control the demand on its
resources.

The other use of MaxBurstSize is to limit how often target may set the A
bit, but the utility of this is unclear.

Regards,
Pat Thaler


---Original message----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, February 12, 2002 12:33 AM
To: Robert D. Russell
Cc: ips@ece.cmu.edu
Subject: Re: UNH Plugfest
+++

<Section 3.8.3 should be 10.8.3>
3. Section 3.8.3 limits the value of the Desired Data Transfer Length in
 an R2T to at most MaxBurstSize.  What is the rationale for this?
  An R2T is sent by the target to the initiator, so why can't the
 target specify any size it wants in the R2T?  The target already
 uses R2Ts to control the flow of Data-Out PDUs from the initiator,
 so why impose this restriction on the R2Ts?

 Could someone please explain the benefit to this limitation on R2Ts?

+++ Is this a plugfest question or one of your own?  For your own questions
the channels are always open.  The MaxBurstSize is there to enable the
initiator to share resources between several executing commands and limit
the number of "pending buffers" a target will have to keep
in case one of the Data Out PDUS is damaged and transfer to a device is not
possible.

+++


--=_alternative 00226E74C2256B68_=-- From owner-ips@ece.cmu.edu Fri Feb 22 05:38: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 FAA26330 for ; Fri, 22 Feb 2002 05:38:38 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1M9sFC17447 for ips-outgoing; Fri, 22 Feb 2002 04:54:15 -0500 (EST) 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 g1M9sEj17443 for ; Fri, 22 Feb 2002 04:54:14 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id KAA28070 for ; Fri, 22 Feb 2002 10:54:06 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1M9tk458578 for ; Fri, 22 Feb 2002 10:55:46 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: FMarker, RFMarkInt and SFMarkInt negotiation X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 22 Feb 2002 11:55:52 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 22/02/2002 11:55:53, Serialize complete at 22/02/2002 11:55:53 Content-Type: multipart/alternative; boundary="=_alternative 00358F02C2256B68_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00358F02C2256B68_= Content-Type: text/plain; charset="us-ascii" What would the IT and TI add? The information is already available in the PDU (IT and IT PDUS are different). Julo Martins Krikis Sent by: owner-ips@ece.cmu.edu 20-02-02 00:50 To: ips@ece.cmu.edu cc: Subject: FMarker, RFMarkInt and SFMarkInt negotiation Dear list members, I seem to be having problems (or at least mild surprises) reading A.3.1 to A.3.3 of draft 10. Would you mind answering a few questions and hearing out some beginner's ideas? Many thanks in advance. Is it true that RFMarkInt when used by initiator means the intervals for the T->I direction, while this same key used by target refers to the I->T direction? Similarly (well, dually) for SFMarkInt? That is, if initiator starts the negotiation and sends FMarker=receive; RFMarkInt=17,51 the target should answer with something like FMarker=send; SFMarkInt=34 (the numbers used are just examples). I'm not sure that RFMarker is properly negotiated if the answer for it comes with the key "SFMarker"... The fact that FMarker=receive by originator is the same as FMarker=send by responder isn't pretty either, but at least the given example leaves no doubt. Or does it? What if send/receive is always with respect to the target? It would contradict the general principle that most everything in iSCSI is named with respect to initiator, but no example eliminates this possibility... May I suggest that we use something like ITFMarkInt and TIFMarkInt to unambiguously show which direction is being talked about? I would also love to tinker with FMarker values a bit, ideally get rid of it (thus getting rid of a clear parameter dependency), and use ITFMarkInt=0 and TIFMarker=0 to denote that markers are not in use in the respective direction. Any comments will be greatly appreciated. Martins Krikis P.S. I am not really a fan of features that are useless for software implementations and that break protocol layering, but would like to at least understand how they are to be negotiated... __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com --=_alternative 00358F02C2256B68_= Content-Type: text/html; charset="us-ascii"
What would the IT and TI add? The information is already available in the PDU (IT and IT PDUS are different).

Julo


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

20-02-02 00:50

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        FMarker, RFMarkInt and SFMarkInt negotiation

       


Dear list members,

I seem to be having problems (or at least mild
surprises) reading A.3.1 to A.3.3 of draft 10.

Would you mind answering a few questions and hearing
out some beginner's ideas? Many thanks in advance.
Is it true that RFMarkInt when used by initiator
means the intervals for the T->I direction, while
this same key used by target refers to the I->T
direction? Similarly (well, dually) for SFMarkInt?

That is, if initiator starts the negotiation and sends
 FMarker=receive; RFMarkInt=17,51
the target should answer with something like
 FMarker=send; SFMarkInt=34
(the numbers used are just examples).

I'm not sure that RFMarker is properly negotiated
if the answer for it comes with the key "SFMarker"...

The fact that FMarker=receive by originator
is the same as FMarker=send by responder isn't
pretty either, but at least the given example
leaves no doubt. Or does it? What if send/receive
is always with respect to the target? It would
contradict the general principle that most everything
in iSCSI is named with respect to initiator, but
no example eliminates this possibility...

May I suggest that we use something like ITFMarkInt
and TIFMarkInt to unambiguously show which
direction is being talked about?

I would also love to tinker with FMarker values
a bit, ideally get rid of it (thus getting rid of
a clear parameter dependency), and use ITFMarkInt=0
and TIFMarker=0 to denote that markers are not in
use in the respective direction.

Any comments will be greatly appreciated.

 Martins Krikis

P.S. I am not really a fan of features that are
    useless for software implementations and that
    break protocol layering, but would like to at
    least understand how they are to be negotiated...


__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com

--=_alternative 00358F02C2256B68_=-- From owner-ips@ece.cmu.edu Fri Feb 22 06:53: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 GAA28311 for ; Fri, 22 Feb 2002 06:53:37 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1MAr7t01678 for ips-outgoing; Fri, 22 Feb 2002 05:53:07 -0500 (EST) 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 g1MAr3j01671 for ; Fri, 22 Feb 2002 05:53:03 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id LAA66452 for ; Fri, 22 Feb 2002 11:52:57 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1MAsa489828 for ; Fri, 22 Feb 2002 11:54:36 +0100 To: ips@ece.cmu.edu Importance: Low MIME-Version: 1.0 Subject: Re: iSCSI:Rules for processing keys and other doc organization commen ts X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 22 Feb 2002 12:54:42 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 22/02/2002 12:54:44, Serialize complete at 22/02/2002 12:54:44 Content-Type: multipart/alternative; boundary="=_alternative 003B6641C2256B68_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 003B6641C2256B68_= Content-Type: text/plain; charset="us-ascii" ----- Forwarded by Julian Satran/Haifa/IBM on 22-02-02 12:48 ----- Julian Satran 20-02-02 09:55 To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" cc: "CHADALAPAKA,MALLIKARJUN (HP-Roseville,ex1)" From: Julian Satran/Haifa/IBM@IBMIL Subject: Re: iSCSI:Rules for processing keys and other doc organization commen ts Marjorie, Some answers in text. Thanks , Julo "KRUEGER,MARJORIE (HP-Roseville,ex1)" 20-02-02 03:08 To: Julian Satran/Haifa/IBM@IBMIL cc: "CHADALAPAKA,MALLIKARJUN (HP-Roseville,ex1)" Subject: iSCSI:Rules for processing keys and other doc organization commen ts Julian, I've been trying to figure out which negotiable parameters should be included in the iSCSI MIB, and in the process of trying to figure this out, I've discovered some omissions in the document, and have some suggestions regarding the organization/content of certain sections in the document. The easiest comment to fix: You've changed the description of the text keys in Sec. 12 and added some information for these keys (use, sender, scope). That format is not reflected in the other sections that contain key specifications (Appendix A.3, section 11 - security keys and values) +++ I will try to align them +++ Another easy fix: Section 11 - the very first paragraph has a spelling error, SecurityNegotiation is spelled "SecurityNegotiatian" +++ will fix+++ I'm puzzled by the change in size of certain text key values from 2**16-1 to 2**24-1 Why are these 24 bit integers rather than 32 bit integers? I.E, DataPDULength used to be 2**15-1, now changed to MaxRecvPDULength with size of 2**24-1, which seems like an odd maximum size? +++ When we had them in the mode pages we where limited to 16 bit counters. To express larger values we used a unit of 512byte. Now that we don't have mode pages we use byte as a unit and reverted to the limits dictated by the PDU format +++ In general, I feel that section 2 has several subsections that have outgrown the main section title of "Overview" - sections containing implementation details should be moved out of the "Overview" heading into A)their own sections B)the appropriate detail section heading. +++ will do that +++ I had a very difficult time determining which keys are "mandatory to recognize" and in the process of trying to figure that out, discovered that there are very specific details of key processing buried in the "Overview" section. I believe that the level of detail specified in section 2.2.4 belongs in section 4 Login, or section 12. +++ will see what I can do +++ There has been much confusion over the processing of keys - I believe it's due in part to the fact that the details necessary to process keys reside in 7 different sections. I like your separation of "Overview" from detail sections, but I would at least like to find all the "details" under the same major section heading, with a single sub-section that cross-references the sections necessary to frame the key processing picture :-) I've thought about how this might be fixed, and have the following suggestion: Title section 4 "Login and Text Mode Negotiation" Move current section 4 under this section (4.1) Move current Section 5 under this new section 4 (4.2) and Title it "Text Mode Negotiation" Move the details in Section 2.2.4 to this section. These details apply to both Login Negotiations and Text Negotiations, perhaps they can be the generic comment under the new section 4 +++ will consider - not a bad idea +++ I would also suggest adding a paragraph with the 2.2.4 text specifying that all text keys in sections ??? MUST be recognized, and therefore MUST NOT be answered with "NotUnderstood". I know that can be inferred by knowing the details of the whole document, but the poor parser implementor shouldn't have to read the whole document in detail. +++ I think it is said - but I will double check +++ Comments? Regards, Marjorie --=_alternative 003B6641C2256B68_= Content-Type: text/html; charset="us-ascii"
----- Forwarded by Julian Satran/Haifa/IBM on 22-02-02 12:48 -----
Julian Satran

20-02-02 09:55


        To:        "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
        cc:        "CHADALAPAKA,MALLIKARJUN (HP-Roseville,ex1)" <mallikarjun_chadalapaka@hp.com>
        From:        Julian Satran/Haifa/IBM@IBMIL
        Subject:        Re: iSCSI:Rules for processing keys and other doc organization commen        tsLink
 





Marjorie,

Some answers in text.

Thanks ,
Julo


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

20-02-02 03:08

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        "CHADALAPAKA,MALLIKARJUN (HP-Roseville,ex1)" <mallikarjun_chadalapaka@hp.com>
        Subject:        iSCSI:Rules for processing keys and other doc organization commen        ts

       


Julian,

I've been trying to figure out which negotiable parameters should be
included in the iSCSI MIB, and in the process of trying to figure this out,
I've discovered some omissions in the document, and have some suggestions
regarding the organization/content of certain sections in the document.

The easiest comment to fix:  You've changed the description of the text keys
in Sec. 12 and added some information for these keys (use, sender, scope).
That format is not reflected in the other sections that contain key
specifications (Appendix A.3, section 11 - security keys and values)
+++ I will try to align them +++

Another easy fix: Section 11 - the very first paragraph has a spelling
error, SecurityNegotiation is spelled "SecurityNegotiatian"
+++ will fix+++

I'm puzzled by the change in size of certain text key values from 2**16-1 to
2**24-1  Why are these 24 bit integers rather than 32 bit integers?  I.E,
DataPDULength used to be 2**15-1, now changed to MaxRecvPDULength with size
of 2**24-1, which seems like an odd maximum size?
+++ When we had them in the mode pages we where limited to 16 bit counters. To express larger values we used a unit of 512byte. Now that we don't have mode pages we use byte as a unit and reverted to the limits dictated by the PDU format +++

In general, I feel that section 2 has several subsections that have outgrown
the main section title of "Overview" - sections containing implementation
details should be moved out of the "Overview" heading into
A)their own sections
B)the appropriate detail section heading.

+++ will do that +++

I had a very difficult time determining which keys are "mandatory to
recognize" and in the process of trying to figure that out, discovered that
there are very specific details of key processing buried in the "Overview"
section.  I believe that the level of detail specified in section 2.2.4
belongs in section 4 Login, or section 12.
+++ will see what I can do +++

There has been much confusion over the processing of keys - I believe it's
due in part to the fact that the details necessary to process keys reside in
7 different sections.  I like your separation of "Overview" from detail
sections, but I would at least like to find all the "details" under the same
major section heading, with a single sub-section that cross-references the
sections necessary to frame the key processing picture :-)

I've thought about how this might be fixed, and have the following
suggestion:

Title section 4 "Login and Text Mode Negotiation"
Move current section 4 under this section (4.1)
Move current Section 5 under this new section 4 (4.2) and Title it "Text
Mode Negotiation"
Move the details in Section 2.2.4 to this section.  These details apply to
both Login Negotiations and Text Negotiations, perhaps they can be the
generic comment under the new section 4
+++ will consider - not a bad idea +++

I would also suggest adding a paragraph with the 2.2.4 text specifying that
all text keys in sections ??? MUST be recognized, and therefore MUST NOT be
answered with "NotUnderstood".  I know that can be inferred by knowing the
details of the whole document, but the poor parser implementor shouldn't
have to read the whole document in detail.

+++ I think it is said - but I will double check +++

Comments?

Regards,
Marjorie



--=_alternative 003B6641C2256B68_=-- From owner-ips@ece.cmu.edu Fri Feb 22 07:49: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 HAA29911 for ; Fri, 22 Feb 2002 07:49:00 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1MBsNG04978 for ips-outgoing; Fri, 22 Feb 2002 06:54:23 -0500 (EST) 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 g1MBsLj04972 for ; Fri, 22 Feb 2002 06:54:21 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id MAA73590; Fri, 22 Feb 2002 12:53:52 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1MBtR405818; Fri, 22 Feb 2002 12:55:28 +0100 To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu, kevin_lemay@agilent.com, luben@splentec.com, marjorie_krueger@hp.com, pat_thaler@agilent.com MIME-Version: 1.0 Subject: RE: iSCSI: key negotiation - Unrecognized value? X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 22 Feb 2002 13:55:32 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 22/02/2002 13:55:39, Serialize complete at 22/02/2002 13:55:39 Content-Type: multipart/alternative; boundary="=_alternative 00412037C2256B68_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00412037C2256B68_= Content-Type: text/plain; charset="us-ascii" you are correct. Julo pat_thaler@agilent.com 21-02-02 02:50 To: pat_thaler@agilent.com, kevin_lemay@agilent.com, luben@splentec.com, marjorie_krueger@hp.com cc: ips@ece.cmu.edu, Julian Satran/Haifa/IBM@IBMIL Subject: RE: iSCSI: key negotiation - Unrecognized value? Thinking about this response further, "protocol error" should be replaced by "negotiation failure." 2.2.4 says that selection of an inadmissible value must be considered a protocol error and handled accordingly, but 7.8 Protocol Errors doesn't seem to say anything relevant to this type of error. Also during login one cannot send a reject PDU with a reason code of Protocol Error. 7.8 Negotiation Failures does contain relevant actions and should replace protocol error in 2.2.4. Pat -----Original Message----- From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@agilent.com] Sent: Wednesday, February 20, 2002 3:34 PM To: LEMAY,KEVIN (A-Roseville,ex1); 'Luben Tuikov'; KRUEGER,MARJORIE (HP-Roseville,ex1) Cc: Ips Reflector (E-mail); Julian Satran Subject: RE: iSCSI: key negotiation - Unrecognized value? 2.2.4 says: "The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are reserved and must only be used as described here." NotUnderstood is for a key not understood by the responder. The draft doesn't say it is used for a value that is not understood. It currently describes Reject only in the context of list negotiation where it is used when none of the values in the offered list are acceptable. For the example Luben gives of a numerical negotiation (MaxConnections), Reject would never be a valid response. If the originator offers a higher valid value than the responder is willing to accept, the responder would respond with the lower number that it is willing to accept. So a valid negotiation for the case where the originator asks for a valid assignable value than the responder is willing to support would be something like: Originator-> MaxConnections=65535 Responder-> MaxConnections=3 In the example Luben gave, 4294967296 is not a valid value for MaxConnections because it is outside the range . The draft doesn't say what to do about out of range values and other invalid values. The draft does say that "selection of a value not admissible under the selection rules rules is considered a protocol error and is handled accordingly." The context for that statement appears to be the selection of a value offered by the responder, but that action would also make sense for responding to a value that is invalid for the key (wrong type of value or out of range). An implementation offering an invalid value is broken which makes proceeding with the negotiation a problem. Sending a "Reject" also would be a reasonable response to an invalid value but it seems that offering an invalid value is just as severe an error as the ones that currently are responded to with protocol errors. Regards, Pat -----Original Message----- From: LEMAY,KEVIN (A-Roseville,ex1) [mailto:kevin_lemay@agilent.com] Sent: Wednesday, February 20, 2002 12:33 PM To: 'Luben Tuikov'; KRUEGER,MARJORIE (HP-Roseville,ex1) Cc: Ips Reflector (E-mail); Julian Satran Subject: RE: iSCSI: key negotiation - Unrecognized value? My impression was that "notUnderstood" was used if the key name itself could not be decoded. I believe that the correct behavior in the specific case should be: Originator-> MaxConnections=yes Responder-> MaxConnections=reject (with a login response of "Initiator error") The reason being, is that this key is clearly defined as a numeric field with specific ranges of values. To send a non-numeric value for this key would be an initiator error and should be treated as such. Although processing as "notunderstood" may allow the login to continue, it will also "cover up" the error allowing bad code to continue live on. Do we really want to make it easy for people to not even follow the spec? Kevin Lemay -----Original Message----- From: Luben Tuikov [mailto:luben@splentec.com] Sent: Wednesday, February 20, 2002 12:17 PM To: KRUEGER,MARJORIE (HP-Roseville,ex1) Cc: Ips Reflector (E-mail); Julian Satran Subject: Re: iSCSI: key negotiation - Unrecognized value? Marjorie, Julian, all, When a value doesn't belong to the valid set of assignable values to a key, but is offered, as Marjorie's example, shouldn't the following take place: Originator-> MaxConnections=yes Responder-> MaxConnections=NotUnderstood Also, isn't ``Reject'' used for a valid, assignable value, but for which the responder has no resources: Originator-> MaxConnections=4294967296 Responder-> MaxConnections=Reject I.e. the responder cannot allow 2^32 connections, since the OS will not allow it in the first place... (If your OS allows it, replace the number with 1e3000 above ;-) ? P.S. The ``NotUnderstood'' reply above would also be semantically correct. -- Luben Tuikov, Senior Software Engineer, Splentec Ltd. Bus: +1-905-707-1954x112, 9-5 EST. Fax: +1-905-707-1974. --=_alternative 00412037C2256B68_= Content-Type: text/html; charset="us-ascii"
you are correct. Julo


pat_thaler@agilent.com

21-02-02 02:50

       
        To:        pat_thaler@agilent.com, kevin_lemay@agilent.com, luben@splentec.com, marjorie_krueger@hp.com
        cc:        ips@ece.cmu.edu, Julian Satran/Haifa/IBM@IBMIL
        Subject:        RE: iSCSI: key negotiation - Unrecognized value?

       


Thinking about this response further, "protocol error" should be replaced by
"negotiation failure." 2.2.4 says that selection of an inadmissible value
must be considered a protocol error and handled accordingly, but 7.8
Protocol Errors doesn't seem to say anything relevant to this type of error.
Also during login one cannot send a reject PDU with a reason code of
Protocol Error.

7.8 Negotiation Failures does contain relevant actions and should replace
protocol error in 2.2.4.

Pat

-----Original Message-----
From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@agilent.com]
Sent: Wednesday, February 20, 2002 3:34 PM
To: LEMAY,KEVIN (A-Roseville,ex1); 'Luben Tuikov'; KRUEGER,MARJORIE
(HP-Roseville,ex1)
Cc: Ips Reflector (E-mail); Julian Satran
Subject: RE: iSCSI: key negotiation - Unrecognized value?


2.2.4 says: "The constants "None", "Reject", "Irrelevant", and
"NotUnderstood" are reserved and must only be used as described here."

NotUnderstood is for a key not understood by the responder. The draft
doesn't say it is used for a value that is not understood.

It currently describes Reject only in the context of list negotiation where
it is used when none of the values in the offered list are acceptable. For
the example Luben gives of a numerical negotiation (MaxConnections), Reject
would never be a valid response. If the originator offers a higher valid
value than the responder is willing to accept, the responder would respond
with the lower number that it is willing to accept. So a valid negotiation
for the case where the originator asks for a valid assignable value than the
responder is willing to support would be something like:

Originator-> MaxConnections=65535
Responder->  MaxConnections=3

In the example Luben gave, 4294967296 is not a valid value for
MaxConnections because it is outside the range <number-from-1-to-65535>. The
draft doesn't say what to do about out of range values and other invalid
values.

The draft does say that "selection of a value not admissible under the
selection rules rules is considered a protocol error and is handled
accordingly." The context for that statement appears to be the selection of
a value offered by the responder, but that action would also make sense for
responding to a value that is invalid for the key (wrong type of value or
out of range). An implementation offering an invalid value is broken which
makes proceeding with the negotiation a problem.

Sending a "Reject" also would be a reasonable response to an invalid value
but it  seems that offering an invalid value is just as severe an error as
the ones that currently are responded to with protocol errors.

Regards,
Pat



-----Original Message-----
From: LEMAY,KEVIN (A-Roseville,ex1) [mailto:kevin_lemay@agilent.com]
Sent: Wednesday, February 20, 2002 12:33 PM
To: 'Luben Tuikov'; KRUEGER,MARJORIE (HP-Roseville,ex1)
Cc: Ips Reflector (E-mail); Julian Satran
Subject: RE: iSCSI: key negotiation - Unrecognized value?


My impression was that "notUnderstood" was used if the key name itself could
not be decoded.

I believe that the correct behavior in the specific case should be:

Originator-> MaxConnections=yes
Responder->  MaxConnections=reject (with a login response of "Initiator
error")

The reason being, is that this key is clearly defined as a numeric field
with specific ranges of values. To send a non-numeric value for this key
would be an initiator error and should be treated as such.

Although processing as "notunderstood" may allow the login to continue, it
will also "cover up" the error allowing bad code to continue live on. Do we
really want to make it easy for people to not even follow the spec?

Kevin Lemay

-----Original Message-----
From: Luben Tuikov [mailto:luben@splentec.com]
Sent: Wednesday, February 20, 2002 12:17 PM
To: KRUEGER,MARJORIE (HP-Roseville,ex1)
Cc: Ips Reflector (E-mail); Julian Satran
Subject: Re: iSCSI: key negotiation - Unrecognized value?


Marjorie, Julian, all,

When a value doesn't belong to the valid set of
assignable values to a key, but is offered,
as Marjorie's example, shouldn't the following
take place:

Originator-> MaxConnections=yes
Responder->  MaxConnections=NotUnderstood

Also, isn't ``Reject'' used for a valid, assignable
value, but for which the responder has no resources:

Originator-> MaxConnections=4294967296
Responder->  MaxConnections=Reject

I.e. the responder cannot allow 2^32 connections,
since the OS will not allow it in the first place...
(If your OS allows it, replace the number with 1e3000
above ;-)

?

P.S. The ``NotUnderstood'' reply above would also
be semantically correct.

--
Luben Tuikov, Senior Software Engineer, Splentec Ltd.
Bus: +1-905-707-1954x112, 9-5 EST. Fax: +1-905-707-1974.

--=_alternative 00412037C2256B68_=-- From owner-ips@ece.cmu.edu Fri Feb 22 10:40: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 KAA06398 for ; Fri, 22 Feb 2002 10:40:47 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1MF8Tq17116 for ips-outgoing; Fri, 22 Feb 2002 10:08:29 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c003.snv.cp.net (c003-h000.c003.snv.cp.net [209.228.32.214]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g1MF8Rj17109 for ; Fri, 22 Feb 2002 10:08:28 -0500 (EST) Received: (cpmta 17866 invoked from network); 22 Feb 2002 07:08:21 -0800 Received: from 64.130.130.105 (HELO dougrmt) by smtp.telocity.com (209.228.32.214) with SMTP; 22 Feb 2002 07:08:21 -0800 X-Sent: 22 Feb 2002 15:08:21 GMT From: "Douglas Otis" To: "Fred Baker" Cc: "Ips" Subject: RE: is 1 Gbps a MUST? Date: Fri, 22 Feb 2002 07:11:07 -0800 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <4.3.2.7.2.20020221204828.01bd8ee0@mira-sjcm-2.cisco.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit At 08:57 PM 2/21/2002, Fred Baker (fred@cisco.com) wrote: > > At 03:06 PM 2/21/2002, CAVANNA,VICENTE V (A-Roseville,ex1) wrote: > >If my interpretation is correct, the current (and earlier ones too) > >security draft at > >http://www.drizzle.com/~aboba/RDMA/draft-ietf-ips-security-10.txt > >seems to say that an IPSec implementation MUST be capable of > >running at 1 Gbps. > > I won't respond to the wording of the draft, but to the sense > that it must be intended to convey. If the wording doesn't > convey this, it is the wording which must change. > > It seems to me that if the transfer of encrypted data at nominal > link rates is expected, then encryption and decryption must be > achieved at link rates. If 1 GBPS link rates are in view, guess > what rates are important. If 10 GBPS... > > It seems to me that the question is not whether or not you are > mandated to implement IPSEC in software, but what you need to do > to accomplish link speed encryption and decryption. Hardware and > software are duals; you can implement the algorithm either way, > and the trade-off is money vs speed. > > We offer our customers both software and hardware options for > IPSEC, and if the expected encryption rate is above certain speeds, > we get fairly insistent on the latter. We call that "common sense". While wire speed parity is ideal, there may be queuing within the IPSEC engine ahead of TCP receive buffers and this will have the effect of pacing the send as the window will be consumed by this queue together with an apparent RTT increase. This does not mean packets must be dropped should the engine lag behind wire speed. Framing offered in SCTP allows segments to be processed irrespective of reception order as does IPSEC, but for such a scheme to be used with TCP, a generalized convention should be adopted within the transport to accommodate pre-application processing that may include a robust checking scheme together with PDU to buffer assignments. Placing PDU pre-processing and PDU to buffer assignment at the IP layer is onerous as advocated by iSCSI. Even combined with TCP, without standardized conventions, a selective process based on application association must be employed. Each new application then imposes unique interfacing and processing by means of these hodgepodge structures. Each application will also need optimization to modularize this unique and optional transport layer processing which will likely become application specific networking APIs. Creating conventions for this technique, if to be included within TCP to assist high speed processing, forestalls degeneration of standardization. Doug From owner-ips@ece.cmu.edu Fri Feb 22 10:48: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 KAA06832 for ; Fri, 22 Feb 2002 10:48:37 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1MEtdI16011 for ips-outgoing; Fri, 22 Feb 2002 09:55:39 -0500 (EST) 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 g1MEtXj16003 for ; Fri, 22 Feb 2002 09:55:34 -0500 (EST) 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 g1MEtIi12376; Fri, 22 Feb 2002 09:55:18 -0500 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with SMTP id g1MEtIf26758; Fri, 22 Feb 2002 09:55:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15478.23509.921845.263858@pkoning.dev.equallogic.com> Date: Fri, 22 Feb 2002 09:55:17 -0500 (EST) From: Paul Koning To: vince_cavanna@agilent.com Cc: ips@ece.cmu.edu Subject: Re: is 1 Gbps a MUST? References: <01A7DAF31F93D511AEE300D0B706ED9201BF4787@axcs13.cos.agilent.com> X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Vince" == A-Roseville,ex1 writes: Vince> Thanks for the clarification. Something still bothers me Vince> however. If IPSec is a bottleneck (because the policy lookup Vince> is done in software) then the receiver may be forced to drop Vince> packets quite frequently. Such behavior could have a dramatic Vince> effect on performance as explained in a memo that Jonathan Vince> Stone posted on 2/5/02 (attached) and in my interpretation Vince> which I did not post on 2/6/02 (attached). Comments? Your assumption "policy lookup is done in software" is not necessarily valid -- just like the popular assertion "TCP is slow because it is done in software" is not necessarily valid. Apart from that, the fact that it's done in software doesn't necessarily make it slow. It is certainly doable with a decent network processor to do SPD lookup at 1Gb/s line speeds in software. Note also that SPD lookup for encrypted traffic is often quite easy. You already have the inbound SA (and that lookup is trivial if you assign SAIDs sensibly). You can bind to that the list of SPD entries -- often just one -- describing the traffic that is allowed to travel on that SA, so you have no search, only a compare of the SPD entry with the address/port/protocol fields of the packet. Going back to the original question, I read the statement in the security spec as a protocol requirement, not an implementation requirement -- so it constrains the choice of security protocol. IPsec ESP can be implemented to run at the specified speeds in the timeframes called for (the whole thing -- not just the crypto primitives) so it satisfies that requirement on the protocol. (It's not trivial to achieve this -- nor is it inexpensive -- but it *can* be done if you really want to.) But there is no requirement on implementations to run at that speed, of course. It would be good for the security spec wording to be clarified so makes it explicit that this is a protocol selection requirement, not an implementation requirement. paul From owner-ips@ece.cmu.edu Fri Feb 22 12:05: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 MAA11148 for ; Fri, 22 Feb 2002 12:05:41 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1MG3bX21863 for ips-outgoing; Fri, 22 Feb 2002 11:03:37 -0500 (EST) 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 g1MG3aj21858 for ; Fri, 22 Feb 2002 11:03:36 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id RAA46572 for ; Fri, 22 Feb 2002 17:03:29 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1MG59424804 for ; Fri, 22 Feb 2002 17:05:09 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSI - started countdown to 11 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 22 Feb 2002 18:05:13 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 22/02/2002 18:05:17, Serialize complete at 22/02/2002 18:05:17 Content-Type: multipart/alternative; boundary="=_alternative 0057C3FCC2256B68_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0057C3FCC2256B68_= Content-Type: text/plain; charset="us-ascii" Dear colleagues, I've put on my site a "working" version of the draft labeled 10-90. Only the pdf version (with change bars vs. 10) is available. I'll soon get out also a text version - without a TOC but otherwise usable. Julo --=_alternative 0057C3FCC2256B68_= Content-Type: text/html; charset="us-ascii"
Dear colleagues,

I've put on my site a "working" version of the draft labeled 10-90.
Only the pdf version (with change bars vs. 10) is available.
I'll soon get out also a text version - without a TOC but otherwise usable.

Julo --=_alternative 0057C3FCC2256B68_=-- From owner-ips@ece.cmu.edu Fri Feb 22 13:00: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 NAA13931 for ; Fri, 22 Feb 2002 13:00:25 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1MH0b126328 for ips-outgoing; Fri, 22 Feb 2002 12:00:37 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1MH0Zj26320 for ; Fri, 22 Feb 2002 12:00:35 -0500 (EST) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id <190QYH30>; Fri, 22 Feb 2002 12:00:31 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029374CD@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: Heads UP -Minneapolis Agenda is in flux Date: Fri, 22 Feb 2002 12:00:27 -0500 Importance: high X-Priority: 1 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've issued general warnings in the past that IETF agendas are subject to change until the final agenda is posted to the web site. This is a specific warning that the meeting days for IPS are in the process of being changed - at the moment, it looks like they're going to be changed to Mon & Tue from the current Tue & Thu, but nothing is certain until the final agenda is posted. 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 Fri Feb 22 14:05: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 OAA17159 for ; Fri, 22 Feb 2002 14:05:40 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1MIi6204698 for ips-outgoing; Fri, 22 Feb 2002 13:44:06 -0500 (EST) 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 g1MIi4j04692 for ; Fri, 22 Feb 2002 13:44:05 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 1DBDA2FB7; Fri, 22 Feb 2002 11:44:04 -0700 (MST) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id EE8B92BA; Fri, 22 Feb 2002 11:44:03 -0700 (MST) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 22 Feb 2002 11:44:04 -0700 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Feb 2002 11:44:03 -0700 Message-ID: <01A7DAF31F93D511AEE300D0B706ED9201BF478C@axcs13.cos.agilent.com> From: "CAVANNA,VICENTE V (A-Roseville,ex1)" To: "'Paul Koning'" Cc: ips@ece.cmu.edu, "CAVANNA,VICENTE V (A-Roseville,ex1)" Subject: RE: is 1 Gbps a MUST? Date: Fri, 22 Feb 2002 11:44:01 -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 Paul, I agree with everything you said. What I was hoping to get comments on, is my interpretation of Jonathan Stone's claim and its implications to IPSec. Jonathan pointed out the need for bandwidth*RoundTripDelay worth of buffering per TCP connection to avoid a cliff-effect drop in performance; and I extrapolated the need to have no bottlenecks (such as IPSec) anywhere in the path to those buffers. From my perspective IPSec, or at least the part of IPSec that discriminates between secured and unsecured traffic, had better not be a bottleneck or IPSec will not be turned on at all. Vince |-----Original Message----- |From: Paul Koning [mailto:ni1d@arrl.net] |Sent: Friday, February 22, 2002 6:55 AM |To: vince_cavanna@agilent.com |Cc: ips@ece.cmu.edu |Subject: Re: is 1 Gbps a MUST? | | |>>>>> "Vince" == A-Roseville,ex1 writes: | | Vince> Thanks for the clarification. Something still bothers me | Vince> however. If IPSec is a bottleneck (because the policy lookup | Vince> is done in software) then the receiver may be forced to drop | Vince> packets quite frequently. Such behavior could have a dramatic | Vince> effect on performance as explained in a memo that Jonathan | Vince> Stone posted on 2/5/02 (attached) and in my interpretation | Vince> which I did not post on 2/6/02 (attached). Comments? | |Your assumption "policy lookup is done in software" is not necessarily |valid -- just like the popular assertion "TCP is slow because it is |done in software" is not necessarily valid. | |Apart from that, the fact that it's done in software doesn't |necessarily make it slow. It is certainly doable with a decent |network processor to do SPD lookup at 1Gb/s line speeds in software. | |Note also that SPD lookup for encrypted traffic is often quite easy. |You already have the inbound SA (and that lookup is trivial if you |assign SAIDs sensibly). You can bind to that the list of SPD entries |-- often just one -- describing the traffic that is allowed to travel |on that SA, so you have no search, only a compare of the SPD entry |with the address/port/protocol fields of the packet. | |Going back to the original question, I read the statement in the |security spec as a protocol requirement, not an implementation |requirement -- so it constrains the choice of security protocol. |IPsec ESP can be implemented to run at the specified speeds in the |timeframes called for (the whole thing -- not just the crypto |primitives) so it satisfies that requirement on the protocol. (It's |not trivial to achieve this -- nor is it inexpensive -- but it *can* |be done if you really want to.) But there is no requirement on |implementations to run at that speed, of course. | |It would be good for the security spec wording to be clarified so |makes it explicit that this is a protocol selection requirement, not |an implementation requirement. | | paul | From owner-ips@ece.cmu.edu Fri Feb 22 14:06: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 OAA17232 for ; Fri, 22 Feb 2002 14:06:48 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1MICIQ01848 for ips-outgoing; Fri, 22 Feb 2002 13:12:18 -0500 (EST) 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 g1MICFj01838 for ; Fri, 22 Feb 2002 13:12:15 -0500 (EST) Message-ID: <20020222181211.76393.qmail@web13703.mail.yahoo.com> Received: from [192.52.58.4] by web13703.mail.yahoo.com via HTTP; Fri, 22 Feb 2002 10:12:11 PST Date: Fri, 22 Feb 2002 10:12:11 -0800 (PST) From: Martins Krikis Subject: Re: FMarker, RFMarkInt and SFMarkInt negotiation 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 --- Julian Satran wrote: > What would the IT and TI add? The information is > already available in the > PDU (IT and IT PDUS are different). They would add clarity and consistency to text negotiation. The concepts being negotiated are "fixed interval markers for the initiator to target direction" and "fixed interval markers for the target to initiator direction". So why should the keys used in negotiating these concepts be different depending on who sent them? If I'm implementing negotiation, I now have to do an extra mapping from a key (e.g., RFMarkInt) to the concept (ITFMarkInt or TIFMarkInt) and this mapping is different for initiators and targets (for the same operation, where operations are send/receive). Plus, if the sequence I mentioned (initiator offers) FMarker=receive; RFMarkInt=17,51 (target responds) FMarker=send; SFMarkInt=34 is correct, then it does not fit well in section 2.2.4, where the general format seems to mandate answering with the same KEY (not the same concept). A little further down there is also a requirement to answer numerical negotiations with the "required key". If the "required key" may or may not be the same key that was received, this should be mentioned. (Of course, one could argue that this is not a numerical negotiation, because ranges are allowed, not just single numbers, but this, too is not obvious to the casual reader.) What I was proposing was simply naming the keys after the concepts and avoiding the extra mapping step and seeming conflicts with 2.2.4. I am a pedant. As to FMarker, its negotiation is very different from everything else in that it may look like a list negotiation because of the list of possible values given, but it isn't. It is yet another special-case parameter, and one that RFMarkInt and SFMarkInt depend on. I was suggesting getting rid of it altogether by allowing RFMarkInt/SFMarkInt (or, better yet, ITFMarkInt, TIFMarkInt) to carry value 0, which would mean that markers are not in use in the respective direction. Just because all the information is there and because implementation is possible, it doesn't mean that it cannot be organized more logically and simplify implementations. IMO, key names should match concept names regardless of how and by whom they are being used; and all parameter dependencies for operational phase should be eliminated. Martins Krikis, Intel Corp. Disclaimer: these opinions are my own and not necessarily those of my employer. __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com From owner-ips@ece.cmu.edu Fri Feb 22 14:28: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 OAA18073 for ; Fri, 22 Feb 2002 14:28:25 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1MIsJh05576 for ips-outgoing; Fri, 22 Feb 2002 13:54:19 -0500 (EST) 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 g1MIsIj05570 for ; Fri, 22 Feb 2002 13:54:18 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 7C05B2F5C; Fri, 22 Feb 2002 11:54:17 -0700 (MST) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 2B3632D5; Fri, 22 Feb 2002 11:54:17 -0700 (MST) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 22 Feb 2002 11:54:17 -0700 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Feb 2002 11:54:17 -0700 Message-ID: <01A7DAF31F93D511AEE300D0B706ED9201BF478D@axcs13.cos.agilent.com> From: vince_cavanna@agilent.com To: fred@cisco.com Cc: ips@ece.cmu.edu, dave_sheehy@agilent.com, vince_cavanna@agilent.com, pat_thaler@agilent.com Subject: RE: is 1 Gbps a MUST? Date: Fri, 22 Feb 2002 11:54: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 Hi Fred, | |I won't respond to the wording of the draft, but to the sense |that it must |be intended to convey. If the wording doesn't convey this, it is the |wording which must change. | |It seems to me that if the transfer of encrypted data at |nominal link rates |is expected, then encryption and decryption must be achieved |at link rates. |If 1 GBPS link rates are in view, guess what rates are |important. If 10 GBPS... Unfortunately some believe that they can be iSCSI compliant by having a slow implementation of IPSec and claiming that most traffic will not require security processing. I am not one of those persons. I think that at least the policy check must occur at link speed regardless of what proportion of traffic requires security processing. | |It seems to me that the question is not whether or not you are |mandated to |implement IPSEC in software, but what you need to do to |accomplish link |speed encryption and decryption. Hardware and software are |duals; you can |implement the algorithm either way, and the trade-off is money |vs speed. I agree, and I did not mean to imply otherwise. I am trying to gather opinions from this group on whether link speed encryption/decryption is necessary, especially now that Bernad Aboba has clarified that the spec does not mandate it. Vince From owner-ips@ece.cmu.edu Fri Feb 22 15:41: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 PAA22818 for ; Fri, 22 Feb 2002 15:41:57 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1MKBUS12392 for ips-outgoing; Fri, 22 Feb 2002 15:11:30 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from demetrius.hosting.pacbell.net (demetrius.hosting.pacbell.net [216.100.99.31]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1MKBRj12384 for ; Fri, 22 Feb 2002 15:11:27 -0500 (EST) Received: from somesh ([65.172.158.93]) by demetrius.hosting.pacbell.net id PAA19501; Fri, 22 Feb 2002 15:10:57 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Reply-To: From: "Somesh Gupta" To: "Julian Satran" Cc: "IPS" Subject: RE: iSCSI - started countdown to 11 Date: Fri, 22 Feb 2002 12:10:57 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01C1BB99.FC063460" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_002E_01C1BB99.FC063460 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Julian, The language in A.1 should be changed from the most recent change. Two things on the changes - 1. We should have a MAY instead of (the now lower case) should to indicate the agreement reached - or worst case delete the sentence. 2. The last sentence in the first para - newly added & repititive (last sentence in previous paragraph) - (in my opinion) tries to get around the agreement. It should either be deleted, or changed to "some receiver implementation will provide (significantly) better performance when the sender inserts markers" or "some receiver implementations may provide degraded performance to senders which do not insert markers". I prefer that we just not add it. You have something like that in the previous paragraph anyway. One comment on what was not changed - 1. The last sentence in the para before A.1 - "in certain environment, a sender ...." - I would suggest be changed to "in certain implementation, ...". As the behavior is more implementation dependent. We reached a compromise on keeping it in the main draft and making it a MAY. I hope we can keep that spirit. Somesh -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Friday, February 22, 2002 8:05 AM To: ips@ece.cmu.edu Subject: iSCSI - started countdown to 11 Dear colleagues, I've put on my site a "working" version of the draft labeled 10-90. Only the pdf version (with change bars vs. 10) is available. I'll soon get out also a text version - without a TOC but otherwise usable. Julo ------=_NextPart_000_002E_01C1BB99.FC063460 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Julian,
 
The=20 language in A.1 should be changed from the most recent change. Two=20 things
on the=20 changes -
1. We=20 should have a MAY instead of (the now lower case) should = to
indicate the agreement reached - or worst = case delete=20 the sentence.
 
2. The=20 last sentence in the first para - newly added & repititive=20 (last
sentence in previous paragraph) = -
(in my=20 opinion) tries to get around the agreement. It should = either
be=20 deleted, or changed to "some receiver implementation will=20 provide
(significantly) better performance when the = sender=20 inserts markers" or
"some=20 receiver implementations may provide degraded = performance
to=20 senders which do not insert markers". I prefer that we just not add=20 it.
You=20 have something like that in the previous paragraph = anyway.
 
One=20 comment on what was not changed -
1. The=20 last sentence in the para before A.1 - "in certain environment,=20 a
sender=20 ...." - I would suggest be changed to "in certain implementation,=20 ...".
As the=20 behavior is more implementation dependent.
 
We=20 reached a compromise on keeping it in the main draft and=20 making
it a=20 MAY. I hope we can keep that spirit.
 
Somesh
-----Original Message-----
From: = owner-ips@ece.cmu.edu=20 [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian=20 Satran
Sent: Friday, February 22, 2002 8:05 AM
To: = ips@ece.cmu.edu
Subject: iSCSI - started countdown to 11=20


Dear = colleagues,=20

I've put on my site a = "working" version=20 of the draft labeled 10-90.
Only the=20 pdf version (with change bars vs. 10) is available.
I'll soon get out also a text version - = without a TOC=20 but otherwise usable.

Julo
------=_NextPart_000_002E_01C1BB99.FC063460-- From owner-ips@ece.cmu.edu Fri Feb 22 15:43: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 PAA22900 for ; Fri, 22 Feb 2002 15:43:39 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1MK0FE11352 for ips-outgoing; Fri, 22 Feb 2002 15:00:15 -0500 (EST) 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 g1MK0Dj11345 for ; Fri, 22 Feb 2002 15:00:13 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.us.ibm.com [9.99.140.23]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA104832; Fri, 22 Feb 2002 14:56:57 -0500 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.99.140.13]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1MK09E45106; Fri, 22 Feb 2002 13:00:09 -0700 X-Priority: 1 (High) Importance: Normal Subject: RE: is 1 Gbps a MUST? To: vince_cavanna@agilent.com Cc: fred@cisco.com, ips@ece.cmu.edu, dave_sheehy@agilent.com, vince_cavanna@agilent.com, pat_thaler@agilent.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Fri, 22 Feb 2002 11:59:08 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 02/22/2002 01:00:09 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Folks, There will be folks that will operate on 100 Mb/s links and will use iSCSI with Encryption. To say that they do not comply with the spec, for that reason, is a bit silly. Likewise, I believe there will be many desktops and laptops that will support 10/100/1000 ethernet adapters and be thrilled with 300 Mb/s, it is also not reasonable to say that they can not claim compliance. The spec is intended to say that the protocol must be capable of being supported at 1 Giga bit per second. I think most of us agree that it is. So to say that those folks that do not operate at gigabit speed are non compliant is inappropriate. . . . 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 vince_cavanna@agilent.com@ece.cmu.edu on 02/22/2002 10:54:15 AM Sent by: owner-ips@ece.cmu.edu To: fred@cisco.com cc: ips@ece.cmu.edu, dave_sheehy@agilent.com, vince_cavanna@agilent.com, pat_thaler@agilent.com Subject: RE: is 1 Gbps a MUST? Hi Fred, | |I won't respond to the wording of the draft, but to the sense |that it must |be intended to convey. If the wording doesn't convey this, it is the |wording which must change. | |It seems to me that if the transfer of encrypted data at |nominal link rates |is expected, then encryption and decryption must be achieved |at link rates. |If 1 GBPS link rates are in view, guess what rates are |important. If 10 GBPS... Unfortunately some believe that they can be iSCSI compliant by having a slow implementation of IPSec and claiming that most traffic will not require security processing. I am not one of those persons. I think that at least the policy check must occur at link speed regardless of what proportion of traffic requires security processing. | |It seems to me that the question is not whether or not you are |mandated to |implement IPSEC in software, but what you need to do to |accomplish link |speed encryption and decryption. Hardware and software are |duals; you can |implement the algorithm either way, and the trade-off is money |vs speed. I agree, and I did not mean to imply otherwise. I am trying to gather opinions from this group on whether link speed encryption/decryption is necessary, especially now that Bernad Aboba has clarified that the spec does not mandate it. Vince From owner-ips@ece.cmu.edu Fri Feb 22 15: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 PAA23303 for ; Fri, 22 Feb 2002 15:51:14 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1MKEOt12711 for ips-outgoing; Fri, 22 Feb 2002 15:14:24 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from EXCHANGE.aciesnetworks.com (exchange.aciesnetworks.com [65.90.51.20]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1MKEMj12706 for ; Fri, 22 Feb 2002 15:14:22 -0500 (EST) Received: from D3XG0X01 ([10.105.2.130]) by EXCHANGE.aciesnetworks.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 22 Feb 2002 13:14:15 -0700 Message-ID: <008301c1bbdd$35acfb20$8202690a@D3XG0X01> From: "Bob Mastors" To: References: <20020222181211.76393.qmail@web13703.mail.yahoo.com> Subject: Re: FMarker, RFMarkInt and SFMarkInt negotiation Date: Fri, 22 Feb 2002 13:12: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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 22 Feb 2002 20:14:15.0659 (UTC) FILETIME=[803AD3B0:01C1BBDD] Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I agree with the general concern. FMarker is processed unlike any of the other negotiated keys. It would be nice if it worked like HeaderDigest or AuthMethod and presented a . R/SFMarkInt also stands out as different (and needing special code) because it takes a range. But I can see that this would take more effort to fix. And then there is the requirement in A.3.2 that "Whenever FMarker and RFMarker are both sent, they MUST appear on the same login request/response." This seems unnecessary to me and will require special code to handle. But I imagine that most implementers (myself included) will just ignore the requirement and hope the pdu doesn't get so full as to cause FMarker to be in one pdu and RFMarker to be in the next. And why are the units in 4 byte words instead of bytes with an alignment requirement. It seems like everything else in the spec is in bytes. I am not really in favor of FIM but if the hardware folks really want it I don't mind implementing it. It is not that much work. It would make my life easier as an implementer if the keys worked like the other keys in section 12. Apologies in advance if this has already been hashed out. Bob ----- Original Message ----- From: "Martins Krikis" To: Sent: Friday, February 22, 2002 11:12 AM Subject: Re: FMarker, RFMarkInt and SFMarkInt negotiation > --- Julian Satran wrote: > > What would the IT and TI add? The information is > > already available in the > > PDU (IT and IT PDUS are different). > > They would add clarity and consistency to text > negotiation. > > The concepts being negotiated are > "fixed interval markers for the initiator to target > direction" and "fixed interval markers for the target > to initiator direction". So why should the keys used > in negotiating these concepts be different depending > on who sent them? If I'm implementing negotiation, I > now have to do an extra mapping from a key (e.g., > RFMarkInt) to the concept (ITFMarkInt or TIFMarkInt) > and this mapping is different for initiators and > targets (for the same operation, where operations > are send/receive). Plus, if the sequence I mentioned > > (initiator offers) FMarker=receive; RFMarkInt=17,51 > (target responds) FMarker=send; SFMarkInt=34 > > is correct, then it does not fit well in section > 2.2.4, where the general format seems to mandate > answering with the same KEY (not the same concept). > A little further down there is also a requirement > to answer numerical negotiations with the "required > key". If the "required key" may or may not be the > same key that was received, this should be mentioned. > (Of course, one could argue that this is not a > numerical negotiation, because ranges are allowed, > not just single numbers, but this, too is not obvious > to the casual reader.) > > What I was proposing was simply naming the keys > after the concepts and avoiding the extra mapping > step and seeming conflicts with 2.2.4. I am a pedant. > > As to FMarker, its negotiation is very different > from everything else in that it may look like a list > negotiation because of the list of possible values > given, but it isn't. It is yet another special-case > parameter, and one that RFMarkInt and SFMarkInt > depend on. > > I was suggesting getting rid of it altogether by > allowing RFMarkInt/SFMarkInt (or, better yet, > ITFMarkInt, TIFMarkInt) to carry value 0, which > would mean that markers are not in use in the > respective direction. > > Just because all the information is there and because > implementation is possible, it doesn't mean that it > cannot be organized more logically and simplify > implementations. > > IMO, key names should match concept names regardless > of how and by whom they are being used; and all > parameter dependencies for operational phase should > be eliminated. > > Martins Krikis, Intel Corp. > > Disclaimer: these opinions are my own and not > necessarily those of my employer. > > __________________________________________________ > Do You Yahoo!? > Yahoo! Sports - Coverage of the 2002 Olympic Games > http://sports.yahoo.com From owner-ips@ece.cmu.edu Fri Feb 22 16:49: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 QAA27059 for ; Fri, 22 Feb 2002 16:49:10 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1MKuVW16321 for ips-outgoing; Fri, 22 Feb 2002 15:56:31 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1MKuSj16313 for ; Fri, 22 Feb 2002 15:56:28 -0500 (EST) Received: from fmsmsxvs041.fm.intel.com (fmsmsxv041-1.fm.intel.com [132.233.48.109]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.51 2002/02/19 21:12:32 root Exp $) with SMTP id UAA20391 for ; Fri, 22 Feb 2002 20:56:27 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002022212571107973 ; Fri, 22 Feb 2002 12:57:11 -0800 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id <1Y30G0VW>; Fri, 22 Feb 2002 12:56:26 -0800 Message-ID: <9678C2B4D848D41187450090276D1FAE1489B73D@FMSMSX32> From: "Zamer, Ahmad" To: "'John Hufferd'" , vince_cavanna@agilent.com Cc: fred@cisco.com, ips@ece.cmu.edu, dave_sheehy@agilent.com, vince_cavanna@agilent.com, pat_thaler@agilent.com Subject: RE: is 1 Gbps a MUST? Date: Fri, 22 Feb 2002 12:56:21 -0800 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, I would like to echo John's view of this topic. Regards, Ahmad Zamer Intel Corporation voice: 512-407-2155 mail: ahmad.zamer@intel.com -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Friday, February 22, 2002 1:59 PM To: vince_cavanna@agilent.com Cc: fred@cisco.com; ips@ece.cmu.edu; dave_sheehy@agilent.com; vince_cavanna@agilent.com; pat_thaler@agilent.com Subject: RE: is 1 Gbps a MUST? Folks, There will be folks that will operate on 100 Mb/s links and will use iSCSI with Encryption. To say that they do not comply with the spec, for that reason, is a bit silly. Likewise, I believe there will be many desktops and laptops that will support 10/100/1000 ethernet adapters and be thrilled with 300 Mb/s, it is also not reasonable to say that they can not claim compliance. The spec is intended to say that the protocol must be capable of being supported at 1 Giga bit per second. I think most of us agree that it is. So to say that those folks that do not operate at gigabit speed are non compliant is inappropriate. . . . 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 vince_cavanna@agilent.com@ece.cmu.edu on 02/22/2002 10:54:15 AM Sent by: owner-ips@ece.cmu.edu To: fred@cisco.com cc: ips@ece.cmu.edu, dave_sheehy@agilent.com, vince_cavanna@agilent.com, pat_thaler@agilent.com Subject: RE: is 1 Gbps a MUST? Hi Fred, | |I won't respond to the wording of the draft, but to the sense |that it must |be intended to convey. If the wording doesn't convey this, it is the |wording which must change. | |It seems to me that if the transfer of encrypted data at |nominal link rates |is expected, then encryption and decryption must be achieved |at link rates. |If 1 GBPS link rates are in view, guess what rates are |important. If 10 GBPS... Unfortunately some believe that they can be iSCSI compliant by having a slow implementation of IPSec and claiming that most traffic will not require security processing. I am not one of those persons. I think that at least the policy check must occur at link speed regardless of what proportion of traffic requires security processing. | |It seems to me that the question is not whether or not you are |mandated to |implement IPSEC in software, but what you need to do to |accomplish link |speed encryption and decryption. Hardware and software are |duals; you can |implement the algorithm either way, and the trade-off is money |vs speed. I agree, and I did not mean to imply otherwise. I am trying to gather opinions from this group on whether link speed encryption/decryption is necessary, especially now that Bernad Aboba has clarified that the spec does not mandate it. Vince From owner-ips@ece.cmu.edu Fri Feb 22 17: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 RAA27822 for ; Fri, 22 Feb 2002 17:01:28 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1MLV0p19285 for ips-outgoing; Fri, 22 Feb 2002 16:31:00 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from osmtp2.electric.net (osmtp2.electric.net [216.129.90.29]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1MLUwj19280 for ; Fri, 22 Feb 2002 16:30:58 -0500 (EST) Received: from [206.175.232.41] (helo=EGRodriguez) by osmtp2.electric.net with esmtp (Exim 3.22 #1) id 16eNGs-00090v-04; Fri, 22 Feb 2002 13:30:27 -0800 From: "Elizabeth G. Rodriguez" To: "'John Hufferd'" , Cc: , , , , Subject: RE: is 1 Gbps a MUST? Date: Fri, 22 Feb 2002 15:29:36 -0600 Keywords: IETF-IPS Message-ID: <00fb01c1bbe8$09c61db0$29e8afce@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, What John states below is accurate. In addition, even if we were to approve this mandate in the IPS WG (which we are not), I do not believe that the IESG will allow the specification to go forth if it is specified in the specification that encryption MUST occur at a minimum of 1 Gbps. There is no technically valid reason to make this a requirement. On the other hand, it is entirely appropriate to indicate in the spec that the PROTOCOL itself MUST be capable of supporting 1 Gbps. Thanks, Elizabeth IPS Co-chair -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of John Hufferd Sent: Friday, February 22, 2002 1:59 PM To: vince_cavanna@agilent.com Cc: fred@cisco.com; ips@ece.cmu.edu; dave_sheehy@agilent.com; vince_cavanna@agilent.com; pat_thaler@agilent.com Subject: RE: is 1 Gbps a MUST? Folks, There will be folks that will operate on 100 Mb/s links and will use iSCSI with Encryption. To say that they do not comply with the spec, for that reason, is a bit silly. Likewise, I believe there will be many desktops and laptops that will support 10/100/1000 ethernet adapters and be thrilled with 300 Mb/s, it is also not reasonable to say that they can not claim compliance. The spec is intended to say that the protocol must be capable of being supported at 1 Giga bit per second. I think most of us agree that it is. So to say that those folks that do not operate at gigabit speed are non compliant is inappropriate. . . . 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 vince_cavanna@agilent.com@ece.cmu.edu on 02/22/2002 10:54:15 AM Sent by: owner-ips@ece.cmu.edu To: fred@cisco.com cc: ips@ece.cmu.edu, dave_sheehy@agilent.com, vince_cavanna@agilent.com, pat_thaler@agilent.com Subject: RE: is 1 Gbps a MUST? Hi Fred, | |I won't respond to the wording of the draft, but to the sense |that it must |be intended to convey. If the wording doesn't convey this, it is the |wording which must change. | |It seems to me that if the transfer of encrypted data at |nominal link rates |is expected, then encryption and decryption must be achieved |at link rates. |If 1 GBPS link rates are in view, guess what rates are |important. If 10 GBPS... Unfortunately some believe that they can be iSCSI compliant by having a slow implementation of IPSec and claiming that most traffic will not require security processing. I am not one of those persons. I think that at least the policy check must occur at link speed regardless of what proportion of traffic requires security processing. | |It seems to me that the question is not whether or not you are |mandated to |implement IPSEC in software, but what you need to do to |accomplish link |speed encryption and decryption. Hardware and software are |duals; you can |implement the algorithm either way, and the trade-off is money |vs speed. I agree, and I did not mean to imply otherwise. I am trying to gather opinions from this group on whether link speed encryption/decryption is necessary, especially now that Bernad Aboba has clarified that the spec does not mandate it. Vince From owner-ips@ece.cmu.edu Fri Feb 22 17:04: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 RAA27963 for ; Fri, 22 Feb 2002 17:04:56 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1MLDCG17765 for ips-outgoing; Fri, 22 Feb 2002 16:13:13 -0500 (EST) 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 g1MLD9j17750 for ; Fri, 22 Feb 2002 16:13:09 -0500 (EST) 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 g1MLCpi15333; Fri, 22 Feb 2002 16:12:51 -0500 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with SMTP id g1MLCp115434; Fri, 22 Feb 2002 16:12:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15478.46163.391722.76594@pkoning.dev.equallogic.com> Date: Fri, 22 Feb 2002 16:12:51 -0500 (EST) From: Paul Koning To: vince_cavanna@agilent.com Cc: ips@ece.cmu.edu Subject: RE: is 1 Gbps a MUST? References: <01A7DAF31F93D511AEE300D0B706ED9201BF478D@axcs13.cos.agilent.com> X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "vince" == vince cavanna writes: vince> Unfortunately some believe that they can be iSCSI compliant by vince> having a slow implementation of IPSec and claiming that most vince> traffic will not require security processing. I am not one of vince> those persons. I think that at least the policy check must vince> occur at link speed regardless of what proportion of traffic vince> requires security processing. I can't think of any RFC that contains a performance mandate. For example, the TCP standard does not mandate doing TCP at wire rate or any other rate. The iSCSI spec does not mandate doing iSCSI at any particular rate. Why, then, should the security spec mandate doing something at some particular rate? vince> Jonathan pointed out the need for bandwidth*RoundTripDelay vince> worth of buffering per TCP connection to avoid a cliff-effect vince> drop in performance; and I extrapolated the need to have no vince> bottlenecks (such as IPSec) anywhere in the path to those vince> buffers. From my perspective IPSec, or at least the part of vince> IPSec that discriminates between secured and unsecured vince> traffic, had better not be a bottleneck or IPSec will not be vince> turned on at all. More generally, the throughput you get is that of the lowest throughput component, and the buffering you ideally want is that times the round-trip delay including any internal delays cause by high latency processing steps. That will drive your design decisions given a particular performance requirement. So if your example, if the requirement is X Mb/s total and Y Mb/s of that protected by IPsec, the sorting of protocol 50 from protocol 6, and the checking of protocol 6 traffic against the SPD to verify that it's allowed to travel in the clear, have to run at rate X (not Y) since they are a common bottleneck. What X is depends on what you're building. If you need X to be gigabit wire rate, you have some work to do, but nothing fundamental in IP or IPsec stands in the way. paul From owner-ips@ece.cmu.edu Fri Feb 22 17:11: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 RAA28249 for ; Fri, 22 Feb 2002 17:11:55 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1MLfBX20144 for ips-outgoing; Fri, 22 Feb 2002 16:41:11 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from erie.mcdata.com (mcjekyll.mcdata.com [144.49.6.25]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1MLf8j20133 for ; Fri, 22 Feb 2002 16:41:09 -0500 (EST) Received: from erie.mcdata.com ([172.18.1.35]) by erie.mcdata.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FM0CY7X7; Fri, 22 Feb 2002 14:40:51 -0700 Received: from 144.49.154.169 by erie.mcdata.com (InterScan E-Mail VirusWall NT); Fri, 22 Feb 2002 14:40:50 -0700 Received: by grizzly.mcdata.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Feb 2002 16:40:48 -0500 Message-ID: <1B8A58D6C376FE4DB329408E27013842448093@grizzly.mcdata.com> From: Robert Grant To: ips@ece.cmu.edu Subject: iSCSI: Gateways: list of topics? Date: Fri, 22 Feb 2002 16:40:48 -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 Jeffrey Chung, Rhapsody Networks, jchung@rhapsodynetworks.com, 510-743-3010 Rob Elliott, Compaq Server Storage, Robert.Elliott@compaq.com Rob Grant, McDATA, Robert.Grant@McDATA.com, 416-496-6564 Robert Griswold, Crossroads, rgriswold@crossroads.com, 512-928-7272 Michel Maddux, McDATA, Michel.Maddux@McDATA.com, 720-566-3760 Dave Peterson, Cisco Systems, dap@cisco.com Barry Reinhold, Trebia Networks, barry.reinhold@trebia.com, 603-868-5144 James Smart, Trebia Networks, james.smart@trebia.com, 978-264-7605 Joshua Tseng, Nishan Systems, jtseng@NishanSystems.com Naoki Watanabe,Hitachi America Ltd., naoki.watanabe@hds.com, 408.970.7088 Regards, Rob Rob Grant McDATA Corporation From owner-ips@ece.cmu.edu Fri Feb 22 17:12: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 RAA28263 for ; Fri, 22 Feb 2002 17:12:30 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1MLgwm20290 for ips-outgoing; Fri, 22 Feb 2002 16:42:58 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from erie.mcdata.com (mcjekyll.mcdata.com [144.49.6.25]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1MLguj20285 for ; Fri, 22 Feb 2002 16:42:56 -0500 (EST) Received: from erie.mcdata.com ([172.18.1.35]) by erie.mcdata.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FM0CY7YN; Fri, 22 Feb 2002 14:42:39 -0700 Received: from 144.49.154.169 by erie.mcdata.com (InterScan E-Mail VirusWall NT); Fri, 22 Feb 2002 14:42:38 -0700 Received: by grizzly.mcdata.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Feb 2002 16:42:36 -0500 Message-ID: <1B8A58D6C376FE4DB329408E27013842448094@grizzly.mcdata.com> From: Robert Grant To: "'ips@ece.cmu.edu'" Subject: Recall: iSCSI: Gateways: list of topics? Date: Fri, 22 Feb 2002 16:42:35 -0500 Expiry-Date: Sun, 24 Feb 2002 16:42:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk Robert Grant would like to recall the message, "iSCSI: Gateways: list of topics?". From owner-ips@ece.cmu.edu Fri Feb 22 18:28: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 SAA00988 for ; Fri, 22 Feb 2002 18:28:52 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1MME7s23024 for ips-outgoing; Fri, 22 Feb 2002 17:14:07 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from erie.mcdata.com (mcjekyll.mcdata.com [144.49.6.25]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1MME5j23018 for ; Fri, 22 Feb 2002 17:14:05 -0500 (EST) Received: from erie.mcdata.com ([172.18.1.35]) by erie.mcdata.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FM0CY8GP; Fri, 22 Feb 2002 15:13:48 -0700 Received: from 144.49.154.169 by erie.mcdata.com (InterScan E-Mail VirusWall NT); Fri, 22 Feb 2002 15:13:47 -0700 Received: by grizzly.mcdata.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Feb 2002 17:13:45 -0500 Message-ID: <1B8A58D6C376FE4DB329408E27013842448099@grizzly.mcdata.com> From: Robert Grant To: ips@ece.cmu.edu Subject: RE: iSCSI: Gateways: list of topics? Date: Fri, 22 Feb 2002 17:13:44 -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 Ooops, sorry - accidently hit the "Send" button too soon. I meant to say : Hello all, Here's a very brief list of topics which have arisen out of discussion of FCP to iSCSI Gateways. Should/can Gateways be "Transparent" or "non-Transparent"? How do Gateways generate Target Portal Group Tags? How do Gateways generate ISIDs? How do Gateways generate Node Names? - 64-bit node identifiers, NAA to EUI64 mapping etc. "SCSI'isms" - pages 18/19 for MODE SENSE/SELECT, protocol support returned in INQUIRY, TARGET RESET etc. Related protocols (IB/SRP etc.) If anyone has other FC-iSCSI Gateway topics they'd like to suggest, let me know. We're trying to form a "small" group to address such things in a draft. Here's the roster so far : Jeffrey Chung, Rhapsody Networks, jchung@rhapsodynetworks.com, 510-743-3010 Rob Elliott, Compaq Server Storage, Robert.Elliott@compaq.com Rob Grant, McDATA, Robert.Grant@McDATA.com, 416-496-6564 Robert Griswold, Crossroads, rgriswold@crossroads.com, 512-928-7272 John Hufferd, IBM, hufferd@us.ibm.com, (408) 256-0403 Michel Maddux, McDATA, Michel.Maddux@McDATA.com, 720-566-3760 Dave Peterson, Cisco Systems, dap@cisco.com Barry Reinhold, Trebia Networks, barry.reinhold@trebia.com, 603-868-5144 James Smart, Trebia Networks, james.smart@trebia.com, 978-264-7605 Joshua Tseng, Nishan Systems, jtseng@NishanSystems.com Naoki Watanabe,Hitachi America Ltd., naoki.watanabe@hds.com, 408.970.7088 Regards, Rob Rob Grant McDATA Corporation From owner-ips@ece.cmu.edu Fri Feb 22 18:58: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 SAA01637 for ; Fri, 22 Feb 2002 18:58:23 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1MNUJ928714 for ips-outgoing; Fri, 22 Feb 2002 18:30:19 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mc.va3.ummail.com (mc.va3.ummail.com [66.187.242.23]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1MNUGj28706 for ; Fri, 22 Feb 2002 18:30:16 -0500 (EST) Received: from hqmailweb.COMMSTOR.Crossroads.com (HQMailWeb.Crossroads.com [63.237.99.250:25]) by mc.va3.ummail.com with ESMTP id V0222-1829-5bfc00; Fri, 22 Feb 2002 23:29:42 GMT Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 22 Feb 2002 17:29:40 -0600 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: RE: iSCSI - started countdown to 11 Date: Fri, 22 Feb 2002 17:29:39 -0600 Message-ID: Thread-Topic: iSCSI - started countdown to 11 Thread-Index: AcG7w4IYA1aF26x8QqipXjS0qDUpVgAJyGyA From: "Buck Landry" To: "Julian Satran" , X-OriginalArrivalTime: 22 Feb 2002 23:29:40.0800 (UTC) FILETIME=[CCF55C00:01C1BBF8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g1MNUGj28707 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Two yes/no questions about the new Task Mgmt Function Request/Response wording. 1) Does ABORT_TASK_SET/CLEAR_TASK_SET apply to an immediate cmd with the same CmdSN? Or to rephrase, in this example scenario: T -> I (Nop-in, ExpCmdSN = 3) I -> T (Scsi Command, CmdSN = 3, Immediate bit set) I -> T (Task Mgmt Func Reqest, ABORT TASK SET, CmdSN = 3, Immediate bit set) .. is the scsi command aborted? The statement in section 9.5.1, "Task management requests must act on all commands having a CmdSN lower than the task management CmdSN" .. would resolve this nicely ("no") but in the same section, the wording "According to [SAM2] for all the tasks covered by the task management response (i.e., with CmdSN not higher than the task management command CmdSN)" ... implies that the task management response covers all tasks w/ equal or lower CmdSN while the request itself only covers tasks w/ lower CmdSN. ----- 2) For CLEAR TASK SET, does the target waiting behavior, "the target on its part, MUST wait for responses on all affected target transfer tags before acting on either of these two task management requests" .. include tasks that originated from a different initiator than the one that sent CLEAR TASK SET? Everything in the draft points to "yes" (I think), and I kindof actually like this. But I'm (somewhat) suprised that, given a scenario with two sessions attached to the same scsi target: session "A": I -> T (Scsi Write Cmd, lun = 8, tag = 2) session "A": T -> I (R2T, tag = 2) session "B": I -> T (Task Mgmt Function Request CLEAR TASK SET, lun = 8) .. that the target would require the cooperation of session "A"'s initiator and network connection in order to deliver a Task Mgmt Function Response to session "B". I suppose, if this cooperation did not occur, then eventually a timeout would fire, the affected task could just be forcefully killed, and a task management response could be sent on session "A".. is that the way it's supposed to work? Thanks for your consideration, --buck -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, February 22, 2002 10:05 AM To: ips@ece.cmu.edu Subject: iSCSI - started countdown to 11 Dear colleagues, I've put on my site a "working" version of the draft labeled 10-90. Only the pdf version (with change bars vs. 10) is available. I'll soon get out also a text version - without a TOC but otherwise usable. Julo From owner-ips@ece.cmu.edu Fri Feb 22 19:00: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 TAA01705 for ; Fri, 22 Feb 2002 19:00:43 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1MNFbX27652 for ips-outgoing; Fri, 22 Feb 2002 18:15:37 -0500 (EST) 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 g1MNFZj27648 for ; Fri, 22 Feb 2002 18:15:35 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id <107NPKL2>; Fri, 22 Feb 2002 18:15:25 -0500 Message-ID: <25369470B6F0D41194820002B328BDD22F55C0@ATLOPS> From: Eddy Quicksall To: "ERICKSON,SHAWN (HP-Roseville,ex1)" , "'Elliott, Robert'" , ips@ece.cmu.edu Subject: RE: iSCSI UNH Plugfest Date: Fri, 22 Feb 2002 18:15:18 -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 > The iSCSI initiator driver should clean up the CDB as needed > (your first > suggestion) and keep the wire protocol clean. If it's in an OS > generating old CDBs, it knows that and is best suited to fix them. > Don't burden the iSCSI targets with any of this. I don't agree that the iSCSI initiator should touch the CDB. This is a ULP issue and the issuer of the CDB should use or not use the bits as desired. Maybe that is what you meant. Eddy -----Original Message----- From: ERICKSON,SHAWN (HP-Roseville,ex1) [mailto:shawn_erickson@hp.com] Sent: Friday, February 15, 2002 12:17 PM To: 'Elliott, Robert'; ips@ece.cmu.edu Subject: RE: iSCSI UNH Plugfest > -----Original Message----- > From: Elliott, Robert [mailto:Robert.Elliott@compaq.com] > Sent: Thursday, February 14, 2002 6:58 PM > To: ips@ece.cmu.edu > Subject: RE: iSCSI UNH Plugfest > > > Although those bits are often reserved, some commands use them (e.g. > SEND DIAGNOSTIC). It's not safe to guess that they contain a > 3 bit LUN > value. Correct. > The iSCSI initiator driver should clean up the CDB as needed > (your first > suggestion) and keep the wire protocol clean. If it's in an OS > generating old CDBs, it knows that and is best suited to fix them. > Don't burden the iSCSI targets with any of this. I second that! > The UNH test suite should check for compliance for this and > other basic [snip] > * logical units implement VPD pages 80h and 83h > * 80h unit serial number > * 83h NAA type IEEE Registered or IEEE Registered Extended Yes, please do. The world will be a better place for storage administrators, your customers will love you. > * initiators don't send TARGET RESETs Yes, please do. Disruptive in multi-initiator environments (which is mostly the domain of FC & iSCSI). > * initiators use logical unit VPD data to identify logical units, not > the dynamic fabric/bus address of the target YES, please do. Again your customers will love you! -Shawn > > -----Original Message----- > > From: Robert D. Russell [mailto:rdr@io.iol.unh.edu] > > Sent: Thursday, February 14, 2002 4:12 PM > > To: Julian Satran > > Cc: ips@ece.cmu.edu > > Subject: Re: UNH Plugfest > > > > > > Julian: > > > > The last several days at the UNH plugfest have uncovered no major > > issues relating to the standard. > > > > One thing that was observed was that a number of implementations are > > dealing with SCSI-2 systems, because most of the world > (i.e., Windows) > > is still based on SCSI-2. The iSCSI standard clearly references the > > SCSI-3 specifications. However, perhaps we should consider > how iSCSI > > could be used with SCSI-2. > > > > In particular, there is the issue of LUNs. Some implementers are > > expecting some SCSI-2 CDBs to carry a LUN number in the 3 high-order > > bits of byte 1 in the CDB, and are not setting/using the LUN field > > in the iSCSI PDU. This is clearly wrong, although if both > target and > > initiator do it, then they interoperate with each other but not with > > standard-conformant implementations. > > > > Of course, there may be (and probably are) additional > issues (besides > > the LUN issue) that may arise. However, it still might be useful to > > warn implementers that this is an issue, and perhaps to suggest a > > "conversion rule" that would allow SCSI-2 to interoperate > with iSCSI. > > > > One possibility for such a rule follows: > > > > If an iSCSI initiator has to send a SCSI-2 PDU containing a LUN, > > it should extract the LUN from the 3 high-order bits of CDB byte 1 > > and send that in the iSCSI LUN field (unless, of course, it has some > > other means of obtaining the LUN value independent of the > > CDB, in which > > case it should send that value in the iSCSI LUN field). > > > > If an iSCSI target receives a SCSI-2 PDU containing a LUN, then if > > the iSCSI LUN field is 0 it should extract the LUN value from the > > 3 high-order bits of CDB byte 1 (which in the SCSI-3 case > > should always > > be 0 anyway) and use that as the LUN value; > > if the iSCSI LUN field is not 0 then it should use that as > > the LUN value. > > > > At first glance this rule seems to allow an initiator > and/or a target > > to interoperate with both SCSI-2 and SCSI-3 systems. > > From owner-ips@ece.cmu.edu Fri Feb 22 19:01: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 TAA01737 for ; Fri, 22 Feb 2002 19:01:02 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1MNU7n28689 for ips-outgoing; Fri, 22 Feb 2002 18:30:07 -0500 (EST) 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 g1MNU5j28684 for ; Fri, 22 Feb 2002 18:30:05 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id <107NPKLR>; Fri, 22 Feb 2002 18:30:05 -0500 Message-ID: <25369470B6F0D41194820002B328BDD22F55C2@ATLOPS> From: Eddy Quicksall To: Julian Satran , ips@ece.cmu.edu Subject: RE: iSCSI - started countdown to 11 Date: Fri, 22 Feb 2002 18:29:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BBF8.D5D73960" 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_01C1BBF8.D5D73960 Content-Type: text/plain; charset="iso-8859-1" Should "Reject" be added to this? Originator-> = Responder-> =|NotUnderstood|Irrelevant Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, February 22, 2002 11:05 AM To: ips@ece.cmu.edu Subject: iSCSI - started countdown to 11 Dear colleagues, I've put on my site a "working" version of the draft labeled 10-90. Only the pdf version (with change bars vs. 10) is available. I'll soon get out also a text version - without a TOC but otherwise usable. Julo ------_=_NextPart_001_01C1BBF8.D5D73960 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Should = “Reject” be added to this?

Originator-> = <key>=3D<valuex>

Responder-> = <key>=3D<valuey>|NotUnderstood|Irrelevant

<= ![if = !supportEmptyParas]> 

=

<= ![if = !supportEmptyParas]> 

=

E= ddy

<= ![if = !supportEmptyParas]> 

=

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, February = 22, 2002 11:05 AM
To: ips@ece.cmu.edu
Subject: iSCSI - started = countdown to 11

 


Dear = colleagues,

I've put on my site a "working" version of the draft labeled = 10-90.
Only the pdf version (with = change bars vs. 10) is available.
I'll soon get out also a = text version - without a TOC but otherwise usable.

Julo=

------_=_NextPart_001_01C1BBF8.D5D73960-- From owner-ips@ece.cmu.edu Fri Feb 22 19:22: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 TAA02204 for ; Fri, 22 Feb 2002 19:22:51 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1MNclj29366 for ips-outgoing; Fri, 22 Feb 2002 18:38:47 -0500 (EST) 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 g1MNcjj29361 for ; Fri, 22 Feb 2002 18:38:45 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id <107NPKLV>; Fri, 22 Feb 2002 18:38:45 -0500 Message-ID: <25369470B6F0D41194820002B328BDD22F55C3@ATLOPS> From: Eddy Quicksall To: Julian Satran , ips@ece.cmu.edu Subject: RE: iSCSI - started countdown to 11 Date: Fri, 22 Feb 2002 18:38:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BBFA.0E5FC4E0" 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_01C1BBFA.0E5FC4E0 Content-Type: text/plain; charset="iso-8859-1" Since most things start with upper case, should we do that for all cases? I think the only ones left are: FMarker= SessionType= Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, February 22, 2002 11:05 AM To: ips@ece.cmu.edu Subject: iSCSI - started countdown to 11 Dear colleagues, I've put on my site a "working" version of the draft labeled 10-90. Only the pdf version (with change bars vs. 10) is available. I'll soon get out also a text version - without a TOC but otherwise usable. Julo ------_=_NextPart_001_01C1BBFA.0E5FC4E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

S= ince most things start with upper case, should we do that for all cases? I think = the only ones left are:

<= ![if = !supportEmptyParas]> 

=

FMarker=3D<send|receive|send-receive|No>=

SessionType=3D <discovery|normal>

 

<= ![if = !supportEmptyParas]> 

=

<= ![if = !supportEmptyParas]> 

=

E= ddy

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, February = 22, 2002 11:05 AM
To: ips@ece.cmu.edu
Subject: iSCSI - started = countdown to 11

 


Dear = colleagues,

I've put on my site a "working" version of the draft labeled = 10-90.
Only the pdf version (with = change bars vs. 10) is available.
I'll soon get out also a = text version - without a TOC but otherwise usable.

Julo=

------_=_NextPart_001_01C1BBFA.0E5FC4E0-- From owner-ips@ece.cmu.edu Fri Feb 22 20:24: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 UAA03286 for ; Fri, 22 Feb 2002 20:24:31 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1N0VGu02788 for ips-outgoing; Fri, 22 Feb 2002 19:31:16 -0500 (EST) 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 g1N0VEj02783 for ; Fri, 22 Feb 2002 19:31:14 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id F256B2F97 for ; Fri, 22 Feb 2002 17:31:13 -0700 (MST) Received: from axcsbh5.cos.agilent.com (axcsbh5.cos.agilent.com [130.29.152.150]) by msgrel1.cos.agilent.com (Postfix) with SMTP id C773F30D for ; Fri, 22 Feb 2002 17:31:13 -0700 (MST) Received: from 130.29.152.150 by axcsbh5.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 22 Feb 2002 17:31:13 -0700 Received: by axcsbh5.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Feb 2002 17:31:13 -0700 Message-ID: <01A7DAF31F93D511AEE300D0B706ED9201BF4790@axcs13.cos.agilent.com> From: "CAVANNA,VICENTE V (A-Roseville,ex1)" To: ips@ece.cmu.edu Cc: "CAVANNA,VICENTE V (A-Roseville,ex1)" Subject: announcing paper on iSCSI CRC Date: Fri, 22 Feb 2002 17:31:12 -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 would like to direct those who are interested in learning more details about the iSCSI CRC process to a paper Luben Tuikov and I wrote and which Julian was kind enough to post on his site at http://www.haifa.il.ibm.com/satran/ips/Vince-Luben-crc32c.pdf. We intended the paper to be an informational Internet Draft but got lazy when confronted with the daunting task of formatting the equations using only ASCII as required by author guidelines. I summarize some results from the paper below. Notation -------- The D algorithm divides the message polynomial by the generator polynomial G(x) (33 bits). It performs the classical long division algorithm. The message polynomial must be multiplied by x^32 prior to application of the D algorithm. The SMD algorithm performs simultaneous multiplication by x^32 and division by G(x); so the message polynomial need not be multiplied by x^32 prior to application of the SMD algorithm. That is, the SMD algorithm works on unmodified data to produce results identical to the D algorithm. See point 5 below. The paper derives SMD from D, such that one could implement SMD and get results identical to D, without any data manipulation. The SMD algorithm is also shown in pseudo-programming language. See point 5 below. The origin of the magic constant 0x1c2d19ed is also shown. Results ------- The following are equivalent: Using the D algorithm: 1. Initializing CRC register to zeroes. Prefixing the data by 0x2a26f826, multiplying the data polynomial by x^32 and then applying the D algorithm. 2. Initializing CRC register to zeroes. XOR-ing the 32 most significant data bits with 0xFFFFFFFF and multiplying the data polynomial by x^32 and then applying the D algorithm. 3. Initializing CRC register to 0x2a26f826. Multiplying the data polynomial by x^32 and then applying the D algorithm. Using the SMD algorithm: 4. Initializing CRC register to zeroes. Prefixing the data with 0x2a26f826 and applying the SMD algorithm. 5. Initializing CRC register to 0xFFFFFFFF and applying the SMD algorithm. 6. Initializing CRC register to zeroes. XOR-ing the 32 most significant data bits with 0xFFFFFFFF and applying the SMD algorithm. 1, 2 and 5 are directly shown in the paper, as 5 was derived from 2, and 1 from 2. The equivalence of 3, 4 and 6 is implicitly shown, but clearly follows from the definitions used in the paper. Initialization of the CRC register in 1, 2 and 5 is implicit (the D algorithm initializes the register to zero and the SMD algorithm initializes the register to 0xFFFFFFFF). Initialization of the CRC register in 3, 4 and 6 is explicit (an extra step). Vince Cavanna Agilent Technologies From owner-ips@ece.cmu.edu Sat Feb 23 01:45: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 BAA08733 for ; Sat, 23 Feb 2002 01:45:42 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1N611I21466 for ips-outgoing; Sat, 23 Feb 2002 01:01:01 -0500 (EST) 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 g1N60mj21449; Sat, 23 Feb 2002 01:00:48 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id HAA67196; Sat, 23 Feb 2002 07:00:36 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1N628P28582; Sat, 23 Feb 2002 07:02:16 +0100 To: Cc: "IPS" , owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI - started countdown to 11 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 23 Feb 2002 08:02:11 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 23/02/2002 08:02:24, Serialize complete at 23/02/2002 08:02:24 Content-Type: multipart/alternative; boundary="=_alternative 0020EEBCC2256B69_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0020EEBCC2256B69_= Content-Type: text/plain; charset="us-ascii" Somesh, Comments in text. Thanks, Julo "Somesh Gupta" Sent by: owner-ips@ece.cmu.edu 22-02-02 22:10 Please respond to somesh_gupta To: Julian Satran/Haifa/IBM@IBMIL cc: "IPS" Subject: RE: iSCSI - started countdown to 11 Julian, The language in A.1 should be changed from the most recent change. Two things on the changes - 1. We should have a MAY instead of (the now lower case) should to indicate the agreement reached - or worst case delete the sentence. +++ the text reflects the currecnt agreement - the lower case should indicates a standard MAY with the performance warning that appears elswhere. I could add the MAY but that would make the text even less readable +++ 2. The last sentence in the first para - newly added & repititive (last sentence in previous paragraph) - (in my opinion) tries to get around the agreement. It should either be deleted, or changed to "some receiver implementation will provide (significantly) better performance when the sender inserts markers" or "some receiver implementations may provide degraded performance to senders which do not insert markers". I prefer that we just not add it. You have something like that in the previous paragraph anyway. +++ OK - I just forgot that I have it in this part. I will delete the previous appearance.+++ One comment on what was not changed - 1. The last sentence in the para before A.1 - "in certain environment, a sender ...." - I would suggest be changed to "in certain implementation, ...". As the behavior is more implementation dependent. +++ That is incorrect. Evironment includes implementation and other factors like RTT. Where RTT is very small framming won't buy you much. Where RTT is large they will. +++ We reached a compromise on keeping it in the main draft and making it a MAY. I hope we can keep that spirit. +++ That is what I did and I may add the MAY - explicitly if that helps. +++ Somesh -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Friday, February 22, 2002 8:05 AM To: ips@ece.cmu.edu Subject: iSCSI - started countdown to 11 Dear colleagues, I've put on my site a "working" version of the draft labeled 10-90. Only the pdf version (with change bars vs. 10) is available. I'll soon get out also a text version - without a TOC but otherwise usable. Julo --=_alternative 0020EEBCC2256B69_= Content-Type: text/html; charset="us-ascii"
Somesh,

Comments in text.

Thanks,
Julo


"Somesh Gupta" <somesh_gupta@silverbacksystems.com>
Sent by: owner-ips@ece.cmu.edu

22-02-02 22:10
Please respond to somesh_gupta

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        "IPS" <ips@ece.cmu.edu>
        Subject:        RE: iSCSI - started countdown to 11

       


Julian,
 
The language in A.1 should be changed from the most recent change. Two things
on the changes -
1. We should have a MAY instead of (the now lower case) should to
indicate the agreement reached - or worst case delete the sentence.

+++ the text reflects the currecnt agreement - the lower case should indicates a standard MAY with the performance warning that appears elswhere.  I could add the MAY but that would make the text even less readable
+++
 
2. The last sentence in the first para - newly added & repititive (last
sentence in previous paragraph) -
(in my opinion) tries to get around the agreement. It should either
be deleted, or changed to "some receiver implementation will provide
(significantly) better performance when the sender inserts markers" or
"some receiver implementations may provide degraded performance
to senders which do not insert markers". I prefer that we just not add it.
You have something like that in the previous paragraph anyway.

+++ OK - I just forgot that I have it in this part. I will delete the previous appearance.+++

One comment on what was not changed -
1. The last sentence in the para before A.1 - "in certain environment, a
sender ...." - I would suggest be changed to "in certain implementation, ...".
As the behavior is more implementation dependent.
 
+++ That is incorrect. Evironment includes implementation and other factors like RTT.
Where RTT is very small framming won't buy you much. Where RTT is large they will.
+++

We reached a compromise on keeping it in the main draft and making
it a MAY. I hope we can keep that spirit.

+++ That is what I did and I may add the MAY - explicitly if that helps. +++
 
Somesh
-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran
Sent: Friday, February 22, 2002 8:05 AM
To: ips@ece.cmu.edu
Subject: iSCSI - started countdown to 11


Dear colleagues,

I've put on my site a "working" version of the draft labeled 10-90.
Only the pdf version (with change bars vs. 10) is available.
I'll soon get out also a text version - without a TOC but otherwise usable.

Julo

--=_alternative 0020EEBCC2256B69_=-- From owner-ips@ece.cmu.edu Sat Feb 23 01:46: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 BAA08764 for ; Sat, 23 Feb 2002 01:46:30 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1N6Iw822450 for ips-outgoing; Sat, 23 Feb 2002 01:18:58 -0500 (EST) 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 g1N6Iuj22444 for ; Sat, 23 Feb 2002 01:18:56 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id HAA15846; Sat, 23 Feb 2002 07:18:44 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1N6KXu69182; Sat, 23 Feb 2002 07:20:33 +0100 To: Eddy Quicksall Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI - started countdown to 11 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 23 Feb 2002 08:20:28 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 23/02/2002 08:20:32, Serialize complete at 23/02/2002 08:20:32 Content-Type: multipart/alternative; boundary="=_alternative 002281BFC2256B69_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 002281BFC2256B69_= Content-Type: text/plain; charset="us-ascii" will do - thanks, julo Eddy Quicksall 23-02-02 01:38 To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iSCSI - started countdown to 11 Since most things start with upper case, should we do that for all cases? I think the only ones left are: FMarker= SessionType= Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, February 22, 2002 11:05 AM To: ips@ece.cmu.edu Subject: iSCSI - started countdown to 11 Dear colleagues, I've put on my site a "working" version of the draft labeled 10-90. Only the pdf version (with change bars vs. 10) is available. I'll soon get out also a text version - without a TOC but otherwise usable. Julo --=_alternative 002281BFC2256B69_= Content-Type: text/html; charset="us-ascii"
will do - thanks, julo


Eddy Quicksall <Eddy_Quicksall@ivivity.com>

23-02-02 01:38

       
        To:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
        cc:        
        Subject:        RE: iSCSI - started countdown to 11

       


Since most things start with upper case, should we do that for all cases? I think the only ones left are:

 

FMarker=<send|receive|send-receive|No>

SessionType= <discovery|normal>

 

 

 

Eddy

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, February 22, 2002 11:05 AM
To: ips@ece.cmu.edu
Subject: iSCSI - started countdown to 11

 


Dear colleagues,

I've put on my site a "working" version of the draft labeled 10-90.
Only the pdf version (with change bars vs. 10) is available.
I'll soon get out also a text version - without a TOC but otherwise usable.

Julo

--=_alternative 002281BFC2256B69_=-- From owner-ips@ece.cmu.edu Sat Feb 23 02:42: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 BAA08744 for ; Sat, 23 Feb 2002 01:45:43 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1N6IpK22439 for ips-outgoing; Sat, 23 Feb 2002 01:18:51 -0500 (EST) 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 g1N6Inj22432 for ; Sat, 23 Feb 2002 01:18:49 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id HAA89780; Sat, 23 Feb 2002 07:18:43 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1N6KNP90358; Sat, 23 Feb 2002 07:20:23 +0100 To: Eddy Quicksall Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI - started countdown to 11 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 23 Feb 2002 08:20:26 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 23/02/2002 08:20:31, Serialize complete at 23/02/2002 08:20:31 Content-Type: multipart/alternative; boundary="=_alternative 002168DBC2256B69_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 002168DBC2256B69_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Definitely - Thanks, Julo Eddy Quicksall 23-02-02 01:29 =20 To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc:=20 Subject: RE: iSCSI - started countdown to 11 =20 Should "Reject" be added to this? Originator-> =3D Responder-> =3D|NotUnderstood|Irrelevant =20 =20 Eddy =20 -----Original Message----- From: Julian Satran [mailto:Julian=5FSatran@il.ibm.com] Sent: Friday, February 22, 2002 11:05 AM To: ips@ece.cmu.edu Subject: iSCSI - started countdown to 11=20 =20 Dear colleagues,=20 I've put on my site a "working" version of the draft labeled 10-90.=20 Only the pdf version (with change bars vs. 10) is available.=20 I'll soon get out also a text version - without a TOC but otherwise=20 usable.=20 Julo --=_alternative 002168DBC2256B69_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Definitely - Thanks, Julo


Eddy Quicksall <Eddy=5FQuicksa= ll@ivivity.com>

23-02-02 01:29

       
        To: &nbs= p;      Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
        cc: &nbs= p;      
        Subject:=        RE: iSCSI - started countdown to 11

       


Should "Reject" be added = to this?

Originator-> <key>=3D<valuex>

Responder-> <key&g= t;=3D<valuey>|NotUnderstood|Irrelevant

 

 

Eddy

 

-----Original Message-----
From: Julian Satran [mailto:Julian=5FSatran@il.ibm.com]
Sent: Friday, February 22, 2002 11:05 AM
To: ips@ece.cmu.edu
Subject: iSCSI - started countdown to 11

 


Dear colleagues,

I've put on my site a "working" version of the draft labeled 10-9= 0.
Only the pdf version (with change bars vs. 10) is available. =
I'll soon get out also a text version - without a TOC but otherwise usable.=

Julo

--=_alternative 002168DBC2256B69_=-- From owner-ips@ece.cmu.edu Sat Feb 23 14:08: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 OAA22816 for ; Sat, 23 Feb 2002 14:08:16 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1NI1R511554 for ips-outgoing; Sat, 23 Feb 2002 13:01:27 -0500 (EST) 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 g1NI1Pj11549 for ; Sat, 23 Feb 2002 13:01:25 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id TAA48180; Sat, 23 Feb 2002 19:01:10 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1NI2wu97516; Sat, 23 Feb 2002 19:02:58 +0100 To: "Buck Landry" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI - started countdown to 11 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 23 Feb 2002 20:02:52 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 23/02/2002 20:02:58, Serialize complete at 23/02/2002 20:02:58 Content-Type: multipart/alternative; boundary="=_alternative 00629D2FC2256B69_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00629D2FC2256B69_= Content-Type: text/plain; charset="us-ascii" Sorry - I've missed it. Clear task set is an "unpleasant feature". Obviously iSCSI can't do anything it does not know about (other initiators) but we assume that SCSI knows how to take care of it (SCSI has to do the clear task set). The rest is a matter of implementation. Julo "Buck Landry" 23-02-02 09:50 To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: iSCSI - started countdown to 11 ok, that's cool. I was worried about the single connection case, where an initiator might *expect* some determinative behavior :-) I'm pressing my luck here but... did you have an off-the-top-of-your-head answer for my second question as well? (scan for "2)" in this message if you don't know what I'm talking about) .. guess I was wondering if you had considered all the interesting consequences. thanks, --buck -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, February 23, 2002 12:20 AM To: Buck Landry Subject: RE: iSCSI - started countdown to 11 Buck, Hard to get a short answer to this question. Immediate commands have some "non-determinism". If you do what you suggested on a single connection session then the answer is yes. If you do it on a multiple connection session - your mileage may vary... If the command arrived before abort it will be aborted. If not... Moreover - even a later immediate command arriving before the abort will be aborted. The text say quite explicitly that iSCSI hands over to SCSI the abort function. With immediate commands we have no control on when a command reaches SCSI. Julo "Buck Landry" Sent by: owner-ips@ece.cmu.edu 23-02-02 01:29 To: Julian Satran/Haifa/IBM@IBMIL, cc: Subject: RE: iSCSI - started countdown to 11 Two yes/no questions about the new Task Mgmt Function Request/Response wording. 1) Does ABORT_TASK_SET/CLEAR_TASK_SET apply to an immediate cmd with the same CmdSN? Or to rephrase, in this example scenario: T -> I (Nop-in, ExpCmdSN = 3) I -> T (Scsi Command, CmdSN = 3, Immediate bit set) I -> T (Task Mgmt Func Reqest, ABORT TASK SET, CmdSN = 3, Immediate bit set) .. is the scsi command aborted? The statement in section 9.5.1, "Task management requests must act on all commands having a CmdSN lower than the task management CmdSN" .. would resolve this nicely ("no") but in the same section, the wording "According to [SAM2] for all the tasks covered by the task management response (i.e., with CmdSN not higher than the task management command CmdSN)" ... implies that the task management response covers all tasks w/ equal or lower CmdSN while the request itself only covers tasks w/ lower CmdSN. ----- 2) For CLEAR TASK SET, does the target waiting behavior, "the target on its part, MUST wait for responses on all affected target transfer tags before acting on either of these two task management requests" .. include tasks that originated from a different initiator than the one that sent CLEAR TASK SET? Everything in the draft points to "yes" (I think), and I kindof actually like this. But I'm (somewhat) suprised that, given a scenario with two sessions attached to the same scsi target: session "A": I -> T (Scsi Write Cmd, lun = 8, tag = 2) session "A": T -> I (R2T, tag = 2) session "B": I -> T (Task Mgmt Function Request CLEAR TASK SET, lun = 8) .. that the target would require the cooperation of session "A"'s initiator and network connection in order to deliver a Task Mgmt Function Response to session "B". I suppose, if this cooperation did not occur, then eventually a timeout would fire, the affected task could just be forcefully killed, and a task management response could be sent on session "A".. is that the way it's supposed to work? Thanks for your consideration, --buck -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, February 22, 2002 10:05 AM To: ips@ece.cmu.edu Subject: iSCSI - started countdown to 11 Dear colleagues, I've put on my site a "working" version of the draft labeled 10-90. Only the pdf version (with change bars vs. 10) is available. I'll soon get out also a text version - without a TOC but otherwise usable. Julo --=_alternative 00629D2FC2256B69_= Content-Type: text/html; charset="us-ascii"
Sorry - I've missed it.

Clear task set is an "unpleasant feature". Obviously iSCSI can't do anything it does not know about (other initiators) but we assume that SCSI knows how to take care of it (SCSI has to do the clear task set).  The rest is a matter of implementation.

Julo




"Buck Landry" <blandry@crossroads.com>

23-02-02 09:50

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        
        Subject:        RE: iSCSI - started countdown to 11

       


ok, that's cool.  I was worried about the single connection case, where an initiator might *expect* some determinative behavior :-)
 
I'm pressing my luck here but... did you have an off-the-top-of-your-head answer for my second question as well?  (scan for "2)" in this message if you don't know what I'm talking about) .. guess I was wondering if you had considered all the interesting consequences.
 
thanks,
--buck
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, February 23, 2002 12:20 AM
To: Buck Landry
Subject: RE: iSCSI - started countdown to 11

Buck,

Hard to get a short answer to this question.
Immediate commands have some "non-determinism".
If you do what you suggested on a single connection session then the answer is yes.
If you do it on a multiple connection session - your mileage may vary...
If the command arrived before abort it will be aborted. If not...
Moreover - even a later immediate command arriving before the abort will be aborted.
The text say quite explicitly that iSCSI hands over to SCSI the abort function.
With immediate commands we have no control on when a command reaches SCSI.


Julo

"Buck Landry" <blandry@crossroads.com>
Sent by: owner-ips@ece.cmu.edu

23-02-02 01:29

       
       To:        Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>
       cc:        
       Subject:        RE: iSCSI - started countdown to 11

     



Two yes/no questions about the new Task Mgmt Function Request/Response wording.

1) Does ABORT_TASK_SET/CLEAR_TASK_SET apply to an immediate cmd with the same CmdSN?  Or to rephrase, in this example scenario:

T -> I (Nop-in, ExpCmdSN = 3)
I -> T (Scsi Command, CmdSN = 3, Immediate bit set)
I -> T (Task Mgmt Func Reqest, ABORT TASK SET, CmdSN = 3, Immediate bit set)

.. is the scsi command aborted?

The statement in section 9.5.1,

"Task management requests must act on all commands having a CmdSN lower than the task management CmdSN"

.. would resolve this nicely ("no") but in the same section, the wording

"According to [SAM2] for all the tasks covered by the task management response (i.e., with CmdSN not higher than the task management command CmdSN)"

...  implies that the task management response covers all tasks w/ equal or lower CmdSN while the request itself only covers tasks w/ lower CmdSN.

-----

2) For CLEAR TASK SET, does the target waiting behavior,

"the target on its part, MUST wait for responses on all affected target transfer tags before acting on either of these two task management requests"

.. include tasks that originated from a different initiator than the one that sent CLEAR TASK SET?  Everything in the draft points to "yes" (I think), and I kindof actually like this.  But I'm (somewhat) suprised that, given a scenario with two sessions attached to the same scsi target:

session "A": I -> T (Scsi Write Cmd, lun = 8, tag = 2)
session "A": T -> I (R2T, tag = 2)
session "B": I -> T (Task Mgmt Function Request CLEAR TASK SET, lun = 8)

.. that the target would require the cooperation of session "A"'s initiator and network connection in order to deliver a Task Mgmt Function Response to session "B".  I suppose, if this cooperation did not occur, then eventually a timeout would fire, the affected task could just be forcefully killed, and a task management response could be sent on session "A".. is that the way it's supposed to work?

Thanks for your consideration,
--buck




-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, February 22, 2002 10:05 AM
To: ips@ece.cmu.edu
Subject: iSCSI - started countdown to 11



Dear colleagues,

I've put on my site a "working" version of the draft labeled 10-90.
Only the pdf version (with change bars vs. 10) is available.
I'll soon get out also a text version - without a TOC but otherwise usable.

Julo

--=_alternative 00629D2FC2256B69_=-- From owner-ips@ece.cmu.edu Sat Feb 23 15:52: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 PAA24115 for ; Sat, 23 Feb 2002 15:52:49 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1NJl7x17399 for ips-outgoing; Sat, 23 Feb 2002 14:47:07 -0500 (EST) 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 g1NJkwj17387; Sat, 23 Feb 2002 14:46:58 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id UAA93374; Sat, 23 Feb 2002 20:46:52 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1NJmeu97448; Sat, 23 Feb 2002 20:48:40 +0100 To: "Bob Mastors" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: FMarker, RFMarkInt and SFMarkInt negotiation X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 23 Feb 2002 21:48:34 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 23/02/2002 21:48:40, Serialize complete at 23/02/2002 21:48:40 Content-Type: multipart/alternative; boundary="=_alternative 006A2389C2256B69_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 006A2389C2256B69_= Content-Type: text/plain; charset="us-ascii" Bob, Your concerns are important and I will attempt to answer them with a revised negotiation for markers early tomorrow, The marker scheme is old (the iSCSI meeting in Haifa) and the parameter negotiation (given the concerns surrounding it) has not been updated. Julo "Bob Mastors" Sent by: owner-ips@ece.cmu.edu 22-02-02 22:12 To: cc: Subject: Re: FMarker, RFMarkInt and SFMarkInt negotiation I agree with the general concern. FMarker is processed unlike any of the other negotiated keys. It would be nice if it worked like HeaderDigest or AuthMethod and presented a . R/SFMarkInt also stands out as different (and needing special code) because it takes a range. But I can see that this would take more effort to fix. And then there is the requirement in A.3.2 that "Whenever FMarker and RFMarker are both sent, they MUST appear on the same login request/response." This seems unnecessary to me and will require special code to handle. But I imagine that most implementers (myself included) will just ignore the requirement and hope the pdu doesn't get so full as to cause FMarker to be in one pdu and RFMarker to be in the next. And why are the units in 4 byte words instead of bytes with an alignment requirement. It seems like everything else in the spec is in bytes. I am not really in favor of FIM but if the hardware folks really want it I don't mind implementing it. It is not that much work. It would make my life easier as an implementer if the keys worked like the other keys in section 12. Apologies in advance if this has already been hashed out. Bob ----- Original Message ----- From: "Martins Krikis" To: Sent: Friday, February 22, 2002 11:12 AM Subject: Re: FMarker, RFMarkInt and SFMarkInt negotiation > --- Julian Satran wrote: > > What would the IT and TI add? The information is > > already available in the > > PDU (IT and IT PDUS are different). > > They would add clarity and consistency to text > negotiation. > > The concepts being negotiated are > "fixed interval markers for the initiator to target > direction" and "fixed interval markers for the target > to initiator direction". So why should the keys used > in negotiating these concepts be different depending > on who sent them? If I'm implementing negotiation, I > now have to do an extra mapping from a key (e.g., > RFMarkInt) to the concept (ITFMarkInt or TIFMarkInt) > and this mapping is different for initiators and > targets (for the same operation, where operations > are send/receive). Plus, if the sequence I mentioned > > (initiator offers) FMarker=receive; RFMarkInt=17,51 > (target responds) FMarker=send; SFMarkInt=34 > > is correct, then it does not fit well in section > 2.2.4, where the general format seems to mandate > answering with the same KEY (not the same concept). > A little further down there is also a requirement > to answer numerical negotiations with the "required > key". If the "required key" may or may not be the > same key that was received, this should be mentioned. > (Of course, one could argue that this is not a > numerical negotiation, because ranges are allowed, > not just single numbers, but this, too is not obvious > to the casual reader.) > > What I was proposing was simply naming the keys > after the concepts and avoiding the extra mapping > step and seeming conflicts with 2.2.4. I am a pedant. > > As to FMarker, its negotiation is very different > from everything else in that it may look like a list > negotiation because of the list of possible values > given, but it isn't. It is yet another special-case > parameter, and one that RFMarkInt and SFMarkInt > depend on. > > I was suggesting getting rid of it altogether by > allowing RFMarkInt/SFMarkInt (or, better yet, > ITFMarkInt, TIFMarkInt) to carry value 0, which > would mean that markers are not in use in the > respective direction. > > Just because all the information is there and because > implementation is possible, it doesn't mean that it > cannot be organized more logically and simplify > implementations. > > IMO, key names should match concept names regardless > of how and by whom they are being used; and all > parameter dependencies for operational phase should > be eliminated. > > Martins Krikis, Intel Corp. > > Disclaimer: these opinions are my own and not > necessarily those of my employer. > > __________________________________________________ > Do You Yahoo!? > Yahoo! Sports - Coverage of the 2002 Olympic Games > http://sports.yahoo.com --=_alternative 006A2389C2256B69_= Content-Type: text/html; charset="us-ascii"
Bob,

Your concerns are important and I will attempt to answer them with a revised negotiation  for markers early tomorrow,
The marker scheme is old (the iSCSI meeting in Haifa) and the parameter negotiation (given the concerns surrounding it) has not been updated.


Julo


"Bob Mastors" <bmastors@aciesnetworks.com>
Sent by: owner-ips@ece.cmu.edu

22-02-02 22:12

       
        To:        <ips@ece.cmu.edu>
        cc:        
        Subject:        Re: FMarker, RFMarkInt and SFMarkInt negotiation

       


I agree with the general concern.
FMarker is processed unlike any of the other negotiated keys.
It would be nice if it worked like HeaderDigest or AuthMethod
and presented a <list-of-options>.

R/SFMarkInt also stands out as different (and needing special code) because
it takes a range. But I can see that this would take more effort to fix.

And then there is the requirement in A.3.2 that "Whenever FMarker and RFMarker
are both sent, they MUST appear on the same login request/response."
This seems unnecessary to me and will require special code to handle.
But I imagine that most implementers (myself included) will just ignore
the requirement and hope the pdu doesn't get so full as to cause FMarker
to be in one pdu and RFMarker to be in the next.

And why are the units in 4 byte words instead of bytes with an alignment requirement.
It seems like everything else in the spec is in bytes.

I am not really in favor of FIM but if the hardware folks really want it
I don't mind implementing it. It is not that much work.
It would make my life easier as an implementer if the keys worked like the
other keys in section 12.

Apologies in advance if this has already been hashed out.

Bob


----- Original Message -----
From: "Martins Krikis" <mkrikis@yahoo.com>
To: <ips@ece.cmu.edu>
Sent: Friday, February 22, 2002 11:12 AM
Subject: Re: FMarker, RFMarkInt and SFMarkInt negotiation


> --- Julian Satran <Julian_Satran@il.ibm.com> wrote:
> > What would the IT and TI add? The information is
> > already available in the
> > PDU (IT and IT PDUS are different).
>
> They would add clarity and consistency to text
> negotiation.
>
> The concepts being negotiated are
> "fixed interval markers for the initiator to target
> direction" and "fixed interval markers for the target
> to initiator direction". So why should the keys used
> in negotiating these concepts be different depending
> on who sent them? If I'm implementing negotiation, I
> now have to do an extra mapping from a key (e.g.,
> RFMarkInt) to the concept (ITFMarkInt or TIFMarkInt)
> and this mapping is different for initiators and
> targets (for the same operation, where operations
> are send/receive). Plus, if the sequence I mentioned
>
>   (initiator offers) FMarker=receive; RFMarkInt=17,51
>   (target responds)  FMarker=send;    SFMarkInt=34
>
> is correct, then it does not fit well in section
> 2.2.4, where the general format seems to mandate
> answering with the same KEY (not the same concept).
> A little further down there is also a requirement
> to answer numerical negotiations with the "required
> key". If the "required key" may or may not be the
> same key that was received, this should be mentioned.
> (Of course, one could argue that this is not a
> numerical negotiation, because ranges are allowed,
> not just single numbers, but this, too is not obvious
> to the casual reader.)
>
> What I was proposing was simply naming the keys
> after the concepts and avoiding the extra mapping
> step and seeming conflicts with 2.2.4. I am a pedant.
>
> As to FMarker, its negotiation is very different
> from everything else in that it may look like a list
> negotiation because of the list of possible values
> given, but it isn't. It is yet another special-case
> parameter, and one that RFMarkInt and SFMarkInt
> depend on.
>
> I was suggesting getting rid of it altogether by
> allowing RFMarkInt/SFMarkInt (or, better yet,
> ITFMarkInt, TIFMarkInt) to carry value 0, which
> would mean that markers are not in use in the
> respective direction.
>
> Just because all the information is there and because
> implementation is possible, it doesn't mean that it
> cannot be organized more logically and simplify
> implementations.
>
> IMO, key names should match concept names regardless
> of how and by whom they are being used; and all
> parameter dependencies for operational phase should
> be eliminated.
>
>   Martins Krikis, Intel Corp.
>
> Disclaimer: these opinions are my own and not
>             necessarily those of my employer.
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Sports - Coverage of the 2002 Olympic Games
> http://sports.yahoo.com

--=_alternative 006A2389C2256B69_=-- From owner-ips@ece.cmu.edu Sat Feb 23 16:24: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 QAA24330 for ; Sat, 23 Feb 2002 16:24:45 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1NKSPQ19694 for ips-outgoing; Sat, 23 Feb 2002 15:28:25 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f204.pav2.hotmail.com [64.4.37.204]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1NKSMj19687 for ; Sat, 23 Feb 2002 15:28:22 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 23 Feb 2002 12:28:13 -0800 Received: from 64.38.134.103 by pv2fd.pav2.hotmail.msn.com with HTTP; Sat, 23 Feb 2002 20:28:13 GMT X-Originating-IP: [64.38.134.103] From: "Bernard Aboba" To: Elizabeth.G.Rodriguez@123mail.net, hufferd@us.ibm.com, vince_cavanna@agilent.com Cc: fred@cisco.com, ips@ece.cmu.edu, dave_sheehy@agilent.com, pat_thaler@agilent.com Subject: RE: is 1 Gbps a MUST? Date: Sat, 23 Feb 2002 12:28:13 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Feb 2002 20:28:13.0455 (UTC) FILETIME=[9E0219F0:01C1BCA8] Sender: owner-ips@ece.cmu.edu Precedence: bulk Hopefully the following paragraph will address this issue: "To be useful, IP block storage security protocols must be capable of being implemented at the line rates in use today or likely to be used in the future. For example, CPU overhead and hardware availability must not preclude implementation at 1 Gbps today. Implementation feasibility at 10 Gbps is highly desirable, but may not be demonstratable at this time. Performance issues are discussed further in Appendix B. " _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From owner-ips@ece.cmu.edu Sat Feb 23 18:19: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 SAA25175 for ; Sat, 23 Feb 2002 18:19:33 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1NMIaI25837 for ips-outgoing; Sat, 23 Feb 2002 17:18:36 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f214.pav2.hotmail.com [64.4.37.214]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1NMIYj25832 for ; Sat, 23 Feb 2002 17:18:34 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 23 Feb 2002 14:18:28 -0800 Received: from 64.38.134.103 by pv2fd.pav2.hotmail.msn.com with HTTP; Sat, 23 Feb 2002 22:18:28 GMT X-Originating-IP: [64.38.134.103] From: "Bernard Aboba" To: Ernest.Dainow@mcdata.com, jharwood@vesta-corp.com Cc: ips@ece.cmu.edu Subject: RE: Review of -10 security draft Date: Sat, 23 Feb 2002 14:18:28 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Feb 2002 22:18:28.0703 (UTC) FILETIME=[0500D6F0:01C1BCB8] Sender: owner-ips@ece.cmu.edu Precedence: bulk The latest -10 draft corrects the problem in section 1.2 with mandating single SA per TCP connection. It also addresses the DHCP/IPsec issue, as well as the performance concerns that have been raised. Comments welcome. http://www.drizzle.com/~aboba/RDMA/draft-ietf-ips-security-10.txt _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From owner-ips@ece.cmu.edu Sun Feb 24 03:50: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 DAA09132 for ; Sun, 24 Feb 2002 03:50:09 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1O7fm921227 for ips-outgoing; Sun, 24 Feb 2002 02:41:48 -0500 (EST) 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 g1O7flj21223 for ; Sun, 24 Feb 2002 02:41:47 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id IAA91530 for ; Sun, 24 Feb 2002 08:41:40 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1O7gDt77768 for ; Sun, 24 Feb 2002 08:42:14 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSI - started countdown to 11 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sun, 24 Feb 2002 09:42:07 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 24/02/2002 09:42:14, Serialize complete at 24/02/2002 09:42:14 Content-Type: multipart/alternative; boundary="=_alternative 00285A2FC2256B6A_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00285A2FC2256B6A_= Content-Type: text/plain; charset="us-ascii" Dear colleagues, I've put on my site a "working" version of the draft labeled 10-91. Only the pdf version (with change bars vs. 10) is available. I'll soon get out also a text version - without a TOC but otherwise usable. I hope this solves all outstanding Marker negotiation issues. Julo --=_alternative 00285A2FC2256B6A_= Content-Type: text/html; charset="us-ascii"

Dear colleagues,

I've put on my site a "working" version of the draft labeled 10-91.
Only the pdf version (with change bars vs. 10) is available.
I'll soon get out also a text version - without a TOC but otherwise usable.
I hope this solves all outstanding Marker negotiation issues.

Julo

--=_alternative 00285A2FC2256B6A_=-- From owner-ips@ece.cmu.edu Sun Feb 24 13: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 NAA14564 for ; Sun, 24 Feb 2002 13:31:27 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1OHTl222897 for ips-outgoing; Sun, 24 Feb 2002 12:29:47 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from groupwise (tigger.dsi.nus.edu.sg [137.132.30.21]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g1OBudj10781 for ; Sun, 24 Feb 2002 06:56:39 -0500 (EST) Received: from DSI-Message_Server by groupwise with Novell_GroupWise; Sun, 24 Feb 2002 19:53:57 +0800 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Sun, 24 Feb 2002 19:53:47 +0800 From: "Wang Yong Hong, Wilson" To: Subject: SCSI command order issue Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g1OBuej10783 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hello, Here I ask one question about SCSI protocol. I traced the linux kernel source code about SCSI module. In SCSI module, every SCSI command block is assigned one unique serial number. However this number is only valid before the block is returned to the SCSI middle layer. There is no mechanism of sequence control for SCSI. What is your opinion about the SCSI block out of order when they return to upper layer ? What do your people think about this ? Thanks Wilson From owner-ips@ece.cmu.edu Mon Feb 25 00:42: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 AAA22745 for ; Mon, 25 Feb 2002 00:42:17 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1P4iJD13562 for ips-outgoing; Sun, 24 Feb 2002 23:44:19 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web14602.mail.yahoo.com (web14602.mail.yahoo.com [216.136.224.82]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g1P4iFH13553 for ; Sun, 24 Feb 2002 23:44:15 -0500 (EST) Message-ID: <20020225044414.49337.qmail@web14602.mail.yahoo.com> Received: from [208.236.45.61] by web14602.mail.yahoo.com via HTTP; Sun, 24 Feb 2002 20:44:14 PST Date: Sun, 24 Feb 2002 20:44:14 -0800 (PST) From: Digital Aryan Subject: RE: is 1 Gbps a MUST? 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 would like to add that though it is not necessary, for an implememtation to follow all the words provided in the draft, it is necessary for the draft to provide the various possible ways of getting itself implemented. Then, whether an implementation is able to attract market attention depends on the requirement of the market. Aryan __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com From owner-ips@ece.cmu.edu Mon Feb 25 09:04: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 JAA10576 for ; Mon, 25 Feb 2002 09:04:56 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1PDKpM14087 for ips-outgoing; Mon, 25 Feb 2002 08:20:51 -0500 (EST) 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 g1PBMDH09382 for ; Mon, 25 Feb 2002 06:22:24 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04686; Mon, 25 Feb 2002 06:22:10 -0500 (EST) Message-Id: <200202251122.GAA04686@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: dhcwg@ietf.org, ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-tseng-dhc-isnsoption-00.txt Date: Mon, 25 Feb 2002 06:22:10 -0500 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DHCP Options for Internet Storage Name Service Author(s) : J. Tseng Filename : draft-tseng-dhc-isnsoption-00.txt Pages : 7 Date : 22-Feb-02 This document proposes a new DHCP option number to allow iSCSI and iFCP devices using DHCP to discover the location of the iSNS server. iSNS provides discovery and management capabilities for iSCSI and Fibre Channel (FCP) storage devices in an enterprise-scale IP storage network. iSNS provides intelligent storage management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity as a storage area network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-tseng-dhc-isnsoption-00.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-tseng-dhc-isnsoption-00.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-tseng-dhc-isnsoption-00.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: <20020222110410.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-tseng-dhc-isnsoption-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-tseng-dhc-isnsoption-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020222110410.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Mon Feb 25 11:09: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 LAA15604 for ; Mon, 25 Feb 2002 11:09:55 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1PFLQD22002 for ips-outgoing; Mon, 25 Feb 2002 10:21:26 -0500 (EST) 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 g1PFLPH21998 for ; Mon, 25 Feb 2002 10:21:25 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id <107NPKW0>; Mon, 25 Feb 2002 10:21:21 -0500 Message-ID: <25369470B6F0D41194820002B328BDD22F55DC@ATLOPS> From: Eddy Quicksall To: "Wang Yong Hong, Wilson" , ips@ece.cmu.edu Subject: RE: SCSI command order issue Date: Mon, 25 Feb 2002 10:21:15 -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 Every operating system will deal with this. It is the nature of multi-threaded disk access. It is a ULP issue and there are lots of ways that the OS's handle it. iSCSI and SCSI are no different in this respect. Eddy -----Original Message----- From: Wang Yong Hong, Wilson [mailto:dsiyhw@dsi.nus.edu.sg] Sent: Sunday, February 24, 2002 6:54 AM To: ips@ece.cmu.edu Subject: SCSI command order issue Hello, Here I ask one question about SCSI protocol. I traced the linux kernel source code about SCSI module. In SCSI module, every SCSI command block is assigned one unique serial number. However this number is only valid before the block is returned to the SCSI middle layer. There is no mechanism of sequence control for SCSI. What is your opinion about the SCSI block out of order when they return to upper layer ? What do your people think about this ? Thanks Wilson From owner-ips@ece.cmu.edu Mon Feb 25 14:13: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 OAA25560 for ; Mon, 25 Feb 2002 14:13:58 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1PIKcW07471 for ips-outgoing; Mon, 25 Feb 2002 13:20:38 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1PIKbH07467 for ; Mon, 25 Feb 2002 13:20:37 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Feb 2002 13:14:53 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029374E8@CORPMX14> From: Black_David@emc.com To: Eddy_Quicksall@ivivity.com, ips@ece.cmu.edu Subject: RE: iSCSI UNH Plugfest Date: Mon, 25 Feb 2002 13:20:16 -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 > > The iSCSI initiator driver should clean up the CDB as needed (your first > > suggestion) and keep the wire protocol clean. If it's in an OS > > generating old CDBs, it knows that and is best suited to fix them. > > Don't burden the iSCSI targets with any of this. > > I don't agree that the iSCSI initiator should touch the CDB. This is a ULP > issue and the issuer of the CDB should use or not use the > bits as desired. This seems to be mostly about where to locate the code that sets the iSCSI LUN when a SCSI-2 stack sits on top of iSCSI. Setting the iSCSI LUN correctly is a MUST, otherwise SCSI task management will misbehave. If one wants to split hairs, SCSI-2 code should figure out the LUN and pass it to iSCSI code that puts it in the correct place in the iSCSI PDU. In practice, I'm not sure this distinction is important, as I can easily imagine this sort of design boundary being optimized out in various ways by implementations. On the more generic issue of SCSI-2 over iSCSI, if someone (or a set of someones) wanted to write up an informational draft on the set of issues that arise in doing this, that would be welcome. 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 Feb 25 14:20: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 OAA25897 for ; Mon, 25 Feb 2002 14:20:44 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1PIiY409365 for ips-outgoing; Mon, 25 Feb 2002 13:44:34 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1PIiTH09358 for ; Mon, 25 Feb 2002 13:44:29 -0500 (EST) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id <190Q5YLJ>; Mon, 25 Feb 2002 13:44:26 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029374E9@CORPMX14> From: Black_David@emc.com To: somesh_gupta@silverbacksystems.com, ips@ece.cmu.edu Subject: iSCSI: Framing Requirements Text Date: Mon, 25 Feb 2002 13:44:20 -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 This issue appears to have been addressed in 10-92, but it's important enough to comment on here. Somesh wrote and Julian responded: > The language in A.1 should be changed from the most recent > change. Two things on the changes - > 1. We should have a MAY instead of (the now lower case) should > to indicate the agreement reached - or worst case delete the sentence. > > +++ the text reflects the currecnt agreement - the lower case should > indicates a standard MAY with the performance warning that appears > elswhere. I could add the MAY but that would make the text even less > readable > +++ Use of lower case must/should/may to imply upper case (i.e., RFC 2119) MUST/SHOULD/MAY requirements in any fashion is an invitation to confusion. A lower case "should" may not contain any RFC 2119 implication, depending on how it's used. The best bet for clarity is to use the RFC 2119 terms for their intended purpose, as the 10-92 text does: If a receiver indicates that it desires a marker, the sender MAY agree (during negotiation) and provide the marker at the desired interval. This conveys the requirement level clearly. Also, for those who need it, Julian's web site where the 10-92 draft can be found is at http://www.haifa.il.ibm.com/satran/ips/ To make it easier for those who may have joined the list recently, any post announcing the availability of something on Julian's web site should include this link. 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 Feb 25 15:29: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 PAA28776 for ; Mon, 25 Feb 2002 15:29:56 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1PJuJQ15434 for ips-outgoing; Mon, 25 Feb 2002 14:56:19 -0500 (EST) 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 g1PJuGH15427 for ; Mon, 25 Feb 2002 14:56:16 -0500 (EST) Message-ID: <20020225195615.57934.qmail@web13705.mail.yahoo.com> Received: from [192.52.58.4] by web13705.mail.yahoo.com via HTTP; Mon, 25 Feb 2002 11:56:15 PST Date: Mon, 25 Feb 2002 11:56:15 -0800 (PST) From: Martins Krikis Subject: Re: FMarker, RFMarkInt and SFMarkInt negotiation 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 Julian, I am very happy with the new text of appendix A; thank you for addressing the issues so quickly. My only remaining suggestion is to change the wording of the following paragraph in A.3.2: "For the offering the receiver or sender indicates..." The "receiver or sender" should probably be "initiator or target" because the party that offers one of these keys can only be a sender of these keys. Similar change would be good for the "responding sender or receiver". I know that sender and receiver could also be interpreted as "sender of markers" and "reciever of markers", but that's not quite how the paragraph sounds. Martins Krikis, Intel Corp. __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com From owner-ips@ece.cmu.edu Mon Feb 25 15: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 PAA28811 for ; Mon, 25 Feb 2002 15:30:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1PJhth14430 for ips-outgoing; Mon, 25 Feb 2002 14:43:55 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1PJhrH14426 for ; Mon, 25 Feb 2002 14:43:53 -0500 (EST) Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1PJhPw22550; Mon, 25 Feb 2002 11:43:25 -0800 (PST) Received: from ALLYN-W2K.cisco.com (altiga-vpn-client-19.cisco.com [10.64.194.19]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id ADS82932; Mon, 25 Feb 2002 11:32:56 -0800 (PST) Message-Id: <4.3.2.7.2.20020225111728.02338928@mira-sjcm-3.cisco.com> X-Sender: allyn@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 25 Feb 2002 11:43:18 -0800 To: ietf@ietf.org, tsvwg@ietf.org, ips@ece.cmu.edu, dafs-discussions@yahoogroups.com, rdma@yahoogroups.com From: allyn romanow Subject: RDMA over IP Internet Draft and BOF at 53rd IETF Cc: allyn@cisco.com, stephen Bailey , sob@harvard.edu, mankin@ISI.EDU Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_7536957==_.ALT" Sender: owner-ips@ece.cmu.edu Precedence: bulk --=====================_7536957==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed There is a new problem statement for RDMA over IP. Discussion is welcome on the RDMA over IP mailing list at http://groups.yahoo.com/group/rdma/ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RDMA over IP Problem Statement Author(s) : A. Romanow et al. Filename : draft-romanow-rdma-over-ip-problem-statement-00.txt Pages : 17 Date : 21-Feb-02 This draft describes the problem that copying in network I/O typically causes high system costs in end-hosts at high speeds. The problem is due to the high cost of memory bandwidth, and it can be substantially improved using 'copy avoidance.' The high overhead has prevented TCP/IP from being used as an interconnection network, and instead special purpose memory-to-memory fabrics have been developed and widely used. An IP-based solution, developed within the IETF, is desirable for interoperability of various network fabrics. It is also particularly important for the IETF to guide the standardization because interconnection technology will soon start to be used over the wide area in the Internet A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-romanow-rdma-over-ip-problem-statement-00.txt There will be a BOF for RDMA over IP (ROI) at the next IETF, scheduled for Tuesday March 19 13:00-14:00. The announcement is at http://ietf.org/ietf/02mar/roi.txt The BOF agenda is subject to change. There will be a proposed charter available for discussion later this week at http://www.cs.uchicago.edu/~steph/roi_charter.txt --=====================_7536957==_.ALT Content-Type: text/html; charset="us-ascii" There is a new problem statement for RDMA over IP.
Discussion is welcome on the RDMA over IP mailing list at
        http://groups.yahoo.com/group/rdma/

A New Internet-Draft is available from the on-line Internet-Drafts directories.


        Title           : RDMA over IP Problem Statement
        Author(s)       : A. Romanow et al.
        Filename        : draft-romanow-rdma-over-ip-problem-statement-00.txt
        Pages           : 17
        Date            : 21-Feb-02
        
This draft describes the problem that copying in network I/O
typically causes high system costs in end-hosts at high speeds.
The problem is due to the high cost of memory bandwidth, and it can
be substantially improved using 'copy avoidance.' The high overhead
has prevented TCP/IP from being used as an interconnection network,
and instead special purpose memory-to-memory fabrics have been
developed and widely used.  An IP-based solution, developed within
the IETF, is desirable for interoperability of various network
fabrics. It is also particularly important for the IETF to guide
the standardization because interconnection technology will soon
start to be used over the wide area in the Internet

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-romanow-rdma-over-ip-problem-statement-00.txt



There will be a BOF for RDMA over IP (ROI) at the next IETF, scheduled for Tuesday March 19 13:00-14:00. The announcement is at

http://ietf.org/ietf/02mar/roi.txt
 
The BOF agenda is subject to change.

There will be a proposed charter available for discussion later this week at
http://www.cs.uchicago.edu/~steph/roi_charter.txt

 
--=====================_7536957==_.ALT-- From owner-ips@ece.cmu.edu Mon Feb 25 15:38: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 PAA29058 for ; Mon, 25 Feb 2002 15:38:57 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1PKMXE17559 for ips-outgoing; Mon, 25 Feb 2002 15:22:33 -0500 (EST) 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 g1PKMVH17551 for ; Mon, 25 Feb 2002 15:22:31 -0500 (EST) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel13.hp.com (Postfix) with ESMTP id 261B740021F for ; Mon, 25 Feb 2002 12:22:25 -0800 (PST) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com with ESMTP (8.9.3 (PHNE_18979)/8.8.6 SMKit7.02) id MAA15024 for ; Mon, 25 Feb 2002 12:22:20 -0800 (PST) Message-ID: <3C7A9DC0.E4B7B1B8@cup.hp.com> Date: Mon, 25 Feb 2002 12:25:36 -0800 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: IPS Reflector Subject: iscsi : T bit MUST be 1 on a login reject response ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Why does the spec require that the T bit MUST be set to 1 when a target responds to a login request with a login reject response ? On a login reject response (non-zero status class), the initiator does not need to look at any field other than the status detail. That being the case, why the need to enfore (MUST set) the T bit to 1 ? - 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 Mon Feb 25 15:41: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 PAA29174 for ; Mon, 25 Feb 2002 15:41:03 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1PKFZ916953 for ips-outgoing; Mon, 25 Feb 2002 15:15:35 -0500 (EST) 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 g1PKFXH16944 for ; Mon, 25 Feb 2002 15:15:33 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 020D02118; Mon, 25 Feb 2002 13:15:32 -0700 (MST) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 2B767166; Mon, 25 Feb 2002 13:13:16 -0700 (MST) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 25 Feb 2002 13:13:15 -0700 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Feb 2002 13:13:15 -0700 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00A754BAA@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: dsiyhw@dsi.nus.edu.sg, ips@ece.cmu.edu Subject: RE: SCSI command order issue Date: Mon, 25 Feb 2002 13:13:07 -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 Wilson, That is the way the SCSI protocol is defined by T10 so this isn't an IETF issue. Regards, Pat -----Original Message----- From: Wang Yong Hong, Wilson [mailto:dsiyhw@dsi.nus.edu.sg] Sent: Sunday, February 24, 2002 3:54 AM To: ips@ece.cmu.edu Subject: SCSI command order issue Hello, Here I ask one question about SCSI protocol. I traced the linux kernel source code about SCSI module. In SCSI module, every SCSI command block is assigned one unique serial number. However this number is only valid before the block is returned to the SCSI middle layer. There is no mechanism of sequence control for SCSI. What is your opinion about the SCSI block out of order when they return to upper layer ? What do your people think about this ? Thanks Wilson From owner-ips@ece.cmu.edu Mon Feb 25 17:48: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 RAA02792 for ; Mon, 25 Feb 2002 17:48:35 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1PLquu24219 for ips-outgoing; Mon, 25 Feb 2002 16:52:56 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj1-3-1-21.securesites.net (sj1-3-1-21.securesites.net [192.220.127.118]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1PLqmH24196 for ; Mon, 25 Feb 2002 16:52:53 -0500 (EST) Received: (qmail 69897 invoked by uid 24410); 25 Feb 2002 21:52:48 -0000 Message-ID: <20020225215248.69896.qmail@bswd.com> Subject: Re: SCSI command order issue To: dsiyhw@dsi.nus.edu.sg (Wang Yong Hong, Wilson) Date: Mon, 25 Feb 2002 21:52:48 +0000 (GMT) Cc: ips@ece.cmu.edu Reply-To: bberg@bswd.com (Brian A. Berg) In-Reply-To: from "Wang Yong Hong, Wilson" at Feb 24, 2002 07:53:47 PM From: bberg@bswd.com (Brian A. Berg) Organization: Berg Software Design ( http://www.bswd.com/ ) X-Mailer: ELM [version 2.5 PL6] 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 SCSI supports Command Tagged Queueing, which allows more than one operation to be outstanding from an initiator. The serial number you mentioned could be the tag that is applied to outgoing commands. Assuming that both the initiator and target support and use this feature, out-of-order responses may be received by an initiator. ___________________________________________________________________ Brian A. Berg bberg@bswd.com Voice: 408.741.5010 Berg Software Design FAX: 408.741.5234 P.O. Box 3488 visit the Storage Cornucopia at www.bswd.com 14500 Big Basin Way, Suite F Consulting: SCSI/FC/SAN/storage Saratoga, CA 95070 USA > Hello, > > Here I ask one question about SCSI protocol. > > I traced the linux kernel source code about SCSI module. > > In SCSI module, every SCSI command block is assigned > one unique serial number. However this number is only > valid before the block is returned to the SCSI middle layer. > > There is no mechanism of sequence control for SCSI. > What is your opinion about the SCSI block out of order > when they return to upper layer ? What do your people > think about this ? > > Thanks > > Wilson From owner-ips@ece.cmu.edu Mon Feb 25 21:56: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 VAA07566 for ; Mon, 25 Feb 2002 21:56:24 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1Q28Qw08771 for ips-outgoing; Mon, 25 Feb 2002 21:08:26 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from groupwise (tigger.dsi.nus.edu.sg [137.132.30.21]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g1Q28NH08767 for ; Mon, 25 Feb 2002 21:08:23 -0500 (EST) Received: from DSI-Message_Server by groupwise with Novell_GroupWise; Tue, 26 Feb 2002 10:05:23 +0800 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Tue, 26 Feb 2002 10:04:36 +0800 From: "Wang Yong Hong, Wilson" To: , Subject: RE: SCSI command order issue Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g1Q28OH08768 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hello Pat, Thanks all the fellows for the reply. Does that mean it is safe for iSCSI and other network related protocols that do not provide SCSI command order control, as we assume the higher layer (or Operating System) may take the responsibility to control the order issue ? Thanks Wilson >>> 02/26/02 04:13AM >>> Wilson, That is the way the SCSI protocol is defined by T10 so this isn't an IETF issue. Regards, Pat -----Original Message----- From: Wang Yong Hong, Wilson [mailto:dsiyhw@dsi.nus.edu.sg] Sent: Sunday, February 24, 2002 3:54 AM To: ips@ece.cmu.edu Subject: SCSI command order issue Hello, Here I ask one question about SCSI protocol. I traced the linux kernel source code about SCSI module. In SCSI module, every SCSI command block is assigned one unique serial number. However this number is only valid before the block is returned to the SCSI middle layer. There is no mechanism of sequence control for SCSI. What is your opinion about the SCSI block out of order when they return to upper layer ? What do your people think about this ? Thanks Wilson From owner-ips@ece.cmu.edu Mon Feb 25 22:00: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 WAA07606 for ; Mon, 25 Feb 2002 22:00:06 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1Q2Txh10029 for ips-outgoing; Mon, 25 Feb 2002 21:29:59 -0500 (EST) 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 g1Q2TvH10020 for ; Mon, 25 Feb 2002 21:29:57 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id <100Q9ZGG>; Mon, 25 Feb 2002 21:29:50 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029374F8@CORPMX14> From: Black_David@emc.com To: dsiyhw@dsi.nus.edu.sg, ips@ece.cmu.edu Subject: RE: SCSI command order issue Date: Mon, 25 Feb 2002 21:29:39 -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 > Does that mean it is safe for iSCSI and other network related > protocols that do not provide > SCSI command order control, as we assume the higher layer (or > Operating System) may > take the responsibility to control the order issue ? > Yes, that is the way that SCSI is generally used. Most code that cares about SCSI command A completing before SCSI command B waits for A to complete before issuing B. Examples include databases and filesystems, and out of order completion of concurrent SCSI operations is the expected behavior (e.g., many disks reorder their command queues for seek and rotational optimization, and a disk array with a cache will usually complete operations that hit in cache before operations that miss). 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 Feb 25 22:01: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 WAA07630 for ; Mon, 25 Feb 2002 22:01:29 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1Q2MUp09599 for ips-outgoing; Mon, 25 Feb 2002 21:22:30 -0500 (EST) 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 g1Q2MSH09592 for ; Mon, 25 Feb 2002 21:22:28 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id <100Q9YZV>; Mon, 25 Feb 2002 21:22:07 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029374F7@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: Huntington Beach DRAFT minutes Date: Mon, 25 Feb 2002 21:22:03 -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 Comments/objections to the list. To save him the time, Doug Otis's standing objection to the including of Fixed Interval Markers in the iSCSI spec is hereby noted. I do hope nobody else is interested in reopening that issue. Thanks, --David IETF IP Storage Interim Meeting Huntington Beach, California February 6, 2002 ------------------------------- -- Boot draft. (John Hufferd) No new issues, will check on changes in main draft. -05 version will be prepared for Minneapolis. -- Stringprep No new issues. Still waiting/needing underlying docs from idn WG; draft available IESG has asked about importance. David Black has said "very important". -- SLP/iSCSI (Dave Peterson) No new issues. David Black announces that Security folks have looked at 2-IP address config issue, and have recommended not doing anything here, as it's an IPsec problem, and ipsec folks are showing some interest in solving this one. Until a solution is available, dynamic configuration of IP Storage systems that use two IP addresses for tunnel mode IPsec may be difficult. -- iSNS (Josh Tseng) Security config is stored per-interface, not per-target to avoid IPsec issues. Monitoring and notification ports have been separated. Security - iSNS can be used to register security settings. This enables devices to determine what security parameters are available/desired. iSCSI implementer can decide what to use. Q: Has security hole been opened by storing/configuring security info in iSNS? A: Mandates IPsec be used to discover security policies, security parameters/policies used to talk to the iSNS need to be manually configured. Q&A: How is this sort of problem solved in general for IP networks? Generally by some sort of vendor-specific config tool so that this information is known in advance. Discussion of iSNS support of pre-shared key. Currently supports key per interface. Will remove pre-shared key support from iSNS as pre-shared key per-interface isn't the right granularity - will leave this to existing IPsec mechanisms. iSNS and FC-iSCSI mapping - iSNS can store this mapping, and in -08 iSNS draft will have ability to store an FC-usable WWN per iSCSI device. If iSCSI node name is in EUI form (WWN), the WWN (eui64) will get set automatically from this. iSNS can produce hashed WWN in local assignment space for convenience. This is all about the FC World Wide Node Name, not Port Name. Also handle setup of this in reverse direction. (Note: device can provide a EUI64 name itself, if it so desires) Persistent hashing needs to be supported. Bob Snively: EUI64 is not in and of itself a valid WWN for Fibre Channel. There is a mapping definition between EUI64 and WWN - should be in FC-FS Annex K and/or chapter 14. Make sure that names that go into iSNS (and can be retrieved) are WWNs that are ok for FC. Example in Josh's slides requires gateway to operate as an FC E_port. Q: Is iSNS needed? A: Produces consistent mappings across multiple gateways, no serious advantage for a single gateway. -- iSNS MIB (Josh Tseng) No serious changes from -00 to -01. Keith has concerns about (1) how the word "instance" is used in documenting the MIB (terminology problem only) and (2) support for values that change on next initialization, which excludes on-the-fly changes without re-initialization. Keith and Josh will resolve this for -02 version offline. -- iSCSI MIB (Marj Kreuger) iSCSI/SCSI MIB relationship has been worked out - changes to iSCSI MIB to fit cleanly with SCSI MIB. Authorization model published - will be going into a separate MIB. Latest version of draft has proposal for writable attributes/objects. Authors, WG chairs and MIB doctor are in process of deciding what to do with this MIB, as it's likely to be useful to WGs other than IPS. Need to cross-check authorization model with iSNS for consistency. See ftp://ftpeng.cisco.com/mbakke/ips for SCSI and iSCSI MIB object models. No objections to object and object model changes to iSCSI MIB. Need to go look at other MIBs that do this sort of authorization - IPsec and SNMP configuration MIB. Paul Koning - use name in certificate rather than certificate itself (i.e., hash of it) as principal for authorization so that info survives certificate expiration. Keith - separate this MIB from the iSCSI MIB and ask Bert Wijnen (O&M AD) about wider applicability. We then have the option to do it as either an IPS MIB (iSCSI or IPS-generic) or a more-generic MIB. Consensus - Authorization MIB approved as an IPS WG work item - authors, WG chairs, and MIB doctor will figure out how to take it forward. -00 draft to be submitted by Minneapolis -00 cutoff deadline. Writable attribute work is in progress - please send comments on what should be writable to authors and the list, ditto anything that appears to be missing. All writable attributes will have minimum access of read-only (so no write support is REQUIRED). Q: Will security attributes overlap with iSNS? Should those parameters be moved to iSCSI MIB? A: No Future work -- Session Profile -- iSCSI Naming and Discovery (John Hufferd) - 6-byte vs. 8-byte ISID issue Trying to provide support to keep implementations (use this word instead of vendors) from having complicated dependence on each other to generate unique ISIDs. Keith's issues - need to make sure that this is about different implementations, not vendors. Big problem is use of OUI scopes this to vendors as opposed to implementations. 4 byte "vendor id" is also problematic, as MAC address won't fit. Issue - proceeding in this direction could cause use of multiple MAC addresses per IP interface to get multiple ISIDs. Big concern appears to be dependence of ISIDs on hardware resulting in naming being tied to hardware. (ISIDs need to be dynamic, ISID could be reassigned to a replacement device for example). Opponents to 8 byte ISID fear 8 bytes would "encourage" poor design. On other side, implementers are looking to reuse unique (MAC) identification information rather than have to re-generate it, e.g. to simplify mfg process. A simplification, but not tying ISID to hw, since configurable. Keith suggests - MUST be configurable to allow support for hot-swap and the like. Marj - that's already in the document. Topic taken offline, and compromise proposal brought in on Thursday evening: ISID compromise - leave field size at 6 bytes, use first two bits as a type field with one value reserved for future use. Result in that a 6-byte IEEE- controlled identifier assigned by the manufacturer (e.g., MAC) can be used (2 MSBs in a MAC are not part of its uniqueness). The intended use is "factory assigned default". MUST be configurable, MUST persist across hot swap, isn't the right approach to scaling this up. See Section 9.1.1 and 9.1.2 of the main iSCSI draft for warnings on not tying this to hardware (i.e., putting the Ethernet MAC in here is not a good idea). No objections to proceeding with this solution. ** Chairs to check that RFC editor will not change bit and byte numbering, also whether the ADs will have issues with the ordering conventions used in the main IPS documents, particularly iSCSI. ** - Long-lived Discovery sessions NDT proposes not to allow long lived discovery sessions (adding async messages, and NOPs for dead session detection). Other ways exist to solve problem. Put wording into draft indicating that discovery sessions are intended to be short lived, and it's acceptable for a target to tear down long-lived sessions if it's short on resources. - Stringprep Discussion of IETF process for stringprep - Work is being handled in the idn WG. Handles internationalization of strings. Some characters which appear the same are represented in different ways in UNICODE. Stringprep is an algorithm which produces the same canonical form for all representations. IPS stringprep draft exists in order to get the grunt work done in time for us to use it. For English, this converts everything to lower case, but there are more complex canonicalization procedures for characters used in other languages. - SLP status update SLP/IPsec will go into RFC2608bis; moving from proposed to draft standard. Notification support in RFC 3082 SLP MIB under construction (individual submission -- which group?) - Portal Group Tags (Dave Peterson, John Hufferd's slides) Target portal group tags mark portals that can participate in a multi-connection session. Appears in MIB, Send Targets and SLP. Initiator analog appears only in MIB. Target Portal Group Tag and ISID - These are the endpoints of the SCSI Nexus, and parallel nexii are NOT allowed. Problem here is Transparent Gateways, where more than one gateway wants to present the same iSCSI node (e.g., to a Fibre Channel Fabric). If two gateways both present a portal group tag of 1 to iSCSI, result is parallel Nexii. Marj - thinks transparent gateways are not possible/reasonable. Will break persistent reservations. Need coordinate target portal groups across gateways. Dave P - Thinks that 90%+ transparency is possible, and in particular for persistent reservations. Q: If gateway is transparent, why does this matter? A: Parallel nexii result from simple example on Dave P's slide. Josh - iSNS can handle this coordination. Dave P - iSNS is one possibility, this is a proposal for another. Examples on Dave Peterson's slides do not do any coordination across gateways. - Gateway coordination would lead to proprietary solutions, but it's the default if nothing is changed. - Have target allocate the target portal group tags to the gateways - not workable for reasons on Dave P's slides Proposal is to use 8 bytes for target portal group tags and add OUI-qualified format for target portal groups. Comment - Gateway naming format could provide an alternate approach to this problem. Favors a non-transparent approach where gateway presents different iSCSI node names. Comment - Fibre Channel doesn't have a solution to this problem. LU serial number (VPD page 83h) or something like a volume header is used to solve this. Comment - Keep in mind that this proposal is to provide a means for the gateways to distinguish themselves. If gateways merge into a shared identity, all sorts of things break in the absence of shared state across the devices. More discussion occurred, on Thursday, the following conclusion was returned to the group: Target Portal Group Tag issue (from Dave Peterson's piece of the presentation yesterday). These tags are used in Send Targets. If two gateways independently report Send Targets for the same node name with different portal group tags, one could wind up with a change to configuration of the node when the second gateway is discovered; that would be bad. Gateways should use different node names - higher level software can cope with LUs presented via both node names. If two gateways claim the same iSCSI node name, they must perform the duties of an iSCSI node - ISID, TSID, and Target Portal group coordination. Can generate independent iSCSI node names with EUI/WWN embedded via IQN format. General principle is that the responsibilities of an iSCSI node for coordinating ISID, TSID, and portal group tags applies independent of whether the iSCSI node is an initiator (e.g., multiple ports/HBAs), target (e.g., multi-ported disk array) or gateways (multiple gateways exporting same/shared LUs). -- Grant EUI64 Draft (Robert Grant, McData) 2 gateways, like Dave Peterson's scenario - want to have the same name for all the ways in which one iSCSI device is presented to Fibre Channel. This is about the Fibre Channel side of naming, vs. previous issue that was about iSCSI side of naming. This gets more complicated when one considers gateway failures. If the gateway does the naming, the same iSCSI initiator may have more than one FC WWN and hence the FC config loses the value of the single iSCSI node name. Gateway coordination and making sure the name doesn't change (e.g., for zoning, lun masking mapping) are complex. This gets really ugly as the number of gateways (e.g., for bandwidth addition) goes up. Proposed solution - have iSCSI supply a node-level EUI64 (yields FC WWN) to the gateway. Support in iSNS (being done) and provide an operational login key to communicate the EUI64 in the absence of iSNS. iSNS does solve the problem. Discussion of what happens when trying to scale up iSNS does not seem productive. Operational key is useful when eui-based naming is not used but one wants to work through a FC gateway. Support would be optional. Alternate proposal - Have eui64 names assigned to any device that wants to do this, preferably by the vendor. NOTE: This is about an eui64 name at the node level, not the port level. This is anticipating a more powerful role for FC Node WWN in Fibre Channel configuration. No consensus to add this to current iSCSI draft - continue to work this as an independent draft for later consideration. May want to produce a larger draft on bridge/gateway issues in general. -- iSCSI Framing Long, interesting discussion ... FIM = Fixed Interval Markers Initial proposal to move FIM to an experimental draft if specified as MAY on transmit accepted. Later, after sentiment in the room taken, decision unanimously reversed -- No matter if FIM MAY or SHOULD on transmit, will remain in the iSCSI draft. Due to concerns among many that moving it to an experimental draft would effectively kill FIM. Room about evenly split as to whether FIM is critical to achieving 10 Gbps speeds. Room about evenly split (vote 19-18 for FIM to be SHOULD) on whether FIM should be SHOULD or MAY on transmit. FIM bidirectionally negotiated. After approximately a 2 hour discussion, could get no clear consensus. Chairs made decision that due to this lack of consensus, FIM on transmit will go to MAY. FIM on receive will stay MAY. Chairs invited the proponents of FIM to write up an informational draft and submit to WG on the advantages/benefits of FIM. Also indicated to the group that the status of FIM may change at some later date, depending on implementation results. Also -- TCP ULP framing will not be discussed in the main iSCSI draft. -- iSCSI Open Mike ** Need to make sure that unrecognized values for recognized keys are ignored when a list with values that are recognized. ** A key with a single unrecognized value results in a reject. Discussion of spec clarity - Suggestion that there should be no implied requirements in the spec, so that a PICS can be written by scanning for the the capitalized words. Everyone should read the spec looking for potentially implied/misleading text. For example, see "reissued w/same CmdSN" sentence in Chapter 2 that does not have an RFC 2119 word. Upper case MAY NOT is not defined in RFC 2119, there are several instances of this in Appendix E (Send Targets) that need to be removed. Discussion of some aspects of error recovery - what needs to be done after connection failover. This is all covered in Chapter 7. Dave Peterson will look into iSCSI error recovery issues for tape and similar devices (don't reissue commands w/o knowledge of tape position, issue can also affect optical jukeboxes and the like) and draft an implementer's note indicating the minimum level of recovery support needed for current tape devices - Mallikarjun to help. ----- Thursday, February 7, 2002 ------ -- Agenda Bashing Add iSCSI carryover slot for ISID and Target Portal Group tag items up front. (This discussion included in Monday's notes, for continuity of issues) -- Last Call and RFC Procedures (Elizabeth Rodriguez) Discussion of WG Last Call, steps involved in an I-D becoming an RFC, including things that authors need to check and/or be aware of to avoid delays in the process. -- SCSI MIB (Yaron Lederman) IETF IPS SCSI MIB design team has developed a new SCSI (not iSCSI) MIB with significant participation from T10's SCSI experts. See Yaron's slides. Virtualization, Bridging and SCSI Command sets are out of scope. SCSI MIB exports information for SCSI entities visible over a SCSI nexus. Object model is posted on Mark Bakke's site at Cisco - URL has been sent to the list and is in the agenda. MIB has a notion of "Authorized Initiator" at Target to allow controls over Initiators that cannot attach. Structural analog on Initiator side is "Discovered Target." Note that the statistics are optional to implement - the structure is being provided to present the statistics if they are maintained. Discussion that some systems keep a recent history, but not a complete history of statistics. Julian suggests that amount of statistics to be kept be expressed in terms of size of data rather than time it covers. Request for a fixed-size error log (last N). There is already an event log MIB that would be appropriate for keeping the last N errors. Need to check how to index this from another MIB. This is an open issue for further consideration on the list, but tape discussion doesn't seem to be a motivating example - this is characterized as a need for a SCSI TAPE MIB as opposed to a SCSI MIB. MIB will NOT model SCSI mode pages. Discussion of versions of SNMP - SMIv2 is being used, and everything works with SNMPv1, v2c, and v3, except for two uses of counter64 to record statistics that can not be accessed by SNMPv1. SNMP security policy is orthogonal to MIB specification and conformance statements (requirements to implement) - one may be required to implement something that is made inaccessible by the security policy. ** SCSI MIB design team will recheck current use of counter64. Network Management Area of IETF is now discouraging use of counter32 to provide SNMPv1 access to counter64 elements in order to encourage people to move to at least SNMPv2c. ** SUBSEQUENT UPDATE: This use of counter32 is still considered acceptable. Keith: usual guideline is that if a 32 bit wrap is possible within an hour, then counter64 should be used for the element. MIB Family - discussion of coordination across SCSI and iSCSI MIBs. FCP MIB example on family slide is completely hypothetical to illustrate intended structure. iSCSI and SCSI ports are separate concepts, each for its own MIB. Still a work in progress - please look at the MIB and MIB structure and comment on the list. -- IPS Security (Bernard Aboba) This is about changes to the -07 version of the security draft to close open issues - authors believe that all open technical issues have closure that should be acceptable to the WG. See Bernard's slides. - IKE fragmentation Long certs, or multiple certs can cause IKE UDP packets to undergo IP fragmentation, and lots of actual network devices don't deal with fragments. Text will contain warnings about things that cause large IKE packets, and advice to use network equipment that supports IP fragmentation. - Dangling SAs Will delete paragraphs prohibiting "Dangling SAs". - Identification Payloads Add a MUST for ID_FQDN. FCIP and iFCP want to have a SHOULD NOT for ID_USER_FQDN, iSCSI will have a MAY. Further discussion of the ID's to which "SHOULD NOT" was applied should go to the list. - SLPv2 Security RFC 2608bis will retain RFC 2608 security model in order to get to draft standard. Separate draft will be written on IPsec for SLPv2 in fairly short order. Once that gets done, a bunch of the IPS Security text on IPsec for SLPv2 will get removed. SLPv2 authorization text will be in SLPv2 drafts. - iSNS Security Policy Had to change per-target security to per-IP Interface, otherwise IPsec Security Policy Database breaks (can only have one per IP interface). Lots more stuff on the slide, Mark Bakke to provide equivalent text for SLPv2. IPsec for iSNS is MUST implement when iSNS is used with iFCP. - IPS Authorization Will describe identification mechanisms, authorization mechanisms, and limitations (IPsec best for intra-domain use due to cert limitations and issues with multiple trusted cert roots). This supports the separation and generalization of the Authorization MIB from the iSCSI MIB. iSNS is also an authorization mechanism for at least iFCP, and could be used for iSCSI (if iSCSI chose to delegate authorization to iSNS - would require IPsec for iSNS). - Rekey Calculations Removed "safety factor" from rekey calculations and deleted AES-CBC material because we are only using AES-CTR. Still wind up needing to rekey prior to sequence rollover. - Transforms Summary of currently specified transforms. David Black to sent prod-o-gram to Ted and Barbara (esp. Barbara) on drafts. Q: What about AES-CBC? A: AES-CTR draft currently appears to be making sufficient progress - this is the path to high performance. NOTE: XCBC is the MAC extension mechanism, not the combined mode (combined mode has Intellectual Property Rights issues, the MAC extension does not). - SRP Issues Will add a 3072-bit group to the appendix if we can find one. Current text key value size limits can hold a 3072 bit value. - Transport mode vs. Tunnel Mode MUST support ESP, tunnel mode, and replay detection. If the IPsec implementation is a host according to RFC 2401, then MUST support transport mode. Q: Does this mean that FCIP (and iFCP) would need to support both tunnel and transport mode? A: No, only devices acting as a host, as defined in RFC 2401. Add an "if" pointing to the ipsra ipsec-dhcp RFC as the way to do DHCP through an IPsec tunnel (avoid using a MUST). Concern expressed that notion of an embedded security gateway is not consistent with RFC 2401. David Black to work with Bernard on clearer text explaining RFC 2401 requirements, and to check issue of "embedded security gateway" being consistent with RFC 2401. Add some text describing current possibilities for gateway discovery. David Black to send Paul Hoffman a prod-o-gram to get ipsra requirements doc out so that ipsec-dhcp draft makes it out of RFC Editor Queue. 2 Consensus calls - Everything except tunnel/transport - no objections - Tunnel/transport requirements - clear majority of room, rough consensus. Noted: Most are not familiar with RFC 2401, as of the time of this consensus call. -- Open Mike Charter update is still in the works - Allison says its because IP Storage is a good WG and hence doesn't have "on fire" requirements for her attention. Change "SHOULD" to "MUST" for use of serial number arithmetic for CmdSNs. ----- Friday, February 8, 2002 ----- -- FC Management MIB (Keith McCloghrie) This will replace both the FC Management MIB (transferred from the ipfc WG) and the FC Fabric Element MIB (RFC 2837). Major revision and rearchitecture to fit IETF guidelines and partition by functionality. Major changes from ipfc FC Mgmt MIB - Remove objects not specific to FC -- entity MIB WG will define MIB support for sensors, trap registration is handled by basic SNMPv3 MIBs, events - RFCs 2819 and 30114, inventory - RFCs 2737 and 2790, revision number [wrong approach], a few other objects, plus obsolete stuff. - Now linked to ifTable in interfaces MIB (RFC 2863), removed objects already covered in the interfaces MIB, and explained how ifTable objects apply to Fibre Channel. - Removed scalars due to AgentX MIB (RFC 2741). Need to partition MIB among agents (e.g., multiple vendors) at instance level, hence global scalars cause problems for AgentX. - Counters: Counter64 for traffic counters, Counter32 for error counters (traffic counters could wrap a 32 bit integer in less than one hour). Issue: What about counter64 vs. SNMPv1 - would like to avoid losing access to the traffic counters when running SNMPv1. Additional counter32 objects would add overhead. Requests from multiple WG members to provide this access. ** Keith and DLB will check with Ops & Mgt ADs on current position on this - IETF is about to make SNMPv1 historic **. SUBSEQUENT UPDATE: This use of counter32 to allow SNMPv1 access is ok. - "Connectivity Unit" renamed to "FC Management Instance", defined as "a separable managed instance of Fibre Channel functionality" Change: Put in reference to FC-MI as strong input to defining set of things that are interesting to manage with this MIB. Open Issues - Name Server. - Class F counters. - Zoning information. Ralph Weber mentions new HBA management server being defined in T11 - sounds like this ought to be a separate MIB. Suggests drawing T11's attention to Section 13 (comparison to ipfc Mgmt MIB), where changes are described, Ralph will send email. Keep Section 13 around and deal with its reference to the ipfc version of the FC management MIB at WG Last Call - there will probably be a stable T11 version of the old FC management MIB that can be referenced at that time. Put in Class F counters now. Defer the Zone Server. Add Security Server to the list of deferred Servers, ditto Alias and HBA Servers. Also a QoS server under development in T11. FC name server should be a separate MIB. Should be first on the list of servers for which MIBs are to be generated after this one is stable. Section 14 contains a comparison to RFC 2837, no functionality will be lost, but stuff does move to other MIBs. Class 4 to be put in after Minneapolis. Can put in traffic counters for it after Minneapolis. Murali to be responsible for informing WG of appropriate points to undertake MIB definition work for items that we deferred here. RFC 2837 and old FC Mgmt MIB have allocated portions of MIB object space (experimental 94 in latter case). These will never go away - they're either that MIB or "Not Implemented". Need to deal with FCIP MIB dependence on old FC Mgmt MIB, and iSNS MIB dependence on RFC 2837 - those should import from this new MIB. FCIP MIB is in the process of being updated. ** Josh and Keith to check iFCP MIB to see if it has any similar dependence issues. ** -- FCIP MIB (Anil Rijhsinghani) Currently at -01. Matches current FCIP model, some changes for NAT. Now deals with FCIP device that can have multiple FCIP Entities - will look at adopting "FC Management Instance" terminology from previous MIB. RFC 2837 references will be updated to previous MIB. TCP-specific counters removed. Keith: IPv6 MIB work has added per-interface IP counters, and might be appropriate place for per-interface TCP counters. Contact Juergen Schoenwalder to pursue this. Structure - FCIP Entity, Link and Connection tables. Dynamic and Static Route tables for FC reachability. Static route table allows pre-configuration of connectivity. DLB requests that care be taken to make it clear that the latter two are about FC Fabric routing and reachability. Work to be done: Align with latest FC-BB-2 changes/requests, add support for security (will look at authorization MIB coming out of iSCSI), and SLP, write conformance statements. FCIP folks need to look at use of IKE info for Authorization - if they want to do this, then use of Authorization MIB coming out of the iSCSI work may be appropriate. Will need to define notifications. Keith - be careful not to get carried away - these are for exceptional conditions, and really want to generate only one notification in most cases. Discussion of possibly treating endpoint of an FCIP link as an interface - might be related to issues in IPsec space about treating endpoint of an IPsec tunnel as an interface for routing purposes. SLP additions - Dave Peterson is not aware of anything that's needed here. -02 version expected for Minneapolis. -- iFCP MIB status (Josh Tseng, no slides) iFCP will not need Authorization MIB emerging from iSCSI - will use iSNS for Authorization, so Authorization info might be extracted from iSNS MIB to use a common authorization MIB. No known open issues. -- iFCP (Charles Monia) Revision 9 is believed to be done (ready for WG Last Call) except for some pending security stuff. Revised terminology to better explain address translation vs. transparent modes. Added TCP port number to N_PORT info. Stale frame detection is now mandatory, added FC-4 link services, and replaced broadcast service to use TCP (UDP approach could have caused IP fragmentation in some circumstances). Added support for "liveness test" message to make sure TCP connection is still up. Tracking security changes - will update to most recent changes. Have same issue with AES-CTR and AES-CBC-MAC w/XCBC references making progress in a timely fashion as in the main IPS security draft, will deal with them in same fashion as main IPS security draft. -- FC Encapsulation (Ralph Weber) Vi Chau has asked to be removed from list of Authors. Adding all the rest of the EOF codes for Class 4. iFCP does not need Class 4 EOF codes. -- FCIP (Ralph Weber) At -08, needs Class 4 EOF codes. Editorial changes still being made. -- iSNS for iFCP (Josh Tseng, no slides) Is in good shape, no issues. -- SLP for FCIP (Dave Peterson, no slides) Waiting for some more clarity on security. Will consult with Mark Bakke (see yesterday's IPS Security draft session) to get the SLP security discussion/ modifications into this draft. -- Open Mike Last call procedure - authors tell WG chairs on list or directly that draft is ready for WG Last Call, chairs announce WG Last Call and define Last Call period. --------------------------------------------------- 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 Feb 25 23: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 XAA10533 for ; Mon, 25 Feb 2002 23:57:38 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1Q44jV15429 for ips-outgoing; Mon, 25 Feb 2002 23:04:45 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailnpd.hcltech.com ([203.197.145.76]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g1Q44cH15424 for ; Mon, 25 Feb 2002 23:04:38 -0500 (EST) Received: from npd.hcltech.com (skotra-pc.hcltech.com [192.168.100.57]) by mailnpd.hcltech.com (8.11.0/8.11.0) with ESMTP id g1Q3ssm17471; Tue, 26 Feb 2002 09:24:55 +0530 Message-ID: <3C7B093D.1643F7E5@npd.hcltech.com> Date: Tue, 26 Feb 2002 09:34:13 +0530 From: Subrahmanya Sastry K V Organization: HCL Technologies X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: "'ips@ece.cmu.edu'" , "'Julian Satran'" Subject: Login Proposal Content-Type: multipart/mixed; boundary="------------74CD8CFEB20A8BAE3D14CE79" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------74CD8CFEB20A8BAE3D14CE79 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The recent plugfest highlighted areas of the login procedure that could be improved. With this in mind, Bob Russell, Marjorie Krueger, and myself have been working on a proposal for the Login procedure. Our goals were to keep it inline as much as possible with 0.7 of the specification and to ensure connectivity can be maintained amongst target and initiators. I believe we have meet all the goals we set out to do. I have also attached a Login Reference Model (in the form of c code) which backs up our proposal. Please note that the reference model is only a reference model and should not be considered as, or be part of the iSCSI specification. Cheers Matthew Burbridge Marjorie Krueger Bob Russell ++++++++++++++++++++++++ The Login Proposal: Definitions: FBit means "I have nothing (more) to negotiate" Request: The first occurrence of a Text Parameter from the initiator or the target. A request MUST be answered with a reply. Reply: A Text Parameter that is a response to a Request. Negotiation: A request followed by a response. 1.1 Actions at the Initiator The initiator starts the login phase by sending a Login Command PDU. The IIN MUST be present in the login command. The SessionType MUST be present if the session type is Discovery, Boot or CopyManager. It MAY be present if SessionType=Normal. The ITN MUST be present unless SessionType=Discovery when it is optional. The initiator MUST NOT send operational text parameters in the login command. The table below defines the parameter present in the login command. SessionType SessionType IIN ITN Present in Present in Present in Login? Login? Login? Normal Optional Yes Yes Boot Yes Yes Yes CopyManager Yes Yes Yes Discovery Yes Yes Optional SecurityContextComplete=yes MUST NOT be present in the login command Operational Parameters MUST NOT be present in the login command At anytime the initiator MAY terminate the login killing the TCP connection. If the initiator requires security negotiation it MUST send one or more security parameters: (AuthMethod, HeaderDigest, DataDigest) in the login command. Fbit Security Parameters Description Present 0 No Initiator has no security parameters to negotiate but has operational parameters to negotiate. 0 Yes The initiator wants to negotiate security. 1 No The initiator has no security parameters to negotiate and no operational parameters to negotiate. 1 Yes ILLEGAL. Target must reject login (Login Status = 0200) 1.2 Actions at the Target On receipt of the Login Command the target MUST respond according to the rules below: If the InitiatorName is not present the target MUST reject the login by sending a Login Response with FBit=1 and StatusCode=0200. Similary, if the SessionType is not Discovery and the TargetName is not present the target MUST reject the login by sending a Login Response with FBit=1 and StatusCode=0200. It both cases the target should kill the TCP connection after the login response has successfully been sent. At anytime the target MAY terminate the login by sending a login response with the FBit set to 1 and a non-zero StatusCode. The target should kill the TCP connection after the login response has successfully been sent. If the login command contains security parameters, the target MUST enter the security phase of the login. It MUST send response to those security parameters and MAY start negotiating security parameters if the parameters that it wants to negotiate are not in the Login command. The target responses with a Text Response (F=0). If the login command does not contain security parameters the target MUST perform one of the two actions below: a) If the target requires security negotiation to be performed, then it MUST enter the security phase and MUST send a text response containing one or more security parameters and F=0. b) If the target does not require security negotiation (and therefore neither does the initiator) it MUST perform one of the actions defined by the table below. Initiator Target has Action FBit params to negotiate 0 No Send Text Response with F=1 (Initiator only wants to negotiate operational parameters). 0 Yes Send Text Response with operation params If all parameters can be sent in a single response then F=1 else F=0 (Both target and initiator want to negotiate operational parameters). 1 No Send Login Response with F=1. (Neither target nor initiator want to negotiate operational parameters). 1 Yes Send Text Response. If all parameters can be sent in a single response then F=1 else F=0 (Target only wants to negotiate operational parameters). 1.3 General Rules If an initiator or target has text parameters (security or operational) to negotiate then it MUST send them at the earliest opportunity and it MUST NOT send an empty text command. An initiator or target MUST respond to the a text parameter request with a text parameter response in the next text PDU to be sent. Once an initiator or target has completed initiating negotiations (security or operational) it MUST not initiate any more of the same type (security or operational). In other words it can not go backwards. Operational Parameters MUST NOT be negotiated during the security phase. Security Parameters MUST NOT be negotiated during the operartional phase. When a party has no more text parameters to negotiate then the FBit MUST be set in the PDU containing the last text parameter request and all subsequent PDUs. For example: if an initiator only wants to negotiate "InitialR2T=yes" and no others, then it MUST set the FBit to 1 in the commands containing "InitialR2T=yes". Once the FBit has been set to 1, it MUST not be set back to 0. Also, if the FBit is 1 then the party MUST not instigate anymore text parameter negotiations. It can only respond to requests from the other party. If FMarker=yes then SFMarkInt and RFMarkInt MUST be present in the same Text PDU as FMarker=yes. If FMarker=no then SHOULD NOT be present. If they are then the remote party MUST reply to them and echo the values sent in the initial PDU. 1.4 Completion of Security Phase [Authors note: This section has been extracted from v0.7 but I have made some clarifications to the version 0.7 spec. - Changes in CAPITALS] -Every party in the security negotiation MUST [Added MUST] indicate that it has completed building its security context (has all the required information) by sending the key=value pair: SecurityContextComplete=yes The other party either offers some more SECURITY parameters or answers with the same: SecurityContextComplete=yes The party that is ready MUST [Added MUST] keep sending the SecurityContextComplete=yes pair (in addition to new security Parameter REPLYS if required) until the handshake is complete. Once the party has set SecurityContextComplete=yes it MUST not instigate anymore negotiations but it MUST respond to any requests from the other pary. If the initiator has been the last to complete the SECUIRTY PHASE it MUST NOT start sending operational parameters within the same text command; a text response including only SecurityContextComplete=yes concludes the security sub-phase. If the target has been the last to complete the SECURITY PHASE, the initiator can start the operational parameter negotiation with the next text command; the security negotiation sub-phase ends with the target text response. The SecurityContextComplete handshake MUST be performed if any of negotiating parties has offered a security/integrity item (even if it is not selected). All PDUs sent after the security negotiation sub phase MUST be built using the agreed security. This proposal removes from 0.7 of the spec: Partial Login response: It no longer coveys any information. OpParamReset: No longer required as operational parameters can not be negotiated during security phase. Keep: SecurityContextComplete=yes. This is how 0.7 works. If people disagree then we can vote and change it. Matthew Burbridge Senior Development Engineer NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com --------------74CD8CFEB20A8BAE3D14CE79 Content-Type: application/octet-stream; name="LoginReferenceModel.zip" Content-Disposition: attachment; filename="LoginReferenceModel.zip" Content-Transfer-Encoding: base64 UEsDBBQAAAAIABqRFStuCfuw4RkAAD9/AAAXAAAATG9naW5SZWZlcmVuY2VNb2RlbC5jcHDtPWtz GzeSn+kq/wdIqcSUTcmUb/euSlplT5bomBtL1Il0nD3H5RqRoDhncoaZGUpWNvrv1914DzB8yk4+ LFOxJAzQaPQb3Rjw+fNnD/J5/Oj5c/yfxd2Tbpu9Sa/jhF3yIc940ufsLB3wse5zFhXFiN+yl7Ps KosH15xauzyJ04yd8hs+TqcTnhSslQAYzjN6/prfjnlRsIuo/ynKBuxNMdijBxMB7uq/AdjeaLrX Tyd6qsWYL/HR0HqjOGfTLL3OosmEswmuKmcwubPsi1GUc+w2TfNozNIh2//L7vHsevdFs7lPcNqF PfaKj6KbOJ1l2PUqLUYCYhIXcVQARaJkQC1FlF3zgt2OeEJQ+mkyzNKk4AN2dcduogxg5GyW84wB 8YDyAzaNAFMOv+d7ehHnacHzA/3nxZgjugm0wixRgVNlMH3OzjtmPIAfz2hRfZ7ncXLN+Oc+nxZs mGaSe/1ZFhd3J4jQ5+IknUyBW/zojuesDovonpzg7zu0mi7CSJPe3ZQf7e3tseMxCQdLce7ypDnr RwkQCUbeFSOcGkFEGeHM+iPe/8QHe2Z9xCRCv0dku02z8eCJwGIC4oQoi5Wi4PBsh/HhMO7HKHB9 4AqLcoKDYycR8DO9+j/eLxBkkSJK8SAiWimuj4nrU+S6weLlLB4XwNAhMlX0G2TRsGDNvf9i+ZT3 TdfO9CLKJpc854XCO59Np2mGnK0nKUyQXAM1Mv7rLAau7pilptA4mIGC9Ynen4EBOB+hjgLGYmxG XYoKIDg9GKbjcXqLdDTSQdCQpM7kBsVXs/FYs5gl/DpF2QSISnMHPRLOnD0Drc+naZILpT7uo7y0 T+mPH8Y82e3NsgQW8xOMQbEASsRAffYjv8u/kNaSLAp0WTvJi2zWx98tHXgTJ7PPB+y632e77yJY 6m4qdNlYMPfPvf50SiPfxbCM2/yAvc2FSJx12U9xPgO9P3n2rGTMbmJQV/odeJTHk3gcCeXpoNwD kDYQMMInwDR2woYx/KjfxmAREBjwGAfnWzssT1k+Smdj0HyQswGDlSntMEz7MUlvE1TZKxABa7VS +1gB6scms7xA5YqFcAgLhjOhktW1EctBgEATY5LQdIr0i8ZaEBczY5nP40cCve4JO3vb7ZF6G8yE PRxLbZMYbuGYb+KkP56B4v4tLwZxujf63m7r4zJLbSADSKly42AcX1Hjwwoh61z02p3zri2SozQF gbkdxf0RMI+zu3TGbiOQDDAxYMFhXd8M+BCtFRjOWm0bzec2Di01V1jdbTGT6tw7vvyh1fv47vi8 1/3YbZ28bV/2/llr1gCTJjsCQjNQxX34DSz0lju0dfK60z6/eNtj+7VacAB7Bb/HyXRWoDECA9Uv JAXlund3H5KeBGvXfOjvU0Q2Jq32n6ulnB3//PHi+PL47OOb1vkPvdeszv7zP8Bg7cP/L/76V/pt h8Fo0GWQ/Shn7ScTNo5+u9shn4GGAaksFrsVANzqtS67tf0mUbYrFRRNcUa+NQG/nM6uR7gIlEoY Di2zCfsXe9P5oX3eYL3Wz70Gu2z9o3XSY/fs4vRt758XrUOve+9dBKtNroH0pLEN5n56SjAAZGfK s0goLPwF3a/5oJ0A9F63d9wLAG9DhKC6CcDti4wbiG3rVwd42wLergB+nmYT7Hsa5/30hmcA5CSd 3p1FSQQ+rsFepqD196zb6nZBdkqr74+ijBGlu+9don94X+buh0ObzMLqP370r8ePapKqDMMP6FSL k6JWe/UyLvAPAb12oV2j7kGE7oIdnOWHjCFwYtDH4jDAz1eXrVaDdd72Pl62/udtqwtcbZ+b3087 5/AYSfS2i3xWxKpAmB7XcG5CGMlQ64EkViz6XtBIEq9K+aRjT8gZsossLVKcPK/uj04AXPVNGg/A y0eDLpnROgaieSGY8xQVpCF/hzWwnUM9DqhIw4DFEHMm/ji7M02CgcWJsPR1QWv2VFr+hvo7k+GG N1hEJBciYl0HCuLbzpWwa4moS4xNmFoaY2QHzTJEkApEXcquFXj581katcGUFpQFsxKtLoCRhQrc 6gtJi1w0U+oJTFPDSCB7Ss1dXpSR/gG4Y1boIdkoL1o1iK2IBcwyFgjU2l3Uq4bQMtpqi1UXf5ef Hw8GnZmNowB2YRBasEoFpZ1sCkSKsQVobbKf4I4JdlyXsJ3geZF34Uk+jPmgvszo44xvPBaicb7C UCLACbjPa66XSrZwOVo2pHn1QJ6mLdgw1Qk12vj58nmedoYBilfrL8yHnkQAfYq/Bo2apZ49Ebet Z+MQlrIuGwGS25sKA9AQayPfR0PxPzlcOHr4gRyBiNCOHg4pYhRP5LZUJjFyaptE/REGUGKPoyJ8 erajJxBhCvyQE5Rjn8NN5tCzaMGpSb8hpaccZ8glcdrDWXIwy0UaxpofQvkii/qfsG0SmEibn+q5 1pzKFkmI2sWKSBiPWPNQxPH0J2wQy7BKYzWS1vDgaJ2vKgP4qEHAnsVA0K24lSF+gGxBzJ1zniyG KZbkABRNa0DrbYBhkGa9tdBToBx7Ika9g52hDkRQBUL7OYwMHz+yYyovdMnff2BHIqbcPo2K6DS+ Bit+tN3Ahtfg1HnmNB3PitEZL0bpQDScv33zBsJLMgD2RKGYxZ7rLPoMcUnCRd5FAn91FmWfeCb/ uqQ/24maulv6WzBjfPmiJxtexqex19ieTGALCqqNq5Nt+CvYszc8uS5Gau44y4uXM/inG//GZSNY k3RWkE05i5NePAk9iD5bD+AvCBCAXckADJJBA6fsZAO9OKI1H8e437HbpblGjxjddUXazX30KorH uE1yHlaxAVZ5DsQnysMeZJsw3m6wbXQN+POSYyZzm93P2RZs8CGQZxB9bn0R4KgPlJCtsx0hWFMM W4d1udJyvYE27ZR6/SXZJrdlBnglCFZ/fbHj9ysXHTCFr3pBPxNByoaMF7MsAZ0H/iymMT3vge5b poac1tkxOa3F420f7oWzerv7EaySDAUOTYvy7gJzN2vifMRTjDWcTJyEuHCs7LeHATkIJqU6HCL/ kpx0zs6Oz08PNAPKOwwFw451Pf8phqqu0mHpiOw715VRX2eD+Z2Olr5z4iSxQGATVnWMG1YVCJUN B1eIaVlOFZQJuuRBiiyshUPXbY0O6iwotr8ekScQmFYAsSspa4IQLmYZJFDgdZhnpYTEI9S2Ojs8 RLmroeDVcgi5+iNolKPwgXjSx5KTHSkeYKuRiNblZeeSHagcWsJvqP4BoRxJoD2SQGu5qdVUVL+v Gq5g3CeBopzXQl3MGw8BScVzKadSUAXSAmvy469BQsacRTIRrUaJ58Ftmga8hPB6yFhZJ8SpKfFR CInershbvXS3EmkPVDiSYzXCXQm74kNMWJoC5CgakFwTeJDrfYvcIYrXavfypxEXvSUQT2QHPlaU U4iWTDr6P1Csb5t/+fkXdGVBuuhpfUzEPOJfnIwRvQwjvAxNgFlsxxMCST3M2FNVkOqtQCMZoVEt UHQ2FLC0xUEpDHqQ8pzMi6oKiClSE2mJWVgdCzUJj6l0SqOsONfFwArTbCSEgsAvto4EFMSjmpNk WoJwRgazLM0ORJUHK46j6IYzC5o1FaymRFdb+DyG34s1PIQi0prdHFUQAET0DYYhGSwXdG+/SlgA dwAgy7owCNYPES6LQYKmEdXU98SQsJ2maQLWWSaRFUXcrdF+WdiE/DudPJQrTAVxSyxgbrUfzyeY WrE4DKE6+LxjAeYRjoiluy8jRNl334nhwWXYTwPpm7CMyqFY+TmT1VB0MmkyvrPOIsgypGPvGfOY fTyGwAhWzrM4YjCSglAszGPBPWQgBLUZBgTn7V77uIck1+STBPYIKMZKQpXNvyCE7UXsJyUH8hxP hIgSlVXXR4sDdMAIBrDBIwhovhmF9mqYdM5tob6AZRaJ4xi4VDxE8nfZd3UvgEhxmA+wuE7xX8/u EVa5CkmHuJ+zAlJ3Vs/u1WrzknBVcaDBuNJ4d4sY+O+ZrAPWj7LsDkRqb08qeWXmbs7strmmX/Ef Ya6ttcyz2Cv5ubIdcM210XDHVnuMWmSu5TI2tthm1UsGcu/4E1iGFmzdfpqCSCcofdUiXSXRiwXD d+CwaQhKxxriOUdAKgLt7owO6ATi52Yofh7wYTQbFwIILOsfaC/xOEZEZxY8oYEQvp3QkSm5B/Am YoFIHRaCmN+vtodWCTaxgY6W3EBvUioU+2uqxlqJUtxJBQuzqqfZcM3t9hPWrMI9rIIXyoreAh6a jdjhob8N6wW3YeV8umU/5NJ3vydN2gpqkmb4jyjhJs13wCQh8cQQBrKRKDIEQ4CmJcFKtqoyCpRT UIUFiEVkElDiRtqaLwmDFrlVCvL0om2bM2e3jg2LTKfbmQzpFZ6m5LT/AgUSux1JMZtEpcKMqcg0 PzdfNDXdZOLJJeIKyyvlEX4S9dL5i7LGfI0l1RxRB9tbLvX+pIu81NlSs+YHysPbZLFBgWDr4yju klegoJtGMX/5EVc4vg5KhoylDapSlzS6zk58WcI6lDUhjSHO/J1eYP1LhQ6I+IKd3hdRg7l2YNeY k5Ah0YH3kpDm0NDEXhUEZDYFYao3zllMkYRRUaUZCOGDyR6XEhJqSg0S/SRWG+4ER4gb/8uzlHUy doZbAD1DJiv8MiAx1deqNIbYWYbqVeXAy1/XeSe4tKtZoQ+9hxcmtpcaMp0mxsw0+rUolxs2d7md hK+92nCQGrQHbhXZ2rNZWe/LVveic95tHdiSrkRbOt0jOhN4WFYrogIuJZVL0RRRRzNsmOVsuplj Aco1Jc1zNtMlMQ4lKYPmgLgRFQzfPyjoEKwvA455q8rurZKdChqt+XguSlBpl5fPSVStiry/UXtY MseZTWa1huUwNhh5JRbrpEG1Fw9sj2wDoF5zwLq4TGvm8YD2SddpKRWA5S/uKe3cPKeV5NTaLULe zZU7kDIMjl+YMsSMljyYPmCWsQQayFdwWFyI3nOyhS6aXqrQO/dQkS0s91uYMDT+6OvlDCtcs3p2 ArwH4UBbar2gsmDcHFM8z4q7HYSp/ja3LTQdgKPXmNx2bbkbUgfrlWfmyiII//2dbZ93tmHLvR2N xxYI5KCXKP39d+2tneSgBeU3DAzwpSnwL9sCGoMFyjLB+k6lSlXCAJZNr4P57QuJ8TOtbH1VobSw GEipenppBqyQOMMj4NJaKg9GepxaxnTbOXe5LC5eQJCrFSrGB3bSNlelu5wXRIU5KrfY1G9uXpao RPiSOc+wfPVKxPKuzgh1hcG0SxMBfYTPcrULPw5QxYsOFiyE51i6VHGiShXlMoUIEIhkFEFc4Uk1 mHXP5gzD4wN0Fm3NkoWia6Bm4T7yixYv8UVZDAxyNkhFpTSJqFKa8IE4kOEmWzXVJAwTL5SqEr7d 10dW3KdObZ7yC7XanKLGnADFqSvYEZMfs3iZ/s3Dlj+R76yFPKcdeJecp/voi/nPNf2kQwfDiffN DyYlVdM6sbUKsuC/2XOntowqkKsx5CvMCQ61v9UGxl0RuCMLWJxT3W+rym706AVxPP4kw3N/HlRD sfEuNGmch5PoE+1d8XV3WVLcZJO6mb0OmxzLHFdYK/18ed+/U0VUMmfSuVPSXNMUCW34Md84Vdm0 asNi1Yj0mIPK3viHUwOqLPf0Vir3PF622jP/477SBmLWF6YrYldRHvfpZXrjB3a8I1ybzZ1bZzFL +cq571OIMlI1Xz2hpljK1mDRUumYPr9oNt0OFbZoHQZ4NKeifJQ4prknAwJRnl95BpuyG70+I0gd 4yn9gKEVAu4WvYzjmndcNQAMRlaZ84ojR4scn1jEcq6vzoIoCcsVcnQWVraRM11TkWzUTo4pMxoI NVwHp47zlOE31Ta0AtWmtJdkJJ/b72PIKsiA3pznmNbK8GoC9IK245HmVPkdWmjFwWLXyVQw6N5d r+diFh0w1nJpBBKP3dWk4q2mGJV6pwPx9ZXuoV4ykwXyNRRqbvqkpAjVCZTq8C/A4UrFqDqJRrIb 1Jq50aFWnA1EUWnVurlGpVK0W8Q7R7RX9FOMax5HXJw4mZ82CXHIZE5E4LQg8egkTkxA9ZC5k3Lm hAIt75W3fWk9nCOY4aQqLeyr5D3KAdnq1m0Z+/YAUV3wU2H+DA5GiFndecNup0GGg2hcypN8ASzL hnSNWIXFgtZaKtpgSsG0fJtblXICIN7+cuzth5I9lReEIA+PvhUDXZYr86K89+2IbiEKGZf3Mbn5 LaWVruzKmb7N3Umc4VIUYyC7EUG5aSqdxgoLV+0CpzOBti95q3PVEy3YRAykzAiZQqmR+LDxEsfM /I8rGEtfpmGdOCv4ZAptc46QPZ0WmfkD+r4QrB2kklfIHmwGVufUVbb5zhf8WIPpKzqo0xB4BE5L otHwbtdpMLyNKVHyhEPI8A15CqDlMxIbfKQckny7ptV5Jd7eK10r5CSPpHFsARPSobgsi14Rwnvv Mj4BN5Px8V3Z4Gl7h9PemzUDeY/UatRjJft1hrSUgi7SlKrhyS/JE78te1JeG/6CDhe4PGXpDDf5 dyyfRn2eq8fysFGcU7MEJ1MGGo5gJKCquFurUYNQIGtRelXiibtaBUScicJbsIbWTU/ojGyWoZhh OA8r++aJuyzNDqnm6soXNd83YPLi4WN8M7l2r+lZAniIlGlfJ+h+Ua3wkrM5eIFI5HU9k5phdTez WM8jdiXuqqGul5QQkXc2inZ5LWK9Ke7DGqR8F/7f2lkZE2kN4sVX5FgmYL76I4pVPaBPrlhH2gv8 Y++bv+9/sPXctRY120qJUXIKnVAjaVHzCgbb8RpJZCm0aU2mEKMIsKTy6ISMzuKQQIzlSJMzJapf U2tk6cE+qaVAVr6pWwd0dtyeuwLC4cahiydgBe5VgUh2vE3ht3/yxZG4fRwUU2YWxbMpLsq8jTeL WRypW+6iIy8mibUR0YGCB4ccPZBfbEKUNJGsTPikP5nWzbIb4eFkWMY8qYK+E9gcSAbvWzJTCjRW e1l7zc8cIVAhBCXOZdzSF+d/cmblW0KH476CfMz5OKJjWLHMfVdWCq4kQ1qCpjZv/QhT7J9C8jot C0W1NDiyUAsIw6aUW1r5k3CZ8isxuGQElrx9bBk7EL4UZBVTUAXBWIPKOf7EBuHZw9iEqtr2H2kW ni2yDM6ZzC9pHMJyvLZ9+BIGovKzlOXgn2MspSJfMysuzUUgJcJSeR3WfJNiAfoaAlK+Yc3izso3 AJakRW50+a9CcmABJxSjv52uK0eeTRLWx8JHGSLLNgYsDwETSNvGT9d/+a9iC94flYW0wZ4cPVHJ RgEHOrtAFBQEAyIrXmROb5DxIDf811k0VmdecI7pncSlgaAU6HuJiXdqpRywa4ax1ucpbMpht32g kjwl/ZKg/VcKA8ddLM37esrnaRpmWVFlktnkimele9fiJGyfvc1haPRDIexqzxL3E25mUucxI17S TXpUFqnXaPnEq5stK6X85hR5y4nT3u73bZE4VcPdzKlbg18idVoqzavcKappuZ5vvzxJulWGK+r1 R95VJ245f0cyIsTHYH1/hRxtxXg/SbueClbkWyx1oczDBjrjZ1UDymGaKq5L9TVGXG0k6A0//la6 8Rvbnj0z5LUTJXT3mmU03wtDgctvJQNMtwRpjRLkMTEc0Cq7iT+8G2sdGHIut569WaDr8RRi1Rue oXYTM2U8AsRMRXwi3mXEYqBnNuUzph8unj700UKw9LXAkuEy1UkeXzrIbf2i5bbt1on80grqHspC VoESN59XwhGPLe0OwbCuSq8EZPVZAA3vWq8Egw/N+MpzXurLJJCsOm3nZuweP/LW+KC7K08GowEd hEhnxXXqfM8Jk1IY5XnaFyVg8yzHyzcfDifbEq15kXQ4vsUaBfUxTVNVvdHPRDw5mE0tEyDdGRU6 VLCpB1iBJsmKLGW4G3VZTnADzCN88lSAbdpKUHZPamFgifbEOUWYAC/KL0XdSkwt3OyhZFD9GBtw as0y/ikS5ySNBXVmhFHWpfxuFP4cj8SjT7qj2IROJIgn5rT7uyhLQKTsMBiiiUgOk4O4CA4MM1TY W3oXbgGi5gsDPDzleQk2zNKJdbJBPA8Aozv81kJCXP73sGQyNyY+CJ3UkRMbyRKEinwPLEVMfJ4W 7FU6SwYHqKu4Ld7Ff9Tr+HqdKFsh8loyhdDVNqsstuW1fhUzGCewZ/mzmME1bsL/txX82lZQiztd g0TfuCYOVR6A2IgvV1Nvnz6orVnX4P0x5vnflnEZy2h4urJhfDAzFEhAmHM82vLluAPF9fR5fAMm sSrTs3i+xZ9yQmODL/eoLMW4Fqc6GVC2yk738pbRyQVVXCisDwqqy3AUiNXvM15hpDg1NmfKx9Km b839BhS9WkOg0vmD+839tr9rRowYfSklnlXVb0qZVy8zOsKMNyL6WXwxRD1/0FS+k3Bc9Ztjlkg9 LusNl/NhwsSVM9ZvE/NanNZ2lfMqWyJlaXXCmdLpNggteZXGU2e02XPxlm3nU3T3BaSG6kIrCM1x Xs1CumwnUblZ2Dr/cWJWeST8zyRkX0o+Ns+qklTQ9xUmd8jIXH49heRdoET8wIwNMnOp73z60rws B5h/MlaWPgEvQW9TiDovLokClhhCJ/XKvzFvD7CNc4OUsNtdZgunv4BLIP2QXFabJBsBz6Av2iQF REWganuCQykCfh1kDSJ7nMWbFw7EjdN08yx+CXByDaSgd2TZNAVqrTmTzUP/G88ELzi16u9AW0N6 vRXlspJKdbF6rM6h4Gt7+zvUG++i68+yDO/Ocs4r4JBVZ7csTjfwFWxWhl+0uClv2eYevd3Gxm0d 8ylVp76KSP8PUEsBAhQAFAAAAAgAGpEVK24J+7DhGQAAP38AABcAAAAAAAAAAQAgALaBAAAAAExv Z2luUmVmZXJlbmNlTW9kZWwuY3BwUEsFBgAAAAABAAEARQAAABYaAAAAAA== --------------74CD8CFEB20A8BAE3D14CE79-- From owner-ips@ece.cmu.edu Tue Feb 26 00:24: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 AAA10763 for ; Tue, 26 Feb 2002 00:24:46 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1Q4bx317237 for ips-outgoing; Mon, 25 Feb 2002 23:37:59 -0500 (EST) 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 g1Q4bvH17232 for ; Mon, 25 Feb 2002 23:37:57 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id FAA67630 for ; Tue, 26 Feb 2002 05:37:50 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1Q4dgJ57560 for ; Tue, 26 Feb 2002 05:39:43 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iscsi : T bit MUST be 1 on a login reject response ? X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 26 Feb 2002 06:39:39 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 26/02/2002 06:39:43, Serialize complete at 26/02/2002 06:39:43 Content-Type: multipart/alternative; boundary="=_alternative 001854FFC2256B6C_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001854FFC2256B6C_= Content-Type: text/plain; charset="us-ascii" just a vestige - I've fixed it. No need for T to be set. Julo Santosh Rao Sent by: owner-ips@ece.cmu.edu 25-02-02 22:25 To: IPS Reflector cc: Subject: iscsi : T bit MUST be 1 on a login reject response ? Hello, Why does the spec require that the T bit MUST be set to 1 when a target responds to a login request with a login reject response ? On a login reject response (non-zero status class), the initiator does not need to look at any field other than the status detail. That being the case, why the need to enfore (MUST set) the T bit to 1 ? - Santosh -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## --=_alternative 001854FFC2256B6C_= Content-Type: text/html; charset="us-ascii"
just a vestige - I've fixed it. No need for T to be set.  Julo


Santosh Rao <santoshr@cup.hp.com>
Sent by: owner-ips@ece.cmu.edu

25-02-02 22:25

       
        To:        IPS Reflector <ips@ece.cmu.edu>
        cc:        
        Subject:        iscsi : T bit MUST be 1 on a login reject response ?

       


Hello,

Why does the spec require that the T bit MUST be set to 1 when a target
responds to a login request with a login reject response ?

On a login reject response (non-zero status class), the initiator does
not need to look at any field other than the status detail. That being
the case, why the need to enfore (MUST set) the T bit to 1 ?

- Santosh

--
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
##################################

--=_alternative 001854FFC2256B6C_=-- From owner-ips@ece.cmu.edu Tue Feb 26 01:44: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 BAA11526 for ; Tue, 26 Feb 2002 01:44:51 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1Q5uTx21285 for ips-outgoing; Tue, 26 Feb 2002 00:56:29 -0500 (EST) 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 g1Q5uRH21281 for ; Tue, 26 Feb 2002 00:56:27 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.us.ibm.com [9.99.140.23]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id AAA67214; Tue, 26 Feb 2002 00:53:11 -0500 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1Q5uPK50202; Mon, 25 Feb 2002 22:56:25 -0700 X-Priority: 1 (High) Importance: Normal Subject: Re: Login Proposal To: Subrahmanya Sastry K V Cc: "'ips@ece.cmu.edu'" , "'Julian Satran'" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Mon, 25 Feb 2002 21:55:31 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 02/25/2002 10:56:25 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I do not see why this is needed, almost everyone has moved on from v0.7, and we have overtly left boot sessions, and copy manager session behind. Everyone I talked to at the last plugfest got through login without a significant issue. This seems a bit strange to bring this up now. . . . 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 Subrahmanya Sastry K V @ece.cmu.edu on 02/25/2002 08:04:13 PM Sent by: owner-ips@ece.cmu.edu To: "'ips@ece.cmu.edu'" , "'Julian Satran'" cc: Subject: Login Proposal The recent plugfest highlighted areas of the login procedure that could be improved. With this in mind, Bob Russell, Marjorie Krueger, and myself have been working on a proposal for the Login procedure. Our goals were to keep it inline as much as possible with 0.7 of the specification and to ensure connectivity can be maintained amongst target and initiators. I believe we have meet all the goals we set out to do. I have also attached a Login Reference Model (in the form of c code) which backs up our proposal. Please note that the reference model is only a reference model and should not be considered as, or be part of the iSCSI specification. Cheers Matthew Burbridge Marjorie Krueger Bob Russell ++++++++++++++++++++++++ The Login Proposal: Definitions: FBit means "I have nothing (more) to negotiate" Request: The first occurrence of a Text Parameter from the initiator or the target. A request MUST be answered with a reply. Reply: A Text Parameter that is a response to a Request. Negotiation: A request followed by a response. 1.1 Actions at the Initiator The initiator starts the login phase by sending a Login Command PDU. The IIN MUST be present in the login command. The SessionType MUST be present if the session type is Discovery, Boot or CopyManager. It MAY be present if SessionType=Normal. The ITN MUST be present unless SessionType=Discovery when it is optional. The initiator MUST NOT send operational text parameters in the login command. The table below defines the parameter present in the login command. SessionType SessionType IIN ITN Present in Present in Present in Login? Login? Login? Normal Optional Yes Yes Boot Yes Yes Yes CopyManager Yes Yes Yes Discovery Yes Yes Optional SecurityContextComplete=yes MUST NOT be present in the login command Operational Parameters MUST NOT be present in the login command At anytime the initiator MAY terminate the login killing the TCP connection. If the initiator requires security negotiation it MUST send one or more security parameters: (AuthMethod, HeaderDigest, DataDigest) in the login command. Fbit Security Parameters Description Present 0 No Initiator has no security parameters to negotiate but has operational parameters to negotiate. 0 Yes The initiator wants to negotiate security. 1 No The initiator has no security parameters to negotiate and no operational parameters to negotiate. 1 Yes ILLEGAL. Target must reject login (Login Status = 0200) 1.2 Actions at the Target On receipt of the Login Command the target MUST respond according to the rules below: If the InitiatorName is not present the target MUST reject the login by sending a Login Response with FBit=1 and StatusCode=0200. Similary, if the SessionType is not Discovery and the TargetName is not present the target MUST reject the login by sending a Login Response with FBit=1 and StatusCode=0200. It both cases the target should kill the TCP connection after the login response has successfully been sent. At anytime the target MAY terminate the login by sending a login response with the FBit set to 1 and a non-zero StatusCode. The target should kill the TCP connection after the login response has successfully been sent. If the login command contains security parameters, the target MUST enter the security phase of the login. It MUST send response to those security parameters and MAY start negotiating security parameters if the parameters that it wants to negotiate are not in the Login command. The target responses with a Text Response (F=0). If the login command does not contain security parameters the target MUST perform one of the two actions below: a) If the target requires security negotiation to be performed, then it MUST enter the security phase and MUST send a text response containing one or more security parameters and F=0. b) If the target does not require security negotiation (and therefore neither does the initiator) it MUST perform one of the actions defined by the table below. Initiator Target has Action FBit params to negotiate 0 No Send Text Response with F=1 (Initiator only wants to negotiate operational parameters). 0 Yes Send Text Response with operation params If all parameters can be sent in a single response then F=1 else F=0 (Both target and initiator want to negotiate operational parameters). 1 No Send Login Response with F=1. (Neither target nor initiator want to negotiate operational parameters). 1 Yes Send Text Response. If all parameters can be sent in a single response then F=1 else F=0 (Target only wants to negotiate operational parameters). 1.3 General Rules If an initiator or target has text parameters (security or operational) to negotiate then it MUST send them at the earliest opportunity and it MUST NOT send an empty text command. An initiator or target MUST respond to the a text parameter request with a text parameter response in the next text PDU to be sent. Once an initiator or target has completed initiating negotiations (security or operational) it MUST not initiate any more of the same type (security or operational). In other words it can not go backwards. Operational Parameters MUST NOT be negotiated during the security phase. Security Parameters MUST NOT be negotiated during the operartional phase. When a party has no more text parameters to negotiate then the FBit MUST be set in the PDU containing the last text parameter request and all subsequent PDUs. For example: if an initiator only wants to negotiate "InitialR2T=yes" and no others, then it MUST set the FBit to 1 in the commands containing "InitialR2T=yes". Once the FBit has been set to 1, it MUST not be set back to 0. Also, if the FBit is 1 then the party MUST not instigate anymore text parameter negotiations. It can only respond to requests from the other party. If FMarker=yes then SFMarkInt and RFMarkInt MUST be present in the same Text PDU as FMarker=yes. If FMarker=no then SHOULD NOT be present. If they are then the remote party MUST reply to them and echo the values sent in the initial PDU. 1.4 Completion of Security Phase [Authors note: This section has been extracted from v0.7 but I have made some clarifications to the version 0.7 spec. - Changes in CAPITALS] -Every party in the security negotiation MUST [Added MUST] indicate that it has completed building its security context (has all the required information) by sending the key=value pair: SecurityContextComplete=yes The other party either offers some more SECURITY parameters or answers with the same: SecurityContextComplete=yes The party that is ready MUST [Added MUST] keep sending the SecurityContextComplete=yes pair (in addition to new security Parameter REPLYS if required) until the handshake is complete. Once the party has set SecurityContextComplete=yes it MUST not instigate anymore negotiations but it MUST respond to any requests from the other pary. If the initiator has been the last to complete the SECUIRTY PHASE it MUST NOT start sending operational parameters within the same text command; a text response including only SecurityContextComplete=yes concludes the security sub-phase. If the target has been the last to complete the SECURITY PHASE, the initiator can start the operational parameter negotiation with the next text command; the security negotiation sub-phase ends with the target text response. The SecurityContextComplete handshake MUST be performed if any of negotiating parties has offered a security/integrity item (even if it is not selected). All PDUs sent after the security negotiation sub phase MUST be built using the agreed security. This proposal removes from 0.7 of the spec: Partial Login response: It no longer coveys any information. OpParamReset: No longer required as operational parameters can not be negotiated during security phase. Keep: SecurityContextComplete=yes. This is how 0.7 works. If people disagree then we can vote and change it. Matthew Burbridge Senior Development Engineer NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com From owner-ips@ece.cmu.edu Tue Feb 26 01:45: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 BAA11539 for ; Tue, 26 Feb 2002 01:45:08 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1Q6HMj22269 for ips-outgoing; Tue, 26 Feb 2002 01:17:22 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailnpd.hcltech.com ([203.197.145.76]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g1Q6HJH22262 for ; Tue, 26 Feb 2002 01:17:20 -0500 (EST) Received: from npd.hcltech.com (skotra-pc.hcltech.com [192.168.100.57]) by mailnpd.hcltech.com (8.11.0/8.11.0) with ESMTP id g1Q68wm24330 for ; Tue, 26 Feb 2002 11:38:58 +0530 Message-ID: <3C7B28A9.6CDB1569@npd.hcltech.com> Date: Tue, 26 Feb 2002 11:48:17 +0530 From: Subrahmanya Sastry K V Organization: HCL Technologies X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Please ignore the previous mail with subject line : "Login Proposal" Content-Type: multipart/alternative; boundary="------------9E1FD2973990A693E7448AAA" Sender: owner-ips@ece.cmu.edu Precedence: bulk --------------9E1FD2973990A693E7448AAA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I have sent out an old mail accidentally to the group alias, while reading the contents of it. I apologize for the inconvenience caused . Please ignore that mail. With best regards, Sastry http://san.hcltech.com -- Subrahmanya Sastry K V Member Technical Staff HCLTech, Chennai, INDIA --------------9E1FD2973990A693E7448AAA Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 

Hello, 

I have sent out an old mail accidentally to the group alias, 
while reading the contents of it. I apologize for the inconvenience 
caused . Please ignore that mail. 

With best regards, 
Sastry 
http://san.hcltech.com
-- 
Subrahmanya Sastry K V
Member Technical Staff
HCLTech, Chennai, INDIA --------------9E1FD2973990A693E7448AAA-- From owner-ips@ece.cmu.edu Tue Feb 26 04:32: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 EAA21556 for ; Tue, 26 Feb 2002 04:32:14 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1Q8p2v29358 for ips-outgoing; Tue, 26 Feb 2002 03:51:02 -0500 (EST) 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 g1Q8p1H29352 for ; Tue, 26 Feb 2002 03:51:01 -0500 (EST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.us.ibm.com [9.99.140.24]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id DAA57978 for ; Tue, 26 Feb 2002 03:47:45 -0500 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay03.boulder.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1Q8oxV102466 for ; Tue, 26 Feb 2002 01:50:59 -0700 X-Priority: 1 (High) Importance: Normal Subject: iSCSI: Residual stuff in 10-92 To: "Julian Satran" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Tue, 26 Feb 2002 00:50:05 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 02/26/2002 01:50:59 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, Section 9.12.9 has some residual "x" commentary. . . . 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 Tue Feb 26 09: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 JAA00763 for ; Tue, 26 Feb 2002 09:19:32 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1QD9ZC21376 for ips-outgoing; Tue, 26 Feb 2002 08:09:35 -0500 (EST) 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 g1QD9XH21368 for ; Tue, 26 Feb 2002 08:09:33 -0500 (EST) 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 9FD86EE; Tue, 26 Feb 2002 14:09:27 +0100 (MET) Received: from 15.145.8.186 by fowey.BR.ITC.HP.COM (InterScan E-Mail VirusWall NT); Tue, 26 Feb 2002 13:09:27 -0000 (GMT Standard Time) Received: by fowey.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Feb 2002 13:09:27 -0000 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC104FF1DFC@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'John Hufferd'" , Subrahmanya Sastry K V Cc: "'ips@ece.cmu.edu'" , "'Julian Satran'" Subject: RE: Login Proposal Date: Tue, 26 Feb 2002 13:09:25 -0000 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 Subrahmanya, I can only presume that you sent this by mistake. If you have any other reasons please can you explain them. As John mentioned this is very old stuff. Cheers Matthew Burbridge -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Tuesday, February 26, 2002 12:56 AM To: Subrahmanya Sastry K V Cc: 'ips@ece.cmu.edu'; 'Julian Satran' Subject: Re: Login Proposal I do not see why this is needed, almost everyone has moved on from v0.7, and we have overtly left boot sessions, and copy manager session behind. Everyone I talked to at the last plugfest got through login without a significant issue. This seems a bit strange to bring this up now. . . . 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 Subrahmanya Sastry K V @ece.cmu.edu on 02/25/2002 08:04:13 PM Sent by: owner-ips@ece.cmu.edu To: "'ips@ece.cmu.edu'" , "'Julian Satran'" cc: Subject: Login Proposal The recent plugfest highlighted areas of the login procedure that could be improved. With this in mind, Bob Russell, Marjorie Krueger, and myself have been working on a proposal for the Login procedure. Our goals were to keep it inline as much as possible with 0.7 of the specification and to ensure connectivity can be maintained amongst target and initiators. I believe we have meet all the goals we set out to do. I have also attached a Login Reference Model (in the form of c code) which backs up our proposal. Please note that the reference model is only a reference model and should not be considered as, or be part of the iSCSI specification. Cheers Matthew Burbridge Marjorie Krueger Bob Russell ++++++++++++++++++++++++ The Login Proposal: Definitions: FBit means "I have nothing (more) to negotiate" Request: The first occurrence of a Text Parameter from the initiator or the target. A request MUST be answered with a reply. Reply: A Text Parameter that is a response to a Request. Negotiation: A request followed by a response. 1.1 Actions at the Initiator The initiator starts the login phase by sending a Login Command PDU. The IIN MUST be present in the login command. The SessionType MUST be present if the session type is Discovery, Boot or CopyManager. It MAY be present if SessionType=Normal. The ITN MUST be present unless SessionType=Discovery when it is optional. The initiator MUST NOT send operational text parameters in the login command. The table below defines the parameter present in the login command. SessionType SessionType IIN ITN Present in Present in Present in Login? Login? Login? Normal Optional Yes Yes Boot Yes Yes Yes CopyManager Yes Yes Yes Discovery Yes Yes Optional SecurityContextComplete=yes MUST NOT be present in the login command Operational Parameters MUST NOT be present in the login command At anytime the initiator MAY terminate the login killing the TCP connection. If the initiator requires security negotiation it MUST send one or more security parameters: (AuthMethod, HeaderDigest, DataDigest) in the login command. Fbit Security Parameters Description Present 0 No Initiator has no security parameters to negotiate but has operational parameters to negotiate. 0 Yes The initiator wants to negotiate security. 1 No The initiator has no security parameters to negotiate and no operational parameters to negotiate. 1 Yes ILLEGAL. Target must reject login (Login Status = 0200) 1.2 Actions at the Target On receipt of the Login Command the target MUST respond according to the rules below: If the InitiatorName is not present the target MUST reject the login by sending a Login Response with FBit=1 and StatusCode=0200. Similary, if the SessionType is not Discovery and the TargetName is not present the target MUST reject the login by sending a Login Response with FBit=1 and StatusCode=0200. It both cases the target should kill the TCP connection after the login response has successfully been sent. At anytime the target MAY terminate the login by sending a login response with the FBit set to 1 and a non-zero StatusCode. The target should kill the TCP connection after the login response has successfully been sent. If the login command contains security parameters, the target MUST enter the security phase of the login. It MUST send response to those security parameters and MAY start negotiating security parameters if the parameters that it wants to negotiate are not in the Login command. The target responses with a Text Response (F=0). If the login command does not contain security parameters the target MUST perform one of the two actions below: a) If the target requires security negotiation to be performed, then it MUST enter the security phase and MUST send a text response containing one or more security parameters and F=0. b) If the target does not require security negotiation (and therefore neither does the initiator) it MUST perform one of the actions defined by the table below. Initiator Target has Action FBit params to negotiate 0 No Send Text Response with F=1 (Initiator only wants to negotiate operational parameters). 0 Yes Send Text Response with operation params If all parameters can be sent in a single response then F=1 else F=0 (Both target and initiator want to negotiate operational parameters). 1 No Send Login Response with F=1. (Neither target nor initiator want to negotiate operational parameters). 1 Yes Send Text Response. If all parameters can be sent in a single response then F=1 else F=0 (Target only wants to negotiate operational parameters). 1.3 General Rules If an initiator or target has text parameters (security or operational) to negotiate then it MUST send them at the earliest opportunity and it MUST NOT send an empty text command. An initiator or target MUST respond to the a text parameter request with a text parameter response in the next text PDU to be sent. Once an initiator or target has completed initiating negotiations (security or operational) it MUST not initiate any more of the same type (security or operational). In other words it can not go backwards. Operational Parameters MUST NOT be negotiated during the security phase. Security Parameters MUST NOT be negotiated during the operartional phase. When a party has no more text parameters to negotiate then the FBit MUST be set in the PDU containing the last text parameter request and all subsequent PDUs. For example: if an initiator only wants to negotiate "InitialR2T=yes" and no others, then it MUST set the FBit to 1 in the commands containing "InitialR2T=yes". Once the FBit has been set to 1, it MUST not be set back to 0. Also, if the FBit is 1 then the party MUST not instigate anymore text parameter negotiations. It can only respond to requests from the other party. If FMarker=yes then SFMarkInt and RFMarkInt MUST be present in the same Text PDU as FMarker=yes. If FMarker=no then SHOULD NOT be present. If they are then the remote party MUST reply to them and echo the values sent in the initial PDU. 1.4 Completion of Security Phase [Authors note: This section has been extracted from v0.7 but I have made some clarifications to the version 0.7 spec. - Changes in CAPITALS] -Every party in the security negotiation MUST [Added MUST] indicate that it has completed building its security context (has all the required information) by sending the key=value pair: SecurityContextComplete=yes The other party either offers some more SECURITY parameters or answers with the same: SecurityContextComplete=yes The party that is ready MUST [Added MUST] keep sending the SecurityContextComplete=yes pair (in addition to new security Parameter REPLYS if required) until the handshake is complete. Once the party has set SecurityContextComplete=yes it MUST not instigate anymore negotiations but it MUST respond to any requests from the other pary. If the initiator has been the last to complete the SECUIRTY PHASE it MUST NOT start sending operational parameters within the same text command; a text response including only SecurityContextComplete=yes concludes the security sub-phase. If the target has been the last to complete the SECURITY PHASE, the initiator can start the operational parameter negotiation with the next text command; the security negotiation sub-phase ends with the target text response. The SecurityContextComplete handshake MUST be performed if any of negotiating parties has offered a security/integrity item (even if it is not selected). All PDUs sent after the security negotiation sub phase MUST be built using the agreed security. This proposal removes from 0.7 of the spec: Partial Login response: It no longer coveys any information. OpParamReset: No longer required as operational parameters can not be negotiated during security phase. Keep: SecurityContextComplete=yes. This is how 0.7 works. If people disagree then we can vote and change it. Matthew Burbridge Senior Development Engineer NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com From owner-ips@ece.cmu.edu Tue Feb 26 13:31: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 NAA14958 for ; Tue, 26 Feb 2002 13:31:50 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1QHVKC11721 for ips-outgoing; Tue, 26 Feb 2002 12:31:20 -0500 (EST) 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 g1QHVDH11711 for ; Tue, 26 Feb 2002 12:31:13 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id SAA55140 for ; Tue, 26 Feb 2002 18:31:07 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1QHWoK102794 for ; Tue, 26 Feb 2002 18:32:50 +0100 To: "John Hufferd" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: Residual stuff in 10-92 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 26 Feb 2002 19:32:54 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 26/02/2002 19:32:59, Serialize complete at 26/02/2002 19:32:59 Content-Type: multipart/alternative; boundary="=_alternative 005F8E15C2256B6C_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005F8E15C2256B6C_= Content-Type: text/plain; charset="us-ascii" thanks - julo John Hufferd@IBMUS 26-02-02 10:50 To: Julian Satran/Haifa/IBM@IBMIL@IBMDE cc: ips@ece.cmu.edu From: John Hufferd/San Jose/IBM@IBMUS Subject: iSCSI: Residual stuff in 10-92 Julian, Section 9.12.9 has some residual "x" commentary. . . . 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 --=_alternative 005F8E15C2256B6C_= Content-Type: text/html; charset="us-ascii"
thanks - julo


John Hufferd@IBMUS

26-02-02 10:50

       
        To:        Julian Satran/Haifa/IBM@IBMIL@IBMDE
        cc:        ips@ece.cmu.edu
        From:        John Hufferd/San Jose/IBM@IBMUS
        Subject:        iSCSI: Residual stuff in 10-92

       


Julian,
Section 9.12.9 has some residual "x" commentary.

.
.
.
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

--=_alternative 005F8E15C2256B6C_=-- From owner-ips@ece.cmu.edu Tue Feb 26 17:35: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 RAA23732 for ; Tue, 26 Feb 2002 17:35:04 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1QLpGU04232 for ips-outgoing; Tue, 26 Feb 2002 16:51:16 -0500 (EST) 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 g1QLpDH04226 for ; Tue, 26 Feb 2002 16:51:13 -0500 (EST) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g1QLp3024537 for ; Tue, 26 Feb 2002 16:51:03 -0500 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 g1QLowK24531 for ; Tue, 26 Feb 2002 16:50:58 -0500 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with SMTP id g1QLowo12158 for ; Tue, 26 Feb 2002 16:50:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15484.834.482742.117582@pkoning.dev.equallogic.com> Date: Tue, 26 Feb 2002 16:50:58 -0500 From: Paul Koning To: ips@ece.cmu.edu Subject: sector alignment for DataOut PDUs? 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 In the past, a number of login parameters were specified as multiples of 512 bytes, which makes a lot of sense for disk targets (but not so much for tape targets). With the spec as it stands now, you can negotiate pretty much arbitrary burst sizes etc. And in any case, the sender can pick "strange" PDU sizes even if the negotiated sizes are multiples of 512, because after all those are limits, not required sizes. It would be very attractive for disk targets to be able to specify that they require DataOut PDUs to be multiples of 512 bytes in length. That way, any PDU would correspond exactly to one or more sectors, rather than potentially having several PDUs straddling sector boundaries as is currently permitted. This could be done by a Boolean key (512 byte alignment, yes or no). (An integer key would allow other values than 512, but I'm not sure that such flexibility is a whole lot more useful.) Basically, the effect of this feature would be to tell the initiator that it must send DataOut PDUs and immediate data whose length is always a multiple of 512. Obviously, targets can't ask for that unless the devices on that target already come with such a limitation. paul From owner-ips@ece.cmu.edu Tue Feb 26 18:35: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 SAA25032 for ; Tue, 26 Feb 2002 18:35:32 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1QN5A909575 for ips-outgoing; Tue, 26 Feb 2002 18:05:10 -0500 (EST) 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 g1QN56H09568 for ; Tue, 26 Feb 2002 18:05:06 -0500 (EST) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g1QN50025033 for ; Tue, 26 Feb 2002 18:05:00 -0500 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 g1QN4xK25024; Tue, 26 Feb 2002 18:04:59 -0500 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with SMTP id g1QN4xo17295; Tue, 26 Feb 2002 18:04:59 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15484.5275.85076.131689@pkoning.dev.equallogic.com> Date: Tue, 26 Feb 2002 18:04:59 -0500 From: Paul Koning To: rod.harrison@windriver.com Cc: ips@ece.cmu.edu Subject: RE: sector alignment for DataOut PDUs? References: <15484.834.482742.117582@pkoning.dev.equallogic.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 >>>>> "Rod" == Rod Harrison writes: Rod> I have no objection in principle to this but I have a concern Rod> over non-media access commands. Things like mode select Rod> payloads, i.e. defect lists etc are not necessarily 512 byte Rod> multiples. The wording would need to allow "odd" sizes when the Rod> SCSI transfer length is not a 512 byte multiple. Are those DataOut or DataIn? The target can arrange inbound PDU sizes to be whatever multiple is helpful if it wants to, that isn't the case I was talking about. In any case, if there are cases where the total transfer length for data out isn't a multiple of 512, then the rule would have to allow the last transfer to have an odd length. The earlier transfers could still be constrained if the constraint is enabled. paul From owner-ips@ece.cmu.edu Tue Feb 26 18: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 SAA25145 for ; Tue, 26 Feb 2002 18:40:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1QMjYN08381 for ips-outgoing; Tue, 26 Feb 2002 17:45:34 -0500 (EST) 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 g1QMjMH08370 for ; Tue, 26 Feb 2002 17:45:22 -0500 (EST) Received: from london ([10.95.10.3]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id OAA01182; Tue, 26 Feb 2002 14:44:56 -0800 (PST) From: "Rod Harrison" To: "Paul Koning" , Subject: RE: sector alignment for DataOut PDUs? Date: Tue, 26 Feb 2002 22:44:43 -0000 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: <15484.834.482742.117582@pkoning.dev.equallogic.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I have no objection in principle to this but I have a concern over non-media access commands. Things like mode select payloads, i.e. defect lists etc are not necessarily 512 byte multiples. The wording would need to allow "odd" sizes when the SCSI transfer length is not a 512 byte multiple. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Paul Koning Sent: Tuesday, February 26, 2002 9:51 PM To: ips@ece.cmu.edu Subject: sector alignment for DataOut PDUs? In the past, a number of login parameters were specified as multiples of 512 bytes, which makes a lot of sense for disk targets (but not so much for tape targets). With the spec as it stands now, you can negotiate pretty much arbitrary burst sizes etc. And in any case, the sender can pick "strange" PDU sizes even if the negotiated sizes are multiples of 512, because after all those are limits, not required sizes. It would be very attractive for disk targets to be able to specify that they require DataOut PDUs to be multiples of 512 bytes in length. That way, any PDU would correspond exactly to one or more sectors, rather than potentially having several PDUs straddling sector boundaries as is currently permitted. This could be done by a Boolean key (512 byte alignment, yes or no). (An integer key would allow other values than 512, but I'm not sure that such flexibility is a whole lot more useful.) Basically, the effect of this feature would be to tell the initiator that it must send DataOut PDUs and immediate data whose length is always a multiple of 512. Obviously, targets can't ask for that unless the devices on that target already come with such a limitation. paul From owner-ips@ece.cmu.edu Tue Feb 26 19:36: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 TAA26410 for ; Tue, 26 Feb 2002 19:36:32 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1QNpOO12268 for ips-outgoing; Tue, 26 Feb 2002 18:51:24 -0500 (EST) 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 g1QNpMH12264 for ; Tue, 26 Feb 2002 18:51:22 -0500 (EST) Received: from london ([10.95.10.3]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id PAA12405; Tue, 26 Feb 2002 15:51:00 -0800 (PST) From: "Rod Harrison" To: "Paul Koning" Cc: Subject: RE: sector alignment for DataOut PDUs? Date: Tue, 26 Feb 2002 23:50:47 -0000 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: <15484.5275.85076.131689@pkoning.dev.equallogic.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I was talking about DATA-OUT PDUs. I would suggest we also restrict any target that wants to negotiate for the 512 byte DATA-OUT option to not doing anything weird with FirstBurstSize or MaxRecvPDULength. I think it would unreasonable to allow a target to require 512 byte aligned DATA-OUTs and have those other two parameters not multiples of 512 bytes. How do we handle the case where the iSCSI target node has multiple LUNs and not all of them are disks? Perhaps the rule for transfers lengths that are not multiples of 512 bytes works OK here? Also, I think we should consider making the "alignment" any multiple of 512 the target wants, not just 512. Otherwise it seems to me you are back where you started if you have a disk with 4096 byte sectors and the initiator chooses to send you DATA-OUT PDUs that are not a multiple of 4k. - Rod -----Original Message----- From: Paul Koning [mailto:ni1d@arrl.net] Sent: Tuesday, February 26, 2002 11:05 PM To: rod.harrison@windriver.com Cc: ips@ece.cmu.edu Subject: RE: sector alignment for DataOut PDUs? >>>>> "Rod" == Rod Harrison writes: Rod> I have no objection in principle to this but I have a concern Rod> over non-media access commands. Things like mode select Rod> payloads, i.e. defect lists etc are not necessarily 512 byte Rod> multiples. The wording would need to allow "odd" sizes when the Rod> SCSI transfer length is not a 512 byte multiple. Are those DataOut or DataIn? The target can arrange inbound PDU sizes to be whatever multiple is helpful if it wants to, that isn't the case I was talking about. In any case, if there are cases where the total transfer length for data out isn't a multiple of 512, then the rule would have to allow the last transfer to have an odd length. The earlier transfers could still be constrained if the constraint is enabled. paul From owner-ips@ece.cmu.edu Tue Feb 26 19:38: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 TAA26427 for ; Tue, 26 Feb 2002 19:38:34 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1R0EaK13623 for ips-outgoing; Tue, 26 Feb 2002 19:14:36 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1R0EZH13619 for ; Tue, 26 Feb 2002 19:14:35 -0500 (EST) Received: from cceexg11.americas.cpqcorp.net (cceexg11.americas.cpqcorp.net [16.110.250.125]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 730D33F32; Tue, 26 Feb 2002 18:14:29 -0600 (CST) Received: from cceexc18.americas.cpqcorp.net ([16.110.250.64]) by cceexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 26 Feb 2002 18:14:29 -0600 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: sector alignment for DataOut PDUs? Date: Tue, 26 Feb 2002 18:14:28 -0600 Message-ID: <31891B757C09184BBFEC5275F85D5595104E3F@cceexc18.americas.cpqcorp.net> Thread-Topic: sector alignment for DataOut PDUs? Thread-Index: AcG/EFW/8g91vwbKRVqdXqPorv1DtQAC7sjA From: "Martin, Nick" To: "Paul Koning" , X-OriginalArrivalTime: 27 Feb 2002 00:14:29.0290 (UTC) FILETIME=[B91360A0:01C1BF23] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g1R0EZH13620 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Paul, For all data carrying PDUs except the last in a sequence, the sender is expected to send maximum sized PDU allowed. When the negotiated maximum is a multiple of 512, this effect is what you request. I thought this was a requirement, but I did not find it as such in draft 10. I did find this: : 8.5 Unsolicited Data and Performance : Unsolicited data on write are meant to reduce the effect of latency on : throughput (no R2T is needed to start sending data). In addition, : immediate data are meant to reduce the protocol overhead (both bandwidth : and execution time). : However, negotiating an amount of unsolicited data for writes and : sending less than the negotiated amount when the total data amount to : be sent by a command is larger than the negotiated amount may negatively : impact performance and may not be supported by all the targets. This is a warning that an initiator sending less than the negotiated maximum when the expected data transfer is greater than the maximum a) may reduce performance and b) may not be supported by all targets. IMHO, it makes more sense to include stronger wording encouraging maximum negotiated length transfers rather than to add another parameter requiring PDU breaks on different boundaries. If such initiator behavior may not be supported by all targets, then the initiators SHOULD NOT do it. A disk target which can not handle such behavior is forgiven in advance ;). Thanks, Nick > -----Original Message----- > From: Paul Koning [mailto:ni1d@arrl.net] > Sent: Tuesday, February 26, 2002 3:51 PM > To: ips@ece.cmu.edu > Subject: sector alignment for DataOut PDUs? > > > In the past, a number of login parameters were specified as multiples > of 512 bytes, which makes a lot of sense for disk targets (but not so > much for tape targets). With the spec as it stands now, you can > negotiate pretty much arbitrary burst sizes etc. And in any case, the > sender can pick "strange" PDU sizes even if the negotiated sizes are > multiples of 512, because after all those are limits, not required > sizes. > > It would be very attractive for disk targets to be able to specify > that they require DataOut PDUs to be multiples of 512 bytes in length. > That way, any PDU would correspond exactly to one or more sectors, > rather than potentially having several PDUs straddling sector > boundaries as is currently permitted. This could be done by a Boolean > key (512 byte alignment, yes or no). (An integer key would allow > other values than 512, but I'm not sure that such flexibility is a > whole lot more useful.) > > Basically, the effect of this feature would be to tell the initiator > that it must send DataOut PDUs and immediate data whose length is > always a multiple of 512. Obviously, targets can't ask for that > unless the devices on that target already come with such a limitation. > > paul > > From owner-ips@ece.cmu.edu Tue Feb 26 22:07: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 WAA29474 for ; Tue, 26 Feb 2002 22:07:16 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1R297k19887 for ips-outgoing; Tue, 26 Feb 2002 21:09:07 -0500 (EST) 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 g1R293H19878 for ; Tue, 26 Feb 2002 21:09:04 -0500 (EST) Received: from london ([10.95.10.3]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id SAA07800; Tue, 26 Feb 2002 18:08:40 -0800 (PST) From: "Rod Harrison" To: "Martin, Nick" , "Paul Koning" , Subject: RE: sector alignment for DataOut PDUs? Date: Wed, 27 Feb 2002 02:08:27 -0000 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: <31891B757C09184BBFEC5275F85D5595104E3F@cceexc18.americas.cpqcorp.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Nick, This makes sense for unsolicited data but it doesn't stop the initiator sending more than one "weird" sized DATA-OUT PDU in response to an R2T, even if the R2T is for a multiple of 512 bytes. Strengthening the wording to make sending "full" PDUs a requirement is not really practical in the post v08 world where we don't have a negotiated PDU size. It would have made sense when the max PDU size was agreed upon but given the current scheme of allowing the receiver to name an arbitrary sized maximum receive PDU it would place an unreasonable burden on the initiator. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Martin, Nick Sent: Wednesday, February 27, 2002 12:14 AM To: Paul Koning; ips@ece.cmu.edu Subject: RE: sector alignment for DataOut PDUs? Paul, For all data carrying PDUs except the last in a sequence, the sender is expected to send maximum sized PDU allowed. When the negotiated maximum is a multiple of 512, this effect is what you request. I thought this was a requirement, but I did not find it as such in draft 10. I did find this: : 8.5 Unsolicited Data and Performance : Unsolicited data on write are meant to reduce the effect of latency on : throughput (no R2T is needed to start sending data). In addition, : immediate data are meant to reduce the protocol overhead (both bandwidth : and execution time). : However, negotiating an amount of unsolicited data for writes and : sending less than the negotiated amount when the total data amount to : be sent by a command is larger than the negotiated amount may negatively : impact performance and may not be supported by all the targets. This is a warning that an initiator sending less than the negotiated maximum when the expected data transfer is greater than the maximum a) may reduce performance and b) may not be supported by all targets. IMHO, it makes more sense to include stronger wording encouraging maximum negotiated length transfers rather than to add another parameter requiring PDU breaks on different boundaries. If such initiator behavior may not be supported by all targets, then the initiators SHOULD NOT do it. A disk target which can not handle such behavior is forgiven in advance ;). Thanks, Nick > -----Original Message----- > From: Paul Koning [mailto:ni1d@arrl.net] > Sent: Tuesday, February 26, 2002 3:51 PM > To: ips@ece.cmu.edu > Subject: sector alignment for DataOut PDUs? > > > In the past, a number of login parameters were specified as multiples > of 512 bytes, which makes a lot of sense for disk targets (but not so > much for tape targets). With the spec as it stands now, you can > negotiate pretty much arbitrary burst sizes etc. And in any case, the > sender can pick "strange" PDU sizes even if the negotiated sizes are > multiples of 512, because after all those are limits, not required > sizes. > > It would be very attractive for disk targets to be able to specify > that they require DataOut PDUs to be multiples of 512 bytes in length. > That way, any PDU would correspond exactly to one or more sectors, > rather than potentially having several PDUs straddling sector > boundaries as is currently permitted. This could be done by a Boolean > key (512 byte alignment, yes or no). (An integer key would allow > other values than 512, but I'm not sure that such flexibility is a > whole lot more useful.) > > Basically, the effect of this feature would be to tell the initiator > that it must send DataOut PDUs and immediate data whose length is > always a multiple of 512. Obviously, targets can't ask for that > unless the devices on that target already come with such a limitation. > > paul > > From owner-ips@ece.cmu.edu Wed Feb 27 01:10: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 BAA03833 for ; Wed, 27 Feb 2002 01:10:34 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1R5M9G00408 for ips-outgoing; Wed, 27 Feb 2002 00:22:09 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mc.va3.ummail.com (mc.va3.ummail.com [66.187.242.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1R5M7H00404 for ; Wed, 27 Feb 2002 00:22:07 -0500 (EST) Received: from hqmailweb.COMMSTOR.Crossroads.com (HQMailWeb.Crossroads.com [63.237.99.250:25]) by mc.va3.ummail.com with ESMTP id J0227-0021-3bad02; Wed, 27 Feb 2002 05:21:37 GMT Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Feb 2002 23:15:00 -0600 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: RE: sector alignment for DataOut PDUs? Date: Tue, 26 Feb 2002 23:15:00 -0600 Message-ID: Thread-Topic: sector alignment for DataOut PDUs? Thread-Index: AcG/J7t8qLU9lL7QRl+x5qr9R0828gAF9+EA From: "Buck Landry" To: "Rod Harrison" , "Paul Koning" Cc: X-OriginalArrivalTime: 27 Feb 2002 05:15:00.0439 (UTC) FILETIME=[B47A5E70:01C1BF4D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g1R5M7H00405 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit >>> Also, I think we should consider making the "alignment" any multiple of 512 the target wants <<< Well.. if we put no restrictions on it, and I decided my target should only handle one data-out pdu per scsi write cmd, I might abuse this and force an alignment of (512 * ReallyHugeNumber). This might demand more resources or complexity from the initiator than is wished for, although I can't think of any reasons off the top of my head (perhaps I should think harder). OTOH I am fully aware that the target is the entity that is supposed to be cheap n' easy to implement... Perhaps you could limit the alignment size by the target's MaxRecvPDULength? Or... I believe this "multiple-of" idea also needs to be reconciled with MaxBurstSize. If MaxBurstSize is negotiated by the initiator to 512 bytes, then by my understanding the target still must send 512-byte R2Ts for writes (and hence, expect 512-byte data-out pdus), even if the target's sector size is 4k. --buck -----Original Message----- From: Rod Harrison [mailto:rod.harrison@windriver.com] Sent: Tuesday, February 26, 2002 5:51 PM To: Paul Koning Cc: ips@ece.cmu.edu Subject: RE: sector alignment for DataOut PDUs? I was talking about DATA-OUT PDUs. I would suggest we also restrict any target that wants to negotiate for the 512 byte DATA-OUT option to not doing anything weird with FirstBurstSize or MaxRecvPDULength. I think it would unreasonable to allow a target to require 512 byte aligned DATA-OUTs and have those other two parameters not multiples of 512 bytes. How do we handle the case where the iSCSI target node has multiple LUNs and not all of them are disks? Perhaps the rule for transfers lengths that are not multiples of 512 bytes works OK here? Also, I think we should consider making the "alignment" any multiple of 512 the target wants, not just 512. Otherwise it seems to me you are back where you started if you have a disk with 4096 byte sectors and the initiator chooses to send you DATA-OUT PDUs that are not a multiple of 4k. - Rod -----Original Message----- From: Paul Koning [mailto:ni1d@arrl.net] Sent: Tuesday, February 26, 2002 11:05 PM To: rod.harrison@windriver.com Cc: ips@ece.cmu.edu Subject: RE: sector alignment for DataOut PDUs? >>>>> "Rod" == Rod Harrison writes: Rod> I have no objection in principle to this but I have a concern Rod> over non-media access commands. Things like mode select Rod> payloads, i.e. defect lists etc are not necessarily 512 byte Rod> multiples. The wording would need to allow "odd" sizes when the Rod> SCSI transfer length is not a 512 byte multiple. Are those DataOut or DataIn? The target can arrange inbound PDU sizes to be whatever multiple is helpful if it wants to, that isn't the case I was talking about. In any case, if there are cases where the total transfer length for data out isn't a multiple of 512, then the rule would have to allow the last transfer to have an odd length. The earlier transfers could still be constrained if the constraint is enabled. paul From owner-ips@ece.cmu.edu Wed Feb 27 12:38: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 MAA05367 for ; Wed, 27 Feb 2002 12:38:51 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1RGfkS17176 for ips-outgoing; Wed, 27 Feb 2002 11:41:46 -0500 (EST) 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 g1RGfgH17171 for ; Wed, 27 Feb 2002 11:41:43 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id <107NPLW6>; Wed, 27 Feb 2002 11:41:32 -0500 Message-ID: <25369470B6F0D41194820002B328BDD22F5611@ATLOPS> From: Eddy Quicksall To: Buck Landry , Rod Harrison , Paul Koning Cc: ips@ece.cmu.edu Subject: RE: sector alignment for DataOut PDUs? Date: Wed, 27 Feb 2002 11:41:31 -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 Given that the TCP issues of reassembly are so much more complicated than the concatenation issues necessary for target data alignment, is there really a problem here? If there is a problem, can someone explain that in more detail? Eddy -----Original Message----- From: Buck Landry [mailto:blandry@crossroads.com] Sent: Wednesday, February 27, 2002 12:15 AM To: Rod Harrison; Paul Koning Cc: ips@ece.cmu.edu Subject: RE: sector alignment for DataOut PDUs? >>> Also, I think we should consider making the "alignment" any multiple of 512 the target wants <<< Well.. if we put no restrictions on it, and I decided my target should only handle one data-out pdu per scsi write cmd, I might abuse this and force an alignment of (512 * ReallyHugeNumber). This might demand more resources or complexity from the initiator than is wished for, although I can't think of any reasons off the top of my head (perhaps I should think harder). OTOH I am fully aware that the target is the entity that is supposed to be cheap n' easy to implement... Perhaps you could limit the alignment size by the target's MaxRecvPDULength? Or... I believe this "multiple-of" idea also needs to be reconciled with MaxBurstSize. If MaxBurstSize is negotiated by the initiator to 512 bytes, then by my understanding the target still must send 512-byte R2Ts for writes (and hence, expect 512-byte data-out pdus), even if the target's sector size is 4k. --buck -----Original Message----- From: Rod Harrison [mailto:rod.harrison@windriver.com] Sent: Tuesday, February 26, 2002 5:51 PM To: Paul Koning Cc: ips@ece.cmu.edu Subject: RE: sector alignment for DataOut PDUs? I was talking about DATA-OUT PDUs. I would suggest we also restrict any target that wants to negotiate for the 512 byte DATA-OUT option to not doing anything weird with FirstBurstSize or MaxRecvPDULength. I think it would unreasonable to allow a target to require 512 byte aligned DATA-OUTs and have those other two parameters not multiples of 512 bytes. How do we handle the case where the iSCSI target node has multiple LUNs and not all of them are disks? Perhaps the rule for transfers lengths that are not multiples of 512 bytes works OK here? Also, I think we should consider making the "alignment" any multiple of 512 the target wants, not just 512. Otherwise it seems to me you are back where you started if you have a disk with 4096 byte sectors and the initiator chooses to send you DATA-OUT PDUs that are not a multiple of 4k. - Rod -----Original Message----- From: Paul Koning [mailto:ni1d@arrl.net] Sent: Tuesday, February 26, 2002 11:05 PM To: rod.harrison@windriver.com Cc: ips@ece.cmu.edu Subject: RE: sector alignment for DataOut PDUs? >>>>> "Rod" == Rod Harrison writes: Rod> I have no objection in principle to this but I have a concern Rod> over non-media access commands. Things like mode select Rod> payloads, i.e. defect lists etc are not necessarily 512 byte Rod> multiples. The wording would need to allow "odd" sizes when the Rod> SCSI transfer length is not a 512 byte multiple. Are those DataOut or DataIn? The target can arrange inbound PDU sizes to be whatever multiple is helpful if it wants to, that isn't the case I was talking about. In any case, if there are cases where the total transfer length for data out isn't a multiple of 512, then the rule would have to allow the last transfer to have an odd length. The earlier transfers could still be constrained if the constraint is enabled. paul From owner-ips@ece.cmu.edu Wed Feb 27 12:39: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 MAA05415 for ; Wed, 27 Feb 2002 12:39:42 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1RHKb020381 for ips-outgoing; Wed, 27 Feb 2002 12:20:37 -0500 (EST) 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 g1RHKPH20369 for ; Wed, 27 Feb 2002 12:20:30 -0500 (EST) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g1RHKE031102 for ; Wed, 27 Feb 2002 12:20:14 -0500 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 g1RHKEK31093; Wed, 27 Feb 2002 12:20:14 -0500 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with SMTP id g1RHKEe15135; Wed, 27 Feb 2002 12:20:14 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15485.5453.782434.47017@pkoning.dev.equallogic.com> Date: Wed, 27 Feb 2002 12:20:13 -0500 From: Paul Koning To: Eddy_Quicksall@ivivity.com Cc: ips@ece.cmu.edu Subject: RE: sector alignment for DataOut PDUs? References: <25369470B6F0D41194820002B328BDD22F5611@ATLOPS> 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 >>>>> "Eddy" == Eddy Quicksall writes: Eddy> Given that the TCP issues of reassembly are so much more Eddy> complicated than the concatenation issues necessary for target Eddy> data alignment, is there really a problem here? Eddy> If there is a problem, can someone explain that in more detail? I'd describe it as an opportunity for optimization. Yes, at the TCP level your segments can be strange sizes. My goal is to make things better once you get up to the iSCSI level, and you're looking at an iSCSI PDU. Right now, the initiator is allowed to send data out in strange sized chunks. There's a requirement for 4 byte multiples but nothing stronger than that. If you're implementing a disk target, what you want to do is to take in the arriving stream of data from the initiator (DataOut or, if applicable, immediate data) and send that off to disk as it arrives. If data out boundaries are 512 byte multiples, this is straightforward: each time an iSCSI PDU arrives, you can send a disk write down your local disk I/O stack. But as matters stand now, it's more complex because the data out may end in the middle of a disk block, so the bookkeeping for what disk I/Os go with what iSCSI PDUs gets a lot more painful. To add to this, it seems entirely likely that initiators will use 512 byte multiples, especially if you negotiate burst sizes and max pdu sizes that are 512 byte multiples. But the current wording in the spec doesn't require that. (It does hint that targets may object if you don't do it that way -- which makes no sense at all unless there's a MUST for initiators to do what targets are allowed to expect.) So that's why I made the proposal. An alternative would be to tighten the spec so it requires all but the last PDU to be exactly the size of the negotiated max size that applies. That already appears to be the intent, so it may be the easier change. paul From owner-ips@ece.cmu.edu Wed Feb 27 12:47: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 MAA05950 for ; Wed, 27 Feb 2002 12:47:18 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1RGp7D18018 for ips-outgoing; Wed, 27 Feb 2002 11:51:07 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from EXCHANGE.aciesnetworks.com (exchange.aciesnetworks.com [65.90.51.20]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1RGp3H18008 for ; Wed, 27 Feb 2002 11:51:03 -0500 (EST) Received: from D3XG0X01 ([10.105.2.130]) by EXCHANGE.aciesnetworks.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 09:50:57 -0700 Message-ID: <031601c1bfae$a6dab3d0$8202690a@D3XG0X01> From: "Bob Mastors" To: "IPS" Subject: header and data digest issue Date: Wed, 27 Feb 2002 09:48:58 -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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 27 Feb 2002 16:50:57.0123 (UTC) FILETIME=[ED66B330:01C1BFAE] Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I think there is a problem with the current design of the header and data digest. There is a non-zero chance that an error could cause the target to process a single pdu that has a header from one pdu and data from a second pdu. This type of error is undetectable by the target with the CRC32C digests turned on. For example: Initiator sends pdu 1 which contains header H1 and data D1 Initiator sends pdu 2 which contains header H2 and data D2 Target receives pdu 1 which contains header H1 and data D1 Target receives pdu 2 which contains header H2 and data D1 (bad) In this example the header and data digests will checksum correctly. However the wrong data will be written to addresses indicated in H2. There are three obvious places this error can occur: 1. the initiator 2. an intelligent router/switch 3. the target Not much can be done about initiator problems. But I would like to detect problems introduced by the other areas. I think it is actually likely that my target software will run in an environment that produces this type of error. Imagining how an intelligent router/switch or off-board iSCSI target hardware might operate, it is probably only a single bit logic error that could cause this type of error. Maybe it is not appropriate to address this problem in the iSCSI spec because I have described a problem that would not occur on the wire. However iSCSI is the mechanism that allows more hardware and software to be interposed between the SCSI initiator and the SCSI target. iSCSI should not allow a single bit logic error in this additional hardware and software to produce an undetectable error. Bob From owner-ips@ece.cmu.edu Wed Feb 27 13:31: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 NAA08774 for ; Wed, 27 Feb 2002 13:31:32 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1RHfvX22277 for ips-outgoing; Wed, 27 Feb 2002 12:41:57 -0500 (EST) 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 g1RHftH22267 for ; Wed, 27 Feb 2002 12:41:55 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.us.ibm.com [9.99.140.23]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA23154; Wed, 27 Feb 2002 12:38:35 -0500 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1RHfmx63124; Wed, 27 Feb 2002 10:41:48 -0700 X-Priority: 1 (High) Importance: Normal Subject: Re: header and data digest issue To: "Bob Mastors" Cc: "IPS" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Wed, 27 Feb 2002 09:40:54 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 02/27/2002 10:41:48 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I do not believe a single bit error could cause what you suggested. The data is a stream of TCP bytes. TCP does not know the difference. Also these are not separate packets, there is no reason to think that there is any more probability of an error occurring at that DataSection boundary then any other place in the stream. To say that somehow, this same error caused a completely different Data section to have a like problem at its Data Section boundary, and that they would now get crossed at exactly that point, tells me it is a SW error, not a single bit error. . . . 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 "Bob Mastors" @ece.cmu.edu on 02/27/2002 08:48:58 AM Sent by: owner-ips@ece.cmu.edu To: "IPS" cc: Subject: header and data digest issue I think there is a problem with the current design of the header and data digest. There is a non-zero chance that an error could cause the target to process a single pdu that has a header from one pdu and data from a second pdu. This type of error is undetectable by the target with the CRC32C digests turned on. For example: Initiator sends pdu 1 which contains header H1 and data D1 Initiator sends pdu 2 which contains header H2 and data D2 Target receives pdu 1 which contains header H1 and data D1 Target receives pdu 2 which contains header H2 and data D1 (bad) In this example the header and data digests will checksum correctly. However the wrong data will be written to addresses indicated in H2. There are three obvious places this error can occur: 1. the initiator 2. an intelligent router/switch 3. the target Not much can be done about initiator problems. But I would like to detect problems introduced by the other areas. I think it is actually likely that my target software will run in an environment that produces this type of error. Imagining how an intelligent router/switch or off-board iSCSI target hardware might operate, it is probably only a single bit logic error that could cause this type of error. Maybe it is not appropriate to address this problem in the iSCSI spec because I have described a problem that would not occur on the wire. However iSCSI is the mechanism that allows more hardware and software to be interposed between the SCSI initiator and the SCSI target. iSCSI should not allow a single bit logic error in this additional hardware and software to produce an undetectable error. Bob From owner-ips@ece.cmu.edu Wed Feb 27 14:41: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 OAA13182 for ; Wed, 27 Feb 2002 14:41:44 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1RIvvo28872 for ips-outgoing; Wed, 27 Feb 2002 13:57:57 -0500 (EST) 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 g1RIvpH28861 for ; Wed, 27 Feb 2002 13:57:52 -0500 (EST) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g1RIvc032013 for ; Wed, 27 Feb 2002 13:57:38 -0500 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 g1RIvcK32004; Wed, 27 Feb 2002 13:57:38 -0500 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with SMTP id g1RIvIP23308; Wed, 27 Feb 2002 13:57:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15485.11277.877052.66900@pkoning.dev.equallogic.com> Date: Wed, 27 Feb 2002 13:57:17 -0500 From: Paul Koning To: Nick.Martin@compaq.com Cc: ips@ece.cmu.edu Subject: RE: sector alignment for DataOut PDUs? References: <31891B757C09184BBFEC5275F85D5595104E3F@cceexc18.americas.cpqcorp.net> 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 >>>>> "Nick" == Martin, Nick writes: Nick> Paul, For all data carrying PDUs except the last in a sequence, Nick> the sender is expected to send maximum sized PDU allowed. When Nick> the negotiated maximum is a multiple of 512, this effect is Nick> what you request. Nick> I thought this was a requirement, but I did not find it as such Nick> in draft 10. ... Nick> IMHO, it makes more sense to include stronger wording Nick> encouraging maximum negotiated length transfers rather than to Nick> add another parameter requiring PDU breaks on different Nick> boundaries. That sounds like a fine suggestion, if it gives the target enough power to achieve the alignment I'm looking for. Strengthening the text you quoted is a start, but other places would have to be strengthened as well -- for example the rules on responding to an R2T. Nick> If such initiator behavior may not be supported by all targets, Nick> then the initiators SHOULD NOT do it. That's not sufficient. You need "MUST NOT". The reason: if you say "should not" then you can build a conforming initiator that cannot interoperate with a conforming target. All correctly written protocol specs have the property that conformance implies interoperability. (Unfortunately, few specs pass this test... :-( ) So a target can be allowed to rely on full size PDUs only if initiators are required (not merely encouraged) to send full size PDUs. paul From owner-ips@ece.cmu.edu Wed Feb 27 14:42: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 OAA13311 for ; Wed, 27 Feb 2002 14:42:59 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1RIcQk27292 for ips-outgoing; Wed, 27 Feb 2002 13:38:26 -0500 (EST) 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 g1RIcOH27288 for ; Wed, 27 Feb 2002 13:38:24 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id CBE1C3139; Wed, 27 Feb 2002 11:38:19 -0700 (MST) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 67C532AC; Wed, 27 Feb 2002 11:38:19 -0700 (MST) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 27 Feb 2002 11:38:19 -0700 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Feb 2002 11:38:18 -0700 Message-ID: <01A7DAF31F93D511AEE300D0B706ED9201BF47A4@axcs13.cos.agilent.com> From: "CAVANNA,VICENTE V (A-Roseville,ex1)" To: "'John Hufferd'" Cc: "CAVANNA,VICENTE V (A-Roseville,ex1)" , ips@ece.cmu.edu, "'Bob Mastors'" Subject: RE: header and data digest issue Date: Wed, 27 Feb 2002 11:38:17 -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 to agree with Bob Mastors that there is a non-negligible probability for such a mixup in an intelligent router such as an iSCSI middlebox. A middle box that touches the iSCSI PDU could, it seems to me, cause the mixup that Bob describes with relative ease. Suppose an iSCSI middle box buffers iSCSI PDUs and, for its convenience, delineates the header from the data sections with some scheme such as storing iscsi headers and data sections (or pointers to them) in separate buffers. The iSCSI middle box then does some manipulations to the headers and eventually rejoins header and data prior to forwarding the PDU. I can envision several types of single logical errors causing an incorrect matchup of header and data. Suppose the pointers to the data and header sections of the iSCSI PDU are stored in circular queues. A circular Queue failure that causes the same entry to be read twice or an entry to get lost could cause the type of mismatch that Bob Masters alludes to. Similarly a single bit change in a pointer could also cause the mismatch. Software errors in the middle box could of course cause the same mismatch. Of course the middle box could also have internal redundancy in order to catch such errors but this is beyond the control of the Initiator and Target. It seems to me that, by splitting header and data digests, we lost the automatic protection that a single CRC would have provided against such mixups. Of course I have to admit that even one CRC accross the entire iSCSI PDU does not guarantee that middle boxes cannot easily corrupt the iSCSI PDU in ways that the end nodes cannot detect. For example a middle box could make some intentional changes to the iSCSI PDU that is protected by a single CRC and also make some unintentional changes. It would then recompute the single CRC. This last problem could be solved if the middle box would simply "adjust" the CRC for the intentional changes - the unintentional changes would then cause a CRC error at the recipient - but it is my understanding that this is considered difficult to do or there would have been no need to split the digest in the first place. What other means are there for the ends to identify such a mismatch? Vince |-----Original Message----- |From: John Hufferd [mailto:hufferd@us.ibm.com] |Sent: Wednesday, February 27, 2002 9:41 AM |To: Bob Mastors |Cc: IPS |Subject: Re: header and data digest issue | | | |I do not believe a single bit error could cause what you |suggested. The |data is a stream of TCP bytes. TCP does not know the difference. Also |these are not separate packets, there is no reason to think |that there is |any more probability of an error occurring at that DataSection boundary |then any other place in the stream. | |To say that somehow, this same error caused a completely different Data |section to have a like problem at its Data Section boundary, |and that they |would now get crossed at exactly that point, tells me it is a |SW error, not |a single bit error. | |. |. |. |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 | | |"Bob Mastors" @ece.cmu.edu on 02/27/2002 |08:48:58 AM | |Sent by: owner-ips@ece.cmu.edu | | |To: "IPS" |cc: |Subject: header and data digest issue | | | |I think there is a problem with the current design of the |header and data digest. |There is a non-zero chance that an error could cause |the target to process a single pdu that has a header from |one pdu and data from a second pdu. | |This type of error is undetectable by the target with the CRC32C |digests turned on. | |For example: | Initiator sends pdu 1 which contains header H1 and data D1 | Initiator sends pdu 2 which contains header H2 and data D2 | Target receives pdu 1 which contains header H1 and data D1 | Target receives pdu 2 which contains header H2 and |data D1 (bad) |In this example the header and data digests will checksum correctly. |However the wrong data will be written to addresses indicated in H2. | |There are three obvious places this error can occur: | 1. the initiator | 2. an intelligent router/switch | 3. the target | |Not much can be done about initiator problems. |But I would like to detect problems introduced by the other areas. | |I think it is actually likely that my target software will run |in an environment that produces this type of error. |Imagining how an intelligent router/switch or off-board iSCSI target |hardware might operate, it is probably only a single bit logic error |that could cause this type of error. | |Maybe it is not appropriate to address this problem in the iSCSI spec |because I have described a problem that would not occur on the wire. |However iSCSI is the mechanism that allows more hardware and software |to be interposed between the SCSI initiator and the SCSI target. |iSCSI should not allow a single bit logic error in this additional |hardware and software to produce an undetectable error. | |Bob | | | | From owner-ips@ece.cmu.edu Wed Feb 27 15: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 PAA15323 for ; Wed, 27 Feb 2002 15:18:28 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1RJkwF03249 for ips-outgoing; Wed, 27 Feb 2002 14:46:58 -0500 (EST) 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 g1RJkrH03239 for ; Wed, 27 Feb 2002 14:46:54 -0500 (EST) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g1RJki032644 for ; Wed, 27 Feb 2002 14:46:44 -0500 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 g1RJkiK32635; Wed, 27 Feb 2002 14:46:44 -0500 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with SMTP id g1RJkiR26390; Wed, 27 Feb 2002 14:46:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15485.14244.79991.204056@pkoning.dev.equallogic.com> Date: Wed, 27 Feb 2002 14:46:44 -0500 From: Paul Koning To: rod.harrison@windriver.com Cc: ips@ece.cmu.edu Subject: RE: sector alignment for DataOut PDUs? References: <15485.5453.782434.47017@pkoning.dev.equallogic.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 >>>>> "Rod" == Rod Harrison writes: Rod> Paul, I strongly object to your alternative of tightening the Rod> spec wording to force all PDUs to be max sized except the Rod> last. As I mentioned in an earlier email, since draft v09 we Rod> don't have a negotiated PDU size we have arbitrary maximums set Rod> by the receivers. Forcing an initiator to send "full" PDUs is Rod> unreasonable since the target may set a huge MaxRecvPDULength. Rod> The intent of the current wording was, if I remember correctly, Rod> to have the initiator always send as much unsolicited data as Rod> possible. This was to avoid the target having to wait for the F Rod> bit on the unsolicited data before issuing R2T(s) for the Rod> remaining payload. Note that unsolicited data, and its maximum Rod> size, are negotiated parameters and that that current SHOULD is Rod> quite different from forcing initiators to always send "full" Rod> DATA-OUT PDUs. That's a good point. So for unsolicited data we have a negotiated max length, but you're allowed to send less than that. Similarly, for R2T the target requests a length and the initiator is allowed to send less than that. That can be tightened up, but doing so doesn't constrain the individual PDUs that are being sent, only the whole burst. I was concerned with the individual PDUs, so a different rule is needed there. And as you point out, the max PDU length is no longer suitable for that. (Undoing the change of what Max PDU length means back to what it was in -08 doesn't sound like the right way to address this.) Rod> Please note that I don't object to your original proposal, just Rod> to the alternative which I believe would be a huge functional Rod> change. Thanks... your comments make sense to me. paul From owner-ips@ece.cmu.edu Wed Feb 27 15:21: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 PAA15463 for ; Wed, 27 Feb 2002 15:21:49 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1RJYtd02216 for ips-outgoing; Wed, 27 Feb 2002 14:34:55 -0500 (EST) 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 g1RJYrH02212 for ; Wed, 27 Feb 2002 14:34:53 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 9451F2F3C; Wed, 27 Feb 2002 12:34:52 -0700 (MST) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 376331CF; Wed, 27 Feb 2002 12:34:52 -0700 (MST) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 27 Feb 2002 12:34:52 -0700 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Feb 2002 12:34:51 -0700 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00A755092@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Rod Harrison , Paul Koning , Eddy_Quicksall@ivivity.com Cc: ips@ece.cmu.edu Subject: RE: sector alignment for DataOut PDUs? Date: Wed, 27 Feb 2002 12:34: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 I agree with Rod. If we changed the rule to require full PDUs, then we would have to also change the negotiation for the related keys. Pat -----Original Message----- From: Rod Harrison [mailto:rod.harrison@windriver.com] Sent: Wednesday, February 27, 2002 11:26 AM To: Paul Koning; Eddy_Quicksall@ivivity.com Cc: ips@ece.cmu.edu Subject: RE: sector alignment for DataOut PDUs? Paul, I strongly object to your alternative of tightening the spec wording to force all PDUs to be max sized except the last. As I mentioned in an earlier email, since draft v09 we don't have a negotiated PDU size we have arbitrary maximums set by the receivers. Forcing an initiator to send "full" PDUs is unreasonable since the target may set a huge MaxRecvPDULength. The intent of the current wording was, if I remember correctly, to have the initiator always send as much unsolicited data as possible. This was to avoid the target having to wait for the F bit on the unsolicited data before issuing R2T(s) for the remaining payload. Note that unsolicited data, and its maximum size, are negotiated parameters and that that current SHOULD is quite different from forcing initiators to always send "full" DATA-OUT PDUs. Please note that I don't object to your original proposal, just to the alternative which I believe would be a huge functional change. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Paul Koning Sent: Wednesday, February 27, 2002 5:20 PM To: Eddy_Quicksall@ivivity.com Cc: ips@ece.cmu.edu Subject: RE: sector alignment for DataOut PDUs? >>>>> "Eddy" == Eddy Quicksall writes: Eddy> Given that the TCP issues of reassembly are so much more Eddy> complicated than the concatenation issues necessary for target Eddy> data alignment, is there really a problem here? Eddy> If there is a problem, can someone explain that in more detail? I'd describe it as an opportunity for optimization. Yes, at the TCP level your segments can be strange sizes. My goal is to make things better once you get up to the iSCSI level, and you're looking at an iSCSI PDU. Right now, the initiator is allowed to send data out in strange sized chunks. There's a requirement for 4 byte multiples but nothing stronger than that. If you're implementing a disk target, what you want to do is to take in the arriving stream of data from the initiator (DataOut or, if applicable, immediate data) and send that off to disk as it arrives. If data out boundaries are 512 byte multiples, this is straightforward: each time an iSCSI PDU arrives, you can send a disk write down your local disk I/O stack. But as matters stand now, it's more complex because the data out may end in the middle of a disk block, so the bookkeeping for what disk I/Os go with what iSCSI PDUs gets a lot more painful. To add to this, it seems entirely likely that initiators will use 512 byte multiples, especially if you negotiate burst sizes and max pdu sizes that are 512 byte multiples. But the current wording in the spec doesn't require that. (It does hint that targets may object if you don't do it that way -- which makes no sense at all unless there's a MUST for initiators to do what targets are allowed to expect.) So that's why I made the proposal. An alternative would be to tighten the spec so it requires all but the last PDU to be exactly the size of the negotiated max size that applies. That already appears to be the intent, so it may be the easier change. paul From owner-ips@ece.cmu.edu Wed Feb 27 15:21: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 PAA15477 for ; Wed, 27 Feb 2002 15:21:55 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1RJlXJ03301 for ips-outgoing; Wed, 27 Feb 2002 14:47:33 -0500 (EST) 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 g1RJlVH03294 for ; Wed, 27 Feb 2002 14:47:31 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id <100R1C2F>; Wed, 27 Feb 2002 14:47:22 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937507@CORPMX14> From: Black_David@emc.com To: bmastors@aciesnetworks.com, ips@ece.cmu.edu Subject: RE: header and data digest issue Date: Wed, 27 Feb 2002 14:47:18 -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 > I think there is a problem with the current design of the > header and data digest. > There is a non-zero chance that an error could cause > the target to process a single pdu that has a header from > one pdu and data from a second pdu. > > This type of error is undetectable by the target with the CRC32C > digests turned on. > > For example: > Initiator sends pdu 1 which contains header H1 and data D1 > Initiator sends pdu 2 which contains header H2 and data D2 > Target receives pdu 1 which contains header H1 and data D1 > Target receives pdu 2 which contains header H2 and data D1 (bad) > In this example the header and data digests will checksum correctly. > However the wrong data will be written to addresses indicated in H2. > > There are three obvious places this error can occur: > 1. the initiator > 2. an intelligent router/switch > 3. the target > > Not much can be done about initiator problems. > But I would like to detect problems introduced by the other areas. The middlebox problem is inherent in allowing middlebox functionality which was the rationale for using separate CRCs. One can stop a middlebox from making this mistake by running IPsec ESP's keyed cryptographic integrity check end-to-end - if some middlebox tries to get clever, the ESP integrity check fails and the packets that make up the corrupted PDU are dropped; if the middlebox error is persistent, the TCP connection will probably close. Changing the CRC check won't stop middleboxes - if some CRC gets in the way, the middlebox will strip the offending CRC and regenerate it - the result is *still* vulnerable to implementation bugs in the middlebox (and cleverer things like putting the data digest in the header or vice versa are vulnerable to similarly cleverer implementation bugs). > I think it is actually likely that my target software will run > in an environment that produces this type of error. > Imagining how an intelligent router/switch or off-board iSCSI target > hardware might operate, it is probably only a single bit logic error > that could cause this type of error. If "intelligent" means the router/switch is iSCSI-aware, ESP cryptographic integrity is the right means to protect against modifications - anything less (especially omitting the keying) is an invitation to the "strip the CRC and regenerate" scenario akin to the one in the middlebox paragraph above. If an iSCSI target is off-board, it has stripped, parsed, and discarded the iSCSI header - no CRC of any form will protect against a bug in that target that got confused about which data went with which header. Protocol implementations remove headers from data and have to keep track of what they're doing - there's no free lunch here (e.g., if a CRC covering header and data is added, an implementation will likely to check that and strip it, after which it can still get confused. > Maybe it is not appropriate to address this problem in the iSCSI spec > because I have described a problem that would not occur on the wire. > However iSCSI is the mechanism that allows more hardware and software > to be interposed between the SCSI initiator and the SCSI target. > iSCSI should not allow a single bit logic error in this additional > hardware and software to produce an undetectable error. The only problem scenario I see involves middleboxes, and iSCSI provides a tool (IPsec ESP cryptographic integrity) that addresses that problem. Did I miss anything? 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 Feb 27 15:22: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 PAA15489 for ; Wed, 27 Feb 2002 15:22:04 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1RJmMB03378 for ips-outgoing; Wed, 27 Feb 2002 14:48:22 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f29.pav2.hotmail.com [64.4.37.29]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1RJmJH03369 for ; Wed, 27 Feb 2002 14:48:19 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Feb 2002 11:48:14 -0800 Received: from 64.38.134.108 by pv2fd.pav2.hotmail.msn.com with HTTP; Wed, 27 Feb 2002 19:48:13 GMT X-Originating-IP: [64.38.134.108] From: "Bernard Aboba" To: ips@ece.cmu.edu Subject: Security -11 draft strawman posted Date: Wed, 27 Feb 2002 11:48:13 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Feb 2002 19:48:14.0015 (UTC) FILETIME=[B17B9CF0:01C1BFC7] Sender: owner-ips@ece.cmu.edu Precedence: bulk A strawman of the -11 security draft has been posted for examination at: http://www.drizzle.com/~aboba/RDMA/draft-ietf-ips-security-11.txt Comments welcome. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. From owner-ips@ece.cmu.edu Wed Feb 27 15:28: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 PAA15866 for ; Wed, 27 Feb 2002 15:28:25 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1RJQZU01453 for ips-outgoing; Wed, 27 Feb 2002 14:26:35 -0500 (EST) 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 g1RJQQH01439 for ; Wed, 27 Feb 2002 14:26:26 -0500 (EST) Received: from london ([10.95.10.3]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id LAA25883; Wed, 27 Feb 2002 11:25:51 -0800 (PST) From: "Rod Harrison" To: "Paul Koning" , Cc: Subject: RE: sector alignment for DataOut PDUs? Date: Wed, 27 Feb 2002 19:25:37 -0000 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: <15485.5453.782434.47017@pkoning.dev.equallogic.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Paul, I strongly object to your alternative of tightening the spec wording to force all PDUs to be max sized except the last. As I mentioned in an earlier email, since draft v09 we don't have a negotiated PDU size we have arbitrary maximums set by the receivers. Forcing an initiator to send "full" PDUs is unreasonable since the target may set a huge MaxRecvPDULength. The intent of the current wording was, if I remember correctly, to have the initiator always send as much unsolicited data as possible. This was to avoid the target having to wait for the F bit on the unsolicited data before issuing R2T(s) for the remaining payload. Note that unsolicited data, and its maximum size, are negotiated parameters and that that current SHOULD is quite different from forcing initiators to always send "full" DATA-OUT PDUs. Please note that I don't object to your original proposal, just to the alternative which I believe would be a huge functional change. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Paul Koning Sent: Wednesday, February 27, 2002 5:20 PM To: Eddy_Quicksall@ivivity.com Cc: ips@ece.cmu.edu Subject: RE: sector alignment for DataOut PDUs? >>>>> "Eddy" == Eddy Quicksall writes: Eddy> Given that the TCP issues of reassembly are so much more Eddy> complicated than the concatenation issues necessary for target Eddy> data alignment, is there really a problem here? Eddy> If there is a problem, can someone explain that in more detail? I'd describe it as an opportunity for optimization. Yes, at the TCP level your segments can be strange sizes. My goal is to make things better once you get up to the iSCSI level, and you're looking at an iSCSI PDU. Right now, the initiator is allowed to send data out in strange sized chunks. There's a requirement for 4 byte multiples but nothing stronger than that. If you're implementing a disk target, what you want to do is to take in the arriving stream of data from the initiator (DataOut or, if applicable, immediate data) and send that off to disk as it arrives. If data out boundaries are 512 byte multiples, this is straightforward: each time an iSCSI PDU arrives, you can send a disk write down your local disk I/O stack. But as matters stand now, it's more complex because the data out may end in the middle of a disk block, so the bookkeeping for what disk I/Os go with what iSCSI PDUs gets a lot more painful. To add to this, it seems entirely likely that initiators will use 512 byte multiples, especially if you negotiate burst sizes and max pdu sizes that are 512 byte multiples. But the current wording in the spec doesn't require that. (It does hint that targets may object if you don't do it that way -- which makes no sense at all unless there's a MUST for initiators to do what targets are allowed to expect.) So that's why I made the proposal. An alternative would be to tighten the spec so it requires all but the last PDU to be exactly the size of the negotiated max size that applies. That already appears to be the intent, so it may be the easier change. paul From owner-ips@ece.cmu.edu Wed Feb 27 16:45: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 QAA20580 for ; Wed, 27 Feb 2002 16:45:35 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1RKjhQ08482 for ips-outgoing; Wed, 27 Feb 2002 15:45:43 -0500 (EST) 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 g1RJaHH02359 for ; Wed, 27 Feb 2002 14:36:17 -0500 (EST) Received: from io.iol.unh.edu (IDENT:rdr@localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.2/8.12.2) with ESMTP id g1RJaCUj024627 for ; Wed, 27 Feb 2002 14:36:12 -0500 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.2/8.12.1/Submit) with ESMTP id g1RJaCZQ024624 for ; Wed, 27 Feb 2002 14:36:12 -0500 Date: Wed, 27 Feb 2002 14:36:12 -0500 (EST) From: "Robert D. Russell" To: ips@ece.cmu.edu Subject: iscsi: version number in draft 11 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian: The version number in draft 10-94 is still 0x3, the same as it was in draft 9 and draft 10. Would you please change it to 0x4 for draft 11. Of course these numbers still need to be taken with a grain of salt, but testing is considerably simpler and more robust when one side identifies the draft it intends to conform to in a manner that can be checked by the other side. Thanks, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Wed Feb 27 17:39: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 RAA22819 for ; Wed, 27 Feb 2002 17:39:22 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1RLhCK13246 for ips-outgoing; Wed, 27 Feb 2002 16:43:12 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from EXCHANGE.aciesnetworks.com (exchange.aciesnetworks.com [65.90.51.20]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1RLh9H13233 for ; Wed, 27 Feb 2002 16:43:10 -0500 (EST) Received: from D3XG0X01 ([10.105.2.130]) by EXCHANGE.aciesnetworks.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 14:42:57 -0700 Message-ID: <035e01c1bfd7$71ec7400$8202690a@D3XG0X01> From: "Bob Mastors" To: , References: <277DD60FB639D511AC0400B0D068B71E02937507@CORPMX14> Subject: Re: header and data digest issue Date: Wed, 27 Feb 2002 14:40:59 -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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 27 Feb 2002 21:42:57.0496 (UTC) FILETIME=[B85B7580:01C1BFD7] Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit IPsec ESP cryptographic integrity is too expensive (at least for me). It seems likely that a iSCSI aware middle box will DMA the header and data separately. If this is the case than it seems likely that eventually the data will be DMAed to the wrong place. This could be caused by software, firmware, or hardware. It also seems likely that a software error in the target operating system will also cause this problem. Again because it is likely that the header and data will be manipulated differently. It is a very minor coding error to cause this behavior. Just mess up a circular queue, or some off by one bug. I am writing software that processes and stores iSCSI data. I will have the iSCSI target (whether software or off-board processor) pass me the CRC digests in addition to the header and data. The CRC digests are verified and stored on disk with the header and data. This provides a high degree of confidence that the data on disk is either correct and at its correct address, or that it can be detected that it is not. Additionally this architecture allows fsck type software to be written to walk the disk looking for CRC errors. By using the CRCs generated by the initiator and verified by my software, I have a high degree of confidence that my own software or the operating system software did not introduce errors. The iSCSI header and data digests are almost perfect for implementing this architecture. But by computing CRCs separately for the address and the data, there is a non-negligible chance that my software will write the wrong data to a block. Not only will I be unable to detect the problem when it occurs, a scan of the disk and CRCs will indicate that nothing is wrong. Only the application will know that the data is wrong. You are correct to point out that there are all sorts of errors brain damaged middle boxes could introduce that CRCs will never solve. But I think that this is a very simple bug to cause. All it takes is an address line in a DMA being held for just a bit too long once a month. I hope you can see from the explanation that to me this is not a theoretical problem. Bob ----- Original Message ----- From: To: ; Sent: Wednesday, February 27, 2002 12:47 PM Subject: RE: header and data digest issue > > I think there is a problem with the current design of the > > header and data digest. > > There is a non-zero chance that an error could cause > > the target to process a single pdu that has a header from > > one pdu and data from a second pdu. > > > > This type of error is undetectable by the target with the CRC32C > > digests turned on. > > > > For example: > > Initiator sends pdu 1 which contains header H1 and data D1 > > Initiator sends pdu 2 which contains header H2 and data D2 > > Target receives pdu 1 which contains header H1 and data D1 > > Target receives pdu 2 which contains header H2 and data D1 (bad) > > In this example the header and data digests will checksum correctly. > > However the wrong data will be written to addresses indicated in H2. > > > > There are three obvious places this error can occur: > > 1. the initiator > > 2. an intelligent router/switch > > 3. the target > > > > Not much can be done about initiator problems. > > But I would like to detect problems introduced by the other areas. > > The middlebox problem is inherent in allowing middlebox functionality > which was the rationale for using separate CRCs. One can stop a middlebox > from making this mistake by running IPsec ESP's keyed cryptographic > integrity > check end-to-end - if some middlebox tries to get clever, the ESP integrity > check fails and the packets that make up the corrupted PDU are dropped; if > the middlebox error is persistent, the TCP connection will probably close. > Changing the CRC check won't stop middleboxes - if some CRC gets in the way, > the middlebox will strip the offending CRC and regenerate it - the result > is *still* vulnerable to implementation bugs in the middlebox (and cleverer > things like putting the data digest in the header or vice versa are > vulnerable to similarly cleverer implementation bugs). > > > I think it is actually likely that my target software will run > > in an environment that produces this type of error. > > Imagining how an intelligent router/switch or off-board iSCSI target > > hardware might operate, it is probably only a single bit logic error > > that could cause this type of error. > > If "intelligent" means the router/switch is iSCSI-aware, ESP cryptographic > integrity is the right means to protect against modifications - anything > less (especially omitting the keying) is an invitation to the "strip the > CRC and regenerate" scenario akin to the one in the middlebox paragraph > above. > > If an iSCSI target is off-board, it has stripped, parsed, and discarded > the iSCSI header - no CRC of any form will protect against a bug in that > target that got confused about which data went with which header. Protocol > implementations remove headers from data and have to keep track of what > they're doing - there's no free lunch here (e.g., if a CRC covering header > and data is added, an implementation will likely to check that and strip it, > after which it can still get confused. > > > Maybe it is not appropriate to address this problem in the iSCSI spec > > because I have described a problem that would not occur on the wire. > > However iSCSI is the mechanism that allows more hardware and software > > to be interposed between the SCSI initiator and the SCSI target. > > iSCSI should not allow a single bit logic error in this additional > > hardware and software to produce an undetectable error. > > The only problem scenario I see involves middleboxes, and iSCSI > provides a tool (IPsec ESP cryptographic integrity) that addresses > that problem. Did I miss anything? > > 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 Feb 27 18:30: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 SAA24261 for ; Wed, 27 Feb 2002 18:30:29 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1RNDF420794 for ips-outgoing; Wed, 27 Feb 2002 18:13:15 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1RNDEH20788 for ; Wed, 27 Feb 2002 18:13:14 -0500 (EST) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Feb 2002 18:13:11 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0293750D@CORPMX14> From: Black_David@emc.com To: rdr@io.iol.unh.edu, ips@ece.cmu.edu Subject: RE: iscsi: version number in draft 11 Date: Wed, 27 Feb 2002 18:13:00 -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 Folks, I've warned in the past that this use of version numbers is going to cause problems, as it encourages the longevity of obsolete implementations that don't interoperate. Version numbers should NEVER have been used for identification of draft versions - in 20/20 hindsight a text key that could have been dropped from the final RFC would have been better. Prior guidance from the ADs has been that a version number change from 0 to 1 in going to RFC would be ok. Let's reset the version number to 0, and anyone still using something based on a draft from back when the version number was still 0 has something truly ancient and is SOL. 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: Robert D. Russell [mailto:rdr@io.iol.unh.edu] > Sent: Wednesday, February 27, 2002 2:36 PM > To: ips@ece.cmu.edu > Subject: iscsi: version number in draft 11 > > > Julian: > > The version number in draft 10-94 is still 0x3, > the same as it was in draft 9 and draft 10. > > Would you please change it to 0x4 for draft 11. > > Of course these numbers still need to be taken with > a grain of salt, but testing is considerably > simpler and more robust when one side identifies the > draft it intends to conform to in a manner that can > be checked by the other side. > > Thanks, > > Bob Russell > InterOperability Lab > University of New Hampshire > rdr@iol.unh.edu > 603-862-3774 > From owner-ips@ece.cmu.edu Wed Feb 27 18:31: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 SAA24286 for ; Wed, 27 Feb 2002 18:31:14 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1RMdQF18053 for ips-outgoing; Wed, 27 Feb 2002 17:39:26 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ariel.nishansystems.com ([65.113.142.135]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1RMdOH18048 for ; Wed, 27 Feb 2002 17:39:24 -0500 (EST) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id <1LYT21WM>; Wed, 27 Feb 2002 14:39:12 -0800 Message-ID: From: Charles Monia To: "Ips (E-mail)" Subject: iFCP: Revision 10 published Date: Wed, 27 Feb 2002 14:39:11 -0800 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 Revision 10 of the iFCP spec has been submitted to the ietf archive. Pending the announcement of its availability, copies of the text or pdf files can be obtained from: ftp://ftp.t11.org/t11/member/incoming/02-023v2.txt or ftp://ftp.t11.org/t11/member/incoming/02-023v2.pdf. On or after 3/1/2002, the files will be moved to: ftp://t11member@ftp.t11.org/t11/docs/02-023v2.txt and ftp://t11member@ftp.t11.org/t11/docs/02-023v2.pdf This version contains the content to be submitted for WG last call. Thanks, Charles 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 Feb 27 19:00: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 TAA24976 for ; Wed, 27 Feb 2002 19:00:57 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1RN81V20384 for ips-outgoing; Wed, 27 Feb 2002 18:08:01 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1RN80H20380 for ; Wed, 27 Feb 2002 18:08:00 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Feb 2002 18:02:24 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0293750C@CORPMX14> From: Black_David@emc.com To: bmastors@aciesnetworks.com, ips@ece.cmu.edu Subject: RE: header and data digest issue Date: Wed, 27 Feb 2002 18:07:47 -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 Bob, > IPsec ESP cryptographic integrity is too expensive (at least for me). > > It seems likely that a iSCSI aware middle box will DMA the header > and data separately. If this is the case than it seems likely that > eventually the data will be DMAed to the wrong place. > This could be caused by software, firmware, or hardware. The whole point of separate CRCs on header and data was to allow an iSCSI middlebox to modify the header without having to touch the data CRC. As I said, a CRC will not prevent this middlebox problem - for example, if iSCSI had a CRC that covered both headers and data, one would almost certainly see middleboxes that stripped that CRC on input and regenerated it on output, producing a vulnerability to the problem of concern. Something like IPsec ESP cryptographic integrity that a middlebox cannot regenerate is necessary to solve this problem. This is a long version of a fairly simple principle - those who don't trust middleboxes shouldn't allow their use. > It also seems likely that a software error in the target operating > system will also cause this problem. Again because it is likely that > the header and data will be manipulated differently. It is a very > minor coding error to cause this behavior. Just mess up a circular > queue, or some off by one bug. I agree, bugs happen. > I am writing software that processes and stores iSCSI data. > I will have the iSCSI target (whether software or off-board processor) > pass me the CRC digests in addition to the header and data. > The CRC digests are verified and stored on disk with the header and data. > This provides a high degree of confidence that the data on disk is > either correct and at its correct address, or that it can be detected > that it is not. Additionally this architecture allows fsck type > software to be written to walk the disk looking for CRC errors. This is not an "off-the-shelf" target, as a vanilla iSCSI target will consume the header, passing only selected pieces of it upward (e.g., nothing above iSCSI needs to know about CmdSNs, nothing above SCSI knows about CDBs). So the target is going to have to be modified to work with your software. > By using the CRCs generated by the initiator and verified by > my software, I have a high degree of confidence that my own > software or the operating system software did not introduce errors. > > The iSCSI header and data digests are almost perfect for implementing this > architecture. But by computing CRCs separately for the address and the data, > there is a non-negligible chance that my software will write the wrong data > to a block. Not only will I be unable to detect the problem when it occurs, > a scan of the disk and CRCs will indicate that nothing is wrong. > Only the application will know that the data is wrong. Since the target has to be modified anyway, here's a simple modification to it that accomplishes this goal without any changes on the wire: When the target first scans the iSCSI PDU, it not only extracts the two CRCs, but also calculates their XOR, and passes all three values upward in addition to the iSCSI header and data. Your software checks and store all three values with the header and data. If something in the target or the OS or your software screws up and swaps the header (and its CRC), the XOR will catch this. Let me know if this works for you. For the middlebox problem, ESP cryptographic integrity is the right solution, as any CRC-based mechanism will be defeated by a middlebox implementer taking fairly obvious and convenient "strip and regenerate" shortcuts. 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 Feb 27 20:41: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 UAA27681 for ; Wed, 27 Feb 2002 20:41:37 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1S0vG527977 for ips-outgoing; Wed, 27 Feb 2002 19:57:16 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from Gregorio.Stanford.EDU (Gregorio.Stanford.EDU [171.64.66.243]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1S0vEH27971 for ; Wed, 27 Feb 2002 19:57:14 -0500 (EST) Received: from Pescadero.DSG.Stanford.EDU (Pescadero.DSG.Stanford.EDU [171.64.79.21]) by Gregorio.Stanford.EDU (8.11.6/8.9.1) with ESMTP id g1S0tMP27638; Wed, 27 Feb 2002 16:55:22 -0800 Message-Id: <200202280055.g1S0tMP27638@Gregorio.Stanford.EDU> To: Black_David@emc.com cc: bmastors@aciesnetworks.com, ips@ece.cmu.edu Subject: Re: header and data digest issue In-reply-to: Your message of "Wed, 27 Feb 2002 18:07:47 EST." <277DD60FB639D511AC0400B0D068B71E0293750C@CORPMX14> Date: Wed, 27 Feb 2002 16:45:32 -0800 From: Jonathan Stone Sender: owner-ips@ece.cmu.edu Precedence: bulk [...] >The whole point of separate CRCs on header and data was to allow >an iSCSI middlebox to modify the header without having to touch >the data CRC. As I said, a CRC will not prevent this middlebox problem >- for example, if iSCSI had a CRC that covered both headers and data, >one would almost certainly see middleboxes that stripped that CRC >on input and regenerated it on output, producing a vulnerability to >the problem of concern. Something like IPsec ESP cryptographic >integrity that a middlebox cannot regenerate is necessary to solve >this problem. This is a long version of a fairly simple principle >- those who don't trust middleboxes shouldn't allow their use. [...] >For the middlebox problem, ESP cryptographic integrity is the right >solution, Technically, ESP isn't necessary. AH between the iSCSI endpoints is adequate if the only requirement is to detect and defeat middle boxes. From owner-ips@ece.cmu.edu Wed Feb 27 20:43: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 UAA27703 for ; Wed, 27 Feb 2002 20:43:12 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1S1Dgm29033 for ips-outgoing; Wed, 27 Feb 2002 20:13:42 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1S1DfH29029 for ; Wed, 27 Feb 2002 20:13:41 -0500 (EST) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Feb 2002 20:13:39 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937514@CORPMX14> From: Black_David@emc.com To: jonathan@dsg.stanford.edu Cc: ips@ece.cmu.edu Subject: RE: header and data digest issue Date: Wed, 27 Feb 2002 20:13:28 -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 > >For the middlebox problem, ESP cryptographic integrity is the right > >solution, > > Technically, ESP isn't necessary. AH between the iSCSI endpoints is > adequate if the only requirement is to detect and defeat middle boxes. We're in semi-violent agreement that encryption isn't required. For "ESP cryptographic integrity", one example is ESP with the NULL Encryption Algorithm, as specified in RFC 2410. AH is not required for any IP Storage protocol and the ipsec WG is in the process of removing the requirement for AH from future versions of the ipsec RFCs. --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 Feb 27 21:25: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 VAA28871 for ; Wed, 27 Feb 2002 21:25:12 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1S29AJ02848 for ips-outgoing; Wed, 27 Feb 2002 21:09:10 -0500 (EST) 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 g1RJaHH02359 for ; Wed, 27 Feb 2002 14:36:17 -0500 (EST) Received: from io.iol.unh.edu (IDENT:rdr@localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.2/8.12.2) with ESMTP id g1RJaCUj024627 for ; Wed, 27 Feb 2002 14:36:12 -0500 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.2/8.12.1/Submit) with ESMTP id g1RJaCZQ024624 for ; Wed, 27 Feb 2002 14:36:12 -0500 Date: Wed, 27 Feb 2002 14:36:12 -0500 (EST) From: "Robert D. Russell" To: ips@ece.cmu.edu Subject: iscsi: version number in draft 11 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian: The version number in draft 10-94 is still 0x3, the same as it was in draft 9 and draft 10. Would you please change it to 0x4 for draft 11. Of course these numbers still need to be taken with a grain of salt, but testing is considerably simpler and more robust when one side identifies the draft it intends to conform to in a manner that can be checked by the other side. Thanks, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Wed Feb 27 21:26: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 VAA28915 for ; Wed, 27 Feb 2002 21:26:36 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1S1egg00913 for ips-outgoing; Wed, 27 Feb 2002 20:40:42 -0500 (EST) 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 g1S1edH00907 for ; Wed, 27 Feb 2002 20:40:39 -0500 (EST) Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.110.250.124]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 19B44246B; Wed, 27 Feb 2002 19:40:34 -0600 (CST) Received: from cceexc18.americas.cpqcorp.net ([16.110.250.64]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Feb 2002 19:40:33 -0600 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: sector alignment for DataOut PDUs? Date: Wed, 27 Feb 2002 19:40:33 -0600 Message-ID: <31891B757C09184BBFEC5275F85D559501F22B85@cceexc18.americas.cpqcorp.net> Thread-Topic: sector alignment for DataOut PDUs? Thread-Index: AcG/wKJcM99YUrarRKC3DvhUXJvuFQAJVNDgAAF48AA= From: "Martin, Nick" To: "Paul Koning" Cc: X-OriginalArrivalTime: 28 Feb 2002 01:40:33.0928 (UTC) FILETIME=[E9DA5880:01C1BFF8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g1S1eeH00908 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Paul, As Rod Harrison points out, MaxRecvPDULength is not negotiated, it is "declared" and is likely to be different for Initiator and Target. I had missed the implication of this change which occurred at draft 09. I can now appreciate your earlier proposal. To be fair to all targets, we should allow targets with arbitrary sized sectors/blocks to request the same kind of boundary alignment. Today we already have a need to support 512, 1K, 2K, and 4K sectors for disk, and anything from 512 up to at least 64K blocks for tape (including non-powers of 2 like 10K). [Ouch, I just realized that the tape block size can be changed mid-session, the most likely time being after a media change. The tape folks may not be able to use of this in the same way, but let's not prevent them from trying.] Further we do not really want iSCSI initiators (or their drivers) to have to guess or issue SCSI commands to learn the sector size. The size needs to be specified by the target during operational parameter negotiation if it is requesting sector/block aligned PDU payloads. I actually do not think unaligned payloads are likely, but there is nothing to prevent them. We may simplify some target designs by eliminating the requirement to support them. Certainly, we want to eliminate loopholes which allow compliant but non-interoperable implementations. Please consider whether the following proposal meets all of your requirements. Proposed addition to chapter 12 to enable requiring sector aligned PDU payloads: " DataPDUAlignment Use: LO Senders: Target and Initiator Scope: SW DataPDUAlignment= The default is 0. The initiator and target negotiate the alignment boundary on which data transfers may be continued to a subsequent PDU. The value 0 means no boundary alignment limitation is imposed on data carrying PDUs. The minimum of two non-zero values is selected. If one value is zero, then the other value is selected. This is intended primarily for a target to force an initiator to send PDU data buffers whose boundaries match physical media boundaries such as disk sector size. When DataPDUAlignment is non-zero, for any PDU other than the last in a sequence, the PDU data segment length (DataSegmentLength) is required to be an integer multiple of DataPDUAlignment less than or equal to MaxRecvPDULength. " Thanks, Nick > -----Original Message----- > From: Paul Koning [mailto:ni1d@arrl.net] > Sent: Wednesday, February 27, 2002 12:57 PM > To: Martin, Nick > Cc: ips@ece.cmu.edu > Subject: RE: sector alignment for DataOut PDUs? > > > >>>>> "Nick" == Martin, Nick writes: > > Nick> Paul, For all data carrying PDUs except the last in a sequence, > Nick> the sender is expected to send maximum sized PDU allowed. When > Nick> the negotiated maximum is a multiple of 512, this effect is > Nick> what you request. > > Nick> I thought this was a requirement, but I did not find it as such > Nick> in draft 10. ... > > Nick> IMHO, it makes more sense to include stronger wording > Nick> encouraging maximum negotiated length transfers rather than to > Nick> add another parameter requiring PDU breaks on different > Nick> boundaries. > > That sounds like a fine suggestion, if it gives the target enough > power to achieve the alignment I'm looking for. Strengthening the > text you quoted is a start, but other places would have to be > strengthened as well -- for example the rules on responding to an R2T. > > Nick> If such initiator behavior may not be supported by all targets, > Nick> then the initiators SHOULD NOT do it. > > That's not sufficient. You need "MUST NOT". The reason: if you say > "should not" then you can build a conforming initiator that cannot > interoperate with a conforming target. All correctly written protocol > specs have the property that conformance implies interoperability. > (Unfortunately, few specs pass this test... :-( ) So a target can be > allowed to rely on full size PDUs only if initiators are required (not > merely encouraged) to send full size PDUs. > > paul > > From owner-ips@ece.cmu.edu Thu Feb 28 02:44: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 CAA13804 for ; Thu, 28 Feb 2002 02:44:04 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1S7M3A19965 for ips-outgoing; Thu, 28 Feb 2002 02:22:03 -0500 (EST) 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 g1S7M1H19961 for ; Thu, 28 Feb 2002 02:22:01 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id IAA62896 for ; Thu, 28 Feb 2002 08:21:55 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1S7Nm771224 for ; Thu, 28 Feb 2002 08:23:48 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI:reservations X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 28 Feb 2002 09:23:45 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 28/02/2002 09:23:48, Serialize complete at 28/02/2002 09:23:48 Content-Type: multipart/alternative; boundary="=_alternative 0027578BC2256B6E_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0027578BC2256B6E_= Content-Type: text/plain; charset="us-ascii" Dear colleagues, We had long discussions on the reservation-clearing being done (or not) at session close (FCP does this). We concluded that it is probably a thing that should be handled at SCSI level (it would be wrong for the transport to mes-up SCSI state) and perhaps we should only state that an indication about session failure should be passed to SCSI. Mallikarjun and Randy have a set of good arguments for not doing this implicitly that they would probably want to share them with you. This is only a warning that this item in the clearing appendix is going to change as this issue was debated earlier on the list. Comments? Julo ----- Forwarded by Julian Satran/Haifa/IBM on 28-02-02 09:02 ----- "Mallikarjun C." 28-02-02 04:41 To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: Re: iSCSI:reservations Julian, [ I assume you meant to answer a different thread. ] That works for me, I am working on revising the table, I will get it out to you by tomorrow. Please feel free to forward this to the list if you want to. I hope to upload a new rev of my reservations discussion tomorrow, so you may quote that even - if you choose to (and like the reasoning, :-)) Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ----- Original Message ----- From: "Julian Satran" To: "Mallikarjun C." Sent: Wednesday, February 27, 2002 1:25 AM Subject: Re: iSCSI:implicit logout > Mallikarjun, > > Perhaps the thing to say is that at session close an indication is passed > to SCSI and SCSI may dictate (or not) additional clearing effects. In this > case we can remove the clearing of the reservations from our text and drop > it into SCSI. > > If this is acceptable I suggest you update the attached. > > Thanks, > Julo > > > > > > "Mallikarjun C." > 26-02-02 22:14 > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: John Hufferd/San Jose/IBM@IBMUS > Subject: Re: iSCSI:implicit logout > > > > Sorry, I totally miss the point......particularly John's > "there is nothing to direct the Task management command against" part..... > > The task reassignment operation is *not* CID-driven at all, > reassignment is always to the connection on which the TMF > command is issued - which may or may not have the same CID. > [ This intentionally directly contrasts with the CID-centric operation > of a Logout command, the connection issuing the Logout has no > significance there. ] > > IMHO, not referring to CIDs at all in this discussion is best. > > John's original question - "is reinstatement also implicit reassignment?" > is answered in rev 10-92, section 4.3.4, 2nd para, first sentence. > As Julian said, the answer is no. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 > > > ----- Original Message ----- > From: "Julian Satran" > To: > Sent: Monday, February 25, 2002 9:32 PM > Subject: Re: iSCSI:implicit logout > > > > ? > > ----- Forwarded by Julian Satran/Haifa/IBM on 26-02-02 07:23 ----- > > > > > > John Hufferd@IBMUS > > 25-02-02 22:55 > > > > > > To: Julian Satran/Haifa/IBM@IBMIL@IBMDE > > cc: > > From: John Hufferd/San Jose/IBM@IBMUS > > Subject: Re: iSCSI:implicit logout > > > > > > > > > > > > > > Thanks, Julian, > > That is fine, I think it might be useful, if we could find a way to say > > that in the 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 > > > > To: John Hufferd/San Jose/IBM@IBMUS@IBMDE > > cc: > > From: Julian Satran/Haifa/IBM@IBMIL > > Subject: Re: iSCSI:implicit logout > > > > Yes the 2 CIDs will be the same if the reassignment is to the new > > connection or different if the reassign is to another connection. The > > implicit logout "suspends" the commands. > > > > Julo > > > > > > > > > > John Hufferd@IBMUS > > 25-02-02 19:10 > > > > > > To: Julian Satran/Haifa/IBM@IBMIL@IBMDE > > cc: > > From: John Hufferd/San Jose/IBM@IBMUS > > Subject: Re: iSCSI:implicit logout > > > > > > > > > > > > > > If you use an implicit logout with login, you have the same CID > > established on a new TCP/IP connection, there is nothing to direct the > > Task management command against. They both have the same CID. Hence > why > > I said that thought there was no need to change allegiance. If you do, > > have to issue the Task Managemet command what would you have as the from > > > and to CID? would they both be the same? > > > > . > > . > > . > > 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 > > > > To: John Hufferd/San Jose/IBM@IBMUS@IBMDE > > cc: > > From: Julian Satran/Haifa/IBM@Haifa/IBM@IBMIL > > Subject: Re: iSCSI:implicit logout > > > > John, > > > > Yes and No. > > > > Yes implicit logout is done by login (or by the target itself). However > > login is only part of recovery (and not always needed). > > Reassign has to be explicit, per command and can be done on (other) > > remaining connections (you don't have to create a new one if you have > > enough old ones). > > > > Regards, > > Julo > > > > > > > > > > John Hufferd@IBMUS > > 25-02-02 04:46 > > > > > > To: Julian Satran/Haifa/IBM@IBMIL@IBMDE > > cc: > > From: John Hufferd/San Jose/IBM@IBMUS > > Subject: iSCSI:implicit logout > > > > > > > > Julian, > > The draft specifies talks about explicit Logouts and implicit Logouts, > but > > I have been having problems determining what an implicit logout is. > > > > I believe it is a Logout that occurs when another TCP/IP connection is > > established and then the Login is issued with the same iSCSI Node Name, > > the same ISID, and the same CID as a current connection to the specified > > > target. > > > > If this is correct, I think the iSCSI connection continues with the new > > TCP/IP connection without having to issue a Task Management change of > > allegiance request. Is that true? > > > > . > > . > > . > > 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 > > > > > > > > > > > > > > > > > > > > > > --=_alternative 0027578BC2256B6E_= Content-Type: text/html; charset="us-ascii"
Dear colleagues,

We had long discussions on the reservation-clearing being done (or not) at session close (FCP does this).
 We concluded that it is probably a thing that should be handled at SCSI level (it would be wrong for the transport to mes-up SCSI state) and perhaps we should only state that an indication about session failure should be passed to SCSI.  Mallikarjun and Randy have a set of good arguments for not doing this implicitly that they would probably want to share them with you.

This is only a warning that this item in the clearing appendix is going to change as this issue was debated earlier on the list.

Comments?

Julo
----- Forwarded by Julian Satran/Haifa/IBM on 28-02-02 09:02 -----
"Mallikarjun C." <cbm@rose.hp.com>

28-02-02 04:41

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        
        Subject:        Re: iSCSI:reservations

       


Julian,

[ I assume you meant to answer a different thread. ]

That works for me, I am working on revising the table, I will get it out to
you by tomorrow.  Please feel free to forward this to the list if you want
to.  I hope to upload a new rev of my reservations discussion tomorrow,
so you may quote that even - if you choose to (and like the reasoning, :-))

Thanks.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668
Roseville CA 95747


----- Original Message -----
From: "Julian Satran" <Julian_Satran@il.ibm.com>
To: "Mallikarjun C." <cbm@rose.hp.com>
Sent: Wednesday, February 27, 2002 1:25 AM
Subject: Re: iSCSI:implicit logout


> Mallikarjun,
>
> Perhaps the thing to say is that at session close an indication is passed
> to SCSI and SCSI may dictate (or not) additional clearing effects. In this
> case we can remove the clearing of the reservations from our text and drop
> it into SCSI.
>
> If this is acceptable I suggest you update the attached.
>
> Thanks,
> Julo
>
>
>
>
>
> "Mallikarjun C." <cbm@rose.hp.com>
> 26-02-02 22:14
>
>  
>         To:     Julian Satran/Haifa/IBM@IBMIL
>         cc:     John Hufferd/San Jose/IBM@IBMUS
>         Subject:        Re: iSCSI:implicit logout
>
>  
>
> Sorry, I totally miss the point......particularly John's
> "there is nothing to direct the Task management command against" part.....
>
> The task reassignment operation is *not* CID-driven at all,
> reassignment is always to the connection on which the TMF
> command is issued - which may or may not have the same CID.
> [ This intentionally directly contrasts with the CID-centric operation
>   of a Logout command, the connection issuing the Logout has no
>   significance there.  ]
>
> IMHO, not referring to CIDs at all in this discussion is best.
>
> John's original question - "is reinstatement also implicit reassignment?"
> is answered in rev 10-92, section 4.3.4, 2nd para, first sentence.
> As Julian said, the answer is no.
> --
> Mallikarjun
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> Hewlett-Packard MS 5668
> Roseville CA 95747
>
>
> ----- Original Message -----
> From: "Julian Satran" <Julian_Satran@il.ibm.com>
> To: <cbm@rose.hp.com>
> Sent: Monday, February 25, 2002 9:32 PM
> Subject: Re: iSCSI:implicit logout
>
>
> > ?
> > ----- Forwarded by Julian Satran/Haifa/IBM on 26-02-02 07:23 -----
> >
> >
> > John Hufferd@IBMUS
> > 25-02-02 22:55
> >
> >
> >         To:     Julian Satran/Haifa/IBM@IBMIL@IBMDE
> >         cc:
> >         From:   John Hufferd/San Jose/IBM@IBMUS
> >         Subject:        Re: iSCSI:implicit logout
> >
> >
> >
> >
> >
> >
> > Thanks, Julian,
> > That is fine, I think it might be useful, if we could find a way to say
> > that in the 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
> >
> > To:     John Hufferd/San Jose/IBM@IBMUS@IBMDE
> > cc:
> > From:   Julian Satran/Haifa/IBM@IBMIL
> > Subject:        Re: iSCSI:implicit logout
> >
> > Yes the 2 CIDs will be the same if the reassignment is to the new
> > connection or different if the reassign is to another connection. The
> > implicit logout "suspends" the commands.
> >
> > Julo
> >
> >
> >
> >
> > John Hufferd@IBMUS
> > 25-02-02 19:10
> >
> >
> >         To:     Julian Satran/Haifa/IBM@IBMIL@IBMDE
> >         cc:
> >         From:   John Hufferd/San Jose/IBM@IBMUS
> >         Subject:        Re: iSCSI:implicit logout
> >
> >
> >
> >
> >
> >
> > If you use an implicit logout with login, you have the same CID
> > established on a new TCP/IP connection, there is nothing to direct the
> > Task management command against.  They both have the same CID.  Hence
> why
> > I said that thought there was no need to change allegiance.  If you do,
> > have to issue the Task Managemet command what would you have as the from
>
> > and to CID? would they both be the same?
> >
> > .
> > .
> > .
> > 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
> >
> > To:     John Hufferd/San Jose/IBM@IBMUS@IBMDE
> > cc:
> > From:   Julian Satran/Haifa/IBM@Haifa/IBM@IBMIL
> > Subject:        Re: iSCSI:implicit logout
> >
> > John,
> >
> > Yes and No.
> >
> > Yes implicit logout is done by login (or by the target itself). However
> > login is only part of recovery (and not always needed).
> > Reassign has to be explicit, per command and can be done on (other)
> > remaining connections (you don't have to create a new one if you have
> > enough old ones).
> >
> > Regards,
> > Julo
> >
> >
> >
> >
> > John Hufferd@IBMUS
> > 25-02-02 04:46
> >
> >
> >         To:     Julian Satran/Haifa/IBM@IBMIL@IBMDE
> >         cc:
> >         From:   John Hufferd/San Jose/IBM@IBMUS
> >         Subject:        iSCSI:implicit logout
> >
> >
> >
> > Julian,
> > The draft specifies talks about explicit Logouts and implicit Logouts,
> but
> > I have been having problems determining what an implicit logout is.
> >
> > I believe it is a Logout that occurs when another TCP/IP connection is
> > established and then the Login is issued with the same iSCSI Node Name,
> > the same ISID, and the same CID as a current connection to the specified
>
> > target.
> >
> > If this is correct, I think the iSCSI connection continues with the new
> > TCP/IP connection without having to issue a Task Management change of
> > allegiance request.  Is that true?
> >
> > .
> > .
> > .
> > 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
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>



--=_alternative 0027578BC2256B6E_=-- From owner-ips@ece.cmu.edu Thu Feb 28 02:45: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 CAA13826 for ; Thu, 28 Feb 2002 02:45:17 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1S6usc18812 for ips-outgoing; Thu, 28 Feb 2002 01:56:54 -0500 (EST) 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 g1S6uoH18804; Thu, 28 Feb 2002 01:56:50 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id HAA91306; Thu, 28 Feb 2002 07:56:43 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1S6wa7100254; Thu, 28 Feb 2002 07:58:36 +0100 To: Black_David@emc.com Cc: bmastors@aciesnetworks.com, ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: header and data digest issue X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 28 Feb 2002 08:58:34 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 28/02/2002 08:58:37, Serialize complete at 28/02/2002 08:58:37 Content-Type: multipart/alternative; boundary="=_alternative 0024B5BCC2256B6E_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0024B5BCC2256B6E_= Content-Type: text/plain; charset="us-ascii" David, Usually (not always) middleboxes terminate TCP connections. That is the reason some of us wanted a separate CRC on the data - even with IPsec. The scenario suggested is not the only way in which middleboxes may mess up things. An incrementaly recomputed CRC may solve this type of failure but who says that the middle box will play by the rules and not mess-up with the data in unexpected ways? I think that we have a decent solution for SCSI data integrity that is both simple and robust with respect to accidental failures. Julo Black_David@emc.com Sent by: owner-ips@ece.cmu.edu 27-02-02 21:47 To: bmastors@aciesnetworks.com, ips@ece.cmu.edu cc: Subject: RE: header and data digest issue > I think there is a problem with the current design of the > header and data digest. > There is a non-zero chance that an error could cause > the target to process a single pdu that has a header from > one pdu and data from a second pdu. > > This type of error is undetectable by the target with the CRC32C > digests turned on. > > For example: > Initiator sends pdu 1 which contains header H1 and data D1 > Initiator sends pdu 2 which contains header H2 and data D2 > Target receives pdu 1 which contains header H1 and data D1 > Target receives pdu 2 which contains header H2 and data D1 (bad) > In this example the header and data digests will checksum correctly. > However the wrong data will be written to addresses indicated in H2. > > There are three obvious places this error can occur: > 1. the initiator > 2. an intelligent router/switch > 3. the target > > Not much can be done about initiator problems. > But I would like to detect problems introduced by the other areas. The middlebox problem is inherent in allowing middlebox functionality which was the rationale for using separate CRCs. One can stop a middlebox from making this mistake by running IPsec ESP's keyed cryptographic integrity check end-to-end - if some middlebox tries to get clever, the ESP integrity check fails and the packets that make up the corrupted PDU are dropped; if the middlebox error is persistent, the TCP connection will probably close. Changing the CRC check won't stop middleboxes - if some CRC gets in the way, the middlebox will strip the offending CRC and regenerate it - the result is *still* vulnerable to implementation bugs in the middlebox (and cleverer things like putting the data digest in the header or vice versa are vulnerable to similarly cleverer implementation bugs). > I think it is actually likely that my target software will run > in an environment that produces this type of error. > Imagining how an intelligent router/switch or off-board iSCSI target > hardware might operate, it is probably only a single bit logic error > that could cause this type of error. If "intelligent" means the router/switch is iSCSI-aware, ESP cryptographic integrity is the right means to protect against modifications - anything less (especially omitting the keying) is an invitation to the "strip the CRC and regenerate" scenario akin to the one in the middlebox paragraph above. If an iSCSI target is off-board, it has stripped, parsed, and discarded the iSCSI header - no CRC of any form will protect against a bug in that target that got confused about which data went with which header. Protocol implementations remove headers from data and have to keep track of what they're doing - there's no free lunch here (e.g., if a CRC covering header and data is added, an implementation will likely to check that and strip it, after which it can still get confused. > Maybe it is not appropriate to address this problem in the iSCSI spec > because I have described a problem that would not occur on the wire. > However iSCSI is the mechanism that allows more hardware and software > to be interposed between the SCSI initiator and the SCSI target. > iSCSI should not allow a single bit logic error in this additional > hardware and software to produce an undetectable error. The only problem scenario I see involves middleboxes, and iSCSI provides a tool (IPsec ESP cryptographic integrity) that addresses that problem. Did I miss anything? 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 --------------------------------------------------- --=_alternative 0024B5BCC2256B6E_= Content-Type: text/html; charset="us-ascii"
David,

Usually (not always) middleboxes terminate TCP connections. That is the reason some of us wanted a separate CRC on the data - even with IPsec.  The scenario suggested is not the only way in which middleboxes may mess up things.  An incrementaly recomputed  CRC may solve this type of failure but who says that the middle box will play by the rules and not mess-up with the data in unexpected ways?  I think that we have a decent solution for SCSI data integrity that is both simple and robust with respect to accidental failures.

Julo


Black_David@emc.com
Sent by: owner-ips@ece.cmu.edu

27-02-02 21:47

       
        To:        bmastors@aciesnetworks.com, ips@ece.cmu.edu
        cc:        
        Subject:        RE: header and data digest issue

       


> I think there is a problem with the current design of the
> header and data digest.
> There is a non-zero chance that an error could cause
> the target to process a single pdu that has a header from
> one pdu and data from a second pdu.
>
> This type of error is undetectable by the target with the CRC32C
> digests turned on.
>
> For example:
>         Initiator sends pdu 1 which contains header H1 and data D1
>         Initiator sends pdu 2 which contains header H2 and data D2
>         Target receives pdu 1 which contains header H1 and data D1
>         Target receives pdu 2 which contains header H2 and data D1 (bad)
> In this example the header and data digests will checksum correctly.
> However the wrong data will be written to addresses indicated in H2.
>
> There are three obvious places this error can occur:
>         1. the initiator
>         2. an intelligent router/switch
>         3. the target
>
> Not much can be done about initiator problems.
> But I would like to detect problems introduced by the other areas.

The middlebox problem is inherent in allowing middlebox functionality
which was the rationale for using separate CRCs.  One can stop a middlebox
from making this mistake by running IPsec ESP's keyed cryptographic
integrity
check end-to-end - if some middlebox tries to get clever, the ESP integrity
check fails and the packets that make up the corrupted PDU are dropped; if
the middlebox error is persistent, the TCP connection will probably close.
Changing the CRC check won't stop middleboxes - if some CRC gets in the way,
the middlebox will strip the offending CRC and regenerate it - the result
is *still* vulnerable to implementation bugs in the middlebox (and cleverer
things like putting the data digest in the header or vice versa are
vulnerable to similarly cleverer implementation bugs).

> I think it is actually likely that my target software will run
> in an environment that produces this type of error.
> Imagining how an intelligent router/switch or off-board iSCSI target
> hardware might operate, it is probably only a single bit logic error
> that could cause this type of error.

If "intelligent" means the router/switch is iSCSI-aware, ESP cryptographic
integrity is the right means to protect against modifications - anything
less (especially omitting the keying) is an invitation to the "strip the
CRC and regenerate" scenario akin to the one in the middlebox paragraph
above.

If an iSCSI target is off-board, it has stripped, parsed, and discarded
the iSCSI header - no CRC of any form will protect against a bug in that
target that got confused about which data went with which header.  Protocol
implementations remove headers from data and have to keep track of what
they're doing - there's no free lunch here (e.g., if a CRC covering header
and data is added, an implementation will likely to check that and strip it,
after which it can still get confused.

> Maybe it is not appropriate to address this problem in the iSCSI spec
> because I have described a problem that would not occur on the wire.
> However iSCSI is the mechanism that allows more hardware and software
> to be interposed between the SCSI initiator and the SCSI target.
> iSCSI should not allow a single bit logic error in this additional
> hardware and software to produce an undetectable error.

The only problem scenario I see involves middleboxes, and iSCSI
provides a tool (IPsec ESP cryptographic integrity) that addresses
that problem.  Did I miss anything?

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
---------------------------------------------------

--=_alternative 0024B5BCC2256B6E_=-- From owner-ips@ece.cmu.edu Thu Feb 28 02:45: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 CAA13843 for ; Thu, 28 Feb 2002 02:45:40 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1S6v8Z18832 for ips-outgoing; Thu, 28 Feb 2002 01:57:08 -0500 (EST) 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 g1S6uqH18807; Thu, 28 Feb 2002 01:56:52 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id HAA98474; Thu, 28 Feb 2002 07:56:46 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1S6wQl95626; Thu, 28 Feb 2002 07:58:27 +0100 To: Paul Koning Cc: Eddy_Quicksall@ivivity.com, ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: sector alignment for DataOut PDUs? X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 28 Feb 2002 08:58:34 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 28/02/2002 08:58:39, Serialize complete at 28/02/2002 08:58:39 Content-Type: multipart/alternative; boundary="=_alternative 002396BDC2256B6E_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 002396BDC2256B6E_= Content-Type: text/plain; charset="us-ascii" Where is the hint you are alluding to? Julo Paul Koning Sent by: owner-ips@ece.cmu.edu 27-02-02 19:20 To: Eddy_Quicksall@ivivity.com cc: ips@ece.cmu.edu Subject: RE: sector alignment for DataOut PDUs? >>>>> "Eddy" == Eddy Quicksall writes: Eddy> Given that the TCP issues of reassembly are so much more Eddy> complicated than the concatenation issues necessary for target Eddy> data alignment, is there really a problem here? Eddy> If there is a problem, can someone explain that in more detail? I'd describe it as an opportunity for optimization. Yes, at the TCP level your segments can be strange sizes. My goal is to make things better once you get up to the iSCSI level, and you're looking at an iSCSI PDU. Right now, the initiator is allowed to send data out in strange sized chunks. There's a requirement for 4 byte multiples but nothing stronger than that. If you're implementing a disk target, what you want to do is to take in the arriving stream of data from the initiator (DataOut or, if applicable, immediate data) and send that off to disk as it arrives. If data out boundaries are 512 byte multiples, this is straightforward: each time an iSCSI PDU arrives, you can send a disk write down your local disk I/O stack. But as matters stand now, it's more complex because the data out may end in the middle of a disk block, so the bookkeeping for what disk I/Os go with what iSCSI PDUs gets a lot more painful. To add to this, it seems entirely likely that initiators will use 512 byte multiples, especially if you negotiate burst sizes and max pdu sizes that are 512 byte multiples. But the current wording in the spec doesn't require that. (It does hint that targets may object if you don't do it that way -- which makes no sense at all unless there's a MUST for initiators to do what targets are allowed to expect.) So that's why I made the proposal. An alternative would be to tighten the spec so it requires all but the last PDU to be exactly the size of the negotiated max size that applies. That already appears to be the intent, so it may be the easier change. paul --=_alternative 002396BDC2256B6E_= Content-Type: text/html; charset="us-ascii"
Where is the hint you are alluding to? Julo


Paul Koning <ni1d@arrl.net>
Sent by: owner-ips@ece.cmu.edu

27-02-02 19:20

       
        To:        Eddy_Quicksall@ivivity.com
        cc:        ips@ece.cmu.edu
        Subject:        RE: sector alignment for DataOut PDUs?

       


>>>>> "Eddy" == Eddy Quicksall <Eddy_Quicksall@ivivity.com> writes:

Eddy> Given that the TCP issues of reassembly are so much more
Eddy> complicated than the concatenation issues necessary for target
Eddy> data alignment, is there really a problem here?

Eddy> If there is a problem, can someone explain that in more detail?

I'd describe it as an opportunity for optimization.

Yes, at the TCP level your segments can be strange sizes.  My goal is
to make things better once you get up to the iSCSI level, and you're
looking at an iSCSI PDU.

Right now, the initiator is allowed to send data out in strange sized
chunks.  There's a requirement for 4 byte multiples but nothing
stronger than that.

If you're implementing a disk target, what you want to do is to take
in the arriving stream of data from the initiator (DataOut or, if
applicable, immediate data) and send that off to disk as it arrives.
If data out boundaries are 512 byte multiples, this is
straightforward: each time an iSCSI PDU arrives, you can send a disk
write down your local disk I/O stack.  But as matters stand now, it's
more complex because the data out may end in the middle of a disk
block, so the bookkeeping for what disk I/Os go with what iSCSI PDUs
gets a lot more painful.

To add to this, it seems entirely likely that initiators will use 512
byte multiples, especially if you negotiate burst sizes and max pdu
sizes that are 512 byte multiples.  But the current wording in the
spec doesn't require that.  (It does hint that targets may object if
you don't do it that way -- which makes no sense at all unless there's
a MUST for initiators to do what targets are allowed to expect.)

So that's why I made the proposal.  An alternative would be to tighten
the spec so it requires all but the last PDU to be exactly the size of
the negotiated max size that applies.  That already appears to be the
intent, so it may be the easier change.

                paul

--=_alternative 002396BDC2256B6E_=-- From owner-ips@ece.cmu.edu Thu Feb 28 02:45: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 CAA13855 for ; Thu, 28 Feb 2002 02:45:59 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1S6v8g18834 for ips-outgoing; Thu, 28 Feb 2002 01:57:08 -0500 (EST) 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 g1S6uuH18815; Thu, 28 Feb 2002 01:56:56 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id HAA06070; Thu, 28 Feb 2002 07:56:43 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1S6wRl64562; Thu, 28 Feb 2002 07:58:27 +0100 To: "Robert D. Russell" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iscsi: version number in draft 11 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 28 Feb 2002 08:58:34 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 28/02/2002 08:58:37, Serialize complete at 28/02/2002 08:58:37 Content-Type: multipart/alternative; boundary="=_alternative 0024DB8CC2256B6E_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0024DB8CC2256B6E_= Content-Type: text/plain; charset="us-ascii" sure - julo "Robert D. Russell" Sent by: owner-ips@ece.cmu.edu 27-02-02 21:36 To: ips@ece.cmu.edu cc: Subject: iscsi: version number in draft 11 Julian: The version number in draft 10-94 is still 0x3, the same as it was in draft 9 and draft 10. Would you please change it to 0x4 for draft 11. Of course these numbers still need to be taken with a grain of salt, but testing is considerably simpler and more robust when one side identifies the draft it intends to conform to in a manner that can be checked by the other side. Thanks, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 --=_alternative 0024DB8CC2256B6E_= Content-Type: text/html; charset="us-ascii"
sure - julo


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

27-02-02 21:36

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iscsi: version number in draft 11

       


Julian:

The version number in draft 10-94 is still 0x3,
the same as it was in draft 9 and draft 10.

Would you please change it to 0x4 for draft 11.

Of course these numbers still need to be taken with
a grain of salt, but testing is considerably
simpler and more robust when one side identifies the
draft it intends to conform to in a manner that can
be checked by the other side.

Thanks,

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

--=_alternative 0024DB8CC2256B6E_=-- From owner-ips@ece.cmu.edu Thu Feb 28 03:39: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 DAA14603 for ; Thu, 28 Feb 2002 03:39:29 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1S7pqI21272 for ips-outgoing; Thu, 28 Feb 2002 02:51:52 -0500 (EST) 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 g1S7pmH21263; Thu, 28 Feb 2002 02:51:48 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id IAA138554; Thu, 28 Feb 2002 08:51:31 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1S7rO732470; Thu, 28 Feb 2002 08:53:24 +0100 To: Black_David@emc.com Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu, rdr@io.iol.unh.edu MIME-Version: 1.0 Subject: RE: iscsi: version number in draft 11 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 28 Feb 2002 09:53:23 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 28/02/2002 09:53:24, Serialize complete at 28/02/2002 09:53:24 Content-Type: multipart/alternative; boundary="=_alternative 002A5844C2256B6E_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 002A5844C2256B6E_= Content-Type: text/plain; charset="us-ascii" David, We could move to 10 when going RFC - version numbers are arbitrary anyhow. Julo Black_David@emc.com Sent by: owner-ips@ece.cmu.edu 28-02-02 01:13 To: rdr@io.iol.unh.edu, ips@ece.cmu.edu cc: Subject: RE: iscsi: version number in draft 11 Folks, I've warned in the past that this use of version numbers is going to cause problems, as it encourages the longevity of obsolete implementations that don't interoperate. Version numbers should NEVER have been used for identification of draft versions - in 20/20 hindsight a text key that could have been dropped from the final RFC would have been better. Prior guidance from the ADs has been that a version number change from 0 to 1 in going to RFC would be ok. Let's reset the version number to 0, and anyone still using something based on a draft from back when the version number was still 0 has something truly ancient and is SOL. 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: Robert D. Russell [mailto:rdr@io.iol.unh.edu] > Sent: Wednesday, February 27, 2002 2:36 PM > To: ips@ece.cmu.edu > Subject: iscsi: version number in draft 11 > > > Julian: > > The version number in draft 10-94 is still 0x3, > the same as it was in draft 9 and draft 10. > > Would you please change it to 0x4 for draft 11. > > Of course these numbers still need to be taken with > a grain of salt, but testing is considerably > simpler and more robust when one side identifies the > draft it intends to conform to in a manner that can > be checked by the other side. > > Thanks, > > Bob Russell > InterOperability Lab > University of New Hampshire > rdr@iol.unh.edu > 603-862-3774 > --=_alternative 002A5844C2256B6E_= Content-Type: text/html; charset="us-ascii"
David,

We could move to 10 when going RFC - version numbers are arbitrary anyhow.

Julo


Black_David@emc.com
Sent by: owner-ips@ece.cmu.edu

28-02-02 01:13

       
        To:        rdr@io.iol.unh.edu, ips@ece.cmu.edu
        cc:        
        Subject:        RE: iscsi: version number in draft 11

       


Folks,

I've warned in the past that this use of version numbers
is going to cause problems, as it encourages the longevity
of obsolete implementations that don't interoperate.  Version
numbers should NEVER have been used for identification of
draft versions - in 20/20 hindsight a text key that could
have been dropped from the final RFC would have been better.

Prior guidance from the ADs has been that a version number
change from 0 to 1 in going to RFC would be ok.  Let's
reset the version number to 0, and anyone still using
something based on a draft from back when the version number
was still 0 has something truly ancient and is SOL.

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: Robert D. Russell [mailto:rdr@io.iol.unh.edu]
> Sent: Wednesday, February 27, 2002 2:36 PM
> To: ips@ece.cmu.edu
> Subject: iscsi: version number in draft 11
>
>
> Julian:
>
> The version number in draft 10-94 is still 0x3,
> the same as it was in draft 9 and draft 10.
>
> Would you please change it to 0x4 for draft 11.
>
> Of course these numbers still need to be taken with
> a grain of salt, but testing is considerably
> simpler and more robust when one side identifies the
> draft it intends to conform to in a manner that can
> be checked by the other side.
>
> Thanks,
>
> Bob Russell
> InterOperability Lab
> University of New Hampshire
> rdr@iol.unh.edu
> 603-862-3774
>


--=_alternative 002A5844C2256B6E_=-- From owner-ips@ece.cmu.edu Thu Feb 28 09:17: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 JAA24111 for ; Thu, 28 Feb 2002 09:17:11 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1SDMVv15369 for ips-outgoing; Thu, 28 Feb 2002 08:22:31 -0500 (EST) 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 g1SDMTH15364 for ; Thu, 28 Feb 2002 08:22:29 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id <107NPMCN>; Thu, 28 Feb 2002 08:22:29 -0500 Message-ID: <25369470B6F0D41194820002B328BDD22F562F@ATLOPS> From: Eddy Quicksall To: Black_David@emc.com, rdr@io.iol.unh.edu, ips@ece.cmu.edu Subject: RE: iscsi: version number in draft 11 Date: Thu, 28 Feb 2002 08:22:28 -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 I agree. One thing we could do is to all agree to a "vendor specific" key that is used during our testing. Being vendor specific, it could still be used in the future. I suggest something like: X-draft=11 or X-draft=9,11 (that is assuming that no one will have a company called "draft") :-) Eddy -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Wednesday, February 27, 2002 6:13 PM To: rdr@io.iol.unh.edu; ips@ece.cmu.edu Subject: RE: iscsi: version number in draft 11 Folks, I've warned in the past that this use of version numbers is going to cause problems, as it encourages the longevity of obsolete implementations that don't interoperate. Version numbers should NEVER have been used for identification of draft versions - in 20/20 hindsight a text key that could have been dropped from the final RFC would have been better. Prior guidance from the ADs has been that a version number change from 0 to 1 in going to RFC would be ok. Let's reset the version number to 0, and anyone still using something based on a draft from back when the version number was still 0 has something truly ancient and is SOL. 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: Robert D. Russell [mailto:rdr@io.iol.unh.edu] > Sent: Wednesday, February 27, 2002 2:36 PM > To: ips@ece.cmu.edu > Subject: iscsi: version number in draft 11 > > > Julian: > > The version number in draft 10-94 is still 0x3, > the same as it was in draft 9 and draft 10. > > Would you please change it to 0x4 for draft 11. > > Of course these numbers still need to be taken with > a grain of salt, but testing is considerably > simpler and more robust when one side identifies the > draft it intends to conform to in a manner that can > be checked by the other side. > > Thanks, > > Bob Russell > InterOperability Lab > University of New Hampshire > rdr@iol.unh.edu > 603-862-3774 > From owner-ips@ece.cmu.edu Thu Feb 28 10:34: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 KAA28655 for ; Thu, 28 Feb 2002 10:34:49 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1SEf4A19946 for ips-outgoing; Thu, 28 Feb 2002 09:41:04 -0500 (EST) 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 g1SEf2H19940 for ; Thu, 28 Feb 2002 09:41:02 -0500 (EST) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g1SEeu008741 for ; Thu, 28 Feb 2002 09:40:56 -0500 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 g1SEetK08732; Thu, 28 Feb 2002 09:40:55 -0500 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with SMTP id g1SEetw32349; Thu, 28 Feb 2002 09:40:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15486.16759.415800.694055@pkoning.dev.equallogic.com> Date: Thu, 28 Feb 2002 09:40:55 -0500 From: Paul Koning To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: sector alignment for DataOut PDUs? References: 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 >>>>> "Julian" == Julian Satran writes: Julian> Where is the hint you are alluding to? >> .... (It does >> hint that targets may object if you don't do it that way -- >> which makes no sense at all unless there's a MUST for >> initiators to do what targets are allowed to expect.) In this section: 9.5 Unsolicited Data and Performance Unsolicited data on write are meant to reduce the effect of latency on throughput (no R2T is needed to start send- ing data). In addition, immediate data are meant to reduce the protocol overhead (both bandwidth and execu- tion time). However, negotiating an amount of unsolicited data for writes and sending less than the negotiated amount when the total data amount to be sent by a command is larger than the negotiated amount may negatively impact perfor- mance and may not be supported by all the targets. Specifically, the last sentence. That statement is not a good thing, because it explicitly permits failures to interoperate, which a protocol standard must never do. Instead, a receiver must always be required to accept anything that the standard permits the sender to send in a state that the sender can legitimately get to. There are two ways to fix this: one is to forbid the sender sending less than the negotiated unsolicited data length. The other is to require the receiver to accept unsolicited data of less than the negotiated length. Either change works because either change establishes interoperability. paul From owner-ips@ece.cmu.edu Thu Feb 28 11: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 LAA01917 for ; Thu, 28 Feb 2002 11:28:57 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1SFptS25017 for ips-outgoing; Thu, 28 Feb 2002 10:51:55 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1SFprH25011 for ; Thu, 28 Feb 2002 10:51:53 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Feb 2002 10:46:15 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937518@CORPMX14> From: Black_David@emc.com To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iscsi: version number in draft 11 Date: Thu, 28 Feb 2002 10:51:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C06F.CED234F0" 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_01C1C06F.CED234F0 Content-Type: text/plain; charset="iso-8859-1" Julian, The problem here is that I don't think the IESG regards them as arbitrary. Mark's message on this topic reveals the underlying issue here: > BTW, there are paying customers that are buying and using >"ancient" iSCSI products that use version 0. Resetting the version number gives vendors a very strong incentive to update those products so that they'll interoperate. The IESG has little interest in helping out folks who have shipped products based on Internet-Drafts (see the boilerplate introduction to every draft), and to the extent that this is the motivation for playing games with the version number, we're going to get a very poor reception. --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: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, February 28, 2002 2:53 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; rdr@io.iol.unh.edu Subject: RE: iscsi: version number in draft 11 David, We could move to 10 when going RFC - version numbers are arbitrary anyhow. Julo Black_David@emc.com Sent by: owner-ips@ece.cmu.edu 28-02-02 01:13 To: rdr@io.iol.unh.edu, ips@ece.cmu.edu cc: Subject: RE: iscsi: version number in draft 11 Folks, I've warned in the past that this use of version numbers is going to cause problems, as it encourages the longevity of obsolete implementations that don't interoperate. Version numbers should NEVER have been used for identification of draft versions - in 20/20 hindsight a text key that could have been dropped from the final RFC would have been better. Prior guidance from the ADs has been that a version number change from 0 to 1 in going to RFC would be ok. Let's reset the version number to 0, and anyone still using something based on a draft from back when the version number was still 0 has something truly ancient and is SOL. 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: Robert D. Russell [mailto:rdr@io.iol.unh.edu] > Sent: Wednesday, February 27, 2002 2:36 PM > To: ips@ece.cmu.edu > Subject: iscsi: version number in draft 11 > > > Julian: > > The version number in draft 10-94 is still 0x3, > the same as it was in draft 9 and draft 10. > > Would you please change it to 0x4 for draft 11. > > Of course these numbers still need to be taken with > a grain of salt, but testing is considerably > simpler and more robust when one side identifies the > draft it intends to conform to in a manner that can > be checked by the other side. > > Thanks, > > Bob Russell > InterOperability Lab > University of New Hampshire > rdr@iol.unh.edu > 603-862-3774 > ------_=_NextPart_001_01C1C06F.CED234F0 Content-Type: text/html; charset="iso-8859-1"
Julian,
 
The problem here is that I don't think the IESG regards them
as arbitrary.  Mark's message on this topic reveals the underlying
issue here:

> BTW, there are paying customers that are buying and using
>"ancient" iSCSI products that use version 0.

Resetting the version number gives vendors a very strong incentive to
update those products so that they'll interoperate.  The IESG has
little interest in helping out folks who have shipped products based
on Internet-Drafts (see the boilerplate introduction to every draft),
and to the extent that this is the motivation for playing games with
the version number, we're going to get a very poor reception.

--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: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, February 28, 2002 2:53 AM
To: Black_David@emc.com
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; rdr@io.iol.unh.edu
Subject: RE: iscsi: version number in draft 11


David,

We could move to 10 when going RFC - version numbers are arbitrary anyhow.

Julo


Black_David@emc.com
Sent by: owner-ips@ece.cmu.edu

28-02-02 01:13

       
        To:        rdr@io.iol.unh.edu, ips@ece.cmu.edu
        cc:        
        Subject:        RE: iscsi: version number in draft 11

       


Folks,

I've warned in the past that this use of version numbers
is going to cause problems, as it encourages the longevity
of obsolete implementations that don't interoperate.  Version
numbers should NEVER have been used for identification of
draft versions - in 20/20 hindsight a text key that could
have been dropped from the final RFC would have been better.

Prior guidance from the ADs has been that a version number
change from 0 to 1 in going to RFC would be ok.  Let's
reset the version number to 0, and anyone still using
something based on a draft from back when the version number
was still 0 has something truly ancient and is SOL.

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: Robert D. Russell [mailto:rdr@io.iol.unh.edu]
> Sent: Wednesday, February 27, 2002 2:36 PM
> To: ips@ece.cmu.edu
> Subject: iscsi: version number in draft 11
>
>
> Julian:
>
> The version number in draft 10-94 is still 0x3,
> the same as it was in draft 9 and draft 10.
>
> Would you please change it to 0x4 for draft 11.
>
> Of course these numbers still need to be taken with
> a grain of salt, but testing is considerably
> simpler and more robust when one side identifies the
> draft it intends to conform to in a manner that can
> be checked by the other side.
>
> Thanks,
>
> Bob Russell
> InterOperability Lab
> University of New Hampshire
> rdr@iol.unh.edu
> 603-862-3774
>


------_=_NextPart_001_01C1C06F.CED234F0-- From owner-ips@ece.cmu.edu Thu Feb 28 11: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 LAA02446 for ; Thu, 28 Feb 2002 11:36:37 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1SG60A26377 for ips-outgoing; Thu, 28 Feb 2002 11:06:00 -0500 (EST) 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 g1SG5wH26369 for ; Thu, 28 Feb 2002 11:05:58 -0500 (EST) Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.110.250.124]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 19F083AE1 for ; Thu, 28 Feb 2002 10:05:53 -0600 (CST) Received: from cceexc17.americas.cpqcorp.net ([16.110.250.84]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 28 Feb 2002 10:05:52 -0600 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:reservations Date: Thu, 28 Feb 2002 10:05:52 -0600 Message-ID: <78AF3C342AEAEF4BA33B35A8A15668C6019E21CB@cceexc17.americas.cpqcorp.net> Thread-Topic: iSCSI:reservations Thread-Index: AcHAKM4J4+ihx5cFQUG6mv8mqRUhrgAQ1nPA From: "Elliott, Robert" To: X-OriginalArrivalTime: 28 Feb 2002 16:05:52.0907 (UTC) FILETIME=[CBF9D5B0:01C1C071] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g1SG5xH26372 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, February 28, 2002 1:24 AM To: ips@ece.cmu.edu Subject: Re: iSCSI:reservations > We had long discussions on the reservation-clearing being > done (or not) at session close (FCP does this). > We concluded that it is probably a thing that should be > handled at SCSI level (it would be wrong for the transport > to mes-up SCSI state) and perhaps we should only state that > an indication about session failure should be passed to > SCSI. Mallikarjun and Randy have a set of good arguments > for not doing this implicitly that they would probably > want to share them with you. > > This is only a warning that this item in the clearing > appendix is going to change as this issue was debated > earlier on the list. > > Comments? T10 is going to discuss this issue on a Friday conference call for both iSCSI and SRP (InfiniBand) and should have a recommendation for you then. Anyone interested is welcome to join the discussion. Here is the meeting announcement posted to the T10 mailing list: * From the T10 Reflector (t10@t10.org), posted by: * "Simpson, Cris" * The SRP WG will discuss reservation issues for at least the first hour of this Friday's conference call. As the issues are of wide concern to the SCSI community, all interested parties are invited to participate. References: "Response to T10 Letter Ballot comments on SRP", Comment IBM050, Pages 37 and 104 ftp://ftp.t10.org/t10/document.01/01-328r3.pdf Rob Elliott, "Clearing effects of logouts on different protocols", t10 mailing list, 21 Feb 2002, <78AF3C342AEAEF4BA33B35A8A15668C60296DB2C@cceexc17.americas.cpqcorp.net> Mallikarjun Chadalapaka, "Reservations & Nexus" ftp://ftp.t10.org/t10/document.02/02-078r0.pdf Conference call information: March 1 0900-1100 PST 1.888.316.5901 or +1.617.801.9781 If you are not an SRP 'regular', please send mail to mailto:cris.simpson@intel.com?subject=Mar_1_passcode for the passcode. (This will ensure that I schedule enough lines.) Cris --- Rob Elliott, Compaq Server Storage Robert.Elliott@compaq.com From owner-ips@ece.cmu.edu Thu Feb 28 11:36: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 LAA02468 for ; Thu, 28 Feb 2002 11:36:45 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1SFcVG23920 for ips-outgoing; Thu, 28 Feb 2002 10:38:31 -0500 (EST) 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 g1SFcTH23915; Thu, 28 Feb 2002 10:38:29 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1SFXth09979; Thu, 28 Feb 2002 07:37:35 -0800 (PST) Received: from cisco.com (58509@mbakke-lnx.cisco.com [161.44.68.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA23966; Thu, 28 Feb 2002 07:33:53 -0800 (PST) Message-ID: <3C7E4A61.BE23B2D@cisco.com> Date: Thu, 28 Feb 2002 09:18:57 -0600 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: Black_David@emc.com, ips@ece.cmu.edu, owner-ips@ece.cmu.edu, rdr@io.iol.unh.edu Subject: Re: iscsi: version number in draft 11 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David- I agree with Julian on this one. We could make it 10 hex; any version starting with 0 is a draft, and anything higher than 10 (say version 11) would be a draft between the Proposed Standard RFC and the Draft Standard RFC, which will hopefully follow. The draft standard RFC could be version 20 hex. This would at least make it clear which versions are drafts (anything with non-zero second digit) and which versions are RFCs (anything with a zero in the second digit), and would be compatible with the version numbers we are using now. This might help with the ADs as well; we would be changing the "major version" from 0 to 1 at RFC time. BTW, there are paying customers that are buying and using "ancient" iSCSI products that use version 0. -- Mark Julian Satran wrote: > > David, > > We could move to 10 when going RFC - version numbers are arbitrary anyhow. > > Julo > > Black_David@emc.com > Sent by: owner-ips@ece.cmu.edu To: rdr@io.iol.unh.edu, ips@ece.cmu.edu > cc: > 28-02-02 01:13 Subject: RE: iscsi: version number in draft 11 > > > > Folks, > > I've warned in the past that this use of version numbers > is going to cause problems, as it encourages the longevity > of obsolete implementations that don't interoperate. Version > numbers should NEVER have been used for identification of > draft versions - in 20/20 hindsight a text key that could > have been dropped from the final RFC would have been better. > > Prior guidance from the ADs has been that a version number > change from 0 to 1 in going to RFC would be ok. Let's > reset the version number to 0, and anyone still using > something based on a draft from back when the version number > was still 0 has something truly ancient and is SOL. > > 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: Robert D. Russell [mailto:rdr@io.iol.unh.edu] > > Sent: Wednesday, February 27, 2002 2:36 PM > > To: ips@ece.cmu.edu > > Subject: iscsi: version number in draft 11 > > > > > > Julian: > > > > The version number in draft 10-94 is still 0x3, > > the same as it was in draft 9 and draft 10. > > > > Would you please change it to 0x4 for draft 11. > > > > Of course these numbers still need to be taken with > > a grain of salt, but testing is considerably > > simpler and more robust when one side identifies the > > draft it intends to conform to in a manner that can > > be checked by the other side. > > > > Thanks, > > > > Bob Russell > > InterOperability Lab > > University of New Hampshire > > rdr@iol.unh.edu > > 603-862-3774 > > -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Thu Feb 28 12:12: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 MAA05312 for ; Thu, 28 Feb 2002 12:12:22 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1SGIBX27472 for ips-outgoing; Thu, 28 Feb 2002 11:18:11 -0500 (EST) 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 g1SGI7H27468 for ; Thu, 28 Feb 2002 11:18:08 -0500 (EST) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g1SGI0009755 for ; Thu, 28 Feb 2002 11:18:00 -0500 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 g1SGI0K09746; Thu, 28 Feb 2002 11:18:00 -0500 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with SMTP id g1SGI0e04705; Thu, 28 Feb 2002 11:18:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15486.22583.837441.190315@pkoning.dev.equallogic.com> Date: Thu, 28 Feb 2002 11:17:59 -0500 From: Paul Koning To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: header and data digest issue References: 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 >>>>> "Julian" == Julian Satran writes: Julian> David, Usually (not always) middleboxes terminate TCP Julian> connections. That is the reason some of us wanted a separate Julian> CRC on the data - even with IPsec. The scenario suggested is Julian> not the only way in which middleboxes may mess up things. An Julian> incrementaly recomputed CRC may solve this type of failure Julian> but who says that the middle box will play by the rules and Julian> not mess-up with the data in unexpected ways? I think that Julian> we have a decent solution for SCSI data integrity that is Julian> both simple and robust with respect to accidental failures. Agreed. For any integrity mechanism, you can postulate an implementation sufficiently broken that it defeats the mechanism. That isn't the point of the CRC, or the TCP checksum, or other mechanisms. All those mechanisms are there to deal with bit errors caused by noise, and things of that sort. paul From owner-ips@ece.cmu.edu Thu Feb 28 12: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 MAA07216 for ; Thu, 28 Feb 2002 12:36:37 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1SH7iP01524 for ips-outgoing; Thu, 28 Feb 2002 12:07:44 -0500 (EST) 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 g1SH7RH01495 for ; Thu, 28 Feb 2002 12:07:28 -0500 (EST) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g1SH7J010570 for ; Thu, 28 Feb 2002 12:07:19 -0500 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 g1SH7IK10561; Thu, 28 Feb 2002 12:07:18 -0500 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with SMTP id g1SH7Ip08410; Thu, 28 Feb 2002 12:07:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15486.25542.231192.700308@pkoning.dev.equallogic.com> Date: Thu, 28 Feb 2002 12:07:18 -0500 From: Paul Koning To: sselvara@npd.hcltech.com Cc: ips@ece.cmu.edu Subject: Re: sector alignment for DataOut PDUs? References: <15486.16759.415800.694055@pkoning.dev.equallogic.com> <3C7E5F78.636AABA6@npd.hcltech.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 >>>>> "Sajay" == Sajay Selvaraj writes: Sajay> The sender should definitely avoid sending less data than the Sajay> negotiated value of unsolicited data length when more data is Sajay> available to be sent. Sajay> However, the total data length available to be sent itself Sajay> could be lesser than the negotiated value. This suggests that Sajay> while we should mandate the receiver to accept anything less Sajay> than the negotiated value, we should not force the initiator Sajay> to send exactly the same value as the negotiated value. In Sajay> other words, we cannot "forbid the sender sending less than Sajay> the negotiated value". I'm for the first option suggested by Sajay> Paul. Sajay, My comments were meant in the context of the case that the spec describes: " when the total data amount to be sent by a command is larger than the negotiated amount". So I abbreviated a bit. The more precise statement would be "one is to forbid the sender sending less than the negotiated unsolicited data length or the total I/O length, whichever is smaller". paul From owner-ips@ece.cmu.edu Thu Feb 28 12:36: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 MAA07256 for ; Thu, 28 Feb 2002 12:36:47 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1SGtuX00569 for ips-outgoing; Thu, 28 Feb 2002 11:55:56 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailnpd.hcltech.com ([203.197.145.76]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g1SGtqH00560 for ; Thu, 28 Feb 2002 11:55:52 -0500 (EST) Received: from npd.hcltech.com (sselvara-pc.hcltech.com [192.168.100.73]) by mailnpd.hcltech.com (8.11.0/8.11.0) with ESMTP id g1SGl2m12564; Thu, 28 Feb 2002 22:17:03 +0530 Message-ID: <3C7E5F78.636AABA6@npd.hcltech.com> Date: Thu, 28 Feb 2002 22:18:56 +0530 From: Sajay Selvaraj X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Koning CC: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: Re: sector alignment for DataOut PDUs? References: <15486.16759.415800.694055@pkoning.dev.equallogic.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The sender should definitely avoid sending less data than the negotiated value of unsolicited data length when more data is available to be sent. However, the total data length available to be sent itself could be lesser than the negotiated value. This suggests that while we should mandate the receiver to accept anything less than the negotiated value, we should not force the initiator to send exactly the same value as the negotiated value. In other words, we cannot "forbid the sender sending less than the negotiated value". I'm for the first option suggested by Paul. BTW, can we change "data amount" to "size of data" to be sent ? Regards, Sajay Paul Koning wrote: > > >>>>> "Julian" == Julian Satran writes: > > Julian> Where is the hint you are alluding to? > > >> .... (It does > >> hint that targets may object if you don't do it that way -- > >> which makes no sense at all unless there's a MUST for > >> initiators to do what targets are allowed to expect.) > > In this section: > > 9.5 Unsolicited Data and Performance > > Unsolicited data on write are meant to reduce the effect > of latency on throughput (no R2T is needed to start send- > ing data). In addition, immediate data are meant to > reduce the protocol overhead (both bandwidth and execu- > tion time). > > However, negotiating an amount of unsolicited data for > writes and sending less than the negotiated amount when > the total data amount to be sent by a command is larger > than the negotiated amount may negatively impact perfor- > mance and may not be supported by all the targets. > > Specifically, the last sentence. That statement is not a good thing, > because it explicitly permits failures to interoperate, which a > protocol standard must never do. Instead, a receiver must always be > required to accept anything that the standard permits the sender to > send in a state that the sender can legitimately get to. > > There are two ways to fix this: one is to forbid the sender sending > less than the negotiated unsolicited data length. The other is to > require the receiver to accept unsolicited data of less than the > negotiated length. Either change works because either change > establishes interoperability. > > paul -- http://san.hcltech.com From owner-ips@ece.cmu.edu Thu Feb 28 12:45: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 MAA07904 for ; Thu, 28 Feb 2002 12:45:40 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1SHLf002706 for ips-outgoing; Thu, 28 Feb 2002 12:21:41 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailnpd.hcltech.com ([203.197.145.76]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g1SHLaH02698 for ; Thu, 28 Feb 2002 12:21:36 -0500 (EST) Received: from npd.hcltech.com (sselvara-pc.hcltech.com [192.168.100.73]) by mailnpd.hcltech.com (8.11.0/8.11.0) with ESMTP id g1SHCmm13203; Thu, 28 Feb 2002 22:42:51 +0530 Message-ID: <3C7E6582.A8DB18CD@npd.hcltech.com> Date: Thu, 28 Feb 2002 22:44:42 +0530 From: Sajay Selvaraj X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Koning CC: ips@ece.cmu.edu Subject: Re: sector alignment for DataOut PDUs? References: <15486.16759.415800.694055@pkoning.dev.equallogic.com> <3C7E5F78.636AABA6@npd.hcltech.com> <15486.25542.231192.700308@pkoning.dev.equallogic.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Now both the options look valid. How about mandating both of them ? - target should accept immediate data which is lesser than the negotiated value of unsolicited data length - initiator should not send "less than the negotiated unsolicited data length or the total I/O length, whichever is smaller". I suppose most implementations would work this way even now. /Sajay Paul Koning wrote: > > >>>>> "Sajay" == Sajay Selvaraj writes: > > Sajay> The sender should definitely avoid sending less data than the > Sajay> negotiated value of unsolicited data length when more data is > Sajay> available to be sent. > > Sajay> However, the total data length available to be sent itself > Sajay> could be lesser than the negotiated value. This suggests that > Sajay> while we should mandate the receiver to accept anything less > Sajay> than the negotiated value, we should not force the initiator > Sajay> to send exactly the same value as the negotiated value. In > Sajay> other words, we cannot "forbid the sender sending less than > Sajay> the negotiated value". I'm for the first option suggested by > Sajay> Paul. > > Sajay, > > My comments were meant in the context of the case that the spec > describes: " when the total data amount to be sent by a command is > larger than the negotiated amount". So I abbreviated a bit. The more > precise statement would be "one is to forbid the sender sending less > than the negotiated unsolicited data length or the total I/O length, > whichever is smaller". > > paul -- http://san.hcltech.com From owner-ips@ece.cmu.edu Thu Feb 28 13:26: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 NAA10748 for ; Thu, 28 Feb 2002 13:26:54 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1SHXnl03783 for ips-outgoing; Thu, 28 Feb 2002 12:33:49 -0500 (EST) 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 g1SHXhH03768 for ; Thu, 28 Feb 2002 12:33:44 -0500 (EST) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g1SHXZ010825 for ; Thu, 28 Feb 2002 12:33:35 -0500 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 g1SHXZK10816; Thu, 28 Feb 2002 12:33:35 -0500 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with SMTP id g1SHXZL09552; Thu, 28 Feb 2002 12:33:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15486.27118.944371.978679@pkoning.dev.equallogic.com> Date: Thu, 28 Feb 2002 12:33:34 -0500 From: Paul Koning To: sselvara@npd.hcltech.com Cc: ips@ece.cmu.edu Subject: Re: sector alignment for DataOut PDUs? References: <15486.16759.415800.694055@pkoning.dev.equallogic.com> <3C7E5F78.636AABA6@npd.hcltech.com> <15486.25542.231192.700308@pkoning.dev.equallogic.com> <3C7E6582.A8DB18CD@npd.hcltech.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 >>>>> "Sajay" == Sajay Selvaraj writes: Sajay> Hi, Now both the options look valid. How about mandating both Sajay> of them ? Sajay> - target should accept immediate data which is lesser than the Sajay> negotiated value of unsolicited data length - initiator should Sajay> not send "less than the negotiated unsolicited data length or Sajay> the total I/O length, whichever is smaller". You could do that. Unfortunately, as the spec points out, flexibility comes at a cost. If you want to make the receiver as simple and efficient as possible, the best answer is to take away options from the sender. Is it important for the sender to be able to send short data? It's not clear to me why it would be. So if it isn't a problem to require the sender to send the full amount when there is enough total data to do so, then this allows the receiver to rely on that and be simpler and possibly more efficient. The current spec points in that direction; the issue is that it doesn't state it strongly enough to ensure interoperability. My proposal #1 keeps the intent as it was but makes the requirement stronger so you do get interoperability. paul From owner-ips@ece.cmu.edu Thu Feb 28 14:32: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 OAA14984 for ; Thu, 28 Feb 2002 14:32:56 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1SJ5Gt11560 for ips-outgoing; Thu, 28 Feb 2002 14:05:16 -0500 (EST) 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 g1SJ5EH11553 for ; Thu, 28 Feb 2002 14:05:14 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id UAA143376 for ; Thu, 28 Feb 2002 20:05:08 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1SJ6ol28460 for ; Thu, 28 Feb 2002 20:06:53 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: revised draft X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 28 Feb 2002 21:06:57 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 28/02/2002 21:06:59, Serialize complete at 28/02/2002 21:06:59 Content-Type: multipart/alternative; boundary="=_alternative 00680309C2256B6E_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00680309C2256B6E_= Content-Type: text/plain; charset="us-ascii" Dear colleagues, I just submitted a new version of the CRC memo as: draft-sheinwald-iscsi-crc-01.txt You may want to take a close look at the new Section 5. Enjoy, Julo ----- Forwarded by Julian Satran/Haifa/IBM on 28-02-02 20:53 ----- Julian Satran 28-02-02 20:52 To: internet-drafts@ietf.org cc: From: Julian Satran/Haifa/IBM@IBMIL Subject: revised draft On behalf of the team of authors 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-sheinwald-iscsi-crc-01.txt http://www.haifa.il.ibm.com/satran/ips/draft-sheinwald-iscsi-crc-01.pdf This version completely replaces: draft-sheinwald-iscsi-crc-00.txt Julian Satran - IBM Research Laboratory at Haifa --=_alternative 00680309C2256B6E_= Content-Type: text/html; charset="us-ascii"
Dear colleagues,

I just submitted a new version of the CRC memo as:

draft-sheinwald-iscsi-crc-01.txt

You may want to take a close look at the new Section 5.

Enjoy,
Julo
----- Forwarded by Julian Satran/Haifa/IBM on 28-02-02 20:53 -----
Julian Satran

28-02-02 20:52

       
        To:        internet-drafts@ietf.org
        cc:        
        From:        Julian Satran/Haifa/IBM@IBMIL
        Subject:        revised draft

       



On behalf of the team of authors 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-sheinwald-iscsi-crc-01.txt

http://www.haifa.il.ibm.com/satran/ips/draft-sheinwald-iscsi-crc-01.pdf


This version completely replaces:

draft-sheinwald-iscsi-crc-00.txt



Julian Satran - IBM Research Laboratory at Haifa





















--=_alternative 00680309C2256B6E_=-- From owner-ips@ece.cmu.edu Thu Feb 28 14:36: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 OAA15130 for ; Thu, 28 Feb 2002 14:36:46 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1SIcrD09170 for ips-outgoing; Thu, 28 Feb 2002 13:38:53 -0500 (EST) 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 g1SIcoH09159 for ; Thu, 28 Feb 2002 13:38:50 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id <107NPMHF>; Thu, 28 Feb 2002 13:38:49 -0500 Message-ID: <25369470B6F0D41194820002B328BDD22F5654@ATLOPS> From: Eddy Quicksall To: "Martin, Nick" , Paul Koning Cc: ips@ece.cmu.edu Subject: RE: sector alignment for DataOut PDUs? Date: Thu, 28 Feb 2002 13:38:47 -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 I think we got rid of the special case of 0 when the minimum is other than 0. I would hate to see it come back. How about = instead? Then you don't have to mention the special case because a 1 would mean "no boundary alignment limitation". Eddy -----Original Message----- From: Martin, Nick [mailto:Nick.Martin@compaq.com] Sent: Wednesday, February 27, 2002 8:41 PM To: Paul Koning Cc: ips@ece.cmu.edu Subject: RE: sector alignment for DataOut PDUs? Paul, As Rod Harrison points out, MaxRecvPDULength is not negotiated, it is "declared" and is likely to be different for Initiator and Target. I had missed the implication of this change which occurred at draft 09. I can now appreciate your earlier proposal. To be fair to all targets, we should allow targets with arbitrary sized sectors/blocks to request the same kind of boundary alignment. Today we already have a need to support 512, 1K, 2K, and 4K sectors for disk, and anything from 512 up to at least 64K blocks for tape (including non-powers of 2 like 10K). [Ouch, I just realized that the tape block size can be changed mid-session, the most likely time being after a media change. The tape folks may not be able to use of this in the same way, but let's not prevent them from trying.] Further we do not really want iSCSI initiators (or their drivers) to have to guess or issue SCSI commands to learn the sector size. The size needs to be specified by the target during operational parameter negotiation if it is requesting sector/block aligned PDU payloads. I actually do not think unaligned payloads are likely, but there is nothing to prevent them. We may simplify some target designs by eliminating the requirement to support them. Certainly, we want to eliminate loopholes which allow compliant but non-interoperable implementations. Please consider whether the following proposal meets all of your requirements. Proposed addition to chapter 12 to enable requiring sector aligned PDU payloads: " DataPDUAlignment Use: LO Senders: Target and Initiator Scope: SW DataPDUAlignment= The default is 0. The initiator and target negotiate the alignment boundary on which data transfers may be continued to a subsequent PDU. The value 0 means no boundary alignment limitation is imposed on data carrying PDUs. The minimum of two non-zero values is selected. If one value is zero, then the other value is selected. This is intended primarily for a target to force an initiator to send PDU data buffers whose boundaries match physical media boundaries such as disk sector size. When DataPDUAlignment is non-zero, for any PDU other than the last in a sequence, the PDU data segment length (DataSegmentLength) is required to be an integer multiple of DataPDUAlignment less than or equal to MaxRecvPDULength. " Thanks, Nick > -----Original Message----- > From: Paul Koning [mailto:ni1d@arrl.net] > Sent: Wednesday, February 27, 2002 12:57 PM > To: Martin, Nick > Cc: ips@ece.cmu.edu > Subject: RE: sector alignment for DataOut PDUs? > > > >>>>> "Nick" == Martin, Nick writes: > > Nick> Paul, For all data carrying PDUs except the last in a sequence, > Nick> the sender is expected to send maximum sized PDU allowed. When > Nick> the negotiated maximum is a multiple of 512, this effect is > Nick> what you request. > > Nick> I thought this was a requirement, but I did not find it as such > Nick> in draft 10. ... > > Nick> IMHO, it makes more sense to include stronger wording > Nick> encouraging maximum negotiated length transfers rather than to > Nick> add another parameter requiring PDU breaks on different > Nick> boundaries. > > That sounds like a fine suggestion, if it gives the target enough > power to achieve the alignment I'm looking for. Strengthening the > text you quoted is a start, but other places would have to be > strengthened as well -- for example the rules on responding to an R2T. > > Nick> If such initiator behavior may not be supported by all targets, > Nick> then the initiators SHOULD NOT do it. > > That's not sufficient. You need "MUST NOT". The reason: if you say > "should not" then you can build a conforming initiator that cannot > interoperate with a conforming target. All correctly written protocol > specs have the property that conformance implies interoperability. > (Unfortunately, few specs pass this test... :-( ) So a target can be > allowed to rely on full size PDUs only if initiators are required (not > merely encouraged) to send full size PDUs. > > paul > > From owner-ips@ece.cmu.edu Thu Feb 28 14:46: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 OAA15587 for ; Thu, 28 Feb 2002 14:46:33 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1SJTsV13863 for ips-outgoing; Thu, 28 Feb 2002 14:29:54 -0500 (EST) 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 g1SJTpH13857; Thu, 28 Feb 2002 14:29:51 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id UAA64974; Thu, 28 Feb 2002 20:29:45 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1SJVTl91920; Thu, 28 Feb 2002 20:31:30 +0100 To: "Elliott, Robert" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI:reservations X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 28 Feb 2002 21:31:36 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 28/02/2002 21:31:39, Serialize complete at 28/02/2002 21:31:39 Content-Type: multipart/alternative; boundary="=_alternative 006A9B9EC2256B6E_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 006A9B9EC2256B6E_= Content-Type: text/plain; charset="us-ascii" Elliott, Thanks. Unfortunately I have to send our text before the Friday call time (too close to the IETF deadline) so we will assume some outcome and adjust for the T10 decision later. Julo "Elliott, Robert" Sent by: owner-ips@ece.cmu.edu 28-02-02 18:05 To: cc: Subject: RE: iSCSI:reservations -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, February 28, 2002 1:24 AM To: ips@ece.cmu.edu Subject: Re: iSCSI:reservations > We had long discussions on the reservation-clearing being > done (or not) at session close (FCP does this). > We concluded that it is probably a thing that should be > handled at SCSI level (it would be wrong for the transport > to mes-up SCSI state) and perhaps we should only state that > an indication about session failure should be passed to > SCSI. Mallikarjun and Randy have a set of good arguments > for not doing this implicitly that they would probably > want to share them with you. > > This is only a warning that this item in the clearing > appendix is going to change as this issue was debated > earlier on the list. > > Comments? T10 is going to discuss this issue on a Friday conference call for both iSCSI and SRP (InfiniBand) and should have a recommendation for you then. Anyone interested is welcome to join the discussion. Here is the meeting announcement posted to the T10 mailing list: * From the T10 Reflector (t10@t10.org), posted by: * "Simpson, Cris" * The SRP WG will discuss reservation issues for at least the first hour of this Friday's conference call. As the issues are of wide concern to the SCSI community, all interested parties are invited to participate. References: "Response to T10 Letter Ballot comments on SRP", Comment IBM050, Pages 37 and 104 ftp://ftp.t10.org/t10/document.01/01-328r3.pdf Rob Elliott, "Clearing effects of logouts on different protocols", t10 mailing list, 21 Feb 2002, <78AF3C342AEAEF4BA33B35A8A15668C60296DB2C@cceexc17.americas.cpqcorp.net> Mallikarjun Chadalapaka, "Reservations & Nexus" ftp://ftp.t10.org/t10/document.02/02-078r0.pdf Conference call information: March 1 0900-1100 PST 1.888.316.5901 or +1.617.801.9781 If you are not an SRP 'regular', please send mail to mailto:cris.simpson@intel.com?subject=Mar_1_passcode for the passcode. (This will ensure that I schedule enough lines.) Cris --- Rob Elliott, Compaq Server Storage Robert.Elliott@compaq.com --=_alternative 006A9B9EC2256B6E_= Content-Type: text/html; charset="us-ascii"
Elliott,

Thanks. Unfortunately I have to send our text before the Friday call time (too close to the IETF deadline) so we will assume
some outcome and adjust for the T10 decision later.

Julo


"Elliott, Robert" <Robert.Elliott@compaq.com>
Sent by: owner-ips@ece.cmu.edu

28-02-02 18:05

       
        To:        <ips@ece.cmu.edu>
        cc:        
        Subject:        RE: iSCSI:reservations

       



-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, February 28, 2002 1:24 AM
To: ips@ece.cmu.edu
Subject: Re: iSCSI:reservations

> We had long discussions on the reservation-clearing being
> done (or not) at session close (FCP does this).
>  We concluded that it is probably a thing that should be
> handled at SCSI level (it would be wrong for the transport
> to mes-up SCSI state) and perhaps we should only state that
> an indication about session failure should be passed to
> SCSI.  Mallikarjun and Randy have a set of good arguments
> for not doing this implicitly that they would probably
> want to share them with you.
>
> This is only a warning that this item in the clearing
> appendix is going to change as this issue was debated
> earlier on the list.
>
> Comments?

T10 is going to discuss this issue on a Friday conference call for both
iSCSI and SRP (InfiniBand) and should have a recommendation for you
then.  Anyone interested is welcome to join the discussion.

Here is the meeting announcement posted to the T10 mailing list:

* From the T10 Reflector (t10@t10.org), posted by:
* "Simpson, Cris" <cris.simpson@intel.com>
*
The SRP WG will discuss reservation issues for at least the first hour
of
this Friday's conference call. As the issues are of wide concern to the
SCSI community, all interested parties are invited to participate.

References:
"Response to T10 Letter Ballot comments on SRP",
Comment IBM050, Pages 37 and 104
ftp://ftp.t10.org/t10/document.01/01-328r3.pdf
Rob Elliott, "Clearing effects of logouts on different protocols",
t10 mailing list, 21 Feb 2002,
<78AF3C342AEAEF4BA33B35A8A15668C60296DB2C@cceexc17.americas.cpqcorp.net>
Mallikarjun Chadalapaka, "Reservations & Nexus"
ftp://ftp.t10.org/t10/document.02/02-078r0.pdf


Conference call information:
March 1 0900-1100 PST
1.888.316.5901 or +1.617.801.9781
If you are not an SRP 'regular', please send
mail to mailto:cris.simpson@intel.com?subject=Mar_1_passcode for the
passcode. (This will ensure that I schedule enough lines.)
Cris

---
Rob Elliott, Compaq Server Storage
Robert.Elliott@compaq.com

--=_alternative 006A9B9EC2256B6E_=-- From owner-ips@ece.cmu.edu Thu Feb 28 14: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 OAA16206 for ; Thu, 28 Feb 2002 14:57:02 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1SJI8X12810 for ips-outgoing; Thu, 28 Feb 2002 14:18:08 -0500 (EST) 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 g1SJI5H12798 for ; Thu, 28 Feb 2002 14:18:05 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id UAA33952 for ; Thu, 28 Feb 2002 20:17:59 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1SJJil51760 for ; Thu, 28 Feb 2002 20:19:44 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: sector alignment for DataOut PDUs? X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 28 Feb 2002 21:19:51 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 28/02/2002 21:19:53, Serialize complete at 28/02/2002 21:19:53 Content-Type: multipart/alternative; boundary="=_alternative 00699487C2256B6E_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00699487C2256B6E_= Content-Type: text/plain; charset="us-ascii" It reffers explicitely (and with good reason) to unsolicited data ONLY. See the archives for a reason. Solicited bursts are what the target asks through R2T. Julo Paul Koning 28-02-02 16:40 To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: sector alignment for DataOut PDUs? >>>>> "Julian" == Julian Satran writes: Julian> Where is the hint you are alluding to? >> .... (It does >> hint that targets may object if you don't do it that way -- >> which makes no sense at all unless there's a MUST for >> initiators to do what targets are allowed to expect.) In this section: 9.5 Unsolicited Data and Performance Unsolicited data on write are meant to reduce the effect of latency on throughput (no R2T is needed to start send- ing data). In addition, immediate data are meant to reduce the protocol overhead (both bandwidth and execu- tion time). However, negotiating an amount of unsolicited data for writes and sending less than the negotiated amount when the total data amount to be sent by a command is larger than the negotiated amount may negatively impact perfor- mance and may not be supported by all the targets. Specifically, the last sentence. That statement is not a good thing, because it explicitly permits failures to interoperate, which a protocol standard must never do. Instead, a receiver must always be required to accept anything that the standard permits the sender to send in a state that the sender can legitimately get to. There are two ways to fix this: one is to forbid the sender sending less than the negotiated unsolicited data length. The other is to require the receiver to accept unsolicited data of less than the negotiated length. Either change works because either change establishes interoperability. paul --=_alternative 00699487C2256B6E_= Content-Type: text/html; charset="us-ascii"

It reffers explicitely (and with good reason) to unsolicited data ONLY.
See the archives for a reason.
Solicited bursts are what the target asks through R2T.

Julo


Paul Koning <ni1d@arrl.net>

28-02-02 16:40

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        RE: sector alignment for DataOut PDUs?

       


>>>>> "Julian" == Julian Satran <Julian_Satran@il.ibm.com> writes:

Julian> Where is the hint you are alluding to?

>> ....  (It does
>> hint that targets may object if you don't do it that way --
>> which makes no sense at all unless there's a MUST for
>> initiators to do what targets are allowed to expect.)

In this section:

    9.5  Unsolicited Data and Performance

       Unsolicited data on write are meant to reduce the effect
       of latency on throughput (no R2T is needed to start send-
       ing data).  In addition, immediate data are meant to
       reduce the protocol overhead (both bandwidth and execu-
       tion time).

       However, negotiating an amount of unsolicited data for
       writes and sending less than the negotiated amount when
       the total data amount to be sent by a command is larger
       than the negotiated amount may negatively impact perfor-
       mance and may not be supported by all the targets.

Specifically, the last sentence.  That statement is not a good thing,
because it explicitly permits failures to interoperate, which a
protocol standard must never do.  Instead, a receiver must always be
required to accept anything that the standard permits the sender to
send in a state that the sender can legitimately get to.

There are two ways to fix this: one is to forbid the sender sending
less than the negotiated unsolicited data length.  The other is to
require the receiver to accept unsolicited data of less than the
negotiated length.  Either change works because either change
establishes interoperability.

                    paul



--=_alternative 00699487C2256B6E_=-- From owner-ips@ece.cmu.edu Thu Feb 28 15: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 PAA16971 for ; Thu, 28 Feb 2002 15:10:59 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1SJYRo14315 for ips-outgoing; Thu, 28 Feb 2002 14:34:27 -0500 (EST) 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 g1SJYQH14310 for ; Thu, 28 Feb 2002 14:34:26 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel13.hp.com (Postfix) with ESMTP id 7AD1F400089; Thu, 28 Feb 2002 11:34:20 -0800 (PST) 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 LAA07091; Thu, 28 Feb 2002 11:36:00 -0800 (PST) Message-ID: <004b01c1c08e$ea576690$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Elliott, Robert" , References: <78AF3C342AEAEF4BA33B35A8A15668C6019E21CB@cceexc17.americas.cpqcorp.net> Subject: Re: iSCSI:reservations Date: Thu, 28 Feb 2002 11:34:18 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > T10 is going to discuss this issue on a Friday conference call for both > iSCSI and SRP (InfiniBand) and should have a recommendation for you > then. I would like that. The reservations discussion is also currently scheduled on CAP agenda for the upcoming Dallas T10 meetings starting March 11. For a discussion of why reservations must surive session failures/logouts, please see the discussion paper at: ftp://ftp.t10.org/t10/document.02/02-078r1.pdf -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ----- Original Message ----- From: "Elliott, Robert" To: Sent: Thursday, February 28, 2002 8:05 AM Subject: RE: iSCSI:reservations > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Thursday, February 28, 2002 1:24 AM > To: ips@ece.cmu.edu > Subject: Re: iSCSI:reservations > > > We had long discussions on the reservation-clearing being > > done (or not) at session close (FCP does this). > > We concluded that it is probably a thing that should be > > handled at SCSI level (it would be wrong for the transport > > to mes-up SCSI state) and perhaps we should only state that > > an indication about session failure should be passed to > > SCSI. Mallikarjun and Randy have a set of good arguments > > for not doing this implicitly that they would probably > > want to share them with you. > > > > This is only a warning that this item in the clearing > > appendix is going to change as this issue was debated > > earlier on the list. > > > > Comments? > > T10 is going to discuss this issue on a Friday conference call for both > iSCSI and SRP (InfiniBand) and should have a recommendation for you > then. Anyone interested is welcome to join the discussion. > > Here is the meeting announcement posted to the T10 mailing list: > > * From the T10 Reflector (t10@t10.org), posted by: > * "Simpson, Cris" > * > The SRP WG will discuss reservation issues for at least the first hour > of > this Friday's conference call. As the issues are of wide concern to the > SCSI community, all interested parties are invited to participate. > > References: > "Response to T10 Letter Ballot comments on SRP", > Comment IBM050, Pages 37 and 104 > ftp://ftp.t10.org/t10/document.01/01-328r3.pdf > Rob Elliott, "Clearing effects of logouts on different protocols", > t10 mailing list, 21 Feb 2002, > <78AF3C342AEAEF4BA33B35A8A15668C60296DB2C@cceexc17.americas.cpqcorp.net> > Mallikarjun Chadalapaka, "Reservations & Nexus" > ftp://ftp.t10.org/t10/document.02/02-078r0.pdf > > > Conference call information: > March 1 0900-1100 PST > 1.888.316.5901 or +1.617.801.9781 > If you are not an SRP 'regular', please send > mail to mailto:cris.simpson@intel.com?subject=Mar_1_passcode for the > passcode. (This will ensure that I schedule enough lines.) > Cris > > --- > Rob Elliott, Compaq Server Storage > Robert.Elliott@compaq.com > > > From owner-ips@ece.cmu.edu Thu Feb 28 15:23: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 PAA17732 for ; Thu, 28 Feb 2002 15:23:48 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1SJi1f15095 for ips-outgoing; Thu, 28 Feb 2002 14:44:01 -0500 (EST) 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 g1SIM1H07802 for ; Thu, 28 Feb 2002 13:22:01 -0500 (EST) Received: by mercury.corp.iready.com with Internet Mail Service (5.5.2653.19) id <1LVD5FKP>; Thu, 28 Feb 2002 10:21:50 -0800 Message-ID: <034670D62D19D31180990090277A37B701ABDE5A@mercury.corp.iready.com> From: Bart Crane To: "'ips@ece.cmu.edu'" Subject: Digests As Connection-Specific Parameters Date: Thu, 28 Feb 2002 10:21:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C084.C8865F30" 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_01C1C084.C8865F30 Content-Type: text/plain; charset="iso-8859-1" Hello, I was asked to follow up on the question that came up at the plugfest about Digests being Session-wide parameters? Digests should be a connection-specific parameter in the event that some boards can and some boards can not accelerate the digest calculation. Bart. ------_=_NextPart_001_01C1C084.C8865F30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Digests As Connection-Specific Parameters

Hello, I was asked to follow up on the question that = came up at the plugfest about Digests being Session-wide = parameters?   Digests should be a connection-specific = parameter in the event that some boards can and some boards can not = accelerate the digest calculation. 

Bart.

------_=_NextPart_001_01C1C084.C8865F30-- From owner-ips@ece.cmu.edu Thu Feb 28 16:25: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 QAA20475 for ; Thu, 28 Feb 2002 16:25:43 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1SK1v016720 for ips-outgoing; Thu, 28 Feb 2002 15:01:57 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13706.mail.yahoo.com (web13706.mail.yahoo.com [216.136.175.139]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g1SK1tH16716 for ; Thu, 28 Feb 2002 15:01:55 -0500 (EST) Message-ID: <20020228200150.91956.qmail@web13706.mail.yahoo.com> Received: from [192.52.58.4] by web13706.mail.yahoo.com via HTTP; Thu, 28 Feb 2002 12:01:50 PST Date: Thu, 28 Feb 2002 12:01:50 -0800 (PST) From: Martins Krikis Subject: RE: sector alignment for DataOut PDUs? To: ips@ece.cmu.edu In-Reply-To: <25369470B6F0D41194820002B328BDD22F5654@ATLOPS> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I like the DataPDUAlignment parameter. (Just mandating to send maximum amount of data that's allowed, while being a good thing, still cannot guarantee the right alignment if those limits are not the right multiples.) But I don't see why the selection function should be the minimum of two numbers. That way the outcome may be completely inapropriate for the target. I think that whatever the target declares should be the final value. So the selection function should be called, IMHO, "target said so". Also, (I'm quoting Nick): > When DataPDUAlignment is non-zero, > for any PDU other than the last in a > sequence, the PDU data segment length > (DataSegmentLength) is required to > be an integer multiple of DataPDUAlignment > less than or equal to MaxRecvPDULength. In case of Data_out pdu-s even the last one should be aligned, shouldn't it? Since all PDU-s have brought data aligned on block-size, if the last one does the same, we guarantee that the total data transfer length is a multiple of block-size, which certainly must be so, right? So far I don't see a guarantee that it will be, but I feel it must match the length carried by CDB which is expressed as the number of blocks... Finally, speaking about MaxRecvPDULength, this really is the last of operational parameters that is not negotiated, but instead declared, right? That makes it different from others. Plus, the same key means different things depending on which direction it is sent. While I'm not as upset with this as I was about RFMarkInt, wouldn't it look cleaner if we used two different keys, MaxORecvPDULength and MaxIRecvPDULength? We could even say that they are negotiated with the very special selection functions "initiator said so" and "target said so", respectively... Any comments? Martins Krikis, Intel Corp. Disclaimer: These opinions are my own and may not reflect those of my employer. __________________________________________________ Do You Yahoo!? Yahoo! Greetings - Send FREE e-cards for every occasion! http://greetings.yahoo.com From owner-ips@ece.cmu.edu Thu Feb 28 17:18: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 RAA22883 for ; Thu, 28 Feb 2002 17:18:26 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1SL50L22149 for ips-outgoing; Thu, 28 Feb 2002 16:05:00 -0500 (EST) 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 g1SL4IH22086 for ; Thu, 28 Feb 2002 16:04:19 -0500 (EST) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g1SL4A013308 for ; Thu, 28 Feb 2002 16:04:10 -0500 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 g1SL48K13302 for ; Thu, 28 Feb 2002 16:04:09 -0500 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with SMTP id g1SL48w32107 for ; Thu, 28 Feb 2002 16:04:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15486.39752.205751.571182@pkoning.dev.equallogic.com> Date: Thu, 28 Feb 2002 16:04:08 -0500 From: Paul Koning To: ips@ece.cmu.edu Subject: RE: sector alignment for DataOut PDUs? References: 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 >>>>> "Julian" == Julian Satran writes: Julian> It reffers explicitely (and with good reason) to unsolicited Julian> data ONLY. See the archives for a reason. Solicited bursts Julian> are what the target asks through R2T. Yes, I realize that. I'm afraid what happened is that the discussion drifted off to a different (but related) topic. Please ignore the "Subject" string on the mail. The new subject is: what should the sender and receiver payload length rules be, to ensure interoperability? My comment was specifically to the text of section 9.5. It allows a sender to send less than the negotiated unsolicited data length even though there is more to be sent. Yes, it says that's not optimal. But it is allowed. It then goes on to say that targets are allowed not to support initiators that do this. In other words, you're explicitly allowing non-interoperable implementations. I believe that this is not a good thing for a standard to do. Unfortunately, it certainly happens that a standard, by accident, ends up specifying legal combinations of choices that cause interop failures. But those should be viewed as bugs in the spec and should be repaired when they are found. So what I would like to see for section 9.5: either require senders to send the full negotiated unsolicited data length as unsolicited data, whenever they have that much total data to send -- or say that receivers MUST accept unsolicited data of less than the negotiated length even when the total I/O length is larger than that. I prefer the first choice (keep the target simpler). As for R2T, is the same sort of question valid there? As far as I can tell, it is legal for the initiator to send less data than the amount requested in the Desired Data Transfer Length. If so, then for interoperability the target must be required to handle that case. On the other hand, if you don't want to make the target deal with that extra complexity, then the rule for R2T needs to be that the initiator must respond with DataOut PDUs that add up to exactly the amount asked for (rather than at most the amount asked for). And just as for the unsolicited case, either answer works but I prefer the one that keeps the target simpler (i.e., require the full length). paul From owner-ips@ece.cmu.edu Thu Feb 28 17: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 RAA23642 for ; Thu, 28 Feb 2002 17:32:54 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1SLSlG24176 for ips-outgoing; Thu, 28 Feb 2002 16:28:47 -0500 (EST) 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 g1SLSjH24170 for ; Thu, 28 Feb 2002 16:28:45 -0500 (EST) Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id NAA03395 for ips@ece.cmu.edu; Thu, 28 Feb 2002 13:28:34 -0800 (PST) From: Keith McCloghrie Message-Id: <200202282128.NAA03395@cisco.com> Subject: FC-Mgmt MIB - new version submitted To: ips@ece.cmu.edu Date: Thu, 28 Feb 2002 13:28:34 -0800 (PST) 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 Hi, I've submitted a new version of the FC Management MIB Internet-Draft. While it's in the publication queue, you can find it at: ftp://ftpeng.cisco.com/ftp/kzm/ips-wg/draft-ietf-ips-fcmgmt-mib-01.txt Keith. From owner-ips@ece.cmu.edu Thu Feb 28 17:33: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 RAA23689 for ; Thu, 28 Feb 2002 17:33:49 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1SLsl226202 for ips-outgoing; Thu, 28 Feb 2002 16:54:47 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ariel.nishansystems.com ([65.113.142.135]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1SLsjH26192 for ; Thu, 28 Feb 2002 16:54:45 -0500 (EST) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id <1LYT2GLR>; Thu, 28 Feb 2002 13:54:35 -0800 Message-ID: From: Charles Monia To: "'Ips (E-mail)'" Subject: iFCP: URLs for iFCP revision 10 Date: Thu, 28 Feb 2002 13:54:30 -0800 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 files for the iFCP spec have been moved to: ftp://ftp.t11.org/t11/docs/02-023v2.txt and ftp://ftp.t11.org/t11/docs/02-023v2.pdf Thanks, Charles 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 Thu Feb 28 18:25: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 SAA25713 for ; Thu, 28 Feb 2002 18:25:08 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1SMbDA29641 for ips-outgoing; Thu, 28 Feb 2002 17:37:13 -0500 (EST) 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 g1SMbCH29636 for ; Thu, 28 Feb 2002 17:37:12 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1SMb5h20474 for ; Thu, 28 Feb 2002 14:37:05 -0800 (PST) Received: from cisco.com (58509@mbakke-lnx.cisco.com [161.44.68.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA28993 for ; Thu, 28 Feb 2002 14:37:04 -0800 (PST) Message-ID: <3C7EAD90.CD2F4D6F@cisco.com> Date: Thu, 28 Feb 2002 16:22:08 -0600 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: IPS Subject: iSCSI: iSCSI MIB Draft Submitted 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 just submitted version -04 of the iSCSI MIB draft. For now, it is available at: ftp://ftpeng.cisco.com/mbakke/ips/iscsi-mib/draft-ietf-ips-iscsi-mib-04.txt The object model is at: ftp://ftpeng.cisco.com/mbakke/ips/iscsi-mib/Visio-ietf-iscsi-uml-model-04.pdf A MIB-only version (without the draft verbiage and pagination): ftp://ftpeng.cisco.com/mbakke/ips/iscsi-mib/iscsi-mib-04.mi2 This MIB includes the re-structuring agreed upon at the interim meeting, as well as references to the new AUTH-MIB submitted last week. Enjoy, Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Thu Feb 28 19:05: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 TAA27081 for ; Thu, 28 Feb 2002 19:05:27 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1SNOJ503245 for ips-outgoing; Thu, 28 Feb 2002 18:24:19 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from Gregorio.Stanford.EDU (Gregorio.Stanford.EDU [171.64.66.243]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g1SNOHH03240 for ; Thu, 28 Feb 2002 18:24:17 -0500 (EST) Received: from Pescadero.DSG.Stanford.EDU (Pescadero.DSG.Stanford.EDU [171.64.79.21]) by Gregorio.Stanford.EDU (8.11.6/8.9.1) with ESMTP id g1SNMSP06907; Thu, 28 Feb 2002 15:22:28 -0800 Message-Id: <200202282322.g1SNMSP06907@Gregorio.Stanford.EDU> To: Black_David@emc.com cc: ips@ece.cmu.edu Subject: Re: header and data digest issue In-reply-to: Your message of "Wed, 27 Feb 2002 20:13:28 EST." <277DD60FB639D511AC0400B0D068B71E02937514@CORPMX14> Date: Thu, 28 Feb 2002 15:12:33 -0800 From: Jonathan Stone Sender: owner-ips@ece.cmu.edu Precedence: bulk >We're in semi-violent agreement that encryption isn't required. For >"ESP cryptographic integrity", one example is ESP with the NULL >Encryption Algorithm, as specified in RFC 2410. AH is not required >for any IP Storage protocol and the ipsec WG is in the process of >removing the requirement for AH from future versions of the ipsec RFCs. ... modulo IP header authentication and NATs. (iir, AH verifies the IP header; ESP+Null enc+ Auth doesn't, or only via the TCP pseudo-header checksum). You and I are in fierce agreement; previous posters may not be entirely happy with prospects of NATting ESP. Given the issues with standards-track progress and in-progress IPsec work, do the IPS security drafts explicilty make clear the rationale for not requiring AH support? The lastest ips-security draft (http://www.drizzle.com/~aboba/RDMA/draft-ietf-ips-security-11.txt) still cites rfc2402. Should that be excised? From owner-ips@ece.cmu.edu Thu Feb 28 19:06: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 TAA27102 for ; Thu, 28 Feb 2002 19:06:53 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g1SNYSF04065 for ips-outgoing; Thu, 28 Feb 2002 18:34:28 -0500 (EST) 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 g1SMP5H28679 for ; Thu, 28 Feb 2002 17:25:05 -0500 (EST) Received: from io.iol.unh.edu (IDENT:rdr@localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.2/8.12.2) with ESMTP id g1SMOxUj022823; Thu, 28 Feb 2002 17:24:59 -0500 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.2/8.12.1/Submit) with ESMTP id g1SMOxrq022820; Thu, 28 Feb 2002 17:24:59 -0500 Date: Thu, 28 Feb 2002 17:24:59 -0500 (EST) From: "Robert D. Russell" To: Bart Crane cc: "'ips@ece.cmu.edu'" Subject: Re: Digests As Connection-Specific Parameters In-Reply-To: <034670D62D19D31180990090277A37B701ABDE5A@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 Bart: I was not aware of any question at the plugfest about the scope of Digests -- what exactly are you refering too? We have always considered digests to be connection-specific parameters, and in Draft 10 this is absolutely clear because the HeaderDigest and DataDigest keys are label "CO", meaning "Connection Only". Bob Russell On Thu, 28 Feb 2002, Bart Crane wrote: > Hello, I was asked to follow up on the question that came up at the plugfest > about Digests being Session-wide parameters? Digests should be a > connection-specific parameter in the event that some boards can and some > boards can not accelerate the digest calculation. > > Bart. > > From owner-ips@ece.cmu.edu Thu Feb 28 20: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 UAA28148 for ; Thu, 28 Feb 2002 20:10:45 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g210k9M09055 for ips-outgoing; Thu, 28 Feb 2002 19:46:09 -0500 (EST) 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 g210k7H09049 for ; Thu, 28 Feb 2002 19:46:08 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id <107NPMMY>; Thu, 28 Feb 2002 19:46:07 -0500 Message-ID: <25369470B6F0D41194820002B328BDD22F566E@ATLOPS> From: Eddy Quicksall To: "ips@ece. cmu. edu (E-mail)" Subject: iSCSI: RefCmdSN != CmdSN Date: Thu, 28 Feb 2002 19:46:06 -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 Is there a reason that this check is mandated? Is there a case where this can happen with bug free code? If RefCmdSN does not match the CmdSN of the command to be aborted at the target, the abort action MUST NOT be performed and the response MUST be 'function rejected'. Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Thu Feb 28 20:10: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 UAA28162 for ; Thu, 28 Feb 2002 20:10:51 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g210Xna08263 for ips-outgoing; Thu, 28 Feb 2002 19:33:49 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g210XlH08255 for ; Thu, 28 Feb 2002 19:33:47 -0500 (EST) Received: from cceexg13.americas.cpqcorp.net (cceexg13.americas.cpqcorp.net [16.110.250.119]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id B7595402F; Thu, 28 Feb 2002 18:33:38 -0600 (CST) Received: from cceexc18.americas.cpqcorp.net ([16.110.250.64]) by cceexg13.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 28 Feb 2002 18:33:38 -0600 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: sector alignment for DataOut PDUs? Date: Thu, 28 Feb 2002 18:33:38 -0600 Message-ID: <31891B757C09184BBFEC5275F85D5595104E43@cceexc18.americas.cpqcorp.net> Thread-Topic: sector alignment for DataOut PDUs? Thread-Index: AcHAkwjCyhUdiJrFTWKmMXReZHFM9gAIjETg From: "Martin, Nick" To: "Martins Krikis" Cc: X-OriginalArrivalTime: 01 Mar 2002 00:33:38.0633 (UTC) FILETIME=[BAF6B390:01C1C0B8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g210XmH08256 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Martins, Comments imbedded. > -----Original Message----- > From: Martins Krikis [mailto:mkrikis@yahoo.com] > Sent: Thursday, February 28, 2002 2:02 PM > To: ips@ece.cmu.edu > Subject: RE: sector alignment for DataOut PDUs? > > > I like the DataPDUAlignment parameter. > (Just mandating to send maximum amount of data > that's allowed, while being a good thing, > still cannot guarantee the right alignment > if those limits are not the right multiples.) > > But I don't see why the selection function should be > the minimum of two numbers. That way the outcome may > be completely inapropriate for the target. > I think that whatever the target declares should be > the final value. So the selection function should > be called, IMHO, "target said so". +++ Yes, I see your point. +++ > > Also, (I'm quoting Nick): > > When DataPDUAlignment is non-zero, > > for any PDU other than the last in a > > sequence, the PDU data segment length > > (DataSegmentLength) is required to > > be an integer multiple of DataPDUAlignment > > less than or equal to MaxRecvPDULength. > > In case of Data_out pdu-s even the last one should > be aligned, shouldn't it? Since all PDU-s have > brought data aligned on block-size, if the last > one does the same, we guarantee that the total > data transfer length is a multiple of block-size, > which certainly must be so, right? So far I don't > see a guarantee that it will be, but I feel it > must match the length carried by CDB which is > expressed as the number of blocks... +++ For disks, yes this will be true. For devices accepting variable length records such as tape, there is no restriction on the total size. My intention is that only the last buffer required by the transfer would not be an integer multiple. I now picture a slightly more general case where the DataPDUAlignment value requested represents the buffer memory management granularity of the target. This might be a convenient multiple of sector size other than one. Again in this case, only the final transfer would not fill each DataPDUAlignment sized buffer allocated to receive it. Finally, it has been suggested (by Eddy Quicksall) that allowing any value including 1, but not zero eliminates special case processing for 0. The value 1 means one byte alignment which is no restriction. Any value convenient to the target could be selected, or the target can leave it unspecified which means it does not require alignment. +++ > > Finally, speaking about MaxRecvPDULength, this > really is the last of operational parameters that > is not negotiated, but instead declared, right? That > makes it different from others. Plus, the same key > means different things depending on which direction > it is sent. While I'm not as upset with this as I > was about RFMarkInt, wouldn't it look cleaner if > we used two different keys, MaxORecvPDULength and > MaxIRecvPDULength? We could even say that they > are negotiated with the very special selection > functions "initiator said so" and "target said so", > respectively... > > Any comments? > > Martins Krikis, Intel Corp. > > Disclaimer: These opinions are my own and may not > reflect those of my employer. > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Greetings - Send FREE e-cards for every occasion! > http://greetings.yahoo.com > From owner-ips@ece.cmu.edu Thu Feb 28 20:13: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 UAA28213 for ; Thu, 28 Feb 2002 20:13:52 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g210KFa07393 for ips-outgoing; Thu, 28 Feb 2002 19:20:15 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from imo-r01.mx.aol.com (imo-r01.mx.aol.com [152.163.225.97]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g210KCH07383 for ; Thu, 28 Feb 2002 19:20:12 -0500 (EST) Received: from ISCSIPerson@aol.com by imo-r01.mx.aol.com (mail_out_v32.5.) id 9.152.9b07879 (1332); Thu, 28 Feb 2002 19:19:57 -0500 (EST) From: ISCSIPerson@aol.com Message-ID: <152.9b07879.29b0232d@aol.com> Date: Thu, 28 Feb 2002 19:19:57 EST Subject: iscsi: Another "silly" question: TotalAHSLength To: Julian_Satran@il.ibm.com CC: ips@ece.cmu.edu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_152.9b07879.29b0232d_boundary" X-Mailer: AOL 6.0 for Windows US sub 10556 Sender: owner-ips@ece.cmu.edu Precedence: bulk --part1_152.9b07879.29b0232d_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Here is a silly question: If the TotalAHSLength field is "only used in SCSI Command PDUs and MUST be 0 in all other PDUs" (draft-11 section 9.2.1.4), why is it included (instead of reserved) in the "other PDUs"? Thanks in advance, Greg A. --part1_152.9b07879.29b0232d_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit Here is a silly question:

If the TotalAHSLength field is "only used in SCSI Command PDUs and MUST be 0 in all other PDUs" (draft-11 section 9.2.1.4), why is it included (instead of reserved) in the "other PDUs"?

Thanks in advance,

Greg A.
--part1_152.9b07879.29b0232d_boundary-- From owner-ips@ece.cmu.edu Thu Feb 28 20:13: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 UAA28225 for ; Thu, 28 Feb 2002 20:13:52 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g210pGj09397 for ips-outgoing; Thu, 28 Feb 2002 19:51:16 -0500 (EST) 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 g210pFH09393 for ; Thu, 28 Feb 2002 19:51:15 -0500 (EST) Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.110.250.124]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id A11723AB6; Thu, 28 Feb 2002 18:51:09 -0600 (CST) Received: from cceexc18.americas.cpqcorp.net ([16.110.250.64]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 28 Feb 2002 18:51:09 -0600 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: sector alignment for DataOut PDUs? Date: Thu, 28 Feb 2002 18:51:08 -0600 Message-ID: <31891B757C09184BBFEC5275F85D5595104E42@cceexc18.americas.cpqcorp.net> Thread-Topic: sector alignment for DataOut PDUs? Thread-Index: AcHAK09/mke2EKLYRqucV0ewLmLiKgAg9dvg From: "Martin, Nick" To: Cc: X-OriginalArrivalTime: 01 Mar 2002 00:51:09.0215 (UTC) FILETIME=[2D28CAF0:01C1C0BB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g210pFH09394 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Aryan, In reply to your question "But what about those implementations which would like to change the size after few transfers? Should they look/wait for something in the spec/draft or try their own implementation?" If you control both ends of the wire, you can add vendor specific X- type of parameters to do what ever you want, but if you want to interoperate with everyone, you need to raise your voice in support of adding something like DataPDUAlignment to the spec. Until it is included, you can not prevent unaligned data transfer sizes. (If you have no desire to prevent such transfers, this parameter will not help you.) If you are for example a tape drive and you want to change the value on the fly, then this parameter would need to be supported in text mode negotiation during Full Feature Phase. There are additional implications if it can change with commands in flight. I did not explicitly state whether this was or was not permitted in my proposal. I have not noticed any other parameters which explicitly can be changed during FPP, although early on, I think that was one important reason to have Text PDUs. Also note that the scope of effect is a single value for the session which includes the target and all of its LUs. There did not seem to be precedent for anything but Session or Connection scope. It would perhaps more logically have LU scope (no pun intended). For a disk target, a single value is probably sufficient. All sectors on all LUs are (almost certainly) the same size. For a multi LU tape library, although each drive may be using a different (fixed or variable) block size, there is perhaps still some value in specifying a power of two PDU alignment to simplify buffer management. If a target sets this value to its data buffer memory management granularity, this could allow simplification or efficiency within the target. The granularity of target data buffer memory management is not likely to change dynamically. Efficiency of memory management in the target is a main benefit. Being to schedule device writes as each data PDU arrives is another. This is possible when no device block will span PDUs. Thanks, Nick > -----Original Message----- > From: Ajit Aryan [mailto:digital_aryan@yahoo.com] > Sent: Thursday, February 28, 2002 1:42 AM > To: Martin, Nick > Subject: Re: sector alignment for DataOut PDUs? > > > Nick, > That looks fine. > But what about those implementations which would > like to change the size after few transfers? > Should they look/wait for something in the spec/draft > or try their own implementation? > > Aryan > > Martin, Nick wrote: > > >Paul, > > > >As Rod Harrison points out, MaxRecvPDULength is not negotiated, it is > >"declared" and is likely to be different for Initiator and Target. I > >had missed the implication of this change which occurred at draft 09. > > > >I can now appreciate your earlier proposal. > > > >To be fair to all targets, we should allow targets with > arbitrary sized > >sectors/blocks to request the same kind of boundary > alignment. Today we > >already have a need to support 512, 1K, 2K, and 4K sectors > for disk, and > >anything from 512 up to at least 64K blocks for tape (including > >non-powers of 2 like 10K). [Ouch, I just realized that the > tape block > >size can be changed mid-session, the most likely time being after a > >media change. The tape folks may not be able to use of this > in the same > >way, but let's not prevent them from trying.] Further we do > not really > >want iSCSI initiators (or their drivers) to have to guess or > issue SCSI > >commands to learn the sector size. The size needs to be specified by > >the target during operational parameter negotiation if it is > requesting > >sector/block aligned PDU payloads. > > > >I actually do not think unaligned payloads are likely, but there is > >nothing to prevent them. We may simplify some target designs by > >eliminating the requirement to support them. > > > >Certainly, we want to eliminate loopholes which allow compliant but > >non-interoperable implementations. > > > >Please consider whether the following proposal meets all of your > >requirements. > > > >Proposed addition to chapter 12 to enable requiring sector > aligned PDU > >payloads: > > > >" > >DataPDUAlignment > > > >Use: LO > >Senders: Target and Initiator > >Scope: SW > > > >DataPDUAlignment= > > > >The default is 0. > > > >The initiator and target negotiate the alignment boundary on > which data > >transfers may be continued to a subsequent PDU. > > > >The value 0 means no boundary alignment limitation is imposed on data > >carrying PDUs. > > > >The minimum of two non-zero values is selected. If one > value is zero, > >then the other value is selected. > > > >This is intended primarily for a target to force an initiator to send > >PDU data buffers whose boundaries match physical media > boundaries such > >as disk sector size. > > > >When DataPDUAlignment is non-zero, for any PDU other than > the last in a > >sequence, the PDU data segment length (DataSegmentLength) is > required to > >be an integer multiple of DataPDUAlignment less than or equal to > >MaxRecvPDULength. > >" > > > >Thanks, > >Nick > > > >>-----Original Message----- > >>From: Paul Koning [mailto:ni1d@arrl.net] > >>Sent: Wednesday, February 27, 2002 12:57 PM > >>To: Martin, Nick > >>Cc: ips@ece.cmu.edu > >>Subject: RE: sector alignment for DataOut PDUs? > >> > >> > >>>>>>>"Nick" == Martin, Nick writes: > >>>>>>> > >> Nick> Paul, For all data carrying PDUs except the last in > a sequence, > >> Nick> the sender is expected to send maximum sized PDU > allowed. When > >> Nick> the negotiated maximum is a multiple of 512, this effect is > >> Nick> what you request. > >> > >> Nick> I thought this was a requirement, but I did not find > it as such > >> Nick> in draft 10. ... > >> > >> Nick> IMHO, it makes more sense to include stronger wording > >> Nick> encouraging maximum negotiated length transfers > rather than to > >> Nick> add another parameter requiring PDU breaks on different > >> Nick> boundaries. > >> > >>That sounds like a fine suggestion, if it gives the target enough > >>power to achieve the alignment I'm looking for. Strengthening the > >>text you quoted is a start, but other places would have to be > >>strengthened as well -- for example the rules on responding > to an R2T. > >> > >> Nick> If such initiator behavior may not be supported by > all targets, > >> Nick> then the initiators SHOULD NOT do it. > >> > >>That's not sufficient. You need "MUST NOT". The reason: if you say > >>"should not" then you can build a conforming initiator that cannot > >>interoperate with a conforming target. All correctly > written protocol > >>specs have the property that conformance implies interoperability. > >>(Unfortunately, few specs pass this test... :-( ) So a > target can be > >>allowed to rely on full size PDUs only if initiators are > required (not > >>merely encouraged) to send full size PDUs. > >> > >> paul > >> > > From owner-ips@ece.cmu.edu Thu Feb 28 21:00: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 VAA29115 for ; Thu, 28 Feb 2002 21:00:56 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g2110T210003 for ips-outgoing; Thu, 28 Feb 2002 20:00:29 -0500 (EST) 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 g210i0H08896 for ; Thu, 28 Feb 2002 19:44:00 -0500 (EST) Received: by mercury.corp.iready.com with Internet Mail Service (5.5.2653.19) id <1LVD5GL3>; Thu, 28 Feb 2002 16:43:54 -0800 Message-ID: <034670D62D19D31180990090277A37B701ABDE5D@mercury.corp.iready.com> From: Bart Crane To: "'Robert D. Russell'" , Bart Crane Cc: "'ips@ece.cmu.edu'" Subject: RE: Digests As Connection-Specific Parameters Date: Thu, 28 Feb 2002 16:43:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C0BA.282B4920" 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_01C1C0BA.282B4920 Content-Type: text/plain; charset="iso-8859-1" Hello Bob, we were consulting the draft 6, 8 and 9 documents. Neither the 6 nor 8 docs were definitive in this regard, and the 9 doc did not have the wording "This is a connection-specific parameter", whereas as other connection-specific parameters did have that wording. Thanks for pointing out that the draft-10 document makes it clear they are connection-specific. I will look at that document when I have finished cleaning up the loose ends in our draft-9 implementation. Bart. -----Original Message----- From: Robert D. Russell [mailto:rdr@io.iol.unh.edu] Sent: Thursday, February 28, 2002 2:25 PM To: Bart Crane Cc: 'ips@ece.cmu.edu' Subject: Re: Digests As Connection-Specific Parameters Bart: I was not aware of any question at the plugfest about the scope of Digests -- what exactly are you refering too? We have always considered digests to be connection-specific parameters, and in Draft 10 this is absolutely clear because the HeaderDigest and DataDigest keys are label "CO", meaning "Connection Only". Bob Russell On Thu, 28 Feb 2002, Bart Crane wrote: > Hello, I was asked to follow up on the question that came up at the plugfest > about Digests being Session-wide parameters? Digests should be a > connection-specific parameter in the event that some boards can and some > boards can not accelerate the digest calculation. > > Bart. > > ------_=_NextPart_001_01C1C0BA.282B4920 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Digests As Connection-Specific Parameters

Hello Bob, we were consulting the draft 6, 8 and 9 = documents.  Neither the 6 nor 8 docs were definitive in this = regard, and the 9 doc did not have the wording "This is a = connection-specific parameter", whereas as other = connection-specific parameters did have that wording. 

Thanks for pointing out that the draft-10 document = makes it clear they are connection-specific.  I will look at that = document when I have finished cleaning up the loose ends in our draft-9 = implementation.

Bart.



-----Original Message-----
From: Robert D. Russell [mailto:rdr@io.iol.unh.edu]=
Sent: Thursday, February 28, 2002 2:25 PM
To: Bart Crane
Cc: 'ips@ece.cmu.edu'
Subject: Re: Digests As Connection-Specific = Parameters


Bart:

I was not aware of any question at the plugfest about = the scope
of Digests -- what exactly are you refering = too?

We have always considered digests to be = connection-specific
parameters, and in Draft 10 this is absolutely clear = because
the HeaderDigest and DataDigest keys are label = "CO", meaning
"Connection Only".

Bob Russell


On Thu, 28 Feb 2002, Bart Crane wrote:

> Hello, I was asked to follow up on the question = that came up at the plugfest
> about Digests being Session-wide = parameters?   Digests should be a
> connection-specific parameter in the event that = some boards can and some
> boards can not accelerate the digest = calculation.
>
> Bart.
>
>

------_=_NextPart_001_01C1C0BA.282B4920-- From owner-ips@ece.cmu.edu Thu Feb 28 21:19: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 VAA29410 for ; Thu, 28 Feb 2002 21:19:30 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g211lId13169 for ips-outgoing; Thu, 28 Feb 2002 20:47:18 -0500 (EST) 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 g211lGH13163 for ; Thu, 28 Feb 2002 20:47:16 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel7.hp.com (Postfix) with ESMTP id 7D4B980514D for ; Thu, 28 Feb 2002 20:47:08 -0500 (EST) 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 RAA19065 for ; Thu, 28 Feb 2002 17:48:48 -0800 (PST) Message-ID: <00b801c1c0c2$fe1b8790$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "ips@ece. cmu. edu (E-mail)" References: <25369470B6F0D41194820002B328BDD22F566E@ATLOPS> Subject: Re: iSCSI: RefCmdSN != CmdSN Date: Thu, 28 Feb 2002 17:47:05 -0800 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Eddy, I agree that targets don't have to check both always, only when it is needed. The intended role of RefCmdSN is to help identify the right command when the command to be aborted had not arrived - the command could be lost due to digest errors or as part of connection failure. So I think the quoted text should be rephrased to: Section 9.5.4 For the ABORT TASK function, initiators MUST always set this to the CmdSN of the task identified by the Initiator Task Tag field. Targets however must consider the field valid only when the task indicated by the Initiator Task Tag field does not exist. Section 9.6.1 For the ABORT TASK function, a) if the ITT identifies a valid task leading to a successful termination, targets must return the "Function complete" response. b)if the ITT does not identify an existing task but if the CmdSN indicated by the RefCmdSN field in the task management function request is within the valid CmdSN window, targets must consider the CmdSN received and return the "Function complete" response. c) if the ITT does not identify an existing task and if the CmdSN indicated by the RefCmdSN field in the task management function request is outside the valid CmdSN window, targets must return the "Task does not exist" response. Comments? -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ----- Original Message ----- From: "Eddy Quicksall" To: "ips@ece. cmu. edu (E-mail)" Sent: Thursday, February 28, 2002 4:46 PM Subject: iSCSI: RefCmdSN != CmdSN > Is there a reason that this check is mandated? Is there a case where this > can happen with bug free code? > > If RefCmdSN does not match the CmdSN of the command to be aborted at the > target, the abort action MUST NOT be performed and the response MUST > be 'function rejected'. > > > Eddy_Quicksall@iVivity.com > From owner-ips@ece.cmu.edu Thu Feb 28 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 VAA29422 for ; Thu, 28 Feb 2002 21:19:43 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g211cKC12556 for ips-outgoing; Thu, 28 Feb 2002 20:38:20 -0500 (EST) 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 g211cJH12550 for ; Thu, 28 Feb 2002 20:38:19 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 5B225C33 for ; Thu, 28 Feb 2002 18:38:18 -0700 (MST) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 1C168502 for ; Thu, 28 Feb 2002 18:38:18 -0700 (MST) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 28 Feb 2002 18:38:17 -0700 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Feb 2002 18:38:17 -0700 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00A984B9A@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: ips@ece.cmu.edu Subject: iscsi: header digest issue Date: Thu, 28 Feb 2002 18:38:17 -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 We have a concern about the header digest location in the PDU. Currently, the header digest is located after the AHS. This is convenient for the transmitter since it calculates the header digest over the BHS and AHS and then appends the digest. The problem is that the receiver must read a field that is covered by the header digest in order to know the position of the digest. This has two problems: it reduces the hamming distance protection of the digest to one and it can cause an error recovery problem when an error changes the length field to a value that is beyond the end of the transmitted data stream. The CRC generally has a hamming distance of 4 and we went to some effort to pick a CRC that was robust in the presence of small numbers of bad bits. With the current PDU definition, an error in the TotalAHSLength field will cause the wrong value of the stream being read as the AHS. There is a possibility that this location contains a value that is the same as the CRC of the bytes up to that point. A single bit error has a 2^-32 chance of producing an undetectable error. The second concern is on error recovery when an error occurs in a PDU that is not followed by other PDUs. The error may change the length field so that it indicates a position beyond the end of the actual PDU. The receiver waits for more data to arrive so that it can check the digest and then process the packet. Since there is no more data arriving it will hang waiting until a timeout occurs. Therefore, when this kind of error occurs the error recovery doesn't function. Both problems could be solved by placing the header digest after the BHS and before the AHS headers. Regards, Pat Thaler