From owner-ips@ece.cmu.edu Tue Jan 1 04:58: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 EAA08809 for ; Tue, 1 Jan 2002 04:58:11 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g018vBR01332 for ips-outgoing; Tue, 1 Jan 2002 03:57:11 -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 g018v9g01326 for ; Tue, 1 Jan 2002 03:57:09 -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 JAA23526 for ; Tue, 1 Jan 2002 09:56:57 +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 g018ve1148364 for ; Tue, 1 Jan 2002 09:57:41 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI - last change for 2001! X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 1 Jan 2002 10:57:38 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 01/01/2002 10:57:42, Serialize complete at 01/01/2002 10:57:42 Content-Type: multipart/alternative; boundary="=_alternative 0030634E42256B34_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0030634E42256B34_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You are correct - I have rephrased to: For ABORT TASK, the task CmdSN of the task to be aborted. Thanks, Julo Eddy Quicksall 31-12-01 22:24 =20 To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI - last change for 2001! =20 For ABORT TASK, the task CmdSN to enable task removal. =20 I assume "the CmdSN to enable task removal" is the CmdSN of the command=20 corresponding to the "Referenced Task Tag" and not some other concept that = I missed. =20 Is that correct? =20 Eddy =20 -----Original Message----- From: Julian Satran [mailto:Julian=5FSatran@il.ibm.com] Sent: Monday, December 31, 2001 10:30 AM To: ips@ece.cmu.edu Subject: iSCSI - last change for 2001! =20 Dear colleagues,=20 According to the agreement reached in SLC here is the new text for the=20 Task Management Request/Response (with all synchronization functions=20 delegated to the target). The impementer's notes - subsection 4 is out.=20 Task Management Function Request=20 Byte / 0 | 1 | 2 | 3 |=20 / | | | |=20 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|=20 +---------------+---------------+---------------+---------------+=20 0|0|I| x02 |0| Function | Reserved |=20 +---------------+---------------+---------------+---------------+=20 4| Reserved |=20 +---------------+---------------+---------------+---------------+=20 8| Logical Unit Number (LUN) or Reserved |=20 + +=20 12| |=20 +---------------+---------------+---------------+---------------+=20 16| Initiator Task Tag |=20 +---------------+---------------+---------------+---------------+=20 20| Referenced Task Tag or 0xffffffff |=20 +---------------+---------------+---------------+---------------+=20 24| CmdSN |=20 +---------------+---------------+---------------+---------------+=20 28| ExpStatSN |=20 +---------------+---------------+---------------+---------------+=20 32| RefCmdSN or ExpDataSN |=20 +---------------+---------------+---------------+---------------+=20 36/ Reserved /=20 +/ /=20 +---------------+---------------+---------------+---------------+=20 48=20 Function=20 The Task Management functions provide an initiator with a way to=20 explicitly control the execution of one or more Tasks (SCSI and iSCSI=20 tasks). The Task Management functions are listed below. For a more=20 detailed description of SCSI task management, see [SAM2].=20 1 ABORT TASK - aborts the task identified by the Referenced Task=20 Tag field.=20 2 ABORT TASK SET - aborts all Tasks issued via this session on the=20 logical unit.=20 3 CLEAR ACA - clears the Auto Contingent Allegiance condi-tion.=20 4 CLEAR TASK SET - aborts all Tasks for the Logical Unit.=20 5 LOGICAL UNIT RESET=20 6 TARGET WARM RESET=20 7 TARGET COLD RESET=20 8 TASK REASSIGN - reassigns connection allegiance for the task=20 identified by the Initiator Task Tag field on this con-nection, thus=20 resuming the iSCSI exchanges for the task.=20 For all these functions, if executed, the Task Management Function=20 Response MUST be returned using the Initiator Task Tag to identify the=20 operation for which it is responding. All these functions apply to the=20 referenced tasks regardless of whether they are proper SCSI tasks or=20 tagged iSCSI operations. Task management commands must be executed as if=20 all the commands having a CmdSN lower or equal to the task manage-ment=20 CmdSN have been received by the target (i.e., have to be executed as if=20 received for ordered delivery even when marked for immediate delivery).=20 For all the tasks covered by the task management response (i.e., with=20 CmdSN not higher than the task management command CmdSN), additional=20 responses MUST NOT be delivered to the SCSI layer after the task=20 management response. The iSCSI initiator MAY deliver to the SCSI layer all = responses received before the task management response (i.e., it is a=20 matter of implementation i! f ! the SCSI responses received before the=20 task mangement response but after the task management request are=20 delivered to the SCSI layer by the iSCSI layer in the ini-tiator). The=20 iSCSI target MUST ensure that no responses for the tasks covered by a task = management function are delivered to the iSCSI ini-tiator after the task=20 management response.=20 If the connection is still active (it is not undergoing an implicit or=20 explicit logout), ABORT TASK MUST be issued on the same connection to=20 which the task to be aborted is allegiant at the time the Task Manage-ment = Request is issued. If the connection is being implicitly or explicitly=20 logged out (i.e., no other request will be issued on the failing=20 connection and no other response will be received on the fail-ing=20 connection), then an ABORT TASK function request may be issued on another=20 connection. This Task Management request will then establish a new=20 allegiance for the command to be aborted as well as abort it (i.e., the=20 task to be aborted will not have to be retried or reas-signed, and its=20 status, if issued, but not acknowledged will be reis-sued). For the=20 LOGICAL UNIT RESET function, the target MUST behave as dictated by the=20 Logical Unit Reset function in [SAM2].=20 The TARGET RESET function (WARM and COLD) implementation is OPTIONAL and=20 when implemented, should act as described below. Target Reset MAY also be=20 subject to SCSI access controls for the requesting initiator. When not=20 implemented or when authorization fails at target, Target Reset functions=20 should end as if the function was executed success-fully and the response=20 qualifier will detail what was executed.=20 For the TARGET WARM RESET and TARGET COLD RESET functions, the target=20 cancels all pending operations. Both functions are equivalent to the=20 Target Reset function specified by [SAM2]. They can affect many other=20 initiators.=20 =20 In addition, for the TARGET COLD RESET, the target MUST then terminate all = of its TCP connections to all initiators (all sessions are termi-nated).=20 =20 For the TASK REASSIGN function, the target should reassign the connec-tion = allegiance to this new connection (and thus resume iSCSI exchanges for the = task). TASK REASSIGN MUST be received by the target ONLY after the=20 connection on which the command was previously execut-ing has been=20 successfully logged-out. For additional usage semantics see Section 7.1=20 Retry and Reassign in Recovery.=20 TASK REASSIGN MUST be issued as an immediate command.=20 LUN=20 This field is required for functions that address a specific LU (ABORT=20 TASK, CLEAR TASK SET, ABORT TASK SET, CLEAR ACA, LOGICAL UNIT RESET) and=20 is reserved in all others.=20 Referenced Task Tag=20 The Initiator Task Tag of the task to be aborted or reassigned.=20 RefCmdSN or ExpDataSN=20 For ABORT TASK, the task CmdSN to enable task removal. If RefCmdSN does=20 not match the CmdSN of the command to be aborted at the target,=20 the abort action MUST NOT be performed and the response MUST be func-tion=20 rejected.=20 If the function is TASK REASSIGN, which establishes a new connection=20 allegiance for a previously issued Read or Bidirectional command, this=20 field will contain the next consecutive input DataSN number expected by=20 the initiator (no gaps) for the referenced command in a previous=20 execution.=20 Otherwise, this field is reserved.=20 Task Management Function Response=20 Byte / 0 | 1 | 2 | 3 |=20 / | | | |=20 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|=20 +---------------+---------------+---------------+---------------+=20 0|0|1| 0x22 |1| Reserved | Response | Qualifier |=20 +---------------+---------------+---------------+---------------+=20 4/ Reserved /=20 / /=20 +---------------+---------------+---------------+---------------+=20 16| Initiator Task Tag |=20 +---------------+---------------+---------------+---------------+=20 20| Referenced Task Tag or 0xffffffff |=20 +---------------+---------------+---------------+---------------+=20 24| StatSN |=20 +---------------+---------------+---------------+---------------+=20 28| ExpCmdSN |=20 +---------------+---------------+---------------+---------------+=20 32| MaxCmdSN |=20 +---------------+---------------+---------------+---------------+=20 36/ Reserved /=20 +/ /=20 +---------------+---------------+---------------+---------------+=20 48| Digest (if any) |=20 +---------------------------------------------------------------+=20 For the functions ABORT TASK, ABORT TASK SET, CLEAR ACA, CLEAR TASK SET,=20 LOGICAL UNIT RESET, and TARGET WARM RESET, the target performs the=20 requested Task Management function and sends a Task Management Response=20 back to the initiator.=20 Response and Qualifier=20 The target provides a Response, which may take on the following val-ues:=20 0 - Function Complete=20 1 - Task specified in the Referenced Task Tag field was not in task set.=20 2 - LUN does not exist.=20 3 - Task still allegiant.=20 4 - Task failover not supported.=20 5 - Task management function not supported.=20 255 Function Rejected=20 All other values are reserved.=20 The Qualifier field provides additional information about the Response.=20 For a Response of "Function Complete" the valid Qualifiers are:=20 0 - Function Executed=20 1 - Not Authorized=20 For a discussion on usage of response codes 3 and 4, see Section 7.1.2=20 Allegiance Reassignment.=20 For the TARGET COLD RESET and TARGET WARM RESET functions, the target=20 cancels all pending operations. For the TARGET COLD RESET function, the=20 target MUST then close all of its TCP connections to all initia-tors=20 (terminates all sessions).=20 The mapping of the response code into a SCSI service response code, if=20 needed, is outside the scope of this document.=20 The response to ABORT TASK SET and CLEAR TASK SET MUST be issued by the=20 target only after all the commands affected have been received by the=20 target the corresponding task management functions functions have been=20 executed by the SCSI target and the delivery of all previous responses has = been confirmed (acknowledged through ExpStatSN) by the initiator on all=20 connections of this session.=20 Referenced Task Tag=20 If the Request was ABORT TASK and the Response is "task not found", THE=20 Referenced Task Tag contains the Initiator Task Tag of the task that had=20 to be aborted. In other cases, it MUST be set to 0xffffffff.=20 Your comments please.=20 Julo --=_alternative 0030634E42256B34_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
You are correct - I have rephrased t= o:

For ABORT TASK, the task CmdSN of t= he task to be aborted.

Thanks,
Julo


Eddy Quicksall <Eddy=5FQuicksa= ll@ivivity.com>

31-12-01 22:24

       
        To: &nbs= p;      Julian Satran/Haifa/IBM@IBMIL
        cc: &nbs= p;      ips@ece.cmu.edu
        Subject:=        RE: iSCSI - last change for 2001!

       


For ABORT TASK, the= task CmdSN to enable task removal.

 

I assume "the CmdSN = to enable task removal" is the CmdSN of the command corresponding to the "R= eferenced Task Tag" and not some other concept that I missed.

 

Is that correct?

 

Eddy

 

-----Original Message-----
From: Julian Satran [mailto:Julian=5FSatran@il.ibm.com]
Sent: Monday, December 31, 2001 10:30 AM
To: ips@ece.cmu.edu
Subject: iSCSI - last change for 2001!

 


Dear colleagues,

According to the agreement reached in SLC here is the new text for the Task= Management Request/Response (with all synchronization functions delegated = to the target). The impementer's notes - subsection 4 is out.

Task Management Function Request

Byte /    0     =   |       1       |      = 2       |       3       |
  /              |     &= nbsp;         |           &nbs= p;   |               |
 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
 +---------------+---------------+---------------+---------------+
0|0|I| x02       |0| Function    | Reserved  = ;                    |
 +---------------+---------------+---------------+---------------+
4| Reserved                  =                     &nbs= p;              |
 +---------------+---------------+---------------+---------------+
8| Logical Unit Number (LUN) or Reserved          = ;               |
 +                   &nb= sp;                     &= nbsp;                    = +
12|                     &= nbsp;                    =                     |
 +---------------+---------------+---------------+---------------+
16| Initiator Task Tag               &nb= sp;                     &= nbsp;      | =
 +---------------+---------------+---------------+---------------+
20| Referenced Task Tag or 0xffffffff           &n= bsp;                 |
 +---------------+---------------+---------------+---------------+
24| CmdSN                   &n= bsp;                     =                 |
  +---------------+-----------= ----+---------------+---------------+
28| ExpStatSN                  = ;                     &nb= sp;             |
 +---------------+---------------+---------------+---------------+
32| RefCmdSN or ExpDataSN               =                      = ;     |
 +---------------+---------------+---------------+---------------+
36/ Reserved                  =                     &nbs= p;              /
+/                     &= nbsp;                    =                     /
 +---------------+---------------+---------------+---------------+
48

Function

The Task Management functions provid= e an initiator with a way to explicitly control the execution of one or mor= e Tasks (SCSI and iSCSI tasks). The Task Management functions are listed be= low. For a more detailed description of SCSI task management, see [SAM2].

1    ABORT TASK - aborts the task identified by the Referenced &n= bsp;     Task Tag field.

2    ABORT TASK SET - aborts all Tasks issued via this session on= the logical unit.
3    CLEAR ACA - clears the Auto Contingent Allegiance condi-tion= .

4    CLEAR TASK SET - aborts all Tasks for the Logical Unit.

5    LOGICAL UNIT RESET

6    TARGET WARM RESET

7                    TARG= ET COLD RESET

8    TASK REASSIGN - reassigns connection allegiance for the task= identified by the Initiator Task Tag field on this con-nection, thus resum= ing the iSCSI exchanges for the task.

For all these functions, if executed, the Task Management Function Response= MUST be returned using the Initiator Task Tag to identify the operation fo= r which it is responding. All these functions apply to the referenced tasks= regardless of whether they are proper SCSI tasks or tagged iSCSI operation= s.  Task management commands must be executed as if all the commands h= aving a CmdSN lower or equal to the task manage-ment CmdSN have been receiv= ed by the target (i.e., have to be executed as if received for ordered deli= very even when marked for immediate delivery).  For all the tasks cove= red by the task management response (i.e., with CmdSN not higher than the t= ask management command CmdSN), additional responses MUST NOT be delivered t= o the SCSI layer after the task management response. The iSCSI initiator MA= Y deliver to the SCSI layer all responses received before the task manageme= nt response (i.e., it is a matter of implementation i! f ! the SCSI respons= es received before the task mangement response but after the task managemen= t request are delivered to the SCSI layer by the iSCSI layer in the ini-tia= tor). The iSCSI target MUST ensure that no responses for the tasks covered = by a task management function are delivered to the iSCSI ini-tiator after t= he task management response.

If the connection is still active (it is not undergoing an implicit or expl= icit logout), ABORT TASK MUST be issued on the same connection to which the= task to be aborted is allegiant at the time the Task Manage-ment Request i= s issued. If the connection is being implicitly or explicitly logged out (i= .e., no other request will be issued on the failing connection and no other= response will be received on the fail-ing connection), then an ABORT TASK = function request may be issued on another connection. This Task Management = request will then establish a new allegiance for the command to be aborted = as well as abort it (i.e., the task to be aborted will not have to be retri= ed or reas-signed, and its status, if issued, but not acknowledged will be = reis-sued). For the LOGICAL UNIT RESET function, the target MUST behave as = dictated by the Logical Unit Reset function in [SAM2].

The TARGET RESET function (WARM and COLD) implementation is OPTIONAL and wh= en implemented, should act as described below. Target Reset MAY also be sub= ject to SCSI access controls for the requesting initiator. When not impleme= nted or when authorization fails at target, Target Reset functions should e= nd as if the function was executed success-fully and the response qualifier= will detail what was executed.

For the TARGET WARM RESET and TARGET COLD RESET functions, the target cance= ls all pending operations. Both functions are equivalent to the Target Rese= t function specified by [SAM2]. They can affect many other initiators.
 
In addition, for the TARGET COLD RESET, the target MUST then terminate all = of its TCP connections to all initiators (all sessions are termi-nated).  
For the TASK REASSIGN function, the target should reassign the connec-tion = allegiance to this new connection (and thus resume iSCSI exchanges for the = task). TASK REASSIGN MUST be received by the target ONLY after the connecti= on on which the command was previously execut-ing has been successfully log= ged-out. For additional usage semantics see Section 7.1 Retry and Reassign = in Recovery.


TASK REASSIGN MUST be issued as an immediate command.


LUN

This field is required for functions= that address a specific LU (ABORT TASK, CLEAR TASK SET, ABORT TASK SET, CL= EAR ACA, LOGICAL UNIT RESET) and is reserved in all others.

Referenced Task Tag

The Initiator Task Tag of the task t= o be aborted or reassigned. =

RefCmdSN or ExpDataSN

For ABORT TASK, the task CmdSN to en= able task removal. If RefCmdSN does not match the CmdSN of the command to b= e aborted at the target,
the abort action MUST NOT be performed and the response MUST be func-tion r= ejected.

If the function is TASK REASSIGN, which establishes a new connection allegi= ance for a previously issued Read or Bidirectional command, this field will= contain the next consecutive input DataSN number expected by the initiator= (no gaps) for the referenced command in a previous execution.

Otherwise, this field is reserved.


Task Management Function Response


Byte /    0       |       1   =     |       2       |    =   3       |
  /              |     &= nbsp;         |           &nbs= p;   |               |
 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
 +---------------+---------------+---------------+---------------+
0|0|1| 0x22      |1| Reserved    | Response  = ;    | Qualifier     |
 +---------------+---------------+---------------+---------------+
4/ Reserved                  =                     &nbs= p;              /
 /                   &nb= sp;                     &= nbsp;                    = /
 +---------------+---------------+---------------+---------------+
16| Initiator Task Tag               &nb= sp;                     &= nbsp;      | =
 +---------------+---------------+---------------+---------------+
20| Referenced Task Tag or 0xffffffff           &n= bsp;                 |
 +---------------+---------------+---------------+---------------+
24| StatSN                   &= nbsp;                    =                | <= br>  +---------------+---------------+---------------+---------------+
28| ExpCmdSN                  =                     &nbs= p;              |
 +---------------+---------------+---------------+---------------+
32| MaxCmdSN                  =                     &nbs= p;              |
 +---------------+---------------+---------------+---------------+
36/ Reserved                  =                     &nbs= p;              /
+/                     &= nbsp;                    =                     /
 +---------------+---------------+---------------+---------------+
48| Digest (if any)                =                     &nbs= p;         |
 +---------------------------------------------------------------+

For the functions ABORT TASK, ABORT TASK SET, CLEAR ACA, CLEAR TASK SET, LO= GICAL UNIT RESET, and TARGET WARM RESET, the target performs the requested = Task Management function and sends a Task Management Response back to the i= nitiator.

Response and Qualifier

The target provides a Response, whic= h may take on the following val-ues:

0 - Function Complete
1 - Task specified in the Referenced Task Tag field was not in task set.
2 - LUN does not exist.
3 - Task still allegiant.
4 - Task failover not supported.
5 - Task management function not supported.
255   Function Rejected=

All other values are reserved.
The Qualifier field provides additional information about the Response.

For a Response of "Function Complete" the valid Qualifiers are:

0 - Function Executed
1 - Not Authorized

For a discussion on usage of response codes 3 and 4, see Section 7.1.2 Alle= giance Reassignment.

For the TARGET COLD RESET and TARGET WARM RESET functions, the target cance= ls all pending operations.  For the TARGET COLD RESET function, the ta= rget MUST then close all of its TCP connections to all initia-tors (termina= tes all sessions).

The mapping of the response code into a SCSI service response code, if need= ed, is outside the scope of this document.

The response to ABORT TASK SET and CLEAR TASK SET MUST be issued by the tar= get only after all the commands affected have been received by the target t= he corresponding task management functions functions have been executed by = the SCSI target and the delivery of all previous responses has been confirm= ed (acknowledged through ExpStatSN) by the initiator on all connections of = this session.

Referenced Task Tag

If the Request was ABORT TASK and th= e Response is "task not found", THE Referenced Task Tag contains = the Initiator Task Tag of the task that had to be aborted. In other cases, = it MUST be set to 0xffffffff.
Your comments please.

Julo

--=_alternative 0030634E42256B34_=-- From owner-ips@ece.cmu.edu Tue Jan 1 15:43: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 PAA15125 for ; Tue, 1 Jan 2002 15:43:25 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g01JxDZ03221 for ips-outgoing; Tue, 1 Jan 2002 14:59:13 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g01JxBg03216 for ; Tue, 1 Jan 2002 14:59:11 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e34.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA90574; Tue, 1 Jan 2002 14:56:09 -0500 Received: from d03nm014.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 g01JvmH25468; Tue, 1 Jan 2002 12:57:48 -0700 X-Priority: 1 (High) Importance: Normal Subject: RE: FW: iSCSI: "conservative reuse" requirement To: Eddy Quicksall Cc: "ips" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Tue, 1 Jan 2002 11:56:59 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 01/01/2002 12:57:48 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy, You might think so, but a number of vendors, for some reason, wanted to give every session a unique ID, and they did not want to give that design up. Therefore, we needed to include the Conservative Reuse, statement. You saw how some folks felt about making the requirement a MUST. That was just a sample of the folks that had built their design on an idea -- which we had not understood to be a problem, until late in the game. . . . 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 on 12/31/2001 07:25:23 PM To: John Hufferd/San Jose/IBM@IBMUS cc: ips@ece.cmu.edu Subject: RE: FW: iSCSI: "conservative reuse" requirement My problem is that we have not done a good job of defining the iSCSI Initiator Portal Group in the spec. If defined correctly, there should be no need for the "conservative reuse" clause. Here is how I think it should be defined ... SCSI Initiator Port: this maps to an iSCSI Initiator Portal Group. You could go on to say something like Marjorie said below ... that it is a collection of IP addresses that can be used to support one or more iSCSI sessions. Given that it is equivalent to a SCSI Initiator Port and that it is identified by the InitiatorName+ISID, it follows that every session from that "port" would have to use the same ISID; and that is what will make persistent reservations work. It is not that "conservative reuse" won't work ... it is more that it is hard to explain because we don't have a clear definition of a SCSI Initiator Port and Initiator Port Identifier. Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Monday, December 31, 2001 8:01 PM To: Amir Shalit Cc: ips@ece.cmu.edu Subject: RE: FW: iSCSI: "conservative reuse" requirement We overtly chose NOT to identify an ISID with a TCP/IP address, since the ISID may span several HBAs and/or TCP/IP addresses. It was more general and consistent NOT to be tied to a TCP/IP address. . . . 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 "Amir Shalit" @ece.cmu.edu on 12/31/2001 03:35:56 PM Sent by: owner-ips@ece.cmu.edu To: "Eddy Quicksall" , "KRUEGER,MARJORIE \(HP-Roseville,ex1\)" , Jim Hafner/Almaden/IBM@IBMUS cc: "ips@ece. cmu. edu \(E-mail\)" Subject: RE: FW: iSCSI: "conservative reuse" requirement Marjorie, If an "initiator/target portal group" concept is "the collection of IP addresses which can be combined to create a single iSCSI session." why isn't it defined as such in the draft? IMO, it would have been better to define ISID/TSID in simple networking terms like {TCP/IP address + Name} instead of coming up with network entity, network portal and portal group terminology. Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Eddy Quicksall Sent: Monday, December 31, 2001 2:15 PM To: KRUEGER,MARJORIE (HP-Roseville,ex1); Jim Hafner Cc: ips@ece. cmu. edu (E-mail) Subject: RE: FW: iSCSI: "conservative reuse" requirement Marjorie, If "an initiator portal group is the same concept as the target portal group", then it must be equivalent to the SCSI Initiator Port (because we have said that the SCSI Target Port maps to an iSCSI Target Portal Group). Comments? Eddy -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie_krueger@hp.com] Sent: Monday, December 31, 2001 4:48 PM To: 'Eddy Quicksall'; Jim Hafner Cc: ips@ece. cmu. edu (E-mail) Subject: RE: FW: iSCSI: "conservative reuse" requirement Your assumption of what is meant by an initiator portal group is incorrect (I don't think it's implied that IPG = IP???) An initiator portal group is the same concept as a target portal group - it's the collection of IP addresses which can be combined to create a single iSCSI session. Frequently this is thought of as an iSCSI HBA, but that is not necessarily so, it could be a number of iSCSI HBAs, etc. 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: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] > Sent: Monday, December 31, 2001 10:39 AM > To: Jim Hafner > Cc: ips@ece. cmu. edu (E-mail) > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > Regarding answer 2 below: > There is no given definition for an iSCSI Initiator Portal Group (however, > it is implied to be the same as the endpoint in 9.1.1, which would be the > same as the SCSI Initiator Port). Since an iSCSI Initiator Portal Group is > the same as a SCSI Initiator Port and since an iSCSI Target Portal Group is > the same as a SCSI Target Port, then each session in answer number 2 would > not have a "different SCSI initiator port"; hence you would have a parallel > nexus. > One thing that is not clear in section 9.1.1 (however, it is loosely > implied) is that the reuse of ISID's applies to a given initiator endpoint > (SCSI Initiator Port or what should be called an iSCSI Initiator Portal > Group)). I think that should be made clear. > What am I missing? Could it be that an iSCSI Initiator Portal Group is not > equivalent to a SCSI Target Port? > > Eddy > > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Saturday, December 29, 2001 6:14 PM > To: Eddy Quicksall > Cc: ips > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > Eddy, > > The SCSI initiator port is modeled as the endpoint of the > iSCSI session; > the SCSI target port is modeled as the iSCSI target portal group. The > reason we did it this way was to allow more than one session > between portal > groups by allowing multi-plexing of sessions with different > ISIDs from the > same iSCSI initiator portal group to the same target portal group. > > So, the answer to your questions are: > 1) no, we're assuming no more than on session *with the same > ISID* to the > same target portal group (that'd be more than one nexus), but > by allowing > different ISIDs we get different SCSI initiator ports. > 2) no, we're allowing more than one session between an iSCSI initiator > portal group and an iSCSI target portal group (each session > has a different > SCSI initiator port (id'ed by its ISID) but the same SCSI target port > (id'ed by its portal group tag). > 3) sort of, the ISID together with the iSCSI Initiator Name fully > identifies the SCSI initiator port (and so defines the SCSI > initiator port > name and the identifier). > > Does that clear this up? > > Jim Hafner > > > "Eddy Quicksall" on 12/28/2001 > 07:19:33 PM > > To: Jim Hafner/Almaden/IBM@IBMUS > cc: "ips@ece. cmu. edu \(E-mail\)" > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > > Due to 2.5.3 (b) "Between a given SCSI initiator port and SCSI target > port, there can be only one I_T nexus (session)", aren't we always > "assuming no more than one session"? > > Or are you talking about more than one session between different SCSI > initiator ports and a single SCSI target port? > > Is the ISID equivalent to SAM-2's Initiator Port Identifier? > > > Eddy > > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Friday, December 28, 2001 12:15 PM > To: John Hufferd; Eddy Quicksall; Mallikarjun C.; Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: FW: iSCSI: "conservative reuse" requirement > > > Folks, > > Sorry for taking so long to jump into this discussion. > > There are a number of issues raised in this thread: > 1) should "conservative reuse" of ISIDs be made a MUST > 2) does "conservative reuse" imply that all hosts look "single SCSI > ported" > > Here's my two cents (using "CR" as a shorthand for "conservative > reuse") > > I don't believe that CR needs to be a MUST. The only time this has > any > real value is in configurations that use SCSI persistent reservations > (and > where new SCSI target reservation features are enabled -- NB. these > features are yet to be approved but are working their way through the > process). I don't think these are going to be (even in the future) the > majority of installations. There are many ways then that CR could be > something that is not generally available in most drivers but is added > by > configuration and perhaps even "value add" (:-{)). > > In short, I don't see a strong case for this to be a MUST. So, to > David > Black, my answer is that having a mechanism to enable this feature or > have > it as a "purchase requirement" is an acceptable mechanism to make sure > the > feature is there when needed, but it is need not be a requirement of > the > protocol. To Mallikarjun, I think I'm agreeing with you that so long > as > there is a mechanism defined, iSCSI has done it's job. > > As for the second issue (raised by Mallikarjun), let's look at the > definition of CR. What is means is that when an iSCSI initiator > (node) > creates ISIDs for use in session identifiers, it attempts to reuse > them > as > much as possible with different SCSI target ports (iSCSI target portal > groups). This is the only way that a SCSI target or LU can see the > same > SCSI initiator port through two or more of its SCSI target ports -- > that > is, that the target can determine multiple paths *from* the same SCSI > initiator port. But, the model for generating ISIDs is not really at > the > node level but at the initiator portal group level. > So, IMO, the conclusion that all hosts must then look "single SCSI > ported" > is too dramatic. As I mentioned, ISIDs are conceptually generated > within > initiator portal groups (that's why we defined the mechanism for > generating > ISIDs). The conclusion I draw is that (assuming no more than one > session > to any given target portal group), an iSCSI initiator implementing CR > will > have as many SCSI initiator ports as iSCSI initiator portal groups > (independent HBAs?). Each initiator portal group would generate one > ISID > (that is different from that generated by/for the other initiator > portal > groups) and use CR for repeatability. [This is consistent with a > model > that mapped SCSI initiator ports to initiator portal groups, which we > had > to abandon because the "assuming no more than one session..." was no > acceptable as a requirement!!!] This independence of ISIDs for each > initiator portal group allows each initiator portal group to open > sessions > with *every* target portal group it knows about without having to > worry > about interfering with other sessions. [This has shades of the > "partitioning" rule for ISIDs that has been discussed ad nauseum!!!] > > (I have a feeling that this note is not well composed -- it is the > holidays, you know). I hope I've addressed everyone's concerns and we > can > lay this one to rest. > > Jim Hafner > > > John Hufferd > 12/25/2001 08:49 AM > > To: "Eddy Quicksall" > cc: Jim Hafner/Almaden/IBM@IBMUS > From: John Hufferd/San Jose/IBM@IBMUS > Subject: Re: FW: iSCSI: "conservative reuse" requirement (Document > link: > Jim Hafner) > > You are correct. The section was created by Jim Hafner, and via this > note > I will ask him if he could answer Mallikarjun Directly since I did not > understand his issue. > > . > . > . > 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" on 12/24/2001 06:06:44 > PM > > To: John Hufferd/San Jose/IBM@IBMUS > cc: > Subject: FW: iSCSI: "conservative reuse" requirement > > > > John, > > Were you the author of "conservative reuse"? I am wondering about some > issues. Maybe you could educate me somewhat ... > > I started this subject in a different thread by saying that it may be > good to make "conservative reuse" a MUST. > > I got one objection from Santosh below. Then David Black picked it up > by basically agreeing with me. Then Mallikarjun objected to that. > > It seems like the objective would be to give targets a way to figure > out that two or more sessions are coming from the same Initiator Port. > That is needed support persistent reservations. > > If an initiator does not use "conservative reuse", I don't think > targets will be able to make that determination. > > Comments? > > Eddy > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Monday, December 24, 2001 12:47 AM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: "conservative reuse" requirement > > > I think this is headed towards "conservative reuse" being a MUST if > > we're serious about support for shared persistent reservations. > > Mandating "conservative reuse" appears to force initiators to always > act > as a single initiator port (wrt one target; assuming only one session > as > an > example) per initiator device - which rules out the case of an > initiator > > intentionally wanting to present a different port to each target > portal > group. > > IMHO, if iSCSI provides an architected mechanism to support shared > persistent reservations ("conservative reuse"), that should be > completely > adequate to meet the expectations to be a legal SCSI protocol. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 > > ----- Original Message ----- > From: > To: > Cc: > Sent: Friday, December 21, 2001 4:50 PM > Subject: iSCSI: "conservative reuse" requirement > > > > Santosh Rao writes: > > > > > I am opposed to the suggestion that "conservative re-use" of ISIDs > be > > > made a MUST. This is really only required when initiators need to > be > > > using the new T10 Reservation scheme that can be shared > > > across initiator ports. > > > > Those reservations are a Target feature. With this approach, the > ability > > to use the target feature depends on details of the initiator > > implementation. > > More below ... > > > > > For those initiators that don't care about this type of > reservation, > > > conservative re-use is of no use and initiators may like to assign > > > ISID's in a per-initiator node fashion, thereby, being able to use > these > > > ISIDs as a lookup index for the sessions on that initiator node. > > > > > > Hence, I suggest that "conservative re-use" be worded as > > > "encouraged to use" or something to that effect, but not MUST USE. > > > > > > Comments ? > > > > The "initiator" is more than one entity. The iSCSI HBA/NIC and > driver > > doesn't know whether shared persistent reservations are being used > and > > shouldn't have to care - they're just more SCSI commands to > transport. > > Some other entity (e.g., clustering software) will be generating the > > shared persistent reservations. This raise the possible scenario > > involving a target that supports the new shared persistent > reservations > > and an entity that wants to use them. The entity detects (via SCSI > means, > > e.g., something in a mode page) that the Target supports shared > persistent > > reservations, tries to use them, only to discover that they don't > work > > because the iSCSI HBA/NIC doesn't implement "conservative reuse". > > > > I'm worried about this causing both interoperability issues and > possible > > T10 issues -- from a T10 viewpoint, if shared persistent > reservations > > don't work, the initiating entity should have some SCSI-level means > > of determining this ... if that means exists only on the Target, the > > above scenario is iSCSI's problem (Target can't query Initiator to > > determine whether it does "conservative reuse"), and having a > separate > > initiator side means that the entity has to check only for iSCSI > (and > > not for any other SCSI transport) does not seem like the right > > approach. > > > > I think this is headed towards "conservative reuse" being a MUST if > > we're serious about support for shared persistent reservations. > > > > Comments? > > --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 Jan 1 15:44: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 PAA15137 for ; Tue, 1 Jan 2002 15:44:44 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g01KKrE03743 for ips-outgoing; Tue, 1 Jan 2002 15:20:53 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g01KKpg03738 for ; Tue, 1 Jan 2002 15:20:51 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e34.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA50682; Tue, 1 Jan 2002 15:17:53 -0500 Received: from d03nm014.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 g01KJWH97340; Tue, 1 Jan 2002 13:19:34 -0700 X-Priority: 1 (High) Importance: Normal Subject: RE: FW: iSCSI: "conservative reuse" requirement To: "Amir Shalit" Cc: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Tue, 1 Jan 2002 12:18:35 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 01/01/2002 01:19:33 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Amir, It could have been a lot of things. We had many folks look at as many different approaches as possible, and it bothered us for a long time. I am trying to tell you that we DID look at IP addresses being part of the Name. That was turned down because of a lot of reasons, one of them was the fact that with Hot Swap, Plug and Play etc. the IP address could change, and then the name would change, and the reservations could not be reclaimed, etc. We even thought that there could be take over of the IP address by the other HBAs, etc. And that got just too complicated for the more simple HBAs and device drivers, and we did not need that level of complexity. We were trying to reduce complexity, and I think we did it. The protocol and the Names and the reason for the names are just different then IP/ATM, SCTP etc. We are talking about a higher level protocol, and the needs of that protocol, and not trying to match it to a lower level protocol which has no issues with Storage and Reservations. Bottom Line; Your thoughts were factored in, they were discarded as Not Approprate for this protocol and the ISID name. . . . 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 "Amir Shalit" @ece.cmu.edu on 12/31/2001 05:22:13 PM Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS cc: Subject: RE: FW: iSCSI: "conservative reuse" requirement It could have been defined as {IP address, port, channel_id} or {IP address, port, stream_number}. This would let you span multiple HBAs etc. and still be consistent with other IP/ATM protocols like SCTP and AAL2. Amir -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Monday, December 31, 2001 5:01 PM To: Amir Shalit Cc: ips@ece.cmu.edu Subject: RE: FW: iSCSI: "conservative reuse" requirement We overtly chose NOT to identify an ISID with a TCP/IP address, since the ISID may span several HBAs and/or TCP/IP addresses. It was more general and consistent NOT to be tied to a TCP/IP address. . . . 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 "Amir Shalit" @ece.cmu.edu on 12/31/2001 03:35:56 PM Sent by: owner-ips@ece.cmu.edu To: "Eddy Quicksall" , "KRUEGER,MARJORIE \(HP-Roseville,ex1\)" , Jim Hafner/Almaden/IBM@IBMUS cc: "ips@ece. cmu. edu \(E-mail\)" Subject: RE: FW: iSCSI: "conservative reuse" requirement Marjorie, If an "initiator/target portal group" concept is "the collection of IP addresses which can be combined to create a single iSCSI session." why isn't it defined as such in the draft? IMO, it would have been better to define ISID/TSID in simple networking terms like {TCP/IP address + Name} instead of coming up with network entity, network portal and portal group terminology. Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Eddy Quicksall Sent: Monday, December 31, 2001 2:15 PM To: KRUEGER,MARJORIE (HP-Roseville,ex1); Jim Hafner Cc: ips@ece. cmu. edu (E-mail) Subject: RE: FW: iSCSI: "conservative reuse" requirement Marjorie, If "an initiator portal group is the same concept as the target portal group", then it must be equivalent to the SCSI Initiator Port (because we have said that the SCSI Target Port maps to an iSCSI Target Portal Group). Comments? Eddy -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie_krueger@hp.com] Sent: Monday, December 31, 2001 4:48 PM To: 'Eddy Quicksall'; Jim Hafner Cc: ips@ece. cmu. edu (E-mail) Subject: RE: FW: iSCSI: "conservative reuse" requirement Your assumption of what is meant by an initiator portal group is incorrect (I don't think it's implied that IPG = IP???) An initiator portal group is the same concept as a target portal group - it's the collection of IP addresses which can be combined to create a single iSCSI session. Frequently this is thought of as an iSCSI HBA, but that is not necessarily so, it could be a number of iSCSI HBAs, etc. 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: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] > Sent: Monday, December 31, 2001 10:39 AM > To: Jim Hafner > Cc: ips@ece. cmu. edu (E-mail) > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > Regarding answer 2 below: > There is no given definition for an iSCSI Initiator Portal Group (however, > it is implied to be the same as the endpoint in 9.1.1, which would be the > same as the SCSI Initiator Port). Since an iSCSI Initiator Portal Group is > the same as a SCSI Initiator Port and since an iSCSI Target Portal Group is > the same as a SCSI Target Port, then each session in answer number 2 would > not have a "different SCSI initiator port"; hence you would have a parallel > nexus. > One thing that is not clear in section 9.1.1 (however, it is loosely > implied) is that the reuse of ISID's applies to a given initiator endpoint > (SCSI Initiator Port or what should be called an iSCSI Initiator Portal > Group)). I think that should be made clear. > What am I missing? Could it be that an iSCSI Initiator Portal Group is not > equivalent to a SCSI Target Port? > > Eddy > > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Saturday, December 29, 2001 6:14 PM > To: Eddy Quicksall > Cc: ips > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > Eddy, > > The SCSI initiator port is modeled as the endpoint of the > iSCSI session; > the SCSI target port is modeled as the iSCSI target portal group. The > reason we did it this way was to allow more than one session > between portal > groups by allowing multi-plexing of sessions with different > ISIDs from the > same iSCSI initiator portal group to the same target portal group. > > So, the answer to your questions are: > 1) no, we're assuming no more than on session *with the same > ISID* to the > same target portal group (that'd be more than one nexus), but > by allowing > different ISIDs we get different SCSI initiator ports. > 2) no, we're allowing more than one session between an iSCSI initiator > portal group and an iSCSI target portal group (each session > has a different > SCSI initiator port (id'ed by its ISID) but the same SCSI target port > (id'ed by its portal group tag). > 3) sort of, the ISID together with the iSCSI Initiator Name fully > identifies the SCSI initiator port (and so defines the SCSI > initiator port > name and the identifier). > > Does that clear this up? > > Jim Hafner > > > "Eddy Quicksall" on 12/28/2001 > 07:19:33 PM > > To: Jim Hafner/Almaden/IBM@IBMUS > cc: "ips@ece. cmu. edu \(E-mail\)" > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > > Due to 2.5.3 (b) "Between a given SCSI initiator port and SCSI target > port, there can be only one I_T nexus (session)", aren't we always > "assuming no more than one session"? > > Or are you talking about more than one session between different SCSI > initiator ports and a single SCSI target port? > > Is the ISID equivalent to SAM-2's Initiator Port Identifier? > > > Eddy > > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Friday, December 28, 2001 12:15 PM > To: John Hufferd; Eddy Quicksall; Mallikarjun C.; Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: FW: iSCSI: "conservative reuse" requirement > > > Folks, > > Sorry for taking so long to jump into this discussion. > > There are a number of issues raised in this thread: > 1) should "conservative reuse" of ISIDs be made a MUST > 2) does "conservative reuse" imply that all hosts look "single SCSI > ported" > > Here's my two cents (using "CR" as a shorthand for "conservative > reuse") > > I don't believe that CR needs to be a MUST. The only time this has > any > real value is in configurations that use SCSI persistent reservations > (and > where new SCSI target reservation features are enabled -- NB. these > features are yet to be approved but are working their way through the > process). I don't think these are going to be (even in the future) the > majority of installations. There are many ways then that CR could be > something that is not generally available in most drivers but is added > by > configuration and perhaps even "value add" (:-{)). > > In short, I don't see a strong case for this to be a MUST. So, to > David > Black, my answer is that having a mechanism to enable this feature or > have > it as a "purchase requirement" is an acceptable mechanism to make sure > the > feature is there when needed, but it is need not be a requirement of > the > protocol. To Mallikarjun, I think I'm agreeing with you that so long > as > there is a mechanism defined, iSCSI has done it's job. > > As for the second issue (raised by Mallikarjun), let's look at the > definition of CR. What is means is that when an iSCSI initiator > (node) > creates ISIDs for use in session identifiers, it attempts to reuse > them > as > much as possible with different SCSI target ports (iSCSI target portal > groups). This is the only way that a SCSI target or LU can see the > same > SCSI initiator port through two or more of its SCSI target ports -- > that > is, that the target can determine multiple paths *from* the same SCSI > initiator port. But, the model for generating ISIDs is not really at > the > node level but at the initiator portal group level. > So, IMO, the conclusion that all hosts must then look "single SCSI > ported" > is too dramatic. As I mentioned, ISIDs are conceptually generated > within > initiator portal groups (that's why we defined the mechanism for > generating > ISIDs). The conclusion I draw is that (assuming no more than one > session > to any given target portal group), an iSCSI initiator implementing CR > will > have as many SCSI initiator ports as iSCSI initiator portal groups > (independent HBAs?). Each initiator portal group would generate one > ISID > (that is different from that generated by/for the other initiator > portal > groups) and use CR for repeatability. [This is consistent with a > model > that mapped SCSI initiator ports to initiator portal groups, which we > had > to abandon because the "assuming no more than one session..." was no > acceptable as a requirement!!!] This independence of ISIDs for each > initiator portal group allows each initiator portal group to open > sessions > with *every* target portal group it knows about without having to > worry > about interfering with other sessions. [This has shades of the > "partitioning" rule for ISIDs that has been discussed ad nauseum!!!] > > (I have a feeling that this note is not well composed -- it is the > holidays, you know). I hope I've addressed everyone's concerns and we > can > lay this one to rest. > > Jim Hafner > > > John Hufferd > 12/25/2001 08:49 AM > > To: "Eddy Quicksall" > cc: Jim Hafner/Almaden/IBM@IBMUS > From: John Hufferd/San Jose/IBM@IBMUS > Subject: Re: FW: iSCSI: "conservative reuse" requirement (Document > link: > Jim Hafner) > > You are correct. The section was created by Jim Hafner, and via this > note > I will ask him if he could answer Mallikarjun Directly since I did not > understand his issue. > > . > . > . > 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" on 12/24/2001 06:06:44 > PM > > To: John Hufferd/San Jose/IBM@IBMUS > cc: > Subject: FW: iSCSI: "conservative reuse" requirement > > > > John, > > Were you the author of "conservative reuse"? I am wondering about some > issues. Maybe you could educate me somewhat ... > > I started this subject in a different thread by saying that it may be > good to make "conservative reuse" a MUST. > > I got one objection from Santosh below. Then David Black picked it up > by basically agreeing with me. Then Mallikarjun objected to that. > > It seems like the objective would be to give targets a way to figure > out that two or more sessions are coming from the same Initiator Port. > That is needed support persistent reservations. > > If an initiator does not use "conservative reuse", I don't think > targets will be able to make that determination. > > Comments? > > Eddy > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Monday, December 24, 2001 12:47 AM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: "conservative reuse" requirement > > > I think this is headed towards "conservative reuse" being a MUST if > > we're serious about support for shared persistent reservations. > > Mandating "conservative reuse" appears to force initiators to always > act > as a single initiator port (wrt one target; assuming only one session > as > an > example) per initiator device - which rules out the case of an > initiator > > intentionally wanting to present a different port to each target > portal > group. > > IMHO, if iSCSI provides an architected mechanism to support shared > persistent reservations ("conservative reuse"), that should be > completely > adequate to meet the expectations to be a legal SCSI protocol. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 > > ----- Original Message ----- > From: > To: > Cc: > Sent: Friday, December 21, 2001 4:50 PM > Subject: iSCSI: "conservative reuse" requirement > > > > Santosh Rao writes: > > > > > I am opposed to the suggestion that "conservative re-use" of ISIDs > be > > > made a MUST. This is really only required when initiators need to > be > > > using the new T10 Reservation scheme that can be shared > > > across initiator ports. > > > > Those reservations are a Target feature. With this approach, the > ability > > to use the target feature depends on details of the initiator > > implementation. > > More below ... > > > > > For those initiators that don't care about this type of > reservation, > > > conservative re-use is of no use and initiators may like to assign > > > ISID's in a per-initiator node fashion, thereby, being able to use > these > > > ISIDs as a lookup index for the sessions on that initiator node. > > > > > > Hence, I suggest that "conservative re-use" be worded as > > > "encouraged to use" or something to that effect, but not MUST USE. > > > > > > Comments ? > > > > The "initiator" is more than one entity. The iSCSI HBA/NIC and > driver > > doesn't know whether shared persistent reservations are being used > and > > shouldn't have to care - they're just more SCSI commands to > transport. > > Some other entity (e.g., clustering software) will be generating the > > shared persistent reservations. This raise the possible scenario > > involving a target that supports the new shared persistent > reservations > > and an entity that wants to use them. The entity detects (via SCSI > means, > > e.g., something in a mode page) that the Target supports shared > persistent > > reservations, tries to use them, only to discover that they don't > work > > because the iSCSI HBA/NIC doesn't implement "conservative reuse". > > > > I'm worried about this causing both interoperability issues and > possible > > T10 issues -- from a T10 viewpoint, if shared persistent > reservations > > don't work, the initiating entity should have some SCSI-level means > > of determining this ... if that means exists only on the Target, the > > above scenario is iSCSI's problem (Target can't query Initiator to > > determine whether it does "conservative reuse"), and having a > separate > > initiator side means that the entity has to check only for iSCSI > (and > > not for any other SCSI transport) does not seem like the right > > approach. > > > > I think this is headed towards "conservative reuse" being a MUST if > > we're serious about support for shared persistent reservations. > > > > Comments? > > --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 Jan 1 16:59: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 QAA15520 for ; Tue, 1 Jan 2002 16:59:08 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g01LadY05499 for ips-outgoing; Tue, 1 Jan 2002 16:36:39 -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 g01Labg05495 for ; Tue, 1 Jan 2002 16:36:37 -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 QAA21981136; Tue, 1 Jan 2002 16:33:27 -0500 Received: from d03nmx42.almaden.ibm.com (d03nmx42.almaden.ibm.com [9.1.24.146]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g01LaMH180014; Tue, 1 Jan 2002 14:36:22 -0700 From: "Jim Hafner" Importance: Normal Subject: Re: iSCSI: definitions To: "Eddy Quicksall" Cc: ips@ece.cmu.edu Date: Tue, 1 Jan 2002 13:36:20 -0800 Message-ID: X-MIMETrack: Serialize by Router on D03NMX42/03/M/IBM(Build M11_11052001 Beta 4|November 05, 2001) at 01/01/2002 01:36:21 PM MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=07BBE1A7DFE648A08f9e8a93df938690918c07BBE1A7DFE648A0" Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk --0__=07BBE1A7DFE648A08f9e8a93df938690918c07BBE1A7DFE648A0 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Eddy, Apologies, this reply is a bit out of order (I've only been doing a scattered job of handling e-mail this season). I think there's a "perspective" difference going on here. First, SAM has defined "abstract" structures, not real things. It is t= he protocols that specify the "implemention" of the abstract model defined= by SAM. In light of this, you're third question is phrased backwards! iSC= SI defines the iSCSI Target Node name, then maps that to the SCSI target device name. As in my other note, iSCSI defines its concrete architec= ture and then maps those to SCSI stuff. Second, (as you note in your first point) there are two different gener= ic definitions for the term "initiator" and "target" and it depends on whi= ch document you're reading. If you read SAM (or any T10 document), the te= rm "initiator" is a synonym for "SCSI initiator port" and "target"=3D"SCSI= target port". See the glossary of SAM-2. However, in the iSCSI draft (and I think it says this somewhere in the glossary or early in the document), the term "initiator" is a synonym f= or "iSCSI Initiator Node" and "target"=3D"iSCSI target node". *I believe this is one source of the confusion we're seeing!*. To be consistent with SAM-2, the iSCSI document would have a major "Fin= d and Replace" job. I have no objections to that. (In all my notes and = text in the iSCSI draft, I have tried to never be ambiguous but to fully qua= lify the terms in every case -- though I may have failed in some cases :-{))= We don't specifically define either the term "iSCSI Initiator" or the t= erm "iSCSI Initiator Portal Group". However, we do define the term "iSCSI N= ode" and "iSCSI Portal Group" -- and these can both come in "initiator" flav= or as well as "target" flavor. Perhaps we need to be more pendantic. Jim Hafner "Eddy Quicksall" @ece.cmu.edu on 12/29/2001= 08: 16:28 AM Sent by: owner-ips@ece.cmu.edu To: Julian Satran/Haifa/IBM@IBMIL cc: "ips@ece. cmu. edu \(E-mail\)" Subject: iSCSI: definitions 1) SAM-2 defines ?initiator? as ?a SCSI initiator port?. iSCSI uses ?initiator? to mean the ?SCSI Initiator Device? as in ?iSCSI Initiator Node: The "initiator"? (because we say ?there can be at most one SCSI Device within a given iSCSI Node? so the node is the device). Should we be consistent with SAM-2? 2) We don?t specifically define the ?iSCSI Initiator? (I agree ... it i= s implied to be the same as iSCSI Initiator Node). My I suggest we define it based on the answer to question 1? 3) Is the iSCSI Target Name equivalent to the SCSI Target Device Name? = If so, can we specify that? Eddy = --0__=07BBE1A7DFE648A08f9e8a93df938690918c07BBE1A7DFE648A0 Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Eddy,

Apologies, this reply is a bit out of order (I've only been doing a sca= ttered job of handling e-mail this season).
I think there's a "perspective" difference going on here.
=
First, SAM has defined "abstract" structures, not real things= . It is the protocols that specify the "implemention" of the= abstract model defined by SAM. In light of this, you're third question= is phrased backwards! iSCSI defines the iSCSI Target Node name, then = maps that to the SCSI target device name. As in my other note, iSCSI = defines its concrete architecture and then maps those to SCSI stuff.
Second, (as you note in your first point) there are two different gener= ic definitions for the term "initiator" and "target"= ; and it depends on which document you're reading. If you read SAM (or= any T10 document), the term "initiator" is a synonym for &qu= ot;SCSI initiator port" and "target"=3D"SCSI target= port". See the glossary of SAM-2.
However, in the iSCSI draft (and I think it says this somewhere in the = glossary or early in the document), the term "initiator" is a= synonym for "iSCSI Initiator Node" and "target"=3D= "iSCSI target node".
*I believe this is one source of the confusion we're seeing!*.

To be consistent with SAM-2, the iSCSI document would have a major &quo= t;Find and Replace" job. I have no objections to that. (In all m= y notes and text in the iSCSI draft, I have tried to never be ambiguous= but to fully qualify the terms in every case -- though I may have fail= ed in some cases :-{))

We don't specifically define either the term "iSCSI Initiator"= ; or the term "iSCSI Initiator Portal Group". However, we do = define the term "iSCSI Node" and "iSCSI Portal Group&quo= t; -- and these can both come in "initiator" flavor as well a= s "target" flavor. Perhaps we need to be more pendantic.
Jim Hafner

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

To: Julia= n Satran/Haifa/IBM@IBMIL
cc: "ip= s@ece. cmu. edu \(E-mail\)" <ips@ece.cmu.edu>
Subject: iSC= SI: definitions





1) SAM-2 defines “initiator” as “a SCSI initiator por= t”. iSCSI uses “initiator” to mean the “SCSI In= itiator Device” as in ‘iSCSI Initiator Nod= e: The "initiator"’ (because we say “there can be= at most one SCSI Device within a given iSCSI Node” so the node i= s the device).

=A0

Should we be consistent with SAM-2?

=A0

2) We don’t specifically define the “iSCSI Initiator”= (I agree ... it is implied to be the same as iSCSI Initiator Node).
=A0

My I suggest we define it based on the answer to question 1?

=A0

3) Is the iSCSI Target Name equivalent to the SCSI Target Device Name? = If so, can we specify that?

=A0

Eddy

=A0

=A0

= --0__=07BBE1A7DFE648A08f9e8a93df938690918c07BBE1A7DFE648A0-- From owner-ips@ece.cmu.edu Tue Jan 1 17:01: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 RAA15558 for ; Tue, 1 Jan 2002 17:01:34 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g01LFqM05028 for ips-outgoing; Tue, 1 Jan 2002 16:15:52 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g01LFog05020 for ; Tue, 1 Jan 2002 16:15:50 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e34.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA66038; Tue, 1 Jan 2002 16:12:52 -0500 Received: from d03nmx42.almaden.ibm.com (d03nmx42.almaden.ibm.com [9.1.24.146]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g01LFmH120768; Tue, 1 Jan 2002 14:15:48 -0700 From: "Jim Hafner" Importance: Normal Subject: RE: FW: iSCSI: "conservative reuse" requirement To: Eddy Quicksall Cc: ips@ece.cmu.edu Date: Tue, 1 Jan 2002 13:15:44 -0800 Message-ID: X-MIMETrack: Serialize by Router on D03NMX42/03/M/IBM(Build M11_11052001 Beta 4|November 05, 2001) at 01/01/2002 01:15:47 PM MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=07BBE1A7DFE01CBC8f9e8a93df938690918c07BBE1A7DFE01CBC" Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk --0__=07BBE1A7DFE01CBC8f9e8a93df938690918c07BBE1A7DFE01CBC Content-type: text/plain; charset=US-ASCII Eddy, I don't know why you think we've done a bad job of defining these terms. I don't have a copy of the draft around at the moment but this is my recollection: These are the iSCSI architectural level components: There is a definition of an iSCSI node (that has a WWU name). There is a definition of Portal Group (which does NOT apply only to targets but is applicable to both targets and initiators). (I even thought there was text that said that this definition applied to both initiator and target, but I could be wrong about this.) There is a definition of sessions and the specification of how SSIDs are generated from the ISID component and the TSID component. There is the (required by any SCSI protocol) a mapping of the SCSI constructs to iSCSI constructs. The SCSI constructs of concern here are (a) device -- both initiator and target (b) port -- initiator, target and initiator/target and (c) nexus: There is explicit language that defines the SCSI device as a component of an iSCSI node (and that there is only one such SCSI device construct within an iSCSI node -- and this allows us to define the SCSI device name as equal to the iSCSI node name). There is explicit language that maps the SCSI initiator port to an iSCSI construct and *different* language that maps the SCSI target port to an iSCSI construct. For the SCSI initiator port, the mapping is to the initiator end of a session. For the SCSI target port, the mapping is to the iSCSI target portal group. It is NOT symmetric and is stated so explicitly. There is explicit language the maps the SCSI nexus to the session. Note that a nexus is a relationship between a SCSI initiator port and a SCSI target port (that's the SAM definition!). What iSCSI does is map this relationship from the iSCSI initiator end of a session (SCSI initiator port) to the iSCSI target portal group (SCSI target port). Does the text not say this? Note that the approach we've taken here is to define the iSCSI architecture and then MAP the iSCSI constructs to SAM-defined SCSI constructs. And, an attempt to map SCSI initiator port to the iSCSI initiator portal group (as you suggest) will force a requirement that there can be only one session between an iSCSI initiator portal group and an iSCSI target portal group! If one thinks that most "portal groups" will be instantiated by an iSCSI HBA, then this requirement is unacceptable. Jim Hafner Eddy Quicksall @ece.cmu.edu on 12/31/2001 07: 25:23 PM Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS cc: ips@ece.cmu.edu Subject: RE: FW: iSCSI: "conservative reuse" requirement My problem is that we have not done a good job of defining the iSCSI Initiator Portal Group in the spec. If defined correctly, there should be no need for the "conservative reuse" clause. Here is how I think it should be defined ... SCSI Initiator Port: this maps to an iSCSI Initiator Portal Group. You could go on to say something like Marjorie said below ... that it is a collection of IP addresses that can be used to support one or more iSCSI sessions. Given that it is equivalent to a SCSI Initiator Port and that it is identified by the InitiatorName+ISID, it follows that every session from that "port" would have to use the same ISID; and that is what will make persistent reservations work. It is not that "conservative reuse" won't work ... it is more that it is hard to explain because we don't have a clear definition of a SCSI Initiator Port and Initiator Port Identifier. Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Monday, December 31, 2001 8:01 PM To: Amir Shalit Cc: ips@ece.cmu.edu Subject: RE: FW: iSCSI: "conservative reuse" requirement We overtly chose NOT to identify an ISID with a TCP/IP address, since the ISID may span several HBAs and/or TCP/IP addresses. It was more general and consistent NOT to be tied to a TCP/IP address. . . . 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 "Amir Shalit" @ece.cmu.edu on 12/31/2001 03:35:56 PM Sent by: owner-ips@ece.cmu.edu To: "Eddy Quicksall" , "KRUEGER,MARJORIE \(HP-Roseville,ex1\)" , Jim Hafner/Almaden/IBM@IBMUS cc: "ips@ece. cmu. edu \(E-mail\)" Subject: RE: FW: iSCSI: "conservative reuse" requirement Marjorie, If an "initiator/target portal group" concept is "the collection of IP addresses which can be combined to create a single iSCSI session." why isn't it defined as such in the draft? IMO, it would have been better to define ISID/TSID in simple networking terms like {TCP/IP address + Name} instead of coming up with network entity, network portal and portal group terminology. Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Eddy Quicksall Sent: Monday, December 31, 2001 2:15 PM To: KRUEGER,MARJORIE (HP-Roseville,ex1); Jim Hafner Cc: ips@ece. cmu. edu (E-mail) Subject: RE: FW: iSCSI: "conservative reuse" requirement Marjorie, If "an initiator portal group is the same concept as the target portal group", then it must be equivalent to the SCSI Initiator Port (because we have said that the SCSI Target Port maps to an iSCSI Target Portal Group). Comments? Eddy -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie_krueger@hp.com] Sent: Monday, December 31, 2001 4:48 PM To: 'Eddy Quicksall'; Jim Hafner Cc: ips@ece. cmu. edu (E-mail) Subject: RE: FW: iSCSI: "conservative reuse" requirement Your assumption of what is meant by an initiator portal group is incorrect (I don't think it's implied that IPG = IP???) An initiator portal group is the same concept as a target portal group - it's the collection of IP addresses which can be combined to create a single iSCSI session. Frequently this is thought of as an iSCSI HBA, but that is not necessarily so, it could be a number of iSCSI HBAs, etc. 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: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] > Sent: Monday, December 31, 2001 10:39 AM > To: Jim Hafner > Cc: ips@ece. cmu. edu (E-mail) > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > Regarding answer 2 below: > There is no given definition for an iSCSI Initiator Portal Group (however, > it is implied to be the same as the endpoint in 9.1.1, which would be the > same as the SCSI Initiator Port). Since an iSCSI Initiator Portal Group is > the same as a SCSI Initiator Port and since an iSCSI Target Portal Group is > the same as a SCSI Target Port, then each session in answer number 2 would > not have a "different SCSI initiator port"; hence you would have a parallel > nexus. > One thing that is not clear in section 9.1.1 (however, it is loosely > implied) is that the reuse of ISID's applies to a given initiator endpoint > (SCSI Initiator Port or what should be called an iSCSI Initiator Portal > Group)). I think that should be made clear. > What am I missing? Could it be that an iSCSI Initiator Portal Group is not > equivalent to a SCSI Target Port? > > Eddy > > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Saturday, December 29, 2001 6:14 PM > To: Eddy Quicksall > Cc: ips > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > Eddy, > > The SCSI initiator port is modeled as the endpoint of the > iSCSI session; > the SCSI target port is modeled as the iSCSI target portal group. The > reason we did it this way was to allow more than one session > between portal > groups by allowing multi-plexing of sessions with different > ISIDs from the > same iSCSI initiator portal group to the same target portal group. > > So, the answer to your questions are: > 1) no, we're assuming no more than on session *with the same > ISID* to the > same target portal group (that'd be more than one nexus), but > by allowing > different ISIDs we get different SCSI initiator ports. > 2) no, we're allowing more than one session between an iSCSI initiator > portal group and an iSCSI target portal group (each session > has a different > SCSI initiator port (id'ed by its ISID) but the same SCSI target port > (id'ed by its portal group tag). > 3) sort of, the ISID together with the iSCSI Initiator Name fully > identifies the SCSI initiator port (and so defines the SCSI > initiator port > name and the identifier). > > Does that clear this up? > > Jim Hafner > > > "Eddy Quicksall" on 12/28/2001 > 07:19:33 PM > > To: Jim Hafner/Almaden/IBM@IBMUS > cc: "ips@ece. cmu. edu \(E-mail\)" > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > > Due to 2.5.3 (b) "Between a given SCSI initiator port and SCSI target > port, there can be only one I_T nexus (session)", aren't we always > "assuming no more than one session"? > > Or are you talking about more than one session between different SCSI > initiator ports and a single SCSI target port? > > Is the ISID equivalent to SAM-2's Initiator Port Identifier? > > > Eddy > > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Friday, December 28, 2001 12:15 PM > To: John Hufferd; Eddy Quicksall; Mallikarjun C.; Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: FW: iSCSI: "conservative reuse" requirement > > > Folks, > > Sorry for taking so long to jump into this discussion. > > There are a number of issues raised in this thread: > 1) should "conservative reuse" of ISIDs be made a MUST > 2) does "conservative reuse" imply that all hosts look "single SCSI > ported" > > Here's my two cents (using "CR" as a shorthand for "conservative > reuse") > > I don't believe that CR needs to be a MUST. The only time this has > any > real value is in configurations that use SCSI persistent reservations > (and > where new SCSI target reservation features are enabled -- NB. these > features are yet to be approved but are working their way through the > process). I don't think these are going to be (even in the future) the > majority of installations. There are many ways then that CR could be > something that is not generally available in most drivers but is added > by > configuration and perhaps even "value add" (:-{)). > > In short, I don't see a strong case for this to be a MUST. So, to > David > Black, my answer is that having a mechanism to enable this feature or > have > it as a "purchase requirement" is an acceptable mechanism to make sure > the > feature is there when needed, but it is need not be a requirement of > the > protocol. To Mallikarjun, I think I'm agreeing with you that so long > as > there is a mechanism defined, iSCSI has done it's job. > > As for the second issue (raised by Mallikarjun), let's look at the > definition of CR. What is means is that when an iSCSI initiator > (node) > creates ISIDs for use in session identifiers, it attempts to reuse > them > as > much as possible with different SCSI target ports (iSCSI target portal > groups). This is the only way that a SCSI target or LU can see the > same > SCSI initiator port through two or more of its SCSI target ports -- > that > is, that the target can determine multiple paths *from* the same SCSI > initiator port. But, the model for generating ISIDs is not really at > the > node level but at the initiator portal group level. > So, IMO, the conclusion that all hosts must then look "single SCSI > ported" > is too dramatic. As I mentioned, ISIDs are conceptually generated > within > initiator portal groups (that's why we defined the mechanism for > generating > ISIDs). The conclusion I draw is that (assuming no more than one > session > to any given target portal group), an iSCSI initiator implementing CR > will > have as many SCSI initiator ports as iSCSI initiator portal groups > (independent HBAs?). Each initiator portal group would generate one > ISID > (that is different from that generated by/for the other initiator > portal > groups) and use CR for repeatability. [This is consistent with a > model > that mapped SCSI initiator ports to initiator portal groups, which we > had > to abandon because the "assuming no more than one session..." was no > acceptable as a requirement!!!] This independence of ISIDs for each > initiator portal group allows each initiator portal group to open > sessions > with *every* target portal group it knows about without having to > worry > about interfering with other sessions. [This has shades of the > "partitioning" rule for ISIDs that has been discussed ad nauseum!!!] > > (I have a feeling that this note is not well composed -- it is the > holidays, you know). I hope I've addressed everyone's concerns and we > can > lay this one to rest. > > Jim Hafner > > > John Hufferd > 12/25/2001 08:49 AM > > To: "Eddy Quicksall" > cc: Jim Hafner/Almaden/IBM@IBMUS > From: John Hufferd/San Jose/IBM@IBMUS > Subject: Re: FW: iSCSI: "conservative reuse" requirement (Document > link: > Jim Hafner) > > You are correct. The section was created by Jim Hafner, and via this > note > I will ask him if he could answer Mallikarjun Directly since I did not > understand his issue. > > . > . > . > 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" on 12/24/2001 06:06:44 > PM > > To: John Hufferd/San Jose/IBM@IBMUS > cc: > Subject: FW: iSCSI: "conservative reuse" requirement > > > > John, > > Were you the author of "conservative reuse"? I am wondering about some > issues. Maybe you could educate me somewhat ... > > I started this subject in a different thread by saying that it may be > good to make "conservative reuse" a MUST. > > I got one objection from Santosh below. Then David Black picked it up > by basically agreeing with me. Then Mallikarjun objected to that. > > It seems like the objective would be to give targets a way to figure > out that two or more sessions are coming from the same Initiator Port. > That is needed support persistent reservations. > > If an initiator does not use "conservative reuse", I don't think > targets will be able to make that determination. > > Comments? > > Eddy > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Monday, December 24, 2001 12:47 AM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: "conservative reuse" requirement > > > I think this is headed towards "conservative reuse" being a MUST if > > we're serious about support for shared persistent reservations. > > Mandating "conservative reuse" appears to force initiators to always > act > as a single initiator port (wrt one target; assuming only one session > as > an > example) per initiator device - which rules out the case of an > initiator > > intentionally wanting to present a different port to each target > portal > group. > > IMHO, if iSCSI provides an architected mechanism to support shared > persistent reservations ("conservative reuse"), that should be > completely > adequate to meet the expectations to be a legal SCSI protocol. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 > > ----- Original Message ----- > From: > To: > Cc: > Sent: Friday, December 21, 2001 4:50 PM > Subject: iSCSI: "conservative reuse" requirement > > > > Santosh Rao writes: > > > > > I am opposed to the suggestion that "conservative re-use" of ISIDs > be > > > made a MUST. This is really only required when initiators need to > be > > > using the new T10 Reservation scheme that can be shared > > > across initiator ports. > > > > Those reservations are a Target feature. With this approach, the > ability > > to use the target feature depends on details of the initiator > > implementation. > > More below ... > > > > > For those initiators that don't care about this type of > reservation, > > > conservative re-use is of no use and initiators may like to assign > > > ISID's in a per-initiator node fashion, thereby, being able to use > these > > > ISIDs as a lookup index for the sessions on that initiator node. > > > > > > Hence, I suggest that "conservative re-use" be worded as > > > "encouraged to use" or something to that effect, but not MUST USE. > > > > > > Comments ? > > > > The "initiator" is more than one entity. The iSCSI HBA/NIC and > driver > > doesn't know whether shared persistent reservations are being used > and > > shouldn't have to care - they're just more SCSI commands to > transport. > > Some other entity (e.g., clustering software) will be generating the > > shared persistent reservations. This raise the possible scenario > > involving a target that supports the new shared persistent > reservations > > and an entity that wants to use them. The entity detects (via SCSI > means, > > e.g., something in a mode page) that the Target supports shared > persistent > > reservations, tries to use them, only to discover that they don't > work > > because the iSCSI HBA/NIC doesn't implement "conservative reuse". > > > > I'm worried about this causing both interoperability issues and > possible > > T10 issues -- from a T10 viewpoint, if shared persistent > reservations > > don't work, the initiating entity should have some SCSI-level means > > of determining this ... if that means exists only on the Target, the > > above scenario is iSCSI's problem (Target can't query Initiator to > > determine whether it does "conservative reuse"), and having a > separate > > initiator side means that the entity has to check only for iSCSI > (and > > not for any other SCSI transport) does not seem like the right > > approach. > > > > I think this is headed towards "conservative reuse" being a MUST if > > we're serious about support for shared persistent reservations. > > > > Comments? > > --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 > > --------------------------------------------------- > > > > > > > --0__=07BBE1A7DFE01CBC8f9e8a93df938690918c07BBE1A7DFE01CBC Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Eddy,

I don't know why you think we've done a bad job of defining these terms. I don't have a copy of the draft around at the moment but this is my recollection:

These are the iSCSI architectural level components:
There is a definition of an iSCSI node (that has a WWU name).

There is a definition of Portal Group (which does NOT apply only to targets but is applicable to both targets and initiators). (I even thought there was text that said that this definition applied to both initiator and target, but I could be wrong about this.)

There is a definition of sessions and the specification of how SSIDs are generated from the ISID component and the TSID component.


There is the (required by any SCSI protocol) a mapping of the SCSI constructs to iSCSI constructs. The SCSI constructs of concern here are (a) device -- both initiator and target (b) port -- initiator, target and initiator/target and (c) nexus:

There is explicit language that defines the SCSI device as a component of an iSCSI node (and that there is only one such SCSI device construct within an iSCSI node -- and this allows us to define the SCSI device name as equal to the iSCSI node name).

There is explicit language that maps the SCSI initiator port to an iSCSI construct and *different* language that maps the SCSI target port to an iSCSI construct. For the SCSI initiator port, the mapping is to the initiator end of a session. For the SCSI target port, the mapping is to the iSCSI target portal group. It is NOT symmetric and is stated so explicitly.

There is explicit language the maps the SCSI nexus to the session. Note that a nexus is a relationship between a SCSI initiator port and a SCSI target port (that's the SAM definition!). What iSCSI does is map this relationship from the iSCSI initiator end of a session (SCSI initiator port) to the iSCSI target portal group (SCSI target port).

Does the text not say this?

Note that the approach we've taken here is to define the iSCSI architecture and then MAP the iSCSI constructs to SAM-defined SCSI constructs.

And, an attempt to map SCSI initiator port to the iSCSI initiator portal group (as you suggest) will force a requirement that there can be only one session between an iSCSI initiator portal group and an iSCSI target portal group! If one thinks that most "portal groups" will be instantiated by an iSCSI HBA, then this requirement is unacceptable.


Jim Hafner

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

To: John Hufferd/San Jose/IBM@IBMUS
cc: ips@ece.cmu.edu
Subject: RE: FW: iSCSI: "conservative reuse" requirement



My problem is that we have not done a good job of defining the iSCSI
Initiator Portal Group in the spec. If defined correctly, there should be no
need for the "conservative reuse" clause.

Here is how I think it should be defined ... SCSI Initiator Port: this maps
to an iSCSI Initiator Portal Group.

You could go on to say something like Marjorie said below ... that it is a
collection of IP addresses that can be used to support one or more iSCSI
sessions.

Given that it is equivalent to a SCSI Initiator Port and that it is
identified by the InitiatorName+ISID, it follows that every session from
that "port" would have to use the same ISID; and that is what will make
persistent reservations work.

It is not that "conservative reuse" won't work ... it is more that it is
hard to explain because we don't have a clear definition of a SCSI Initiator
Port and Initiator Port Identifier.

Eddy

-----Original Message-----
From: John Hufferd [mailto:hufferd@us.ibm.com]
Sent: Monday, December 31, 2001 8:01 PM
To: Amir Shalit
Cc: ips@ece.cmu.edu
Subject: RE: FW: iSCSI: "conservative reuse" requirement


We overtly chose NOT to identify an ISID with a TCP/IP address, since the
ISID may span several HBAs and/or TCP/IP addresses.  It was more general
and consistent NOT to be tied to a  TCP/IP address.

.
.
.
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


"Amir Shalit" <amir@astutenetworks.com>@ece.cmu.edu on 12/31/2001 03:35:56
PM

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


To:    "Eddy Quicksall" <Eddy_Quicksall@ivivity.com>, "KRUEGER,MARJORIE
      \(HP-Roseville,ex1\)" <marjorie_krueger@hp.com>, Jim
      Hafner/Almaden/IBM@IBMUS
cc:    "ips@ece. cmu. edu \(E-mail\)" <ips@ece.cmu.edu>
Subject:    RE: FW: iSCSI: "conservative reuse" requirement



Marjorie,

If an "initiator/target portal group" concept is
"the collection of IP addresses which can be combined to create a single
iSCSI session."
why isn't it defined as such in the draft?

IMO, it would have been better to define ISID/TSID in simple networking
terms
like {TCP/IP address + Name} instead of coming up with network entity,
network portal
and portal group terminology.

Amir


-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Eddy Quicksall
Sent: Monday, December 31, 2001 2:15 PM
To: KRUEGER,MARJORIE (HP-Roseville,ex1); Jim Hafner
Cc: ips@ece. cmu. edu (E-mail)
Subject: RE: FW: iSCSI: "conservative reuse" requirement


Marjorie,

If "an initiator portal group is the same concept as the target portal
group", then it must be equivalent to the SCSI Initiator Port (because we
have said that the SCSI Target Port maps to an iSCSI Target Portal Group).

Comments?

Eddy

-----Original Message-----
From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie_krueger@hp.com]
Sent: Monday, December 31, 2001 4:48 PM
To: 'Eddy Quicksall'; Jim Hafner
Cc: ips@ece. cmu. edu (E-mail)
Subject: RE: FW: iSCSI: "conservative reuse" requirement

Your assumption of what is meant by an initiator portal group is incorrect
(I don't think it's implied that IPG = IP???)  An initiator portal group is
the same concept as a target portal group - it's the collection of IP
addresses which can be combined to create a single iSCSI session.
Frequently this is thought of as an iSCSI HBA, but that is not necessarily
so, it could be a number of iSCSI HBAs, etc.

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: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com]
> Sent: Monday, December 31, 2001 10:39 AM
> To: Jim Hafner
> Cc: ips@ece. cmu. edu (E-mail)
> Subject: RE: FW: iSCSI: "conservative reuse" requirement
>
>
> Regarding answer 2 below:
> There is no given definition for an iSCSI Initiator Portal Group
(however,
> it is implied to be the same as the endpoint in 9.1.1, which would be the
> same as the SCSI Initiator Port). Since an iSCSI Initiator Portal Group
is
> the same as a SCSI Initiator Port and since an iSCSI Target Portal Group
is
> the same as a SCSI Target Port, then each session in answer number 2
would
> not have a "different SCSI initiator port"; hence you would have a
parallel
> nexus.
> One thing that is not clear in section 9.1.1 (however, it is loosely
> implied) is that the reuse of ISID's applies to a given initiator
endpoint
> (SCSI Initiator Port or what should be called an iSCSI Initiator Portal
> Group)). I think that should be made clear.
> What am I missing? Could it be that an iSCSI Initiator Portal Group is
not
> equivalent to a SCSI Target Port?
>
> Eddy
>
> -----Original Message-----
> From: Jim Hafner [mailto:hafner@almaden.ibm.com]
> Sent: Saturday, December 29, 2001 6:14 PM
> To: Eddy Quicksall
> Cc: ips
> Subject: RE: FW: iSCSI: "conservative reuse" requirement
>
>
> Eddy,
>
> The SCSI initiator port is modeled as the endpoint of the
> iSCSI session;
> the SCSI target port is modeled as the iSCSI target portal group.  The
> reason we did it this way was to allow more than one session
> between portal
> groups by allowing multi-plexing of sessions with different
> ISIDs from the
> same iSCSI initiator portal group to the same target portal group.
>
> So, the answer to your questions are:
> 1) no, we're assuming no more than on session *with the same
> ISID* to the
> same target portal group (that'd be more than one nexus), but
> by allowing
> different ISIDs we get different SCSI initiator ports.
> 2) no, we're allowing more than one session between an iSCSI initiator
> portal group and an iSCSI target portal group (each session
> has a different
> SCSI initiator port (id'ed by its ISID) but the same SCSI target port
> (id'ed by its portal group tag).
> 3) sort of, the ISID together with the iSCSI Initiator Name fully
> identifies the SCSI initiator port (and so defines the SCSI
> initiator port
> name and the identifier).
>
> Does that clear this up?
>
> Jim Hafner
>
>
> "Eddy Quicksall" <Eddy_Quicksall@iVivity.com> on 12/28/2001
> 07:19:33 PM
>
> To:   Jim Hafner/Almaden/IBM@IBMUS
> cc:   "ips@ece. cmu. edu \(E-mail\)" <ips@ece.cmu.edu>
> Subject:  RE: FW: iSCSI: "conservative reuse" requirement
>
>
>
> Due to 2.5.3 (b) "Between a given SCSI initiator port and SCSI target
> port, there can be only one I_T nexus (session)", aren't we always
> "assuming no more than one session"?
>
> Or are you talking about more than one session between different SCSI
> initiator ports and a single SCSI target port?
>
> Is the ISID equivalent to SAM-2's Initiator Port Identifier?
>
>
> Eddy
>
> -----Original Message-----
> From: Jim Hafner [mailto:hafner@almaden.ibm.com]
> Sent: Friday, December 28, 2001 12:15 PM
> To: John Hufferd; Eddy Quicksall; Mallikarjun C.; Black_David@emc.com
> Cc: ips@ece.cmu.edu
> Subject: Re: FW: iSCSI: "conservative reuse" requirement
>
>
> Folks,
>
> Sorry for taking so long to jump into this discussion.
>
> There are a number of issues raised in this thread:
> 1) should "conservative reuse" of ISIDs be made a MUST
> 2) does "conservative reuse" imply that all hosts look "single SCSI
> ported"
>
> Here's my two cents (using "CR" as a shorthand for "conservative
> reuse")
>
> I don't believe that CR needs to be a MUST.  The only time this has
> any
> real value is in configurations that use SCSI persistent reservations
> (and
> where new SCSI target reservation features are enabled -- NB.  these
> features are yet to be approved but are working their way through the
> process). I don't think these are going to be (even in the future) the
> majority of installations.  There are many ways then that CR could be
> something that is not generally available in most drivers but is added
> by
> configuration and perhaps even "value add" (:-{)).
>
> In short, I don't see a strong case for this to be a MUST.  So, to
> David
> Black, my answer is that having a mechanism to enable this feature or
> have
> it as a "purchase requirement" is an acceptable mechanism to make sure
> the
> feature is there when needed, but it is need not be a requirement of
> the
> protocol.  To Mallikarjun, I think I'm agreeing with you that so long
> as
> there is a mechanism defined, iSCSI has done it's job.
>
> As for the second issue (raised by Mallikarjun), let's look at the
> definition of CR.  What is means is that when an iSCSI initiator
> (node)
> creates ISIDs for use in session identifiers, it attempts to reuse
> them
> as
> much as possible with different SCSI target ports (iSCSI target portal
> groups).  This is the only way that a SCSI target or LU can see the
> same
> SCSI initiator port through two or more of its SCSI target ports --
> that
> is, that the target can determine multiple paths *from* the same SCSI
> initiator port.   But, the model for generating ISIDs is not really at
> the
> node level but at the initiator portal group level.
> So, IMO, the conclusion that all hosts must then look "single SCSI
> ported"
> is too dramatic.  As I mentioned,  ISIDs are conceptually generated
> within
> initiator portal groups (that's why we defined the mechanism for
> generating
> ISIDs).  The conclusion I draw is that (assuming no more than one
> session
> to any given target portal group), an iSCSI initiator implementing CR
> will
> have as many SCSI initiator ports as iSCSI initiator portal groups
> (independent HBAs?).  Each initiator portal group would generate one
> ISID
> (that is different from that generated by/for the other initiator
> portal
> groups) and use CR for repeatability.  [This is consistent with a
> model
> that mapped SCSI initiator ports to initiator portal groups, which we
> had
> to abandon because the "assuming no more than one session..." was no
> acceptable as a requirement!!!]  This independence of ISIDs for each
> initiator portal group allows each initiator portal group to open
> sessions
> with *every* target portal group it knows about without having to
> worry
> about interfering with other sessions. [This has shades of the
> "partitioning" rule for ISIDs that has been discussed ad nauseum!!!]
>
> (I have a feeling that this note is not well composed -- it is the
> holidays, you know).  I hope I've addressed everyone's concerns and we
> can
> lay this one to rest.
>
> Jim Hafner
>
>
> John Hufferd
> 12/25/2001 08:49 AM
>
> To:   "Eddy Quicksall" <Eddy_Quicksall@iVivity.com>
> cc:   Jim Hafner/Almaden/IBM@IBMUS
> From: John Hufferd/San Jose/IBM@IBMUS
> Subject:  Re: FW: iSCSI: "conservative reuse" requirement  (Document
> link:
>       Jim Hafner)
>
> You are correct.  The section was created by Jim Hafner, and via this
> note
> I will ask him if he could answer Mallikarjun Directly since I did not
> understand his issue.
>
> .
> .
> .
> 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" <Eddy_Quicksall@iVivity.com> on 12/24/2001 06:06:44
> PM
>
> To:   John Hufferd/San Jose/IBM@IBMUS
> cc:
> Subject:  FW: iSCSI: "conservative reuse" requirement
>
>
>
> John,
>
> Were you the author of "conservative reuse"? I am wondering about some
> issues. Maybe you could educate me somewhat ...
>
> I started this subject in a different thread by saying that it may be
> good to make "conservative reuse" a MUST.
>
> I got one objection from Santosh below. Then David Black picked it up
> by basically agreeing with me. Then Mallikarjun objected to that.
>
> It seems like the objective would be to give targets a way to figure
> out that two or more sessions are coming from the same Initiator Port.
> That is needed support persistent reservations.
>
> If an initiator does not use "conservative reuse", I don't think
> targets will be able to make that determination.
>
> Comments?
>
> Eddy
>
> -----Original Message-----
> From: Mallikarjun C. [mailto:cbm@rose.hp.com]
> Sent: Monday, December 24, 2001 12:47 AM
> To: Black_David@emc.com
> Cc: ips@ece.cmu.edu
> Subject: Re: iSCSI: "conservative reuse" requirement
>
> > I think this is headed towards "conservative reuse" being a MUST if
> > we're serious about support for shared persistent reservations.
>
> Mandating "conservative reuse" appears to force initiators to always
> act
> as a single initiator port (wrt one target; assuming only one session
> as
> an
> example) per initiator device - which rules out the case of an
> initiator
>
> intentionally wanting to present a different port to each target
> portal
> group.
>
> IMHO, if iSCSI provides an architected mechanism to support shared
> persistent reservations ("conservative reuse"),  that should be
> completely
> adequate to meet the expectations to be a legal SCSI protocol.
> --
> Mallikarjun
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> Hewlett-Packard MS 5668
> Roseville CA 95747
>
> ----- Original Message -----
> From: <Black_David@emc.com>
> To: <santoshr@cup.hp.com>
> Cc: <ips@ece.cmu.edu>
> Sent: Friday, December 21, 2001 4:50 PM
> Subject: iSCSI: "conservative reuse" requirement
>
>
> > Santosh Rao writes:
> >
> > > I am opposed to the suggestion that "conservative re-use" of ISIDs
> be
> > > made a MUST. This is really only required when initiators need to
> be
> > > using the new T10 Reservation scheme that can be shared
> > > across initiator ports.
> >
> > Those reservations are a Target feature.  With this approach, the
> ability
> > to use the target feature depends on details of the initiator
> > implementation.
> > More below ...
> >
> > > For those initiators that don't care about this type of
> reservation,
> > > conservative re-use is of no use and initiators may like to assign
> > > ISID's in a per-initiator node fashion, thereby, being able to use
> these
> > > ISIDs as a lookup index for the sessions on that initiator node.
> > >
> > > Hence, I suggest that "conservative re-use" be worded as
> > > "encouraged to use" or something to that effect, but not MUST USE.
> > >
> > > Comments ?
> >
> > The "initiator" is more than one entity.  The iSCSI HBA/NIC and
> driver
> > doesn't know whether shared persistent reservations are being used
> and
> > shouldn't have to care - they're just more SCSI commands to
> transport.
> > Some other entity (e.g., clustering software) will be generating the
> > shared persistent reservations.  This raise the possible scenario
> > involving a target that supports the new shared persistent
> reservations
> > and an entity that wants to use them.  The entity detects (via SCSI
> means,
> > e.g., something in a mode page) that the Target supports shared
> persistent
> > reservations, tries to use them, only to discover that they don't
> work
> > because the iSCSI HBA/NIC doesn't implement "conservative reuse".
> >
> > I'm worried about this causing both interoperability issues and
> possible
> > T10 issues -- from a T10 viewpoint, if shared persistent
> reservations
> > don't work, the initiating entity should have some SCSI-level means
> > of determining this ... if that means exists only on the Target, the
> > above scenario is iSCSI's problem (Target can't query Initiator to
> > determine whether it does "conservative reuse"), and having a
> separate
> > initiator side means that the entity has to check only for iSCSI
> (and
> > not for any other SCSI transport) does not seem like the right
> > approach.
> >
> > I think this is headed towards "conservative reuse" being a MUST if
> > we're serious about support for shared persistent reservations.
> >
> > Comments?
> > --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
> > ---------------------------------------------------
> >
> >
>
>
>





--0__=07BBE1A7DFE01CBC8f9e8a93df938690918c07BBE1A7DFE01CBC-- From owner-ips@ece.cmu.edu Wed Jan 2 01:38: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 BAA22013 for ; Wed, 2 Jan 2002 01:38:42 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g025aZl17718 for ips-outgoing; Wed, 2 Jan 2002 00:36:35 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dcmtechdom.dcmtech.co.in ([203.190.136.130]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g025aUg17714 for ; Wed, 2 Jan 2002 00:36:32 -0500 (EST) Received: by DCMTECHDOM with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Jan 2002 11:09:47 +0530 Message-ID: <7FADCB99FC82D41199F9000629A85D1A0293A9A5@DCMTECHDOM> From: Nitin Dhingra To: ips@ece.cmu.edu Subject: iScsi: Date: Wed, 2 Jan 2002 11:09:46 +0530 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 Why don't you put a restriction on the read/write access to a target? This can solve some of the synchronization problems that can occur... And Yeah Happy New Year to All... - Nitin From owner-ips@ece.cmu.edu Wed Jan 2 09:28: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 JAA04584 for ; Wed, 2 Jan 2002 09:28:15 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g02DCMF09123 for ips-outgoing; Wed, 2 Jan 2002 08:12:22 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g02DCFg09114 for ; Wed, 2 Jan 2002 08:12:15 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Jan 2002 08:12:09 -0500 Message-ID: <25369470B6F0D41194820002B328BDD2202296@ATLOPS> From: Eddy Quicksall To: Jim Hafner Cc: ips@ece.cmu.edu Subject: RE: FW: iSCSI: "conservative reuse" requirement Date: Wed, 2 Jan 2002 08:12:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1938F.136BC1C0" 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_01C1938F.136BC1C0 Content-Type: text/plain; charset="iso-8859-1" I see I must have offended you. I didn't mean to do that ... I was referring to the definition of iSCSI Initiator Portal Group and that it has been left out. It is an important item to define (as mapping to the SCSI Initiator Port). It is what is needed for persistent reservations. Defining it properly will eliminate the need for the "conservative reuse" clause. The problem I saw was that many people have misunderstood the ISID and how it should be used to be compliant with SAM-2. I said much earlier that the definition of iSCSI Initiator Portal Group was implied and that is exactly what you have pointed out below. It seems so silly not to define it. Can you give me a reason why it should not be defined? Eddy -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Tuesday, January 01, 2002 4:16 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu Subject: RE: FW: iSCSI: "conservative reuse" requirement Eddy, I don't know why you think we've done a bad job of defining these terms. I don't have a copy of the draft around at the moment but this is my recollection: These are the iSCSI architectural level components: There is a definition of an iSCSI node (that has a WWU name). There is a definition of Portal Group (which does NOT apply only to targets but is applicable to both targets and initiators). (I even thought there was text that said that this definition applied to both initiator and target, but I could be wrong about this.) There is a definition of sessions and the specification of how SSIDs are generated from the ISID component and the TSID component. There is the (required by any SCSI protocol) a mapping of the SCSI constructs to iSCSI constructs. The SCSI constructs of concern here are (a) device -- both initiator and target (b) port -- initiator, target and initiator/target and (c) nexus: There is explicit language that defines the SCSI device as a component of an iSCSI node (and that there is only one such SCSI device construct within an iSCSI node -- and this allows us to define the SCSI device name as equal to the iSCSI node name). There is explicit language that maps the SCSI initiator port to an iSCSI construct and *different* language that maps the SCSI target port to an iSCSI construct. For the SCSI initiator port, the mapping is to the initiator end of a session. For the SCSI target port, the mapping is to the iSCSI target portal group. It is NOT symmetric and is stated so explicitly. There is explicit language the maps the SCSI nexus to the session. Note that a nexus is a relationship between a SCSI initiator port and a SCSI target port (that's the SAM definition!). What iSCSI does is map this relationship from the iSCSI initiator end of a session (SCSI initiator port) to the iSCSI target portal group (SCSI target port). Does the text not say this? Note that the approach we've taken here is to define the iSCSI architecture and then MAP the iSCSI constructs to SAM-defined SCSI constructs. And, an attempt to map SCSI initiator port to the iSCSI initiator portal group (as you suggest) will force a requirement that there can be only one session between an iSCSI initiator portal group and an iSCSI target portal group! If one thinks that most "portal groups" will be instantiated by an iSCSI HBA, then this requirement is unacceptable. Jim Hafner Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS cc: ips@ece.cmu.edu Subject: RE: FW: iSCSI: "conservative reuse" requirement My problem is that we have not done a good job of defining the iSCSI Initiator Portal Group in the spec. If defined correctly, there should be no need for the "conservative reuse" clause. Here is how I think it should be defined ... SCSI Initiator Port: this maps to an iSCSI Initiator Portal Group. You could go on to say something like Marjorie said below ... that it is a collection of IP addresses that can be used to support one or more iSCSI sessions. Given that it is equivalent to a SCSI Initiator Port and that it is identified by the InitiatorName+ISID, it follows that every session from that "port" would have to use the same ISID; and that is what will make persistent reservations work. It is not that "conservative reuse" won't work ... it is more that it is hard to explain because we don't have a clear definition of a SCSI Initiator Port and Initiator Port Identifier. Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Monday, December 31, 2001 8:01 PM To: Amir Shalit Cc: ips@ece.cmu.edu Subject: RE: FW: iSCSI: "conservative reuse" requirement We overtly chose NOT to identify an ISID with a TCP/IP address, since the ISID may span several HBAs and/or TCP/IP addresses. It was more general and consistent NOT to be tied to a TCP/IP address. . . . 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 "Amir Shalit" @ece.cmu.edu on 12/31/2001 03:35:56 PM Sent by: owner-ips@ece.cmu.edu To: "Eddy Quicksall" , "KRUEGER,MARJORIE \(HP-Roseville,ex1\)" , Jim Hafner/Almaden/IBM@IBMUS cc: "ips@ece. cmu. edu \(E-mail\)" Subject: RE: FW: iSCSI: "conservative reuse" requirement Marjorie, If an "initiator/target portal group" concept is "the collection of IP addresses which can be combined to create a single iSCSI session." why isn't it defined as such in the draft? IMO, it would have been better to define ISID/TSID in simple networking terms like {TCP/IP address + Name} instead of coming up with network entity, network portal and portal group terminology. Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Eddy Quicksall Sent: Monday, December 31, 2001 2:15 PM To: KRUEGER,MARJORIE (HP-Roseville,ex1); Jim Hafner Cc: ips@ece. cmu. edu (E-mail) Subject: RE: FW: iSCSI: "conservative reuse" requirement Marjorie, If "an initiator portal group is the same concept as the target portal group", then it must be equivalent to the SCSI Initiator Port (because we have said that the SCSI Target Port maps to an iSCSI Target Portal Group). Comments? Eddy -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie_krueger@hp.com] Sent: Monday, December 31, 2001 4:48 PM To: 'Eddy Quicksall'; Jim Hafner Cc: ips@ece. cmu. edu (E-mail) Subject: RE: FW: iSCSI: "conservative reuse" requirement Your assumption of what is meant by an initiator portal group is incorrect (I don't think it's implied that IPG = IP???) An initiator portal group is the same concept as a target portal group - it's the collection of IP addresses which can be combined to create a single iSCSI session. Frequently this is thought of as an iSCSI HBA, but that is not necessarily so, it could be a number of iSCSI HBAs, etc. 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: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] > Sent: Monday, December 31, 2001 10:39 AM > To: Jim Hafner > Cc: ips@ece. cmu. edu (E-mail) > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > Regarding answer 2 below: > There is no given definition for an iSCSI Initiator Portal Group (however, > it is implied to be the same as the endpoint in 9.1.1, which would be the > same as the SCSI Initiator Port). Since an iSCSI Initiator Portal Group is > the same as a SCSI Initiator Port and since an iSCSI Target Portal Group is > the same as a SCSI Target Port, then each session in answer number 2 would > not have a "different SCSI initiator port"; hence you would have a parallel > nexus. > One thing that is not clear in section 9.1.1 (however, it is loosely > implied) is that the reuse of ISID's applies to a given initiator endpoint > (SCSI Initiator Port or what should be called an iSCSI Initiator Portal > Group)). I think that should be made clear. > What am I missing? Could it be that an iSCSI Initiator Portal Group is not > equivalent to a SCSI Target Port? > > Eddy > > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Saturday, December 29, 2001 6:14 PM > To: Eddy Quicksall > Cc: ips > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > Eddy, > > The SCSI initiator port is modeled as the endpoint of the > iSCSI session; > the SCSI target port is modeled as the iSCSI target portal group. The > reason we did it this way was to allow more than one session > between portal > groups by allowing multi-plexing of sessions with different > ISIDs from the > same iSCSI initiator portal group to the same target portal group. > > So, the answer to your questions are: > 1) no, we're assuming no more than on session *with the same > ISID* to the > same target portal group (that'd be more than one nexus), but > by allowing > different ISIDs we get different SCSI initiator ports. > 2) no, we're allowing more than one session between an iSCSI initiator > portal group and an iSCSI target portal group (each session > has a different > SCSI initiator port (id'ed by its ISID) but the same SCSI target port > (id'ed by its portal group tag). > 3) sort of, the ISID together with the iSCSI Initiator Name fully > identifies the SCSI initiator port (and so defines the SCSI > initiator port > name and the identifier). > > Does that clear this up? > > Jim Hafner > > > "Eddy Quicksall" on 12/28/2001 > 07:19:33 PM > > To: Jim Hafner/Almaden/IBM@IBMUS > cc: "ips@ece. cmu. edu \(E-mail\)" > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > > Due to 2.5.3 (b) "Between a given SCSI initiator port and SCSI target > port, there can be only one I_T nexus (session)", aren't we always > "assuming no more than one session"? > > Or are you talking about more than one session between different SCSI > initiator ports and a single SCSI target port? > > Is the ISID equivalent to SAM-2's Initiator Port Identifier? > > > Eddy > > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Friday, December 28, 2001 12:15 PM > To: John Hufferd; Eddy Quicksall; Mallikarjun C.; Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: FW: iSCSI: "conservative reuse" requirement > > > Folks, > > Sorry for taking so long to jump into this discussion. > > There are a number of issues raised in this thread: > 1) should "conservative reuse" of ISIDs be made a MUST > 2) does "conservative reuse" imply that all hosts look "single SCSI > ported" > > Here's my two cents (using "CR" as a shorthand for "conservative > reuse") > > I don't believe that CR needs to be a MUST. The only time this has > any > real value is in configurations that use SCSI persistent reservations > (and > where new SCSI target reservation features are enabled -- NB. these > features are yet to be approved but are working their way through the > process). I don't think these are going to be (even in the future) the > majority of installations. There are many ways then that CR could be > something that is not generally available in most drivers but is added > by > configuration and perhaps even "value add" (:-{)). > > In short, I don't see a strong case for this to be a MUST. So, to > David > Black, my answer is that having a mechanism to enable this feature or > have > it as a "purchase requirement" is an acceptable mechanism to make sure > the > feature is there when needed, but it is need not be a requirement of > the > protocol. To Mallikarjun, I think I'm agreeing with you that so long > as > there is a mechanism defined, iSCSI has done it's job. > > As for the second issue (raised by Mallikarjun), let's look at the > definition of CR. What is means is that when an iSCSI initiator > (node) > creates ISIDs for use in session identifiers, it attempts to reuse > them > as > much as possible with different SCSI target ports (iSCSI target portal > groups). This is the only way that a SCSI target or LU can see the > same > SCSI initiator port through two or more of its SCSI target ports -- > that > is, that the target can determine multiple paths *from* the same SCSI > initiator port. But, the model for generating ISIDs is not really at > the > node level but at the initiator portal group level. > So, IMO, the conclusion that all hosts must then look "single SCSI > ported" > is too dramatic. As I mentioned, ISIDs are conceptually generated > within > initiator portal groups (that's why we defined the mechanism for > generating > ISIDs). The conclusion I draw is that (assuming no more than one > session > to any given target portal group), an iSCSI initiator implementing CR > will > have as many SCSI initiator ports as iSCSI initiator portal groups > (independent HBAs?). Each initiator portal group would generate one > ISID > (that is different from that generated by/for the other initiator > portal > groups) and use CR for repeatability. [This is consistent with a > model > that mapped SCSI initiator ports to initiator portal groups, which we > had > to abandon because the "assuming no more than one session..." was no > acceptable as a requirement!!!] This independence of ISIDs for each > initiator portal group allows each initiator portal group to open > sessions > with *every* target portal group it knows about without having to > worry > about interfering with other sessions. [This has shades of the > "partitioning" rule for ISIDs that has been discussed ad nauseum!!!] > > (I have a feeling that this note is not well composed -- it is the > holidays, you know). I hope I've addressed everyone's concerns and we > can > lay this one to rest. > > Jim Hafner > > > John Hufferd > 12/25/2001 08:49 AM > > To: "Eddy Quicksall" > cc: Jim Hafner/Almaden/IBM@IBMUS > From: John Hufferd/San Jose/IBM@IBMUS > Subject: Re: FW: iSCSI: "conservative reuse" requirement (Document > link: > Jim Hafner) > > You are correct. The section was created by Jim Hafner, and via this > note > I will ask him if he could answer Mallikarjun Directly since I did not > understand his issue. > > . > . > . > 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" on 12/24/2001 06:06:44 > PM > > To: John Hufferd/San Jose/IBM@IBMUS > cc: > Subject: FW: iSCSI: "conservative reuse" requirement > > > > John, > > Were you the author of "conservative reuse"? I am wondering about some > issues. Maybe you could educate me somewhat ... > > I started this subject in a different thread by saying that it may be > good to make "conservative reuse" a MUST. > > I got one objection from Santosh below. Then David Black picked it up > by basically agreeing with me. Then Mallikarjun objected to that. > > It seems like the objective would be to give targets a way to figure > out that two or more sessions are coming from the same Initiator Port. > That is needed support persistent reservations. > > If an initiator does not use "conservative reuse", I don't think > targets will be able to make that determination. > > Comments? > > Eddy > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Monday, December 24, 2001 12:47 AM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: "conservative reuse" requirement > > > I think this is headed towards "conservative reuse" being a MUST if > > we're serious about support for shared persistent reservations. > > Mandating "conservative reuse" appears to force initiators to always > act > as a single initiator port (wrt one target; assuming only one session > as > an > example) per initiator device - which rules out the case of an > initiator > > intentionally wanting to present a different port to each target > portal > group. > > IMHO, if iSCSI provides an architected mechanism to support shared > persistent reservations ("conservative reuse"), that should be > completely > adequate to meet the expectations to be a legal SCSI protocol. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 > > ----- Original Message ----- > From: > To: > Cc: > Sent: Friday, December 21, 2001 4:50 PM > Subject: iSCSI: "conservative reuse" requirement > > > > Santosh Rao writes: > > > > > I am opposed to the suggestion that "conservative re-use" of ISIDs > be > > > made a MUST. This is really only required when initiators need to > be > > > using the new T10 Reservation scheme that can be shared > > > across initiator ports. > > > > Those reservations are a Target feature. With this approach, the > ability > > to use the target feature depends on details of the initiator > > implementation. > > More below ... > > > > > For those initiators that don't care about this type of > reservation, > > > conservative re-use is of no use and initiators may like to assign > > > ISID's in a per-initiator node fashion, thereby, being able to use > these > > > ISIDs as a lookup index for the sessions on that initiator node. > > > > > > Hence, I suggest that "conservative re-use" be worded as > > > "encouraged to use" or something to that effect, but not MUST USE. > > > > > > Comments ? > > > > The "initiator" is more than one entity. The iSCSI HBA/NIC and > driver > > doesn't know whether shared persistent reservations are being used > and > > shouldn't have to care - they're just more SCSI commands to > transport. > > Some other entity (e.g., clustering software) will be generating the > > shared persistent reservations. This raise the possible scenario > > involving a target that supports the new shared persistent > reservations > > and an entity that wants to use them. The entity detects (via SCSI > means, > > e.g., something in a mode page) that the Target supports shared > persistent > > reservations, tries to use them, only to discover that they don't > work > > because the iSCSI HBA/NIC doesn't implement "conservative reuse". > > > > I'm worried about this causing both interoperability issues and > possible > > T10 issues -- from a T10 viewpoint, if shared persistent > reservations > > don't work, the initiating entity should have some SCSI-level means > > of determining this ... if that means exists only on the Target, the > > above scenario is iSCSI's problem (Target can't query Initiator to > > determine whether it does "conservative reuse"), and having a > separate > > initiator side means that the entity has to check only for iSCSI > (and > > not for any other SCSI transport) does not seem like the right > > approach. > > > > I think this is headed towards "conservative reuse" being a MUST if > > we're serious about support for shared persistent reservations. > > > > Comments? > > --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 > > --------------------------------------------------- > > > > > > > ------_=_NextPart_001_01C1938F.136BC1C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I= see I must have offended you. I didn’t mean to do that … =

<= ![if = !supportEmptyParas]> 

=

I= was referring to the definition of iSCSI Initiator Portal Group and that it has been = left out. It is an important item to define (as mapping to the SCSI Initiator = Port). It is what is needed for persistent reservations. Defining it properly will = eliminate the need for the “conservative reuse” = clause.

<= ![if = !supportEmptyParas]> 

=

T= he problem I saw was that many people have misunderstood the ISID and how = it should be used to be compliant with SAM-2.

<= ![if = !supportEmptyParas]> 

=

I= said much earlier that the definition of iSCSI Initiator Portal Group was = implied and that is exactly what you have pointed out = below.

<= ![if = !supportEmptyParas]> 

=

I= t seems so silly not to define it. Can you give me a reason why it should not = be defined?

<= ![if = !supportEmptyParas]> 

=

E= ddy

<= ![if = !supportEmptyParas]> 

=

-----Original Message-----
From: Jim Hafner [mailto:hafner@almaden.ibm.com]
Sent: Tuesday, January = 01, 2002 4:16 PM
To: Eddy Quicksall
Cc: ips@ece.cmu.edu
Subject: RE: FW: iSCSI: "conservative reuse" requirement

 



Eddy,

I don't know why you think we've done a bad job of defining these = terms. I don't have a copy of the draft around at the moment but this is my recollection:

These are the iSCSI architectural level components:
There is a definition of an iSCSI node (that has a WWU name).

There is a definition of Portal Group (which does NOT apply only to = targets but is applicable to both targets and initiators). (I even thought there = was text that said that this definition applied to both initiator and target, = but I could be wrong about this.)

There is a definition of sessions and the specification of how SSIDs = are generated from the ISID component and the TSID component.


There is the (required by any SCSI protocol) a mapping of the SCSI = constructs to iSCSI constructs. The SCSI constructs of concern here are (a) device = -- both initiator and target (b) port -- initiator, target and initiator/target = and (c) nexus:

There is explicit language that defines the SCSI device as a component = of an iSCSI node (and that there is only one such SCSI device construct = within an iSCSI node -- and this allows us to define the SCSI device name as = equal to the iSCSI node name).

There is explicit language that maps the SCSI initiator port to an = iSCSI construct and *different* language that maps the SCSI target port to an = iSCSI construct. For the SCSI initiator port, the mapping is to the initiator = end of a session. For the SCSI target port, the mapping is to the iSCSI target = portal group. It is NOT symmetric and is stated so explicitly.

There is explicit language the maps the SCSI nexus to the session. Note = that a nexus is a relationship between a SCSI initiator port and a SCSI target = port (that's the SAM definition!). What iSCSI does is map this relationship = from the iSCSI initiator end of a session (SCSI initiator port) to the iSCSI = target portal group (SCSI target port).

Does the text not say this?

Note that the approach we've taken here is to define the iSCSI = architecture and then MAP the iSCSI constructs to SAM-defined SCSI constructs.

And, an attempt to map SCSI initiator port to the iSCSI initiator = portal group (as you suggest) will force a requirement that there can be only one = session between an iSCSI initiator portal group and an iSCSI target portal = group! If one thinks that most "portal groups" will be instantiated by = an iSCSI HBA, then this requirement is unacceptable.


Jim Hafner

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

To: John Hufferd/San Jose/IBM@IBMUS
cc: ips@ece.cmu.edu =
Subject: RE: FW: iSCSI: = "conservative reuse" requirement



My = problem is that we have not done a good job of defining the = iSCSI
Initiator Portal Group in the spec. If defined correctly, there = should be no
need for the "conservative reuse" clause.

Here = is how I think it should be defined ... SCSI Initiator Port: this = maps
to an iSCSI Initiator Portal Group.

You = could go on to say something like Marjorie said below ... that it is = a
collection of IP addresses that can be used to support one or more = iSCSI
sessions.

Given = that it is equivalent to a SCSI Initiator Port and that it = is
identified by the InitiatorName+ISID, it follows that every session = from
that "port" would have to use the same ISID; and that is = what will make
persistent reservations work.

It is = not that "conservative reuse" won't work ... it is more that it = is
hard to explain because we don't have a clear definition of a SCSI Initiator
Port and Initiator Port Identifier.

Eddy

-----Original Message-----
From: John Hufferd [mailto:hufferd@us.ibm.com]
Sent: Monday, December 31, 2001 8:01 PM
To: Amir Shalit
Cc: ips@ece.cmu.edu
Subject: RE: FW: iSCSI: "conservative reuse" = requirement


We = overtly chose NOT to identify an ISID with a TCP/IP address, since = the
ISID may span several HBAs and/or TCP/IP addresses.  It was = more general
and consistent NOT to be tied to a  TCP/IP address.

.
.
.
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


"Amir Shalit" <amir@astutenetworks.com>@ece.cmu.edu on 12/31/2001 = 03:35:56
PM

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


To: =    "Eddy Quicksall" <Eddy_Quicksall@ivivity.com>, "KRUEGER,MARJORIE
      \(HP-Roseville,ex1\)" = <marjorie_krueger@hp.com>, Jim
      Hafner/Almaden/IBM@IBMUS
cc:    "ips@ece. cmu. edu \(E-mail\)" <ips@ece.cmu.edu>
Subject:    RE: FW: iSCSI: "conservative reuse" requirement



Marjorie,

If an "initiator/target portal group" concept = is
"the collection of IP addresses which can be combined to = create a single
iSCSI session."
why isn't it defined as such in the draft?

IMO, = it would have been better to define ISID/TSID in simple = networking
terms
like {TCP/IP address + Name} instead of coming up with network = entity,
network portal
and portal group terminology.

Amir


-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf = Of
Eddy Quicksall
Sent: Monday, December 31, 2001 2:15 PM
To: KRUEGER,MARJORIE (HP-Roseville,ex1); Jim Hafner
Cc: ips@ece. cmu. edu (E-mail)
Subject: RE: FW: iSCSI: "conservative reuse" = requirement


Marjorie,

If = "an initiator portal group is the same concept as the target = portal
group", then it must be equivalent to the SCSI Initiator Port = (because we
have said that the SCSI Target Port maps to an iSCSI Target Portal = Group).

Comments?

Eddy

-----Original Message-----
From: KRUEGER,MARJORIE (HP-Roseville,ex1) = [mailto:marjorie_krueger@hp.com]
Sent: Monday, December 31, 2001 4:48 PM
To: 'Eddy Quicksall'; Jim Hafner
Cc: ips@ece. cmu. edu (E-mail)
Subject: RE: FW: iSCSI: "conservative reuse" = requirement

Your = assumption of what is meant by an initiator portal group is = incorrect
(I don't think it's implied that IPG =3D IP???)  An initiator = portal group is
the same concept as a target portal group - it's the collection of = IP
addresses which can be combined to create a single iSCSI = session.
Frequently this is thought of as an iSCSI HBA, but that is not = necessarily
so, it could be a number of iSCSI HBAs, etc.

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: Eddy Quicksall = [mailto:Eddy_Quicksall@ivivity.com]
> Sent: Monday, December 31, 2001 10:39 AM
> To: Jim Hafner
> Cc: ips@ece. cmu. edu (E-mail)
> Subject: RE: FW: iSCSI: "conservative reuse" = requirement
>
>
> Regarding answer 2 below:
> There is no given definition for an iSCSI Initiator Portal = Group
(however,
> it is implied to be the same as the endpoint in 9.1.1, which = would be the
> same as the SCSI Initiator Port). Since an iSCSI Initiator = Portal Group
is
> the same as a SCSI Initiator Port and since an iSCSI Target = Portal Group
is
> the same as a SCSI Target Port, then each session in answer = number 2
would
> not have a "different SCSI initiator port"; hence = you would have a
parallel
> nexus.
> One thing that is not clear in section 9.1.1 (however, it is = loosely
> implied) is that the reuse of ISID's applies to a given = initiator
endpoint
> (SCSI Initiator Port or what should be called an iSCSI = Initiator Portal
> Group)). I think that should be made clear.
> What am I missing? Could it be that an iSCSI Initiator Portal = Group is
not
> equivalent to a SCSI Target Port?
>
> Eddy
>
> -----Original Message-----
> From: Jim Hafner [mailto:hafner@almaden.ibm.com]
> Sent: Saturday, December 29, 2001 6:14 PM
> To: Eddy Quicksall
> Cc: ips
> Subject: RE: FW: iSCSI: "conservative reuse" = requirement
>
>
> Eddy,
>
> The SCSI initiator port is modeled as the endpoint of = the
> iSCSI session;
> the SCSI target port is modeled as the iSCSI target portal = group.  The
> reason we did it this way was to allow more than one = session
> between portal
> groups by allowing multi-plexing of sessions with = different
> ISIDs from the
> same iSCSI initiator portal group to the same target portal = group.
>
> So, the answer to your questions are:
> 1) no, we're assuming no more than on session *with the = same
> ISID* to the
> same target portal group (that'd be more than one nexus), = but
> by allowing
> different ISIDs we get different SCSI initiator = ports.
> 2) no, we're allowing more than one session between an iSCSI = initiator
> portal group and an iSCSI target portal group (each = session
> has a different
> SCSI initiator port (id'ed by its ISID) but the same SCSI = target port
> (id'ed by its portal group tag).
> 3) sort of, the ISID together with the iSCSI Initiator Name = fully
> identifies the SCSI initiator port (and so defines the = SCSI
> initiator port
> name and the identifier).
>
> Does that clear this up?
>
> Jim Hafner
>
>
> "Eddy Quicksall" <Eddy_Quicksall@iVivity.com> = on 12/28/2001
> 07:19:33 PM
>
> To:   Jim Hafner/Almaden/IBM@IBMUS
> cc:   "ips@ece. cmu. edu \(E-mail\)" = <ips@ece.cmu.edu>
> Subject:  RE: FW: iSCSI: "conservative reuse" requirement
>
>
>
> Due to 2.5.3 (b) "Between a given SCSI initiator port and = SCSI target
> port, there can be only one I_T nexus (session)", aren't = we always
> "assuming no more than one session"?
>
> Or are you talking about more than one session between = different SCSI
> initiator ports and a single SCSI target port?
>
> Is the ISID equivalent to SAM-2's Initiator Port = Identifier?
>
>
> Eddy
>
> -----Original Message-----
> From: Jim Hafner [mailto:hafner@almaden.ibm.com]
> Sent: Friday, December 28, 2001 12:15 PM
> To: John Hufferd; Eddy Quicksall; Mallikarjun C.; = Black_David@emc.com
> Cc: ips@ece.cmu.edu
> Subject: Re: FW: iSCSI: "conservative reuse" = requirement
>
>
> Folks,
>
> Sorry for taking so long to jump into this = discussion.
>
> There are a number of issues raised in this thread:
> 1) should "conservative reuse" of ISIDs be made a = MUST
> 2) does "conservative reuse" imply that all hosts = look "single SCSI
> ported"
>
> Here's my two cents (using "CR" as a shorthand for "conservative
> reuse")
>
> I don't believe that CR needs to be a MUST.  The only = time this has
> any
> real value is in configurations that use SCSI persistent = reservations
> (and
> where new SCSI target reservation features are enabled -- NB.  these
> features are yet to be approved but are working their way = through the
> process). I don't think these are going to be (even in the = future) the
> majority of installations.  There are many ways then that = CR could be
> something that is not generally available in most drivers but = is added
> by
> configuration and perhaps even "value add" = (:-{)).
>
> In short, I don't see a strong case for this to be a MUST. =  So, to
> David
> Black, my answer is that having a mechanism to enable this = feature or
> have
> it as a "purchase requirement" is an acceptable = mechanism to make sure
> the
> feature is there when needed, but it is need not be a = requirement of
> the
> protocol.  To Mallikarjun, I think I'm agreeing with you = that so long
> as
> there is a mechanism defined, iSCSI has done it's = job.
>
> As for the second issue (raised by Mallikarjun), let's look at = the
> definition of CR.  What is means is that when an iSCSI = initiator
> (node)
> creates ISIDs for use in session identifiers, it attempts to = reuse
> them
> as
> much as possible with different SCSI target ports (iSCSI = target portal
> groups).  This is the only way that a SCSI target or LU = can see the
> same
> SCSI initiator port through two or more of its SCSI target = ports --
> that
> is, that the target can determine multiple paths *from* the = same SCSI
> initiator port.   But, the model for generating ISIDs is = not really at
> the
> node level but at the initiator portal group level.
> So, IMO, the conclusion that all hosts must then look = "single SCSI
> ported"
> is too dramatic.  As I mentioned,  ISIDs are = conceptually generated
> within
> initiator portal groups (that's why we defined the mechanism = for
> generating
> ISIDs).  The conclusion I draw is that (assuming no more = than one
> session
> to any given target portal group), an iSCSI initiator = implementing CR
> will
> have as many SCSI initiator ports as iSCSI initiator portal = groups
> (independent HBAs?).  Each initiator portal group would = generate one
> ISID
> (that is different from that generated by/for the other = initiator
> portal
> groups) and use CR for repeatability.  [This is = consistent with a
> model
> that mapped SCSI initiator ports to initiator portal groups, = which we
> had
> to abandon because the "assuming no more than one session..." was no
> acceptable as a requirement!!!]  This independence of = ISIDs for each
> initiator portal group allows each initiator portal group to = open
> sessions
> with *every* target portal group it knows about without having = to
> worry
> about interfering with other sessions. [This has shades of = the
> "partitioning" rule for ISIDs that has been = discussed ad nauseum!!!]
>
> (I have a feeling that this note is not well composed -- it is = the
> holidays, you know).  I hope I've addressed everyone's = concerns and we
> can
> lay this one to rest.
>
> Jim Hafner
>
>
> John Hufferd
> 12/25/2001 08:49 AM
>
> To:   "Eddy Quicksall" <Eddy_Quicksall@iVivity.com>
> cc:   Jim Hafner/Almaden/IBM@IBMUS
> From: John Hufferd/San Jose/IBM@IBMUS
> Subject:  Re: FW: iSCSI: "conservative reuse" requirement  (Document
> link:
>       Jim Hafner)
>
> You are correct.  The section was created by Jim Hafner, = and via this
> note
> I will ask him if he could answer Mallikarjun Directly since I = did not
> understand his issue.
>
> .
> .
> .
> 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" <Eddy_Quicksall@iVivity.com> = on 12/24/2001 06:06:44
> PM
>
> To:   John Hufferd/San Jose/IBM@IBMUS
> cc:
> Subject:  FW: iSCSI: "conservative reuse" = requirement
>
>
>
> John,
>
> Were you the author of "conservative reuse"? I am = wondering about some
> issues. Maybe you could educate me somewhat ...
>
> I started this subject in a different thread by saying that it = may be
> good to make "conservative reuse" a MUST.
>
> I got one objection from Santosh below. Then David Black = picked it up
> by basically agreeing with me. Then Mallikarjun objected to = that.
>
> It seems like the objective would be to give targets a way to = figure
> out that two or more sessions are coming from the same = Initiator Port.
> That is needed support persistent reservations.
>
> If an initiator does not use "conservative reuse", I = don't think
> targets will be able to make that determination.
>
> Comments?
>
> Eddy
>
> -----Original Message-----
> From: Mallikarjun C. [mailto:cbm@rose.hp.com]
> Sent: Monday, December 24, 2001 12:47 AM
> To: Black_David@emc.com
> Cc: ips@ece.cmu.edu
> Subject: Re: iSCSI: "conservative reuse" = requirement
>
> > I think this is headed towards "conservative = reuse" being a MUST if
> > we're serious about support for shared persistent = reservations.
>
> Mandating "conservative reuse" appears to force = initiators to always
> act
> as a single initiator port (wrt one target; assuming only one = session
> as
> an
> example) per initiator device - which rules out the case of = an
> initiator
>
> intentionally wanting to present a different port to each = target
> portal
> group.
>
> IMHO, if iSCSI provides an architected mechanism to support = shared
> persistent reservations ("conservative reuse"), =  that should be
> completely
> adequate to meet the expectations to be a legal SCSI = protocol.
> --
> Mallikarjun
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> Hewlett-Packard MS 5668
> Roseville CA 95747
>
> ----- Original Message -----
> From: <Black_David@emc.com>
> To: <santoshr@cup.hp.com>
> Cc: <ips@ece.cmu.edu>
> Sent: Friday, December 21, 2001 4:50 PM
> Subject: iSCSI: "conservative reuse" = requirement
>
>
> > Santosh Rao writes:
> >
> > > I am opposed to the suggestion that = "conservative re-use" of ISIDs
> be
> > > made a MUST. This is really only required when = initiators need to
> be
> > > using the new T10 Reservation scheme that can be = shared
> > > across initiator ports.
> >
> > Those reservations are a Target feature.  With this approach, the
> ability
> > to use the target feature depends on details of the = initiator
> > implementation.
> > More below ...
> >
> > > For those initiators that don't care about this type = of
> reservation,
> > > conservative re-use is of no use and initiators may = like to assign
> > > ISID's in a per-initiator node fashion, thereby, = being able to use
> these
> > > ISIDs as a lookup index for the sessions on that = initiator node.
> > >
> > > Hence, I suggest that "conservative = re-use" be worded as
> > > "encouraged to use" or something to that = effect, but not MUST USE.
> > >
> > > Comments ?
> >
> > The "initiator" is more than one entity. =  The iSCSI HBA/NIC and
> driver
> > doesn't know whether shared persistent reservations are = being used
> and
> > shouldn't have to care - they're just more SCSI commands = to
> transport.
> > Some other entity (e.g., clustering software) will be = generating the
> > shared persistent reservations.  This raise the = possible scenario
> > involving a target that supports the new shared = persistent
> reservations
> > and an entity that wants to use them.  The entity = detects (via SCSI
> means,
> = > e.g., something in a mode page) that the Target supports = shared
> persistent
> > reservations, tries to use them, only to discover that = they don't
> work
> > because the iSCSI HBA/NIC doesn't implement = "conservative reuse".
> >
> > I'm worried about this causing both interoperability = issues and
> possible
> > T10 issues -- from a T10 viewpoint, if shared = persistent
> reservations
> > don't work, the initiating entity should have some = SCSI-level means
> > of determining this ... if that means exists only on the = Target, the
> > above scenario is iSCSI's problem (Target can't query = Initiator to
> > determine whether it does "conservative = reuse"), and having a
> separate
> > initiator side means that the entity has to check only = for iSCSI
> (and
> > not for any other SCSI transport) does not seem like the = right
> > approach.
> >
> > I think this is headed towards "conservative = reuse" being a MUST if
> > we're serious about support for shared persistent = reservations.
> >
> > Comments?
> > --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
> > = ---------------------------------------------------
> >
> >
>
>
>




------_=_NextPart_001_01C1938F.136BC1C0-- From owner-ips@ece.cmu.edu Wed Jan 2 10:25: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 KAA05552 for ; Wed, 2 Jan 2002 10:25:03 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g02EXh211762 for ips-outgoing; Wed, 2 Jan 2002 09:33:43 -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.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g02EXfg11758 for ; Wed, 2 Jan 2002 09:33:41 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Jan 2002 09:29:05 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0320DA34@CORPMX14> From: Black_David@emc.com To: mklock@crossroads.com, ips@ece.cmu.edu Subject: RE: IPSEC: IKE preshared keys, ID payload, and DHCP Date: Wed, 2 Jan 2002 09:21: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 > Digging this out from a ways back ... > If only the required IKE mode of preshared keys is supported > and ID payloads must contain a single IP address > (ips-security-06, last paragraph, page 12), how are > DHCP-enabled ports handled? When setting up the preshared > key, an administrator needs to know the IP address since this > is what the ID payload will identify (and what is used to > select the preshared key). But can't the IP address change > for a DHCP-enabled port on a power cycle, or lease > expiration, etc.? Is there an assumption that only ports with > static IP addresses are being used? Yes and No in that order. Sharing the preshared key among the set of DHCP-enabled ports is a solution that's often found in practice. Some of the aspects of dealing with DHCP are still open issues (e.g., I think another look/check is needed at the current restriction on ID payload usage)- with luck there'll be more on the mailing list in the near future. > In a related vein, will the IPSec DOI definition be updated > to include iSCSI names for ID payload types? I think this > would remove the problem with DHCP (at least for IKE Aggressive Mode). There are no plans to update the DOI - I would expect strong resistance from the ipsec WG (with good reason) to every protocol that uses IPsec adding its preferred naming types/formats to IPsec. 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 Jan 2 14:37:52 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09300 for ; Wed, 2 Jan 2002 14:37:51 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g02I5xR21906 for ips-outgoing; Wed, 2 Jan 2002 13:05: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 g02I5vg21902 for ; Wed, 2 Jan 2002 13:05:57 -0500 (EST) Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel7.hp.com (Postfix) with ESMTP id 40B70E00582; Wed, 2 Jan 2002 13:05:52 -0500 (EST) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id E0F96400095; Wed, 2 Jan 2002 13:05:51 -0500 (EST) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Jan 2002 13:05:51 -0500 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF2DC@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Eddy Quicksall'" , Jim Hafner Cc: ips@ece.cmu.edu Subject: RE: FW: iSCSI: "conservative reuse" requirement Date: Wed, 2 Jan 2002 13:05:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C193B8.1B7284C0" 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_01C193B8.1B7284C0 Content-Type: text/plain; charset="iso-8859-1" Did you read Jim's response carefully? You repeat the statement "It (initiator portal group" is an important item to define (as mapping to the SCSI Initiator Port). It is what is needed for persistent reservations. Defining it properly will eliminate the need for the "conservative reuse" clause." and Jim has explained to you that this statement is incorrect. Several of us have given you the definition of initiator portal group and you still have this misconception. I don't know how putting the definition in the draft would clear up your misunderstanding? If "initiator portal group" is not explicitly defined in the draft, it is in part because that concept plays no part in the iSCSI protocol - it's very important that you understand that. In order for an initiator to connect to a target, the initiator must know the target's portal groups. The converse is NOT true - nothing external to the target that participates in the iSCSI protocol needs to know the initiator's address information. Perhaps if you let go of the idea that the initiator portal group is an important thing in the iSCSI protocol, you'll understand what has been explained? 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: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] Sent: Wednesday, January 02, 2002 5:12 AM To: Jim Hafner Cc: ips@ece.cmu.edu Subject: RE: FW: iSCSI: "conservative reuse" requirement I see I must have offended you. I didn't mean to do that ... I was referring to the definition of iSCSI Initiator Portal Group and that it has been left out. It is an important item to define (as mapping to the SCSI Initiator Port). It is what is needed for persistent reservations. Defining it properly will eliminate the need for the "conservative reuse" clause. The problem I saw was that many people have misunderstood the ISID and how it should be used to be compliant with SAM-2. I said much earlier that the definition of iSCSI Initiator Portal Group was implied and that is exactly what you have pointed out below. It seems so silly not to define it. Can you give me a reason why it should not be defined? Eddy -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Tuesday, January 01, 2002 4:16 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu Subject: RE: FW: iSCSI: "conservative reuse" requirement Eddy, I don't know why you think we've done a bad job of defining these terms. I don't have a copy of the draft around at the moment but this is my recollection: These are the iSCSI architectural level components: There is a definition of an iSCSI node (that has a WWU name). There is a definition of Portal Group (which does NOT apply only to targets but is applicable to both targets and initiators). (I even thought there was text that said that this definition applied to both initiator and target, but I could be wrong about this.) There is a definition of sessions and the specification of how SSIDs are generated from the ISID component and the TSID component. There is the (required by any SCSI protocol) a mapping of the SCSI constructs to iSCSI constructs. The SCSI constructs of concern here are (a) device -- both initiator and target (b) port -- initiator, target and initiator/target and (c) nexus: There is explicit language that defines the SCSI device as a component of an iSCSI node (and that there is only one such SCSI device construct within an iSCSI node -- and this allows us to define the SCSI device name as equal to the iSCSI node name). There is explicit language that maps the SCSI initiator port to an iSCSI construct and *different* language that maps the SCSI target port to an iSCSI construct. For the SCSI initiator port, the mapping is to the initiator end of a session. For the SCSI target port, the mapping is to the iSCSI target portal group. It is NOT symmetric and is stated so explicitly. There is explicit language the maps the SCSI nexus to the session. Note that a nexus is a relationship between a SCSI initiator port and a SCSI target port (that's the SAM definition!). What iSCSI does is map this relationship from the iSCSI initiator end of a session (SCSI initiator port) to the iSCSI target portal group (SCSI target port). Does the text not say this? Note that the approach we've taken here is to define the iSCSI architecture and then MAP the iSCSI constructs to SAM-defined SCSI constructs. And, an attempt to map SCSI initiator port to the iSCSI initiator portal group (as you suggest) will force a requirement that there can be only one session between an iSCSI initiator portal group and an iSCSI target portal group! If one thinks that most "portal groups" will be instantiated by an iSCSI HBA, then this requirement is unacceptable. Jim Hafner Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS cc: ips@ece.cmu.edu Subject: RE: FW: iSCSI: "conservative reuse" requirement My problem is that we have not done a good job of defining the iSCSI Initiator Portal Group in the spec. If defined correctly, there should be no need for the "conservative reuse" clause. Here is how I think it should be defined ... SCSI Initiator Port: this maps to an iSCSI Initiator Portal Group. You could go on to say something like Marjorie said below ... that it is a collection of IP addresses that can be used to support one or more iSCSI sessions. Given that it is equivalent to a SCSI Initiator Port and that it is identified by the InitiatorName+ISID, it follows that every session from that "port" would have to use the same ISID; and that is what will make persistent reservations work. It is not that "conservative reuse" won't work ... it is more that it is hard to explain because we don't have a clear definition of a SCSI Initiator Port and Initiator Port Identifier. Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Monday, December 31, 2001 8:01 PM To: Amir Shalit Cc: ips@ece.cmu.edu Subject: RE: FW: iSCSI: "conservative reuse" requirement We overtly chose NOT to identify an ISID with a TCP/IP address, since the ISID may span several HBAs and/or TCP/IP addresses. It was more general and consistent NOT to be tied to a TCP/IP address. . . . 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 "Amir Shalit" @ece.cmu.edu on 12/31/2001 03:35:56 PM Sent by: owner-ips@ece.cmu.edu To: "Eddy Quicksall" , "KRUEGER,MARJORIE \(HP-Roseville,ex1\)" , Jim Hafner/Almaden/IBM@IBMUS cc: "ips@ece. cmu. edu \(E-mail\)" Subject: RE: FW: iSCSI: "conservative reuse" requirement Marjorie, If an "initiator/target portal group" concept is "the collection of IP addresses which can be combined to create a single iSCSI session." why isn't it defined as such in the draft? IMO, it would have been better to define ISID/TSID in simple networking terms like {TCP/IP address + Name} instead of coming up with network entity, network portal and portal group terminology. Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Eddy Quicksall Sent: Monday, December 31, 2001 2:15 PM To: KRUEGER,MARJORIE (HP-Roseville,ex1); Jim Hafner Cc: ips@ece. cmu. edu (E-mail) Subject: RE: FW: iSCSI: "conservative reuse" requirement Marjorie, If "an initiator portal group is the same concept as the target portal group", then it must be equivalent to the SCSI Initiator Port (because we have said that the SCSI Target Port maps to an iSCSI Target Portal Group). Comments? Eddy -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie_krueger@hp.com] Sent: Monday, December 31, 2001 4:48 PM To: 'Eddy Quicksall'; Jim Hafner Cc: ips@ece. cmu. edu (E-mail) Subject: RE: FW: iSCSI: "conservative reuse" requirement Your assumption of what is meant by an initiator portal group is incorrect (I don't think it's implied that IPG = IP???) An initiator portal group is the same concept as a target portal group - it's the collection of IP addresses which can be combined to create a single iSCSI session. Frequently this is thought of as an iSCSI HBA, but that is not necessarily so, it could be a number of iSCSI HBAs, etc. 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: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] > Sent: Monday, December 31, 2001 10:39 AM > To: Jim Hafner > Cc: ips@ece. cmu. edu (E-mail) > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > Regarding answer 2 below: > There is no given definition for an iSCSI Initiator Portal Group (however, > it is implied to be the same as the endpoint in 9.1.1, which would be the > same as the SCSI Initiator Port). Since an iSCSI Initiator Portal Group is > the same as a SCSI Initiator Port and since an iSCSI Target Portal Group is > the same as a SCSI Target Port, then each session in answer number 2 would > not have a "different SCSI initiator port"; hence you would have a parallel > nexus. > One thing that is not clear in section 9.1.1 (however, it is loosely > implied) is that the reuse of ISID's applies to a given initiator endpoint > (SCSI Initiator Port or what should be called an iSCSI Initiator Portal > Group)). I think that should be made clear. > What am I missing? Could it be that an iSCSI Initiator Portal Group is not > equivalent to a SCSI Target Port? > > Eddy > > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Saturday, December 29, 2001 6:14 PM > To: Eddy Quicksall > Cc: ips > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > Eddy, > > The SCSI initiator port is modeled as the endpoint of the > iSCSI session; > the SCSI target port is modeled as the iSCSI target portal group. The > reason we did it this way was to allow more than one session > between portal > groups by allowing multi-plexing of sessions with different > ISIDs from the > same iSCSI initiator portal group to the same target portal group. > > So, the answer to your questions are: > 1) no, we're assuming no more than on session *with the same > ISID* to the > same target portal group (that'd be more than one nexus), but > by allowing > different ISIDs we get different SCSI initiator ports. > 2) no, we're allowing more than one session between an iSCSI initiator > portal group and an iSCSI target portal group (each session > has a different > SCSI initiator port (id'ed by its ISID) but the same SCSI target port > (id'ed by its portal group tag). > 3) sort of, the ISID together with the iSCSI Initiator Name fully > identifies the SCSI initiator port (and so defines the SCSI > initiator port > name and the identifier). > > Does that clear this up? > > Jim Hafner > > > "Eddy Quicksall" on 12/28/2001 > 07:19:33 PM > > To: Jim Hafner/Almaden/IBM@IBMUS > cc: "ips@ece. cmu. edu \(E-mail\)" > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > > Due to 2.5.3 (b) "Between a given SCSI initiator port and SCSI target > port, there can be only one I_T nexus (session)", aren't we always > "assuming no more than one session"? > > Or are you talking about more than one session between different SCSI > initiator ports and a single SCSI target port? > > Is the ISID equivalent to SAM-2's Initiator Port Identifier? > > > Eddy > > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Friday, December 28, 2001 12:15 PM > To: John Hufferd; Eddy Quicksall; Mallikarjun C.; Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: FW: iSCSI: "conservative reuse" requirement > > > Folks, > > Sorry for taking so long to jump into this discussion. > > There are a number of issues raised in this thread: > 1) should "conservative reuse" of ISIDs be made a MUST > 2) does "conservative reuse" imply that all hosts look "single SCSI > ported" > > Here's my two cents (using "CR" as a shorthand for "conservative > reuse") > > I don't believe that CR needs to be a MUST. The only time this has > any > real value is in configurations that use SCSI persistent reservations > (and > where new SCSI target reservation features are enabled -- NB. these > features are yet to be approved but are working their way through the > process). I don't think these are going to be (even in the future) the > majority of installations. There are many ways then that CR could be > something that is not generally available in most drivers but is added > by > configuration and perhaps even "value add" (:-{)). > > In short, I don't see a strong case for this to be a MUST. So, to > David > Black, my answer is that having a mechanism to enable this feature or > have > it as a "purchase requirement" is an acceptable mechanism to make sure > the > feature is there when needed, but it is need not be a requirement of > the > protocol. To Mallikarjun, I think I'm agreeing with you that so long > as > there is a mechanism defined, iSCSI has done it's job. > > As for the second issue (raised by Mallikarjun), let's look at the > definition of CR. What is means is that when an iSCSI initiator > (node) > creates ISIDs for use in session identifiers, it attempts to reuse > them > as > much as possible with different SCSI target ports (iSCSI target portal > groups). This is the only way that a SCSI target or LU can see the > same > SCSI initiator port through two or more of its SCSI target ports -- > that > is, that the target can determine multiple paths *from* the same SCSI > initiator port. But, the model for generating ISIDs is not really at > the > node level but at the initiator portal group level. > So, IMO, the conclusion that all hosts must then look "single SCSI > ported" > is too dramatic. As I mentioned, ISIDs are conceptually generated > within > initiator portal groups (that's why we defined the mechanism for > generating > ISIDs). The conclusion I draw is that (assuming no more than one > session > to any given target portal group), an iSCSI initiator implementing CR > will > have as many SCSI initiator ports as iSCSI initiator portal groups > (independent HBAs?). Each initiator portal group would generate one > ISID > (that is different from that generated by/for the other initiator > portal > groups) and use CR for repeatability. [This is consistent with a > model > that mapped SCSI initiator ports to initiator portal groups, which we > had > to abandon because the "assuming no more than one session..." was no > acceptable as a requirement!!!] This independence of ISIDs for each > initiator portal group allows each initiator portal group to open > sessions > with *every* target portal group it knows about without having to > worry > about interfering with other sessions. [This has shades of the > "partitioning" rule for ISIDs that has been discussed ad nauseum!!!] > > (I have a feeling that this note is not well composed -- it is the > holidays, you know). I hope I've addressed everyone's concerns and we > can > lay this one to rest. > > Jim Hafner > > > John Hufferd > 12/25/2001 08:49 AM > > To: "Eddy Quicksall" > cc: Jim Hafner/Almaden/IBM@IBMUS > From: John Hufferd/San Jose/IBM@IBMUS > Subject: Re: FW: iSCSI: "conservative reuse" requirement (Document > link: > Jim Hafner) > > You are correct. The section was created by Jim Hafner, and via this > note > I will ask him if he could answer Mallikarjun Directly since I did not > understand his issue. > > . > . > . > 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" on 12/24/2001 06:06:44 > PM > > To: John Hufferd/San Jose/IBM@IBMUS > cc: > Subject: FW: iSCSI: "conservative reuse" requirement > > > > John, > > Were you the author of "conservative reuse"? I am wondering about some > issues. Maybe you could educate me somewhat ... > > I started this subject in a different thread by saying that it may be > good to make "conservative reuse" a MUST. > > I got one objection from Santosh below. Then David Black picked it up > by basically agreeing with me. Then Mallikarjun objected to that. > > It seems like the objective would be to give targets a way to figure > out that two or more sessions are coming from the same Initiator Port. > That is needed support persistent reservations. > > If an initiator does not use "conservative reuse", I don't think > targets will be able to make that determination. > > Comments? > > Eddy > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Monday, December 24, 2001 12:47 AM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: "conservative reuse" requirement > > > I think this is headed towards "conservative reuse" being a MUST if > > we're serious about support for shared persistent reservations. > > Mandating "conservative reuse" appears to force initiators to always > act > as a single initiator port (wrt one target; assuming only one session > as > an > example) per initiator device - which rules out the case of an > initiator > > intentionally wanting to present a different port to each target > portal > group. > > IMHO, if iSCSI provides an architected mechanism to support shared > persistent reservations ("conservative reuse"), that should be > completely > adequate to meet the expectations to be a legal SCSI protocol. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 > > ----- Original Message ----- > From: > To: > Cc: > Sent: Friday, December 21, 2001 4:50 PM > Subject: iSCSI: "conservative reuse" requirement > > > > Santosh Rao writes: > > > > > I am opposed to the suggestion that "conservative re-use" of ISIDs > be > > > made a MUST. This is really only required when initiators need to > be > > > using the new T10 Reservation scheme that can be shared > > > across initiator ports. > > > > Those reservations are a Target feature. With this approach, the > ability > > to use the target feature depends on details of the initiator > > implementation. > > More below ... > > > > > For those initiators that don't care about this type of > reservation, > > > conservative re-use is of no use and initiators may like to assign > > > ISID's in a per-initiator node fashion, thereby, being able to use > these > > > ISIDs as a lookup index for the sessions on that initiator node. > > > > > > Hence, I suggest that "conservative re-use" be worded as > > > "encouraged to use" or something to that effect, but not MUST USE. > > > > > > Comments ? > > > > The "initiator" is more than one entity. The iSCSI HBA/NIC and > driver > > doesn't know whether shared persistent reservations are being used > and > > shouldn't have to care - they're just more SCSI commands to > transport. > > Some other entity (e.g., clustering software) will be generating the > > shared persistent reservations. This raise the possible scenario > > involving a target that supports the new shared persistent > reservations > > and an entity that wants to use them. The entity detects (via SCSI > means, > > e.g., something in a mode page) that the Target supports shared > persistent > > reservations, tries to use them, only to discover that they don't > work > > because the iSCSI HBA/NIC doesn't implement "conservative reuse". > > > > I'm worried about this causing both interoperability issues and > possible > > T10 issues -- from a T10 viewpoint, if shared persistent > reservations > > don't work, the initiating entity should have some SCSI-level means > > of determining this ... if that means exists only on the Target, the > > above scenario is iSCSI's problem (Target can't query Initiator to > > determine whether it does "conservative reuse"), and having a > separate > > initiator side means that the entity has to check only for iSCSI > (and > > not for any other SCSI transport) does not seem like the right > > approach. > > > > I think this is headed towards "conservative reuse" being a MUST if > > we're serious about support for shared persistent reservations. > > > > Comments? > > --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 > > --------------------------------------------------- > > > > > > > ------_=_NextPart_001_01C193B8.1B7284C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Did you read Jim's response carefully?  = You repeat=20 the statement "It (initiator portal = group" is an=20 important item to define (as mapping to the SCSI Initiator Port). It is = what is=20 needed for persistent reservations. Defining it properly will eliminate = the need=20 for the "conservative reuse" clause." and=20 Jim has explained to you that this statement is incorrect.  = Several of us=20 have given you the definition of initiator portal group and you still = have this=20 misconception.  I don't know how putting the definition in the = draft would=20 clear up your misunderstanding?
 
If "initiator portal group" is not = explicitly defined=20 in the draft, it is in part because that concept plays no part in the = iSCSI=20 protocol - it's very important that you understand that.  In order = for an=20 initiator to connect to a target, the initiator must know the target's = portal=20 groups.  The converse is NOT true - nothing external to the target = that=20 participates in the iSCSI protocol needs to know the initiator's = address=20 information.  Perhaps if you let go of the idea that the initiator = portal=20 group is an important thing in the iSCSI protocol, you'll understand = what has=20 been explained?

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

-----Original Message-----
From: Eddy Quicksall=20 [mailto:Eddy_Quicksall@ivivity.com]
Sent: Wednesday, = January 02,=20 2002 5:12 AM
To: Jim Hafner
Cc:=20 ips@ece.cmu.edu
Subject: RE: FW: iSCSI: "conservative = reuse"=20 requirement

I see=20 I must have offended you. I didn't mean to do that ...=20

 

=

I was=20 referring to the definition of iSCSI Initiator Portal Group and that = it has=20 been left out. It is an important item to define (as mapping to the = SCSI=20 Initiator Port). It is what is needed for persistent reservations. = Defining it=20 properly will eliminate the need for the "conservative reuse"=20 clause.

 

=

The=20 problem I saw was that many people have misunderstood the ISID and = how it=20 should be used to be compliant with = SAM-2.

 

=

I said=20 much earlier that the definition of iSCSI Initiator Portal Group was = implied=20 and that is exactly what you have pointed out=20 below.

 

=

It=20 seems so silly not to define it. Can you give me a reason why it = should not be=20 defined?

 

=

Eddy

 

=

-----Original=20 Message-----
From: = Jim Hafner=20 [mailto:hafner@almaden.ibm.com]
Sent: Tuesday, January 01, = 2002 4:16=20 PM
To: Eddy=20 Quicksall
Cc:=20 ips@ece.cmu.edu
Subject: RE:=20 FW: iSCSI: "conservative reuse" requirement

 



Eddy,

I don't = know why=20 you think we've done a bad job of defining these terms. I don't have = a copy of=20 the draft around at the moment but this is my = recollection:

These are=20 the iSCSI architectural level components:
There is a definition = of an=20 iSCSI node (that has a WWU name).

There is a definition of = Portal=20 Group (which does NOT apply only to targets but is applicable to both = targets=20 and initiators). (I even thought there was text that said that this = definition=20 applied to both initiator and target, but I could be wrong about=20 this.)

There is a definition of sessions and the specification = of how=20 SSIDs are generated from the ISID component and the TSID component.=20


There is the (required by any SCSI protocol) a mapping of = the SCSI=20 constructs to iSCSI constructs. The SCSI constructs of concern here = are (a)=20 device -- both initiator and target (b) port -- initiator, target and = initiator/target and (c) nexus:

There is explicit language = that=20 defines the SCSI device as a component of an iSCSI node (and that = there is=20 only one such SCSI device construct within an iSCSI node -- and this = allows us=20 to define the SCSI device name as equal to the iSCSI node = name).

There=20 is explicit language that maps the SCSI initiator port to an iSCSI = construct=20 and *different* language that maps the SCSI target port to an iSCSI = construct.=20 For the SCSI initiator port, the mapping is to the initiator end of a = session.=20 For the SCSI target port, the mapping is to the iSCSI target portal = group. It=20 is NOT symmetric and is stated so explicitly.

There is = explicit=20 language the maps the SCSI nexus to the session. Note that a nexus is = a=20 relationship between a SCSI initiator port and a SCSI target port = (that's the=20 SAM definition!). What iSCSI does is map this relationship from the = iSCSI=20 initiator end of a session (SCSI initiator port) to the iSCSI target = portal=20 group (SCSI target port).

Does the text not say = this?

Note that=20 the approach we've taken here is to define the iSCSI architecture and = then MAP=20 the iSCSI constructs to SAM-defined SCSI constructs.

And, an = attempt=20 to map SCSI initiator port to the iSCSI initiator portal group (as = you=20 suggest) will force a requirement that there can be only one session = between=20 an iSCSI initiator portal group and an iSCSI target portal group! If = one=20 thinks that most "portal groups" will be instantiated by an iSCSI = HBA, then=20 this requirement is unacceptable.


Jim = Hafner

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

To: John = Hufferd/San=20 Jose/IBM@IBMUS
cc: ips@ece.cmu.edu=20
Subject: RE: FW: iSCSI:=20 "conservative reuse" requirement



My problem=20 is that we have not done a good job of defining the=20 iSCSI
Initiator=20 Portal Group in the spec. If defined correctly, there should be=20 no
need for the "conservative reuse"=20 clause.

Here is how=20 I think it should be defined ... SCSI Initiator Port: this=20 maps
to=20 an iSCSI Initiator Portal Group.

You could go=20 on to say something like Marjorie said below ... that it is=20 a
collection=20 of IP addresses that can be used to support one or more=20 iSCSI
sessions.

Given that=20 it is equivalent to a SCSI Initiator Port and that it=20 is
identified=20 by the InitiatorName+ISID, it follows that every session = from
that=20 "port" would have to use the same ISID; and that is what will=20 make
persistent reservations = work.

It is not=20 that "conservative reuse" won't work ... it is more that it=20 is
hard=20 to explain because we don't have a clear definition of a SCSI=20 Initiator
Port and Initiator Port=20 Identifier.

Eddy

-----Original=20 Message-----
From:=20 John Hufferd [mailto:hufferd@us.ibm.com]
Sent: Monday, = December=20 31, 2001 8:01 PM
To: Amir Shalit
Cc:=20 ips@ece.cmu.edu
Subject: RE: FW: iSCSI: "conservative = reuse"=20 requirement


We overtly=20 chose NOT to identify an ISID with a TCP/IP address, since=20 the
ISID=20 may span several HBAs and/or TCP/IP addresses.  It was more=20 general
and consistent NOT to be tied to a  TCP/IP=20 address.

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


"Amir=20 Shalit" <amir@astutenetworks.com>@ece.cmu.edu on 12/31/2001=20 03:35:56
PM

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


To:  =20  "Eddy Quicksall" <Eddy_Quicksall@ivivity.com>,=20 "KRUEGER,MARJORIE
 =20     \(HP-Roseville,ex1\)" <marjorie_krueger@hp.com>,=20 Jim
      = Hafner/Almaden/IBM@IBMUS
cc:=20    "ips@ece. cmu. edu \(E-mail\)"=20 <ips@ece.cmu.edu>
Subject:    RE: FW: = iSCSI:=20 "conservative reuse" requirement



Marjorie,

If an=20 "initiator/target portal group" concept is
"the=20 collection of IP addresses which can be combined to create a=20 single
iSCSI session."
why isn't it defined = as such in=20 the draft?

IMO, it=20 would have been better to define ISID/TSID in simple=20 networking
terms
like=20 {TCP/IP address + Name} instead of coming up with network=20 entity,
network portal
and portal group=20 terminology.

Amir


-----Original=20 Message-----
From:=20 owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf=20 Of
Eddy Quicksall
Sent: Monday, December 31, = 2001 2:15=20 PM
To: KRUEGER,MARJORIE (HP-Roseville,ex1); Jim=20 Hafner
Cc: ips@ece. cmu. edu = (E-mail)
Subject: RE: FW:=20 iSCSI: "conservative reuse" requirement


Marjorie,

If "an=20 initiator portal group is the same concept as the target=20 portal
group",=20 then it must be equivalent to the SCSI Initiator Port (because=20 we
have said that the SCSI Target Port maps to an iSCSI = Target=20 Portal Group).

Comments?

Eddy

-----Original=20 Message-----
From:=20 KRUEGER,MARJORIE (HP-Roseville,ex1)=20 [mailto:marjorie_krueger@hp.com]
Sent: Monday, December = 31, 2001=20 4:48 PM
To: 'Eddy Quicksall'; Jim Hafner
Cc: = ips@ece.=20 cmu. edu (E-mail)
Subject: RE: FW: iSCSI: "conservative = reuse"=20 requirement

Your=20 assumption of what is meant by an initiator portal group is=20 incorrect
(I=20 don't think it's implied that IPG =3D IP???)  An initiator = portal group=20 is
the same concept as a target portal group - it's the = collection=20 of IP
addresses which can be combined to create a single = iSCSI=20 session.
Frequently this is thought of as an iSCSI HBA, = but that=20 is not necessarily
so, it could be a number of iSCSI = HBAs,=20 etc.

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

>=20 -----Original Message-----
>=20 From: Eddy Quicksall = [mailto:Eddy_Quicksall@ivivity.com]
>=20 Sent: Monday, December 31, 2001 10:39 AM
> To: Jim=20 Hafner
> Cc: ips@ece. cmu. edu = (E-mail)
>=20 Subject: RE: FW: iSCSI: "conservative reuse"=20 requirement
>
>
> = Regarding=20 answer 2 below:
> There is no given definition for an = iSCSI=20 Initiator Portal Group
(however,
> it is = implied to=20 be the same as the endpoint in 9.1.1, which would be = the
> same=20 as the SCSI Initiator Port). Since an iSCSI Initiator Portal=20 Group
is
> the same as a SCSI Initiator = Port and=20 since an iSCSI Target Portal Group
is
> = the same as=20 a SCSI Target Port, then each session in answer number=20 2
would
> not have a "different SCSI = initiator=20 port"; hence you would have a
parallel
>=20 nexus.
> One thing that is not clear in section 9.1.1 = (however,=20 it is loosely
> implied) is that the reuse of ISID's = applies to=20 a given initiator
endpoint
> (SCSI = Initiator Port=20 or what should be called an iSCSI Initiator Portal
> = Group)). I=20 think that should be made clear.
> What am I missing? = Could it=20 be that an iSCSI Initiator Portal Group = is
not
>=20 equivalent to a SCSI Target Port?
>
>=20 Eddy
>
> -----Original=20 Message-----
> From: Jim Hafner=20 [mailto:hafner@almaden.ibm.com]
> Sent: Saturday, = December 29,=20 2001 6:14 PM
> To: Eddy Quicksall
> Cc: = ips
> Subject: RE: FW: iSCSI: "conservative reuse"=20 requirement
>
>
>=20 Eddy,
>
> The SCSI initiator port is = modeled as=20 the endpoint of the
> iSCSI session;
> = the SCSI=20 target port is modeled as the iSCSI target portal group.=20  The
> reason we did it this way was to allow = more than=20 one session
> between portal
> groups = by=20 allowing multi-plexing of sessions with different
> = ISIDs from=20 the
> same iSCSI initiator portal group to the same = target=20 portal group.
>
> So, the answer to = your=20 questions are:
> 1) no, we're assuming no more than on = session=20 *with the same
> ISID* to the
> same = target=20 portal group (that'd be more than one nexus), but
> by = allowing
> different ISIDs we get different SCSI = initiator=20 ports.
> 2) no, we're allowing more than one session = between an=20 iSCSI initiator
> portal group and an iSCSI target = portal group=20 (each session
> has a different
> SCSI = initiator=20 port (id'ed by its ISID) but the same SCSI target = port
> (id'ed=20 by its portal group tag).
> 3) sort of, the ISID = together with=20 the iSCSI Initiator Name fully
> identifies the SCSI = initiator=20 port (and so defines the SCSI
> initiator = port
>=20 name and the identifier).
>
> Does that = clear=20 this up?
>
> Jim=20 Hafner
>
>
> "Eddy = Quicksall"=20 <Eddy_Quicksall@iVivity.com> on 12/28/2001
> = 07:19:33=20 PM
>
> To:   Jim=20 Hafner/Almaden/IBM@IBMUS
> cc:   "ips@ece. cmu. = edu=20 \(E-mail\)" <ips@ece.cmu.edu>
> Subject: =  RE: FW:=20 iSCSI: "conservative reuse"=20 = requirement
>
>
>
<= TT>>=20 Due to 2.5.3 (b) "Between a given SCSI initiator port and SCSI=20 target
> port, there can be only one I_T nexus = (session)",=20 aren't we always
> "assuming no more than one=20 session"?
>
> Or are you talking about = more than=20 one session between different SCSI
> initiator ports = and a=20 single SCSI target port?
>
> Is the = ISID=20 equivalent to SAM-2's Initiator Port=20 Identifier?
>
>
>=20 Eddy
>
> -----Original=20 Message-----
> From: Jim Hafner=20 [mailto:hafner@almaden.ibm.com]
> Sent: Friday, = December 28,=20 2001 12:15 PM
> To: John Hufferd; Eddy Quicksall; = Mallikarjun=20 C.; Black_David@emc.com
> Cc: = ips@ece.cmu.edu
>=20 Subject: Re: FW: iSCSI: "conservative reuse"=20 requirement
>
>
>=20 Folks,
>
> Sorry for taking so long to = jump into=20 this discussion.
>
> There are a number = of=20 issues raised in this thread:
> 1) should = "conservative reuse"=20 of ISIDs be made a MUST
> 2) does "conservative reuse" = imply=20 that all hosts look "single SCSI
>=20 ported"
>
> Here's my two cents (using = "CR" as a=20 shorthand for "conservative
>=20 reuse")
>
> I don't believe that CR = needs to be=20 a MUST.  The only time this has
> = any
>=20 real value is in configurations that use SCSI persistent=20 reservations
> (and
> where new SCSI = target=20 reservation features are enabled -- NB.  these
> = features=20 are yet to be approved but are working their way through = the
>=20 process). I don't think these are going to be (even in the future)=20 the
> majority of installations.  There are many = ways then=20 that CR could be
> something that is not generally = available in=20 most drivers but is added
> by
> = configuration=20 and perhaps even "value add" = (:-{)).
>
> In=20 short, I don't see a strong case for this to be a MUST.  So,=20 to
> David
> Black, my answer is that = having a=20 mechanism to enable this feature or
> = have
> it=20 as a "purchase requirement" is an acceptable mechanism to make=20 sure
> the
> feature is there when = needed, but=20 it is need not be a requirement of
> = the
>=20 protocol.  To Mallikarjun, I think I'm agreeing with you that so = long
> as
> there is a mechanism = defined, iSCSI=20 has done it's job.
>
> As for the = second issue=20 (raised by Mallikarjun), let's look at the
> = definition of CR.=20  What is means is that when an iSCSI initiator
>=20 (node)
> creates ISIDs for use in session identifiers, = it=20 attempts to reuse
> them
> = as
>=20 much as possible with different SCSI target ports (iSCSI target=20 portal
> groups).  This is the only way that a = SCSI target=20 or LU can see the
> same
> SCSI = initiator port=20 through two or more of its SCSI target ports --
>=20 that
> is, that the target can determine multiple = paths *from*=20 the same SCSI
> initiator port.   But, the model = for=20 generating ISIDs is not really at
> = the
> node=20 level but at the initiator portal group level.
> So, = IMO, the=20 conclusion that all hosts must then look "single = SCSI
>=20 ported"
> is too dramatic.  As I mentioned, =  ISIDs=20 are conceptually generated
> within
> = initiator=20 portal groups (that's why we defined the mechanism = for
>=20 generating
> ISIDs).  The conclusion I draw is = that=20 (assuming no more than one
> session
> = to any=20 given target portal group), an iSCSI initiator implementing=20 CR
> will
> have as many SCSI initiator = ports as=20 iSCSI initiator portal groups
> (independent HBAs?). =  Each=20 initiator portal group would generate one
>=20 ISID
> (that is different from that generated by/for = the other=20 initiator
> portal
> groups) and use CR = for=20 repeatability.  [This is consistent with a
>=20 model
> that mapped SCSI initiator ports to initiator = portal=20 groups, which we
> had
> to abandon = because the=20 "assuming no more than one session..." was no
> = acceptable as a=20 requirement!!!]  This independence of ISIDs for = each
>=20 initiator portal group allows each initiator portal group to=20 open
> sessions
> with *every* target = portal=20 group it knows about without having to
> = worry
>=20 about interfering with other sessions. [This has shades of=20 the
> "partitioning" rule for ISIDs that has been = discussed ad=20 nauseum!!!]
>
> (I have a feeling that = this note=20 is not well composed -- it is the
> holidays, you = know).=20  I hope I've addressed everyone's concerns and = we
>=20 can
> lay this one to = rest.
>
>=20 Jim Hafner
>
>
> John=20 Hufferd
> 12/25/2001 08:49 = AM
>
>=20 To:   "Eddy Quicksall"=20 <Eddy_Quicksall@iVivity.com>
> cc:   Jim=20 Hafner/Almaden/IBM@IBMUS
> From: John Hufferd/San=20 Jose/IBM@IBMUS
> Subject:  Re: FW: iSCSI: = "conservative=20 reuse" requirement  (Document
> = link:
>=20       Jim Hafner)
>
> = You are=20 correct.  The section was created by Jim Hafner, and via=20 this
> note
> I will ask him if he = could answer=20 Mallikarjun Directly since I did not
> understand his=20 issue.
>
> .
> = .
>=20 .
> John L. Hufferd
> Senior Technical = Staff=20 Member (STSM)
> IBM/SSG San Jose Ca
> = Main=20 Office (408) 256-0403, Tie: 276-0403,  eFax: (408)=20 904-4688
> Home Office (408) 997-6136, Cell: (408)=20 499-9702
> Internet address:=20 hufferd@us.ibm.com
>
>
> = "Eddy=20 Quicksall" <Eddy_Quicksall@iVivity.com> on 12/24/2001=20 06:06:44
> PM
>
> To: =   John=20 Hufferd/San Jose/IBM@IBMUS
> cc:
> = Subject:=20  FW: iSCSI: "conservative reuse"=20 = requirement
>
>
>
<= TT>>=20 John,
>
> Were you the author of = "conservative=20 reuse"? I am wondering about some
> issues. Maybe you = could=20 educate me somewhat ...
>
> I started = this=20 subject in a different thread by saying that it may = be
> good=20 to make "conservative reuse" a = MUST.
>
> I got=20 one objection from Santosh below. Then David Black picked it=20 up
> by basically agreeing with me. Then Mallikarjun = objected=20 to that.
>
> It seems like the = objective would=20 be to give targets a way to figure
> out that two or = more=20 sessions are coming from the same Initiator Port.
> = That is=20 needed support persistent = reservations.
>
> If=20 an initiator does not use "conservative reuse", I don't = think
>=20 targets will be able to make that=20 determination.
>
>=20 Comments?
>
>=20 Eddy
>
> -----Original=20 Message-----
> From: Mallikarjun C.=20 [mailto:cbm@rose.hp.com]
> Sent: Monday, December 24, = 2001=20 12:47 AM
> To: Black_David@emc.com
> = Cc:=20 ips@ece.cmu.edu
> Subject: Re: iSCSI: "conservative = reuse"=20 requirement
>
> > I think this is = headed=20 towards "conservative reuse" being a MUST if
> > = we're=20 serious about support for shared persistent=20 reservations.
>
> Mandating = "conservative reuse"=20 appears to force initiators to always
> = act
> as=20 a single initiator port (wrt one target; assuming only one=20 session
> as
> an
> = example) per=20 initiator device - which rules out the case of an
>=20 initiator
>
> intentionally wanting to = present a=20 different port to each target
> = portal
>=20 group.
>
> IMHO, if iSCSI provides an=20 architected mechanism to support shared
> persistent=20 reservations ("conservative reuse"),  that should = be
>=20 completely
> adequate to meet the expectations to be a = legal=20 SCSI protocol.
> --
>=20 Mallikarjun
>
> Mallikarjun=20 Chadalapaka
> Networked Storage = Architecture
>=20 Network Storage Solutions Organization
> = Hewlett-Packard MS=20 5668
> Roseville CA = 95747
>
>=20 ----- Original Message -----
> From:=20 <Black_David@emc.com>
> To:=20 <santoshr@cup.hp.com>
> Cc:=20 <ips@ece.cmu.edu>
> Sent: Friday, December 21, = 2001 4:50=20 PM
> Subject: iSCSI: "conservative reuse"=20 requirement
>
>
> > = Santosh=20 Rao writes:
> >
> > > I am = opposed to=20 the suggestion that "conservative re-use" of ISIDs
>=20 be
> > > made a MUST. This is really only = required when=20 initiators need to
> be
> > > = using the=20 new T10 Reservation scheme that can be shared
> > = >=20 across initiator ports.
> >
> > = Those=20 reservations are a Target feature.  With this approach,=20 the
> ability
> > to use the target = feature=20 depends on details of the initiator
> >=20 implementation.
> > More below ...
> = >
> > > For those initiators that don't care = about=20 this type of
> reservation,
> > > = conservative re-use is of no use and initiators may like to=20 assign
> > > ISID's in a per-initiator node = fashion,=20 thereby, being able to use
> these
> = > >=20 ISIDs as a lookup index for the sessions on that initiator=20 node.
> > >
> > > Hence, I = suggest=20 that "conservative re-use" be worded as
> > > = "encouraged=20 to use" or something to that effect, but not MUST = USE.
> >=20 >
> > > Comments ?
>=20 >
> > The "initiator" is more than one entity. =  The=20 iSCSI HBA/NIC and
> driver
> > = doesn't know=20 whether shared persistent reservations are being = used
>=20 and
> > shouldn't have to care - they're just more = SCSI=20 commands to
> transport.
> > Some = other=20 entity (e.g., clustering software) will be generating = the
>=20 > shared persistent reservations.  This raise the possible=20 scenario
> > involving a target that supports the = new shared=20 persistent
> reservations
> > and an = entity=20 that wants to use them.  The entity detects (via = SCSI
>=20 means,
> >=20 e.g., something in a mode page) that the Target supports=20 shared
>=20 persistent
> > reservations, tries to use them, = only to=20 discover that they don't
> work
> > = because=20 the iSCSI HBA/NIC doesn't implement "conservative = reuse".
>=20 >
> > I'm worried about this causing both=20 interoperability issues and
> = possible
> >=20 T10 issues -- from a T10 viewpoint, if shared = persistent
>=20 reservations
> > don't work, the initiating entity = should=20 have some SCSI-level means
> > of determining this = ... if=20 that means exists only on the Target, the
> > above = scenario=20 is iSCSI's problem (Target can't query Initiator to
> = >=20 determine whether it does "conservative reuse"), and having = a
>=20 separate
> > initiator side means that the entity = has to=20 check only for iSCSI
> (and
> > not = for any=20 other SCSI transport) does not seem like the right
> = >=20 approach.
> >
> > I think this is = headed=20 towards "conservative reuse" being a MUST if
> > = we're=20 serious about support for shared persistent = reservations.
>=20 >
> > Comments?
> >=20 --David
> >=20 ---------------------------------------------------
> = >=20 David L. Black, Senior Technologist
> > EMC = Corporation, 42=20 South St., Hopkinton, MA  01748
> > +1 (508) = 249-6449=20 *NEW*      FAX: +1 (508) 497-8500
> = >=20 black_david@emc.com         Cell: +1 (978)=20 394-7754
> >=20 ---------------------------------------------------
>=20 >
>=20 = >
>
>
>
<= /FONT>


------_=_NextPart_001_01C193B8.1B7284C0-- From owner-ips@ece.cmu.edu Wed Jan 2 14:46: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 OAA09521 for ; Wed, 2 Jan 2002 14:46:59 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g02Itm724322 for ips-outgoing; Wed, 2 Jan 2002 13:55: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 (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g02Itfg24308 for ; Wed, 2 Jan 2002 13:55:41 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Jan 2002 13:55:34 -0500 Message-ID: <25369470B6F0D41194820002B328BDD22022A6@ATLOPS> From: Eddy Quicksall To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" , Jim Hafner Cc: ips@ece.cmu.edu Subject: RE: FW: iSCSI: "conservative reuse" requirement Date: Wed, 2 Jan 2002 13:55:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C193BF.0E73EF00" 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_01C193BF.0E73EF00 Content-Type: text/plain; charset="iso-8859-1" If you don't want to define it, then you should not use it. There is an "endpoint" that represents the SCSI Initiator Port. If that "endpoint" can you just give that "endpoint" a term? Eddy -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie_krueger@hp.com] Sent: Wednesday, January 02, 2002 1:06 PM To: 'Eddy Quicksall'; Jim Hafner Cc: ips@ece.cmu.edu Subject: RE: FW: iSCSI: "conservative reuse" requirement Did you read Jim's response carefully? You repeat the statement "It (initiator portal group" is an important item to define (as mapping to the SCSI Initiator Port). It is what is needed for persistent reservations. Defining it properly will eliminate the need for the "conservative reuse" clause." and Jim has explained to you that this statement is incorrect. Several of us have given you the definition of initiator portal group and you still have this misconception. I don't know how putting the definition in the draft would clear up your misunderstanding? If "initiator portal group" is not explicitly defined in the draft, it is in part because that concept plays no part in the iSCSI protocol - it's very important that you understand that. In order for an initiator to connect to a target, the initiator must know the target's portal groups. The converse is NOT true - nothing external to the target that participates in the iSCSI protocol needs to know the initiator's address information. Perhaps if you let go of the idea that the initiator portal group is an important thing in the iSCSI protocol, you'll understand what has been explained? 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: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] Sent: Wednesday, January 02, 2002 5:12 AM To: Jim Hafner Cc: ips@ece.cmu.edu Subject: RE: FW: iSCSI: "conservative reuse" requirement I see I must have offended you. I didn't mean to do that ... I was referring to the definition of iSCSI Initiator Portal Group and that it has been left out. It is an important item to define (as mapping to the SCSI Initiator Port). It is what is needed for persistent reservations. Defining it properly will eliminate the need for the "conservative reuse" clause. The problem I saw was that many people have misunderstood the ISID and how it should be used to be compliant with SAM-2. I said much earlier that the definition of iSCSI Initiator Portal Group was implied and that is exactly what you have pointed out below. It seems so silly not to define it. Can you give me a reason why it should not be defined? Eddy -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Tuesday, January 01, 2002 4:16 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu Subject: RE: FW: iSCSI: "conservative reuse" requirement Eddy, I don't know why you think we've done a bad job of defining these terms. I don't have a copy of the draft around at the moment but this is my recollection: These are the iSCSI architectural level components: There is a definition of an iSCSI node (that has a WWU name). There is a definition of Portal Group (which does NOT apply only to targets but is applicable to both targets and initiators). (I even thought there was text that said that this definition applied to both initiator and target, but I could be wrong about this.) There is a definition of sessions and the specification of how SSIDs are generated from the ISID component and the TSID component. There is the (required by any SCSI protocol) a mapping of the SCSI constructs to iSCSI constructs. The SCSI constructs of concern here are (a) device -- both initiator and target (b) port -- initiator, target and initiator/target and (c) nexus: There is explicit language that defines the SCSI device as a component of an iSCSI node (and that there is only one such SCSI device construct within an iSCSI node -- and this allows us to define the SCSI device name as equal to the iSCSI node name). There is explicit language that maps the SCSI initiator port to an iSCSI construct and *different* language that maps the SCSI target port to an iSCSI construct. For the SCSI initiator port, the mapping is to the initiator end of a session. For the SCSI target port, the mapping is to the iSCSI target portal group. It is NOT symmetric and is stated so explicitly. There is explicit language the maps the SCSI nexus to the session. Note that a nexus is a relationship between a SCSI initiator port and a SCSI target port (that's the SAM definition!). What iSCSI does is map this relationship from the iSCSI initiator end of a session (SCSI initiator port) to the iSCSI target portal group (SCSI target port). Does the text not say this? Note that the approach we've taken here is to define the iSCSI architecture and then MAP the iSCSI constructs to SAM-defined SCSI constructs. And, an attempt to map SCSI initiator port to the iSCSI initiator portal group (as you suggest) will force a requirement that there can be only one session between an iSCSI initiator portal group and an iSCSI target portal group! If one thinks that most "portal groups" will be instantiated by an iSCSI HBA, then this requirement is unacceptable. Jim Hafner Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS cc: ips@ece.cmu.edu Subject: RE: FW: iSCSI: "conservative reuse" requirement My problem is that we have not done a good job of defining the iSCSI Initiator Portal Group in the spec. If defined correctly, there should be no need for the "conservative reuse" clause. Here is how I think it should be defined ... SCSI Initiator Port: this maps to an iSCSI Initiator Portal Group. You could go on to say something like Marjorie said below ... that it is a collection of IP addresses that can be used to support one or more iSCSI sessions. Given that it is equivalent to a SCSI Initiator Port and that it is identified by the InitiatorName+ISID, it follows that every session from that "port" would have to use the same ISID; and that is what will make persistent reservations work. It is not that "conservative reuse" won't work ... it is more that it is hard to explain because we don't have a clear definition of a SCSI Initiator Port and Initiator Port Identifier. Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Monday, December 31, 2001 8:01 PM To: Amir Shalit Cc: ips@ece.cmu.edu Subject: RE: FW: iSCSI: "conservative reuse" requirement We overtly chose NOT to identify an ISID with a TCP/IP address, since the ISID may span several HBAs and/or TCP/IP addresses. It was more general and consistent NOT to be tied to a TCP/IP address. . . . 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 "Amir Shalit" @ece.cmu.edu on 12/31/2001 03:35:56 PM Sent by: owner-ips@ece.cmu.edu To: "Eddy Quicksall" , "KRUEGER,MARJORIE \(HP-Roseville,ex1\)" , Jim Hafner/Almaden/IBM@IBMUS cc: "ips@ece. cmu. edu \(E-mail\)" Subject: RE: FW: iSCSI: "conservative reuse" requirement Marjorie, If an "initiator/target portal group" concept is "the collection of IP addresses which can be combined to create a single iSCSI session." why isn't it defined as such in the draft? IMO, it would have been better to define ISID/TSID in simple networking terms like {TCP/IP address + Name} instead of coming up with network entity, network portal and portal group terminology. Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Eddy Quicksall Sent: Monday, December 31, 2001 2:15 PM To: KRUEGER,MARJORIE (HP-Roseville,ex1); Jim Hafner Cc: ips@ece. cmu. edu (E-mail) Subject: RE: FW: iSCSI: "conservative reuse" requirement Marjorie, If "an initiator portal group is the same concept as the target portal group", then it must be equivalent to the SCSI Initiator Port (because we have said that the SCSI Target Port maps to an iSCSI Target Portal Group). Comments? Eddy -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie_krueger@hp.com] Sent: Monday, December 31, 2001 4:48 PM To: 'Eddy Quicksall'; Jim Hafner Cc: ips@ece. cmu. edu (E-mail) Subject: RE: FW: iSCSI: "conservative reuse" requirement Your assumption of what is meant by an initiator portal group is incorrect (I don't think it's implied that IPG = IP???) An initiator portal group is the same concept as a target portal group - it's the collection of IP addresses which can be combined to create a single iSCSI session. Frequently this is thought of as an iSCSI HBA, but that is not necessarily so, it could be a number of iSCSI HBAs, etc. 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: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] > Sent: Monday, December 31, 2001 10:39 AM > To: Jim Hafner > Cc: ips@ece. cmu. edu (E-mail) > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > Regarding answer 2 below: > There is no given definition for an iSCSI Initiator Portal Group (however, > it is implied to be the same as the endpoint in 9.1.1, which would be the > same as the SCSI Initiator Port). Since an iSCSI Initiator Portal Group is > the same as a SCSI Initiator Port and since an iSCSI Target Portal Group is > the same as a SCSI Target Port, then each session in answer number 2 would > not have a "different SCSI initiator port"; hence you would have a parallel > nexus. > One thing that is not clear in section 9.1.1 (however, it is loosely > implied) is that the reuse of ISID's applies to a given initiator endpoint > (SCSI Initiator Port or what should be called an iSCSI Initiator Portal > Group)). I think that should be made clear. > What am I missing? Could it be that an iSCSI Initiator Portal Group is not > equivalent to a SCSI Target Port? > > Eddy > > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Saturday, December 29, 2001 6:14 PM > To: Eddy Quicksall > Cc: ips > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > Eddy, > > The SCSI initiator port is modeled as the endpoint of the > iSCSI session; > the SCSI target port is modeled as the iSCSI target portal group. The > reason we did it this way was to allow more than one session > between portal > groups by allowing multi-plexing of sessions with different > ISIDs from the > same iSCSI initiator portal group to the same target portal group. > > So, the answer to your questions are: > 1) no, we're assuming no more than on session *with the same > ISID* to the > same target portal group (that'd be more than one nexus), but > by allowing > different ISIDs we get different SCSI initiator ports. > 2) no, we're allowing more than one session between an iSCSI initiator > portal group and an iSCSI target portal group (each session > has a different > SCSI initiator port (id'ed by its ISID) but the same SCSI target port > (id'ed by its portal group tag). > 3) sort of, the ISID together with the iSCSI Initiator Name fully > identifies the SCSI initiator port (and so defines the SCSI > initiator port > name and the identifier). > > Does that clear this up? > > Jim Hafner > > > "Eddy Quicksall" on 12/28/2001 > 07:19:33 PM > > To: Jim Hafner/Almaden/IBM@IBMUS > cc: "ips@ece. cmu. edu \(E-mail\)" > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > > Due to 2.5.3 (b) "Between a given SCSI initiator port and SCSI target > port, there can be only one I_T nexus (session)", aren't we always > "assuming no more than one session"? > > Or are you talking about more than one session between different SCSI > initiator ports and a single SCSI target port? > > Is the ISID equivalent to SAM-2's Initiator Port Identifier? > > > Eddy > > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Friday, December 28, 2001 12:15 PM > To: John Hufferd; Eddy Quicksall; Mallikarjun C.; Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: FW: iSCSI: "conservative reuse" requirement > > > Folks, > > Sorry for taking so long to jump into this discussion. > > There are a number of issues raised in this thread: > 1) should "conservative reuse" of ISIDs be made a MUST > 2) does "conservative reuse" imply that all hosts look "single SCSI > ported" > > Here's my two cents (using "CR" as a shorthand for "conservative > reuse") > > I don't believe that CR needs to be a MUST. The only time this has > any > real value is in configurations that use SCSI persistent reservations > (and > where new SCSI target reservation features are enabled -- NB. these > features are yet to be approved but are working their way through the > process). I don't think these are going to be (even in the future) the > majority of installations. There are many ways then that CR could be > something that is not generally available in most drivers but is added > by > configuration and perhaps even "value add" (:-{)). > > In short, I don't see a strong case for this to be a MUST. So, to > David > Black, my answer is that having a mechanism to enable this feature or > have > it as a "purchase requirement" is an acceptable mechanism to make sure > the > feature is there when needed, but it is need not be a requirement of > the > protocol. To Mallikarjun, I think I'm agreeing with you that so long > as > there is a mechanism defined, iSCSI has done it's job. > > As for the second issue (raised by Mallikarjun), let's look at the > definition of CR. What is means is that when an iSCSI initiator > (node) > creates ISIDs for use in session identifiers, it attempts to reuse > them > as > much as possible with different SCSI target ports (iSCSI target portal > groups). This is the only way that a SCSI target or LU can see the > same > SCSI initiator port through two or more of its SCSI target ports -- > that > is, that the target can determine multiple paths *from* the same SCSI > initiator port. But, the model for generating ISIDs is not really at > the > node level but at the initiator portal group level. > So, IMO, the conclusion that all hosts must then look "single SCSI > ported" > is too dramatic. As I mentioned, ISIDs are conceptually generated > within > initiator portal groups (that's why we defined the mechanism for > generating > ISIDs). The conclusion I draw is that (assuming no more than one > session > to any given target portal group), an iSCSI initiator implementing CR > will > have as many SCSI initiator ports as iSCSI initiator portal groups > (independent HBAs?). Each initiator portal group would generate one > ISID > (that is different from that generated by/for the other initiator > portal > groups) and use CR for repeatability. [This is consistent with a > model > that mapped SCSI initiator ports to initiator portal groups, which we > had > to abandon because the "assuming no more than one session..." was no > acceptable as a requirement!!!] This independence of ISIDs for each > initiator portal group allows each initiator portal group to open > sessions > with *every* target portal group it knows about without having to > worry > about interfering with other sessions. [This has shades of the > "partitioning" rule for ISIDs that has been discussed ad nauseum!!!] > > (I have a feeling that this note is not well composed -- it is the > holidays, you know). I hope I've addressed everyone's concerns and we > can > lay this one to rest. > > Jim Hafner > > > John Hufferd > 12/25/2001 08:49 AM > > To: "Eddy Quicksall" > cc: Jim Hafner/Almaden/IBM@IBMUS > From: John Hufferd/San Jose/IBM@IBMUS > Subject: Re: FW: iSCSI: "conservative reuse" requirement (Document > link: > Jim Hafner) > > You are correct. The section was created by Jim Hafner, and via this > note > I will ask him if he could answer Mallikarjun Directly since I did not > understand his issue. > > . > . > . > 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" on 12/24/2001 06:06:44 > PM > > To: John Hufferd/San Jose/IBM@IBMUS > cc: > Subject: FW: iSCSI: "conservative reuse" requirement > > > > John, > > Were you the author of "conservative reuse"? I am wondering about some > issues. Maybe you could educate me somewhat ... > > I started this subject in a different thread by saying that it may be > good to make "conservative reuse" a MUST. > > I got one objection from Santosh below. Then David Black picked it up > by basically agreeing with me. Then Mallikarjun objected to that. > > It seems like the objective would be to give targets a way to figure > out that two or more sessions are coming from the same Initiator Port. > That is needed support persistent reservations. > > If an initiator does not use "conservative reuse", I don't think > targets will be able to make that determination. > > Comments? > > Eddy > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Monday, December 24, 2001 12:47 AM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: "conservative reuse" requirement > > > I think this is headed towards "conservative reuse" being a MUST if > > we're serious about support for shared persistent reservations. > > Mandating "conservative reuse" appears to force initiators to always > act > as a single initiator port (wrt one target; assuming only one session > as > an > example) per initiator device - which rules out the case of an > initiator > > intentionally wanting to present a different port to each target > portal > group. > > IMHO, if iSCSI provides an architected mechanism to support shared > persistent reservations ("conservative reuse"), that should be > completely > adequate to meet the expectations to be a legal SCSI protocol. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 > > ----- Original Message ----- > From: > To: > Cc: > Sent: Friday, December 21, 2001 4:50 PM > Subject: iSCSI: "conservative reuse" requirement > > > > Santosh Rao writes: > > > > > I am opposed to the suggestion that "conservative re-use" of ISIDs > be > > > made a MUST. This is really only required when initiators need to > be > > > using the new T10 Reservation scheme that can be shared > > > across initiator ports. > > > > Those reservations are a Target feature. With this approach, the > ability > > to use the target feature depends on details of the initiator > > implementation. > > More below ... > > > > > For those initiators that don't care about this type of > reservation, > > > conservative re-use is of no use and initiators may like to assign > > > ISID's in a per-initiator node fashion, thereby, being able to use > these > > > ISIDs as a lookup index for the sessions on that initiator node. > > > > > > Hence, I suggest that "conservative re-use" be worded as > > > "encouraged to use" or something to that effect, but not MUST USE. > > > > > > Comments ? > > > > The "initiator" is more than one entity. The iSCSI HBA/NIC and > driver > > doesn't know whether shared persistent reservations are being used > and > > shouldn't have to care - they're just more SCSI commands to > transport. > > Some other entity (e.g., clustering software) will be generating the > > shared persistent reservations. This raise the possible scenario > > involving a target that supports the new shared persistent > reservations > > and an entity that wants to use them. The entity detects (via SCSI > means, > > e.g., something in a mode page) that the Target supports shared > persistent > > reservations, tries to use them, only to discover that they don't > work > > because the iSCSI HBA/NIC doesn't implement "conservative reuse". > > > > I'm worried about this causing both interoperability issues and > possible > > T10 issues -- from a T10 viewpoint, if shared persistent > reservations > > don't work, the initiating entity should have some SCSI-level means > > of determining this ... if that means exists only on the Target, the > > above scenario is iSCSI's problem (Target can't query Initiator to > > determine whether it does "conservative reuse"), and having a > separate > > initiator side means that the entity has to check only for iSCSI > (and > > not for any other SCSI transport) does not seem like the right > > approach. > > > > I think this is headed towards "conservative reuse" being a MUST if > > we're serious about support for shared persistent reservations. > > > > Comments? > > --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 > > --------------------------------------------------- > > > > > > > ------_=_NextPart_001_01C193BF.0E73EF00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

If you don’t want to define it, then you should not use = it.

 

=

There is an “endpoint” that represents the SCSI = Initiator Port. If that “endpoint” can you just give that “endpoint” a = term?

 

=

Eddy

 

=

-----Original Message-----
From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie_krueger@hp.com]
Sent: Wednesday, January = 02, 2002 1:06 PM
To: 'Eddy Quicksall'; = Jim Hafner
Cc: ips@ece.cmu.edu
Subject: RE: FW: iSCSI: "conservative reuse" requirement

 

Did you read Jim's response carefully?  You repeat the statement "It (initiator = portal group" is an important item to define (as mapping to the SCSI = Initiator Port). It is what is needed for persistent reservations. Defining it = properly will eliminate the need for the "conservative reuse" = clause." and Jim has explained to you that this = statement is incorrect.  Several of us have given you the definition of = initiator portal group and you still have this misconception.  I don't know = how putting the definition in the draft would clear up your = misunderstanding?=

 =

If "initiator portal group" is not explicitly = defined in the draft, it is in part because that concept plays no part in the = iSCSI protocol - it's very important that you understand that.  In order = for an initiator to connect to a target, the initiator must know the target's = portal groups.  The converse is NOT true - nothing external to the target = that participates in the iSCSI protocol needs to know the initiator's = address information.  Perhaps if you let go of the idea that the initiator = portal group is an important thing in the iSCSI protocol, you'll understand = what has been explained?

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: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com]
Sent: Wednesday, January = 02, 2002 5:12 AM
To: Jim Hafner
Cc: ips@ece.cmu.edu
Subject: RE: FW: iSCSI: "conservative reuse" requirement=

I see I must have = offended you. I didn't mean to do that ...

 

I was referring to = the definition of iSCSI Initiator Portal Group and that it has been left = out. It is an important item to define (as mapping to the SCSI Initiator Port). It = is what is needed for persistent reservations. Defining it properly will = eliminate the need for the "conservative reuse" = clause.

 

The problem I saw = was that many people have misunderstood the ISID and how it should be used to be compliant with SAM-2.

 

I said much earlier = that the definition of iSCSI Initiator Portal Group was implied and that is = exactly what you have pointed out below.

 

It seems so silly = not to define it. Can you give me a reason why it should not be = defined?

 

Eddy

 

-----Original Message-----
From: Jim Hafner [mailto:hafner@almaden.ibm.com]
Sent: Tuesday, January = 01, 2002 4:16 PM
To: Eddy Quicksall
Cc: ips@ece.cmu.edu
Subject: RE: FW: iSCSI: "conservative reuse" requirement=

 =



Eddy,

I don't know why you think we've done a bad job of defining these = terms. I don't have a copy of the draft around at the moment but this is my recollection:

These are the iSCSI architectural level components:
There is a definition of an iSCSI node (that has a WWU name).

There is a definition of Portal Group (which does NOT apply only to = targets but is applicable to both targets and initiators). (I even thought there = was text that said that this definition applied to both initiator and target, = but I could be wrong about this.)

There is a definition of sessions and the specification of how SSIDs = are generated from the ISID component and the TSID component.


There is the (required by any SCSI protocol) a mapping of the SCSI = constructs to iSCSI constructs. The SCSI constructs of concern here are (a) device = -- both initiator and target (b) port -- initiator, target and initiator/target = and (c) nexus:

There is explicit language that defines the SCSI device as a component = of an iSCSI node (and that there is only one such SCSI device construct = within an iSCSI node -- and this allows us to define the SCSI device name as = equal to the iSCSI node name).

There is explicit language that maps the SCSI initiator port to an = iSCSI construct and *different* language that maps the SCSI target port to an = iSCSI construct. For the SCSI initiator port, the mapping is to the initiator = end of a session. For the SCSI target port, the mapping is to the iSCSI target = portal group. It is NOT symmetric and is stated so explicitly.

There is explicit language the maps the SCSI nexus to the session. Note = that a nexus is a relationship between a SCSI initiator port and a SCSI target = port (that's the SAM definition!). What iSCSI does is map this relationship = from the iSCSI initiator end of a session (SCSI initiator port) to the iSCSI = target portal group (SCSI target port).

Does the text not say this?

Note that the approach we've taken here is to define the iSCSI = architecture and then MAP the iSCSI constructs to SAM-defined SCSI constructs.

And, an attempt to map SCSI initiator port to the iSCSI initiator = portal group (as you suggest) will force a requirement that there can be only one = session between an iSCSI initiator portal group and an iSCSI target portal = group! If one thinks that most "portal groups" will be instantiated by = an iSCSI HBA, then this requirement is unacceptable.


Jim Hafner

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

To: John Hufferd/San Jose/IBM@IBMUS
cc: ips@ece.cmu.edu =
Subject: RE: FW: iSCSI: = "conservative reuse" requirement



My = problem is that we have not done a good job of defining the = iSCSI
Initiator Portal Group in the spec. If defined correctly, there = should be no
need for the "conservative reuse" clause.

Here = is how I think it should be defined ... SCSI Initiator Port: this = maps
to an iSCSI Initiator Portal Group.

You = could go on to say something like Marjorie said below ... that it is = a
collection of IP addresses that can be used to support one or more = iSCSI
sessions.

Given = that it is equivalent to a SCSI Initiator Port and that it = is
identified by the InitiatorName+ISID, it follows that every session = from
that "port" would have to use the same ISID; and that is = what will make
persistent reservations work.

It is = not that "conservative reuse" won't work ... it is more that it = is
hard to explain because we don't have a clear definition of a SCSI Initiator
Port and Initiator Port Identifier.

Eddy

-----Original Message-----
From: John Hufferd [mailto:hufferd@us.ibm.com]
Sent: Monday, December 31, 2001 8:01 PM
To: Amir Shalit
Cc: ips@ece.cmu.edu
Subject: RE: FW: iSCSI: "conservative reuse" = requirement


We = overtly chose NOT to identify an ISID with a TCP/IP address, since = the
ISID may span several HBAs and/or TCP/IP addresses.  It was = more general
and consistent NOT to be tied to a  TCP/IP address.

.
.
.
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


"Amir Shalit" <amir@astutenetworks.com>@ece.cmu.edu on 12/31/2001 = 03:35:56
PM

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


To: =    "Eddy Quicksall" <Eddy_Quicksall@ivivity.com>, "KRUEGER,MARJORIE
      \(HP-Roseville,ex1\)" <marjorie_krueger@hp.com>, Jim
      Hafner/Almaden/IBM@IBMUS
cc:    "ips@ece. cmu. edu \(E-mail\)" <ips@ece.cmu.edu>
Subject:    RE: FW: iSCSI: "conservative reuse" requirement



Marjorie,

If an = "initiator/target portal group" concept is
"the collection of IP addresses which can be combined to = create a single
iSCSI session."
why isn't it defined as such in the draft?

IMO, = it would have been better to define ISID/TSID in simple = networking
terms
like {TCP/IP address + Name} instead of coming up with network = entity,
network portal
and portal group terminology.

Amir


-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf = Of
Eddy Quicksall
Sent: Monday, December 31, 2001 2:15 PM
To: KRUEGER,MARJORIE (HP-Roseville,ex1); Jim Hafner
Cc: ips@ece. cmu. edu (E-mail)
Subject: RE: FW: iSCSI: "conservative reuse" = requirement


Marjorie,

If = "an initiator portal group is the same concept as the target = portal
group", then it must be equivalent to the SCSI Initiator Port = (because we
have said that the SCSI Target Port maps to an iSCSI Target Portal = Group).

Comments?

Eddy

-----Original Message-----
From: KRUEGER,MARJORIE (HP-Roseville,ex1) = [mailto:marjorie_krueger@hp.com]
Sent: Monday, December 31, 2001 4:48 PM
To: 'Eddy Quicksall'; Jim Hafner
Cc: ips@ece. cmu. edu (E-mail)
Subject: RE: FW: iSCSI: "conservative reuse" = requirement

Your = assumption of what is meant by an initiator portal group is = incorrect
(I don't think it's implied that IPG =3D IP???)  An initiator = portal group is
the same concept as a target portal group - it's the collection of = IP
addresses which can be combined to create a single iSCSI = session.
Frequently this is thought of as an iSCSI HBA, but that is not = necessarily
so, it could be a number of iSCSI HBAs, etc.

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: Eddy Quicksall = [mailto:Eddy_Quicksall@ivivity.com]
> Sent: Monday, December 31, 2001 10:39 AM
> To: Jim Hafner
> Cc: ips@ece. cmu. edu (E-mail)
> Subject: RE: FW: iSCSI: "conservative reuse" = requirement
>
>
> Regarding answer 2 below:
> There is no given definition for an iSCSI Initiator Portal = Group
(however,
> it is implied to be the same as the endpoint in 9.1.1, which = would be the
> same as the SCSI Initiator Port). Since an iSCSI Initiator = Portal Group
is
> the same as a SCSI Initiator Port and since an iSCSI Target = Portal Group
is
> the same as a SCSI Target Port, then each session in answer = number 2
would
> not have a "different SCSI initiator port"; hence = you would have a
parallel
> nexus.
> One thing that is not clear in section 9.1.1 (however, it is = loosely
> implied) is that the reuse of ISID's applies to a given = initiator
endpoint
> (SCSI Initiator Port or what should be called an iSCSI = Initiator Portal
> Group)). I think that should be made clear.
> What am I missing? Could it be that an iSCSI Initiator Portal = Group is
not
> equivalent to a SCSI Target Port?
>
> Eddy
>
> -----Original Message-----
> From: Jim Hafner [mailto:hafner@almaden.ibm.com]
> Sent: Saturday, December 29, 2001 6:14 PM
> To: Eddy Quicksall
> Cc: ips
> Subject: RE: FW: iSCSI: "conservative reuse" = requirement
>
>
> Eddy,
>
> The SCSI initiator port is modeled as the endpoint of = the
> iSCSI session;
> the SCSI target port is modeled as the iSCSI target portal = group.  The
> reason we did it this way was to allow more than one = session
> between portal
> groups by allowing multi-plexing of sessions with = different
> ISIDs from the
> same iSCSI initiator portal group to the same target portal = group.
>
> So, the answer to your questions are:
> 1) no, we're assuming no more than on session *with the = same
> ISID* to the
> same target portal group (that'd be more than one nexus), = but
> by allowing
> different ISIDs we get different SCSI initiator = ports.
> 2) no, we're allowing more than one session between an iSCSI = initiator
> portal group and an iSCSI target portal group (each = session
> has a different
> SCSI initiator port (id'ed by its ISID) but the same SCSI = target port
> (id'ed by its portal group tag).
> 3) sort of, the ISID together with the iSCSI Initiator Name = fully
> identifies the SCSI initiator port (and so defines the = SCSI
> initiator port
> name and the identifier).
>
> Does that clear this up?
>
> Jim Hafner
>
>
> "Eddy Quicksall" <Eddy_Quicksall@iVivity.com> = on 12/28/2001
> 07:19:33 PM
>
> To:   Jim Hafner/Almaden/IBM@IBMUS
> cc:   "ips@ece. cmu. edu \(E-mail\)" <ips@ece.cmu.edu>
> Subject:  RE: FW: iSCSI: "conservative reuse" requirement
>
>
>
> Due to 2.5.3 (b) "Between a given SCSI initiator port and = SCSI target
> port, there can be only one I_T nexus (session)", aren't = we always
> "assuming no more than one session"?
>
> Or are you talking about more than one session between = different SCSI
> initiator ports and a single SCSI target port?
>
> Is the ISID equivalent to SAM-2's Initiator Port = Identifier?
>
>
> Eddy
>
> -----Original Message-----
> From: Jim Hafner [mailto:hafner@almaden.ibm.com]
> Sent: Friday, December 28, 2001 12:15 PM
> To: John Hufferd; Eddy Quicksall; Mallikarjun C.; = Black_David@emc.com
> Cc: ips@ece.cmu.edu
> Subject: Re: FW: iSCSI: "conservative reuse" = requirement
>
>
> Folks,
>
> Sorry for taking so long to jump into this = discussion.
>
> There are a number of issues raised in this thread:
> 1) should "conservative reuse" of ISIDs be made a = MUST
> 2) does "conservative reuse" imply that all hosts = look "single SCSI
> ported"
>
> Here's my two cents (using "CR" as a shorthand for "conservative
> reuse")
>
> I don't believe that CR needs to be a MUST.  The only = time this has
> any
> real value is in configurations that use SCSI persistent = reservations
> (and
> where new SCSI target reservation features are enabled -- NB.  these
> features are yet to be approved but are working their way = through the
> process). I don't think these are going to be (even in the = future) the
> majority of installations.  There are many ways then that = CR could be
> something that is not generally available in most drivers but = is added
> by
> configuration and perhaps even "value add" = (:-{)).
>
> In short, I don't see a strong case for this to be a MUST. =  So, to
> David
> Black, my answer is that having a mechanism to enable this = feature or
> have
> it as a "purchase requirement" is an acceptable = mechanism to make sure
> the
> feature is there when needed, but it is need not be a = requirement of
> the
> protocol.  To Mallikarjun, I think I'm agreeing with you = that so long
> as
> there is a mechanism defined, iSCSI has done it's = job.
>
> As for the second issue (raised by Mallikarjun), let's look at = the
> definition of CR.  What is means is that when an iSCSI = initiator
> (node)
> creates ISIDs for use in session identifiers, it attempts to = reuse
> them
> as
> much as possible with different SCSI target ports (iSCSI = target portal
> groups).  This is the only way that a SCSI target or LU = can see the
> same
> SCSI initiator port through two or more of its SCSI target = ports --
> that
> is, that the target can determine multiple paths *from* the = same SCSI
> initiator port.   But, the model for generating ISIDs is = not really at
> the
> node level but at the initiator portal group level.
> So, IMO, the conclusion that all hosts must then look = "single SCSI
> ported"
> is too dramatic.  As I mentioned,  ISIDs are = conceptually generated
> within
> initiator portal groups (that's why we defined the mechanism = for
> generating
> ISIDs).  The conclusion I draw is that (assuming no more = than one
> session
> to any given target portal group), an iSCSI initiator = implementing CR
> will
> have as many SCSI initiator ports as iSCSI initiator portal = groups
> (independent HBAs?).  Each initiator portal group would = generate one
> ISID
> (that is different from that generated by/for the other = initiator
> portal
> groups) and use CR for repeatability.  [This is = consistent with a
> model
> that mapped SCSI initiator ports to initiator portal groups, = which we
> had
> to abandon because the "assuming no more than one session..." was no
> acceptable as a requirement!!!]  This independence of = ISIDs for each
> initiator portal group allows each initiator portal group to = open
> sessions
> with *every* target portal group it knows about without having = to
> worry
> about interfering with other sessions. [This has shades of = the
> "partitioning" rule for ISIDs that has been = discussed ad nauseum!!!]
>
> (I have a feeling that this note is not well composed -- it is = the
> holidays, you know).  I hope I've addressed everyone's = concerns and we
> can
> lay this one to rest.
>
> Jim Hafner
>
>
> John Hufferd
> 12/25/2001 08:49 AM
>
> To:   "Eddy Quicksall" = <Eddy_Quicksall@iVivity.com>
> cc:   Jim Hafner/Almaden/IBM@IBMUS
> From: John Hufferd/San Jose/IBM@IBMUS
> Subject:  Re: FW: iSCSI: "conservative reuse" requirement  (Document
> link:
>       Jim Hafner)
>
> You are correct.  The section was created by Jim Hafner, = and via this
> note
> I will ask him if he could answer Mallikarjun Directly since I = did not
> understand his issue.
>
> .
> .
> .
> 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" <Eddy_Quicksall@iVivity.com> = on 12/24/2001 06:06:44
> PM
>
> To:   John Hufferd/San Jose/IBM@IBMUS
> cc:
> Subject:  FW: iSCSI: "conservative reuse" = requirement
>
>
>
> John,
>
> Were you the author of "conservative reuse"? I am = wondering about some
> issues. Maybe you could educate me somewhat ...
>
> I started this subject in a different thread by saying that it = may be
> good to make "conservative reuse" a MUST.
>
> I got one objection from Santosh below. Then David Black = picked it up
> by basically agreeing with me. Then Mallikarjun objected to = that.
>
> It seems like the objective would be to give targets a way to = figure
> out that two or more sessions are coming from the same = Initiator Port.
> That is needed support persistent reservations.
>
> If an initiator does not use "conservative reuse", I = don't think
> targets will be able to make that determination.
>
> Comments?
>
> Eddy
>
> -----Original Message-----
> From: Mallikarjun C. [mailto:cbm@rose.hp.com]
> Sent: Monday, December 24, 2001 12:47 AM
> To: Black_David@emc.com
> Cc: ips@ece.cmu.edu
> Subject: Re: iSCSI: "conservative reuse" = requirement
>
> > I think this is headed towards "conservative = reuse" being a MUST if
> > we're serious about support for shared persistent = reservations.
>
> Mandating "conservative reuse" appears to force = initiators to always
> act
> as a single initiator port (wrt one target; assuming only one = session
> as
> an
> example) per initiator device - which rules out the case of = an
> initiator
>
> intentionally wanting to present a different port to each = target
> portal
> group.
>
> IMHO, if iSCSI provides an architected mechanism to support = shared
> persistent reservations ("conservative reuse"), =  that should be
> completely
> adequate to meet the expectations to be a legal SCSI = protocol.
> --
> Mallikarjun
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> Hewlett-Packard MS 5668
> Roseville CA 95747
>
> ----- Original Message -----
> From: <Black_David@emc.com>
> To: <santoshr@cup.hp.com>
> Cc: <ips@ece.cmu.edu>
> Sent: Friday, December 21, 2001 4:50 PM
> Subject: iSCSI: "conservative reuse" = requirement
>
>
> > Santosh Rao writes:
> >
> > > I am opposed to the suggestion that = "conservative re-use" of ISIDs
> be
> > > made a MUST. This is really only required when = initiators need to
> be
> > > using the new T10 Reservation scheme that can be = shared
> > > across initiator ports.
> >
> > Those reservations are a Target feature.  With this approach, the
> ability
> > to use the target feature depends on details of the = initiator
> > implementation.
> > More below ...
> >
> > > For those initiators that don't care about this type = of
> reservation,
> > > conservative re-use is of no use and initiators may = like to assign
> > > ISID's in a per-initiator node fashion, thereby, = being able to use
> these
> > > ISIDs as a lookup index for the sessions on that = initiator node.
> > >
> > > Hence, I suggest that "conservative = re-use" be worded as
> > > "encouraged to use" or something to that = effect, but not MUST USE.
> > >
> > > Comments ?
> >
> > The "initiator" is more than one entity. =  The iSCSI HBA/NIC and
> driver
> > doesn't know whether shared persistent reservations are = being used
> and
> > shouldn't have to care - they're just more SCSI commands = to
> transport.
> > Some other entity (e.g., clustering software) will be = generating the
> > shared persistent reservations.  This raise the = possible scenario
> > involving a target that supports the new shared = persistent
> reservations
> > and an entity that wants to use them.  The entity = detects (via SCSI
> means,
> = > e.g., something in a mode page) that the Target supports = shared
> persistent
> > reservations, tries to use them, only to discover that = they don't
> work
> > because the iSCSI HBA/NIC doesn't implement = "conservative reuse".
> >
> > I'm worried about this causing both interoperability = issues and
> possible
> > T10 issues -- from a T10 viewpoint, if shared = persistent
> reservations
> > don't work, the initiating entity should have some = SCSI-level means
> > of determining this ... if that means exists only on the = Target, the
> > above scenario is iSCSI's problem (Target can't query = Initiator to
> > determine whether it does "conservative = reuse"), and having a
> separate
> > initiator side means that the entity has to check only = for iSCSI
> (and
> > not for any other SCSI transport) does not seem like the = right
> > approach.
> >
> > I think this is headed towards "conservative = reuse" being a MUST if
> > we're serious about support for shared persistent = reservations.
> >
> > Comments?
> > --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
> > = ---------------------------------------------------
> >
> >
>
>
>




------_=_NextPart_001_01C193BF.0E73EF00-- From owner-ips@ece.cmu.edu Wed Jan 2 15:46: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 PAA10509 for ; Wed, 2 Jan 2002 15:46:11 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g02Jed126427 for ips-outgoing; Wed, 2 Jan 2002 14:40:39 -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 g02Jeag26421 for ; Wed, 2 Jan 2002 14:40:37 -0500 (EST) Received: from xparelay2.corp.hp.com (xparelay2.corp.hp.com [15.58.137.112]) by palrel10.hp.com (Postfix) with ESMTP id 0E6B8400218; Wed, 2 Jan 2002 11:40:31 -0800 (PST) Received: from xpabh2.corp.hp.com (xpabh2.corp.hp.com [15.58.136.192]) by xparelay2.corp.hp.com (Postfix) with ESMTP id 0DF644000A5; Wed, 2 Jan 2002 11:40:05 -0800 (PST) Received: by xpabh2.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Jan 2002 11:40:30 -0800 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF2DD@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Eddy Quicksall'" Cc: ips@ece.cmu.edu Subject: RE: FW: iSCSI: "conservative reuse" requirement Date: Wed, 2 Jan 2002 11:40:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C193C5.540245C0" 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_01C193C5.540245C0 Content-Type: text/plain; charset="iso-8859-1" ? You asked for the definition it, but you don't want me to use it? Could you point out where the iSCSI protocol document uses the term "initiator portal group" in a manner that confuses you? The "endpoint" that represents the SCSI Initiator Port is the iSCSI initiator node's end of the iSCSI session. 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: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] Sent: Wednesday, January 02, 2002 10:56 AM To: KRUEGER,MARJORIE (HP-Roseville,ex1); Jim Hafner Cc: ips@ece.cmu.edu Subject: RE: FW: iSCSI: "conservative reuse" requirement If you don't want to define it, then you should not use it. There is an "endpoint" that represents the SCSI Initiator Port. If that "endpoint" can you just give that "endpoint" a term? Eddy -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie_krueger@hp.com] Sent: Wednesday, January 02, 2002 1:06 PM To: 'Eddy Quicksall'; Jim Hafner Cc: ips@ece.cmu.edu Subject: RE: FW: iSCSI: "conservative reuse" requirement Did you read Jim's response carefully? You repeat the statement "It (initiator portal group" is an important item to define (as mapping to the SCSI Initiator Port). It is what is needed for persistent reservations. Defining it properly will eliminate the need for the "conservative reuse" clause." and Jim has explained to you that this statement is incorrect. Several of us have given you the definition of initiator portal group and you still have this misconception. I don't know how putting the definition in the draft would clear up your misunderstanding? If "initiator portal group" is not explicitly defined in the draft, it is in part because that concept plays no part in the iSCSI protocol - it's very important that you understand that. In order for an initiator to connect to a target, the initiator must know the target's portal groups. The converse is NOT true - nothing external to the target that participates in the iSCSI protocol needs to know the initiator's address information. Perhaps if you let go of the idea that the initiator portal group is an important thing in the iSCSI protocol, you'll understand what has been explained? 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: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] Sent: Wednesday, January 02, 2002 5:12 AM To: Jim Hafner Cc: ips@ece.cmu.edu Subject: RE: FW: iSCSI: "conservative reuse" requirement I see I must have offended you. I didn't mean to do that ... I was referring to the definition of iSCSI Initiator Portal Group and that it has been left out. It is an important item to define (as mapping to the SCSI Initiator Port). It is what is needed for persistent reservations. Defining it properly will eliminate the need for the "conservative reuse" clause. The problem I saw was that many people have misunderstood the ISID and how it should be used to be compliant with SAM-2. I said much earlier that the definition of iSCSI Initiator Portal Group was implied and that is exactly what you have pointed out below. It seems so silly not to define it. Can you give me a reason why it should not be defined? Eddy -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Tuesday, January 01, 2002 4:16 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu Subject: RE: FW: iSCSI: "conservative reuse" requirement Eddy, I don't know why you think we've done a bad job of defining these terms. I don't have a copy of the draft around at the moment but this is my recollection: These are the iSCSI architectural level components: There is a definition of an iSCSI node (that has a WWU name). There is a definition of Portal Group (which does NOT apply only to targets but is applicable to both targets and initiators). (I even thought there was text that said that this definition applied to both initiator and target, but I could be wrong about this.) There is a definition of sessions and the specification of how SSIDs are generated from the ISID component and the TSID component. There is the (required by any SCSI protocol) a mapping of the SCSI constructs to iSCSI constructs. The SCSI constructs of concern here are (a) device -- both initiator and target (b) port -- initiator, target and initiator/target and (c) nexus: There is explicit language that defines the SCSI device as a component of an iSCSI node (and that there is only one such SCSI device construct within an iSCSI node -- and this allows us to define the SCSI device name as equal to the iSCSI node name). There is explicit language that maps the SCSI initiator port to an iSCSI construct and *different* language that maps the SCSI target port to an iSCSI construct. For the SCSI initiator port, the mapping is to the initiator end of a session. For the SCSI target port, the mapping is to the iSCSI target portal group. It is NOT symmetric and is stated so explicitly. There is explicit language the maps the SCSI nexus to the session. Note that a nexus is a relationship between a SCSI initiator port and a SCSI target port (that's the SAM definition!). What iSCSI does is map this relationship from the iSCSI initiator end of a session (SCSI initiator port) to the iSCSI target portal group (SCSI target port). Does the text not say this? Note that the approach we've taken here is to define the iSCSI architecture and then MAP the iSCSI constructs to SAM-defined SCSI constructs. And, an attempt to map SCSI initiator port to the iSCSI initiator portal group (as you suggest) will force a requirement that there can be only one session between an iSCSI initiator portal group and an iSCSI target portal group! If one thinks that most "portal groups" will be instantiated by an iSCSI HBA, then this requirement is unacceptable. Jim Hafner Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS cc: ips@ece.cmu.edu Subject: RE: FW: iSCSI: "conservative reuse" requirement My problem is that we have not done a good job of defining the iSCSI Initiator Portal Group in the spec. If defined correctly, there should be no need for the "conservative reuse" clause. Here is how I think it should be defined ... SCSI Initiator Port: this maps to an iSCSI Initiator Portal Group. You could go on to say something like Marjorie said below ... that it is a collection of IP addresses that can be used to support one or more iSCSI sessions. Given that it is equivalent to a SCSI Initiator Port and that it is identified by the InitiatorName+ISID, it follows that every session from that "port" would have to use the same ISID; and that is what will make persistent reservations work. It is not that "conservative reuse" won't work ... it is more that it is hard to explain because we don't have a clear definition of a SCSI Initiator Port and Initiator Port Identifier. Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Monday, December 31, 2001 8:01 PM To: Amir Shalit Cc: ips@ece.cmu.edu Subject: RE: FW: iSCSI: "conservative reuse" requirement We overtly chose NOT to identify an ISID with a TCP/IP address, since the ISID may span several HBAs and/or TCP/IP addresses. It was more general and consistent NOT to be tied to a TCP/IP address. . . . 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 "Amir Shalit" @ece.cmu.edu on 12/31/2001 03:35:56 PM Sent by: owner-ips@ece.cmu.edu To: "Eddy Quicksall" , "KRUEGER,MARJORIE \(HP-Roseville,ex1\)" , Jim Hafner/Almaden/IBM@IBMUS cc: "ips@ece. cmu. edu \(E-mail\)" Subject: RE: FW: iSCSI: "conservative reuse" requirement Marjorie, If an "initiator/target portal group" concept is "the collection of IP addresses which can be combined to create a single iSCSI session." why isn't it defined as such in the draft? IMO, it would have been better to define ISID/TSID in simple networking terms like {TCP/IP address + Name} instead of coming up with network entity, network portal and portal group terminology. Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Eddy Quicksall Sent: Monday, December 31, 2001 2:15 PM To: KRUEGER,MARJORIE (HP-Roseville,ex1); Jim Hafner Cc: ips@ece. cmu. edu (E-mail) Subject: RE: FW: iSCSI: "conservative reuse" requirement Marjorie, If "an initiator portal group is the same concept as the target portal group", then it must be equivalent to the SCSI Initiator Port (because we have said that the SCSI Target Port maps to an iSCSI Target Portal Group). Comments? Eddy -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie_krueger@hp.com] Sent: Monday, December 31, 2001 4:48 PM To: 'Eddy Quicksall'; Jim Hafner Cc: ips@ece. cmu. edu (E-mail) Subject: RE: FW: iSCSI: "conservative reuse" requirement Your assumption of what is meant by an initiator portal group is incorrect (I don't think it's implied that IPG = IP???) An initiator portal group is the same concept as a target portal group - it's the collection of IP addresses which can be combined to create a single iSCSI session. Frequently this is thought of as an iSCSI HBA, but that is not necessarily so, it could be a number of iSCSI HBAs, etc. 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: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] > Sent: Monday, December 31, 2001 10:39 AM > To: Jim Hafner > Cc: ips@ece. cmu. edu (E-mail) > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > Regarding answer 2 below: > There is no given definition for an iSCSI Initiator Portal Group (however, > it is implied to be the same as the endpoint in 9.1.1, which would be the > same as the SCSI Initiator Port). Since an iSCSI Initiator Portal Group is > the same as a SCSI Initiator Port and since an iSCSI Target Portal Group is > the same as a SCSI Target Port, then each session in answer number 2 would > not have a "different SCSI initiator port"; hence you would have a parallel > nexus. > One thing that is not clear in section 9.1.1 (however, it is loosely > implied) is that the reuse of ISID's applies to a given initiator endpoint > (SCSI Initiator Port or what should be called an iSCSI Initiator Portal > Group)). I think that should be made clear. > What am I missing? Could it be that an iSCSI Initiator Portal Group is not > equivalent to a SCSI Target Port? > > Eddy > > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Saturday, December 29, 2001 6:14 PM > To: Eddy Quicksall > Cc: ips > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > Eddy, > > The SCSI initiator port is modeled as the endpoint of the > iSCSI session; > the SCSI target port is modeled as the iSCSI target portal group. The > reason we did it this way was to allow more than one session > between portal > groups by allowing multi-plexing of sessions with different > ISIDs from the > same iSCSI initiator portal group to the same target portal group. > > So, the answer to your questions are: > 1) no, we're assuming no more than on session *with the same > ISID* to the > same target portal group (that'd be more than one nexus), but > by allowing > different ISIDs we get different SCSI initiator ports. > 2) no, we're allowing more than one session between an iSCSI initiator > portal group and an iSCSI target portal group (each session > has a different > SCSI initiator port (id'ed by its ISID) but the same SCSI target port > (id'ed by its portal group tag). > 3) sort of, the ISID together with the iSCSI Initiator Name fully > identifies the SCSI initiator port (and so defines the SCSI > initiator port > name and the identifier). > > Does that clear this up? > > Jim Hafner > > > "Eddy Quicksall" on 12/28/2001 > 07:19:33 PM > > To: Jim Hafner/Almaden/IBM@IBMUS > cc: "ips@ece. cmu. edu \(E-mail\)" > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > > Due to 2.5.3 (b) "Between a given SCSI initiator port and SCSI target > port, there can be only one I_T nexus (session)", aren't we always > "assuming no more than one session"? > > Or are you talking about more than one session between different SCSI > initiator ports and a single SCSI target port? > > Is the ISID equivalent to SAM-2's Initiator Port Identifier? > > > Eddy > > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Friday, December 28, 2001 12:15 PM > To: John Hufferd; Eddy Quicksall; Mallikarjun C.; Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: FW: iSCSI: "conservative reuse" requirement > > > Folks, > > Sorry for taking so long to jump into this discussion. > > There are a number of issues raised in this thread: > 1) should "conservative reuse" of ISIDs be made a MUST > 2) does "conservative reuse" imply that all hosts look "single SCSI > ported" > > Here's my two cents (using "CR" as a shorthand for "conservative > reuse") > > I don't believe that CR needs to be a MUST. The only time this has > any > real value is in configurations that use SCSI persistent reservations > (and > where new SCSI target reservation features are enabled -- NB. these > features are yet to be approved but are working their way through the > process). I don't think these are going to be (even in the future) the > majority of installations. There are many ways then that CR could be > something that is not generally available in most drivers but is added > by > configuration and perhaps even "value add" (:-{)). > > In short, I don't see a strong case for this to be a MUST. So, to > David > Black, my answer is that having a mechanism to enable this feature or > have > it as a "purchase requirement" is an acceptable mechanism to make sure > the > feature is there when needed, but it is need not be a requirement of > the > protocol. To Mallikarjun, I think I'm agreeing with you that so long > as > there is a mechanism defined, iSCSI has done it's job. > > As for the second issue (raised by Mallikarjun), let's look at the > definition of CR. What is means is that when an iSCSI initiator > (node) > creates ISIDs for use in session identifiers, it attempts to reuse > them > as > much as possible with different SCSI target ports (iSCSI target portal > groups). This is the only way that a SCSI target or LU can see the > same > SCSI initiator port through two or more of its SCSI target ports -- > that > is, that the target can determine multiple paths *from* the same SCSI > initiator port. But, the model for generating ISIDs is not really at > the > node level but at the initiator portal group level. > So, IMO, the conclusion that all hosts must then look "single SCSI > ported" > is too dramatic. As I mentioned, ISIDs are conceptually generated > within > initiator portal groups (that's why we defined the mechanism for > generating > ISIDs). The conclusion I draw is that (assuming no more than one > session > to any given target portal group), an iSCSI initiator implementing CR > will > have as many SCSI initiator ports as iSCSI initiator portal groups > (independent HBAs?). Each initiator portal group would generate one > ISID > (that is different from that generated by/for the other initiator > portal > groups) and use CR for repeatability. [This is consistent with a > model > that mapped SCSI initiator ports to initiator portal groups, which we > had > to abandon because the "assuming no more than one session..." was no > acceptable as a requirement!!!] This independence of ISIDs for each > initiator portal group allows each initiator portal group to open > sessions > with *every* target portal group it knows about without having to > worry > about interfering with other sessions. [This has shades of the > "partitioning" rule for ISIDs that has been discussed ad nauseum!!!] > > (I have a feeling that this note is not well composed -- it is the > holidays, you know). I hope I've addressed everyone's concerns and we > can > lay this one to rest. > > Jim Hafner > > > John Hufferd > 12/25/2001 08:49 AM > > To: "Eddy Quicksall" > cc: Jim Hafner/Almaden/IBM@IBMUS > From: John Hufferd/San Jose/IBM@IBMUS > Subject: Re: FW: iSCSI: "conservative reuse" requirement (Document > link: > Jim Hafner) > > You are correct. The section was created by Jim Hafner, and via this > note > I will ask him if he could answer Mallikarjun Directly since I did not > understand his issue. > > . > . > . > 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" on 12/24/2001 06:06:44 > PM > > To: John Hufferd/San Jose/IBM@IBMUS > cc: > Subject: FW: iSCSI: "conservative reuse" requirement > > > > John, > > Were you the author of "conservative reuse"? I am wondering about some > issues. Maybe you could educate me somewhat ... > > I started this subject in a different thread by saying that it may be > good to make "conservative reuse" a MUST. > > I got one objection from Santosh below. Then David Black picked it up > by basically agreeing with me. Then Mallikarjun objected to that. > > It seems like the objective would be to give targets a way to figure > out that two or more sessions are coming from the same Initiator Port. > That is needed support persistent reservations. > > If an initiator does not use "conservative reuse", I don't think > targets will be able to make that determination. > > Comments? > > Eddy > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Monday, December 24, 2001 12:47 AM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: "conservative reuse" requirement > > > I think this is headed towards "conservative reuse" being a MUST if > > we're serious about support for shared persistent reservations. > > Mandating "conservative reuse" appears to force initiators to always > act > as a single initiator port (wrt one target; assuming only one session > as > an > example) per initiator device - which rules out the case of an > initiator > > intentionally wanting to present a different port to each target > portal > group. > > IMHO, if iSCSI provides an architected mechanism to support shared > persistent reservations ("conservative reuse"), that should be > completely > adequate to meet the expectations to be a legal SCSI protocol. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 > > ----- Original Message ----- > From: > To: > Cc: > Sent: Friday, December 21, 2001 4:50 PM > Subject: iSCSI: "conservative reuse" requirement > > > > Santosh Rao writes: > > > > > I am opposed to the suggestion that "conservative re-use" of ISIDs > be > > > made a MUST. This is really only required when initiators need to > be > > > using the new T10 Reservation scheme that can be shared > > > across initiator ports. > > > > Those reservations are a Target feature. With this approach, the > ability > > to use the target feature depends on details of the initiator > > implementation. > > More below ... > > > > > For those initiators that don't care about this type of > reservation, > > > conservative re-use is of no use and initiators may like to assign > > > ISID's in a per-initiator node fashion, thereby, being able to use > these > > > ISIDs as a lookup index for the sessions on that initiator node. > > > > > > Hence, I suggest that "conservative re-use" be worded as > > > "encouraged to use" or something to that effect, but not MUST USE. > > > > > > Comments ? > > > > The "initiator" is more than one entity. The iSCSI HBA/NIC and > driver > > doesn't know whether shared persistent reservations are being used > and > > shouldn't have to care - they're just more SCSI commands to > transport. > > Some other entity (e.g., clustering software) will be generating the > > shared persistent reservations. This raise the possible scenario > > involving a target that supports the new shared persistent > reservations > > and an entity that wants to use them. The entity detects (via SCSI > means, > > e.g., something in a mode page) that the Target supports shared > persistent > > reservations, tries to use them, only to discover that they don't > work > > because the iSCSI HBA/NIC doesn't implement "conservative reuse". > > > > I'm worried about this causing both interoperability issues and > possible > > T10 issues -- from a T10 viewpoint, if shared persistent > reservations > > don't work, the initiating entity should have some SCSI-level means > > of determining this ... if that means exists only on the Target, the > > above scenario is iSCSI's problem (Target can't query Initiator to > > determine whether it does "conservative reuse"), and having a > separate > > initiator side means that the entity has to check only for iSCSI > (and > > not for any other SCSI transport) does not seem like the right > > approach. > > > > I think this is headed towards "conservative reuse" being a MUST if > > we're serious about support for shared persistent reservations. > > > > Comments? > > --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 > > --------------------------------------------------- > > > > > > > ------_=_NextPart_001_01C193C5.540245C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
? You asked for the definition it, but = you don't=20 want me to use it?  Could you point out where the iSCSI protocol = document=20 uses the term "initiator portal group" in a manner that confuses=20 you?
 
The "endpoint" that represents the SCSI = Initiator Port=20 is the iSCSI initiator node's end of the iSCSI=20 session.
 
Marjorie Krueger
Networked = Storage=20 Architecture
Networked Storage Solutions = Org.
Hewlett-Packard
tel: +1=20 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com=20
-----Original Message-----
From: Eddy Quicksall=20 [mailto:Eddy_Quicksall@ivivity.com]
Sent: Wednesday, = January 02,=20 2002 10:56 AM
To: KRUEGER,MARJORIE (HP-Roseville,ex1); Jim=20 Hafner
Cc: ips@ece.cmu.edu
Subject: RE: FW: = iSCSI:=20 "conservative reuse" requirement

If you=20 don't want to define it, then you should not use=20 it.

 

=

There=20 is an "endpoint" that represents the SCSI Initiator Port. If that = "endpoint"=20 can you just give that "endpoint" a = term?

 

=

Eddy

 

=

-----Original=20 Message-----
From: = KRUEGER,MARJORIE (HP-Roseville,ex1)=20 [mailto:marjorie_krueger@hp.com]
Sent: Wednesday, January 02, = 2002 1:06=20 PM
To: 'Eddy = Quicksall'; Jim=20 Hafner
Cc:=20 ips@ece.cmu.edu
Subject: RE:=20 FW: iSCSI: "conservative reuse" requirement

 

Did you read=20 Jim's response carefully?  You repeat the statement = "It = (initiator portal=20 group" is an important item to define (as mapping to the SCSI = Initiator Port).=20 It is what is needed for persistent reservations. Defining it = properly will=20 eliminate the need for the "conservative reuse" clause." = and Jim has=20 explained to you that this statement is incorrect.  Several of = us have=20 given you the definition of initiator portal group and you still have = this=20 misconception.  I don't know how putting the definition in the = draft=20 would clear up your misunderstanding?

 

If = "initiator=20 portal group" is not explicitly defined in the draft, it is in part = because=20 that concept plays no part in the iSCSI protocol - it's very = important that=20 you understand that.  In order for an initiator to connect to a = target,=20 the initiator must know the target's portal groups.  The = converse is NOT=20 true - nothing external to the target that participates in the iSCSI = protocol=20 needs to know the initiator's address information.  Perhaps if = you let go=20 of the idea that the initiator portal group is an important thing in = the iSCSI=20 protocol, you'll understand what has been = explained?

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

-----Original=20 Message-----
From: = Eddy=20 Quicksall [mailto:Eddy_Quicksall@ivivity.com]
Sent: Wednesday, January 02, = 2002 5:12=20 AM
To: Jim = Hafner
Cc: = ips@ece.cmu.edu
Subject: RE: FW: iSCSI: = "conservative=20 reuse" requirement

I see=20 I must have offended you. I didn't mean to do that ...=20

 

I was=20 referring to the definition of iSCSI Initiator Portal Group and that = it has=20 been left out. It is an important item to define (as mapping to the = SCSI=20 Initiator Port). It is what is needed for persistent reservations. = Defining it=20 properly will eliminate the need for the "conservative reuse"=20 clause.

 

The=20 problem I saw was that many people have misunderstood the ISID and = how it=20 should be used to be compliant with = SAM-2.

 

I said=20 much earlier that the definition of iSCSI Initiator Portal Group was = implied=20 and that is exactly what you have pointed out=20 below.

 

It=20 seems so silly not to define it. Can you give me a reason why it = should not be=20 defined?

 

Eddy

 

-----Original=20 Message-----
From: = Jim Hafner=20 [mailto:hafner@almaden.ibm.com]
Sent: Tuesday, January 01, = 2002 4:16=20 PM
To: Eddy=20 Quicksall
Cc:=20 ips@ece.cmu.edu
Subject: RE:=20 FW: iSCSI: "conservative reuse" requirement

 



Eddy,

I don't = know why=20 you think we've done a bad job of defining these terms. I don't have = a copy of=20 the draft around at the moment but this is my = recollection:

These are=20 the iSCSI architectural level components:
There is a definition = of an=20 iSCSI node (that has a WWU name).

There is a definition of = Portal=20 Group (which does NOT apply only to targets but is applicable to both = targets=20 and initiators). (I even thought there was text that said that this = definition=20 applied to both initiator and target, but I could be wrong about=20 this.)

There is a definition of sessions and the specification = of how=20 SSIDs are generated from the ISID component and the TSID component.=20


There is the (required by any SCSI protocol) a mapping of = the SCSI=20 constructs to iSCSI constructs. The SCSI constructs of concern here = are (a)=20 device -- both initiator and target (b) port -- initiator, target and = initiator/target and (c) nexus:

There is explicit language = that=20 defines the SCSI device as a component of an iSCSI node (and that = there is=20 only one such SCSI device construct within an iSCSI node -- and this = allows us=20 to define the SCSI device name as equal to the iSCSI node = name).

There=20 is explicit language that maps the SCSI initiator port to an iSCSI = construct=20 and *different* language that maps the SCSI target port to an iSCSI = construct.=20 For the SCSI initiator port, the mapping is to the initiator end of a = session.=20 For the SCSI target port, the mapping is to the iSCSI target portal = group. It=20 is NOT symmetric and is stated so explicitly.

There is = explicit=20 language the maps the SCSI nexus to the session. Note that a nexus is = a=20 relationship between a SCSI initiator port and a SCSI target port = (that's the=20 SAM definition!). What iSCSI does is map this relationship from the = iSCSI=20 initiator end of a session (SCSI initiator port) to the iSCSI target = portal=20 group (SCSI target port).

Does the text not say = this?

Note that=20 the approach we've taken here is to define the iSCSI architecture and = then MAP=20 the iSCSI constructs to SAM-defined SCSI constructs.

And, an = attempt=20 to map SCSI initiator port to the iSCSI initiator portal group (as = you=20 suggest) will force a requirement that there can be only one session = between=20 an iSCSI initiator portal group and an iSCSI target portal group! If = one=20 thinks that most "portal groups" will be instantiated by an iSCSI = HBA, then=20 this requirement is unacceptable.


Jim = Hafner

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

To: John = Hufferd/San=20 Jose/IBM@IBMUS
cc: ips@ece.cmu.edu=20
Subject: RE: FW: iSCSI:=20 "conservative reuse" requirement



My problem=20 is that we have not done a good job of defining the=20 iSCSI
Initiator=20 Portal Group in the spec. If defined correctly, there should be=20 no
need for the "conservative reuse"=20 clause.

Here is how=20 I think it should be defined ... SCSI Initiator Port: this=20 maps
to=20 an iSCSI Initiator Portal Group.

You could go=20 on to say something like Marjorie said below ... that it is=20 a
collection=20 of IP addresses that can be used to support one or more=20 iSCSI
sessions.

Given that=20 it is equivalent to a SCSI Initiator Port and that it=20 is
identified=20 by the InitiatorName+ISID, it follows that every session = from
that=20 "port" would have to use the same ISID; and that is what will=20 make
persistent reservations = work.

It is not=20 that "conservative reuse" won't work ... it is more that it=20 is
hard=20 to explain because we don't have a clear definition of a SCSI=20 Initiator
Port and Initiator Port=20 Identifier.

Eddy

-----Original=20 Message-----
From:=20 John Hufferd [mailto:hufferd@us.ibm.com]
Sent: Monday, = December=20 31, 2001 8:01 PM
To: Amir Shalit
Cc:=20 ips@ece.cmu.edu
Subject: RE: FW: iSCSI: "conservative = reuse"=20 requirement


We overtly=20 chose NOT to identify an ISID with a TCP/IP address, since=20 the
ISID=20 may span several HBAs and/or TCP/IP addresses.  It was more=20 general
and consistent NOT to be tied to a  TCP/IP=20 address.

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


"Amir=20 Shalit" <amir@astutenetworks.com>@ece.cmu.edu on 12/31/2001=20 03:35:56
PM

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


To:  =20  "Eddy Quicksall" <Eddy_Quicksall@ivivity.com>,=20 "KRUEGER,MARJORIE
 =20     \(HP-Roseville,ex1\)" <marjorie_krueger@hp.com>,=20 Jim
      = Hafner/Almaden/IBM@IBMUS
cc:=20    "ips@ece. cmu. edu \(E-mail\)"=20 <ips@ece.cmu.edu>
Subject:    RE: FW: = iSCSI:=20 "conservative reuse" requirement



Marjorie,

If an=20 "initiator/target portal group" concept is
"the=20 collection of IP addresses which can be combined to create a=20 single
iSCSI session."
why isn't it defined = as such in=20 the draft?

IMO, it=20 would have been better to define ISID/TSID in simple=20 networking
terms
like=20 {TCP/IP address + Name} instead of coming up with network=20 entity,
network portal
and portal group=20 terminology.

Amir


-----Original=20 Message-----
From:=20 owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf=20 Of
Eddy Quicksall
Sent: Monday, December 31, = 2001 2:15=20 PM
To: KRUEGER,MARJORIE (HP-Roseville,ex1); Jim=20 Hafner
Cc: ips@ece. cmu. edu = (E-mail)
Subject: RE: FW:=20 iSCSI: "conservative reuse" requirement


Marjorie,

If "an=20 initiator portal group is the same concept as the target=20 portal
group",=20 then it must be equivalent to the SCSI Initiator Port (because=20 we
have said that the SCSI Target Port maps to an iSCSI = Target=20 Portal Group).

Comments?

Eddy

-----Original=20 Message-----
From:=20 KRUEGER,MARJORIE (HP-Roseville,ex1)=20 [mailto:marjorie_krueger@hp.com]
Sent: Monday, December = 31, 2001=20 4:48 PM
To: 'Eddy Quicksall'; Jim Hafner
Cc: = ips@ece.=20 cmu. edu (E-mail)
Subject: RE: FW: iSCSI: "conservative = reuse"=20 requirement

Your=20 assumption of what is meant by an initiator portal group is=20 incorrect
(I=20 don't think it's implied that IPG =3D IP???)  An initiator = portal group=20 is
the same concept as a target portal group - it's the = collection=20 of IP
addresses which can be combined to create a single = iSCSI=20 session.
Frequently this is thought of as an iSCSI HBA, = but that=20 is not necessarily
so, it could be a number of iSCSI = HBAs,=20 etc.

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

>=20 -----Original Message-----
>=20 From: Eddy Quicksall = [mailto:Eddy_Quicksall@ivivity.com]
>=20 Sent: Monday, December 31, 2001 10:39 AM
> To: Jim=20 Hafner
> Cc: ips@ece. cmu. edu = (E-mail)
>=20 Subject: RE: FW: iSCSI: "conservative reuse"=20 requirement
>
>
> = Regarding=20 answer 2 below:
> There is no given definition for an = iSCSI=20 Initiator Portal Group
(however,
> it is = implied to=20 be the same as the endpoint in 9.1.1, which would be = the
> same=20 as the SCSI Initiator Port). Since an iSCSI Initiator Portal=20 Group
is
> the same as a SCSI Initiator = Port and=20 since an iSCSI Target Portal Group
is
> = the same as=20 a SCSI Target Port, then each session in answer number=20 2
would
> not have a "different SCSI = initiator=20 port"; hence you would have a
parallel
>=20 nexus.
> One thing that is not clear in section 9.1.1 = (however,=20 it is loosely
> implied) is that the reuse of ISID's = applies to=20 a given initiator
endpoint
> (SCSI = Initiator Port=20 or what should be called an iSCSI Initiator Portal
> = Group)). I=20 think that should be made clear.
> What am I missing? = Could it=20 be that an iSCSI Initiator Portal Group = is
not
>=20 equivalent to a SCSI Target Port?
>
>=20 Eddy
>
> -----Original=20 Message-----
> From: Jim Hafner=20 [mailto:hafner@almaden.ibm.com]
> Sent: Saturday, = December 29,=20 2001 6:14 PM
> To: Eddy Quicksall
> Cc: = ips
> Subject: RE: FW: iSCSI: "conservative reuse"=20 requirement
>
>
>=20 Eddy,
>
> The SCSI initiator port is = modeled as=20 the endpoint of the
> iSCSI session;
> = the SCSI=20 target port is modeled as the iSCSI target portal group.=20  The
> reason we did it this way was to allow = more than=20 one session
> between portal
> groups = by=20 allowing multi-plexing of sessions with different
> = ISIDs from=20 the
> same iSCSI initiator portal group to the same = target=20 portal group.
>
> So, the answer to = your=20 questions are:
> 1) no, we're assuming no more than on = session=20 *with the same
> ISID* to the
> same = target=20 portal group (that'd be more than one nexus), but
> by = allowing
> different ISIDs we get different SCSI = initiator=20 ports.
> 2) no, we're allowing more than one session = between an=20 iSCSI initiator
> portal group and an iSCSI target = portal group=20 (each session
> has a different
> SCSI = initiator=20 port (id'ed by its ISID) but the same SCSI target = port
> (id'ed=20 by its portal group tag).
> 3) sort of, the ISID = together with=20 the iSCSI Initiator Name fully
> identifies the SCSI = initiator=20 port (and so defines the SCSI
> initiator = port
>=20 name and the identifier).
>
> Does that = clear=20 this up?
>
> Jim=20 Hafner
>
>
> "Eddy = Quicksall"=20 <Eddy_Quicksall@iVivity.com> on 12/28/2001
> = 07:19:33=20 PM
>
> To:   Jim=20 Hafner/Almaden/IBM@IBMUS
> cc:   "ips@ece. cmu. = edu=20 \(E-mail\)" <ips@ece.cmu.edu>
> Subject: =  RE: FW:=20 iSCSI: "conservative reuse"=20 = requirement
>
>
>
<= TT>>=20 Due to 2.5.3 (b) "Between a given SCSI initiator port and SCSI=20 target
> port, there can be only one I_T nexus = (session)",=20 aren't we always
> "assuming no more than one=20 session"?
>
> Or are you talking about = more than=20 one session between different SCSI
> initiator ports = and a=20 single SCSI target port?
>
> Is the = ISID=20 equivalent to SAM-2's Initiator Port=20 Identifier?
>
>
>=20 Eddy
>
> -----Original=20 Message-----
> From: Jim Hafner=20 [mailto:hafner@almaden.ibm.com]
> Sent: Friday, = December 28,=20 2001 12:15 PM
> To: John Hufferd; Eddy Quicksall; = Mallikarjun=20 C.; Black_David@emc.com
> Cc: = ips@ece.cmu.edu
>=20 Subject: Re: FW: iSCSI: "conservative reuse"=20 requirement
>
>
>=20 Folks,
>
> Sorry for taking so long to = jump into=20 this discussion.
>
> There are a number = of=20 issues raised in this thread:
> 1) should = "conservative reuse"=20 of ISIDs be made a MUST
> 2) does "conservative reuse" = imply=20 that all hosts look "single SCSI
>=20 ported"
>
> Here's my two cents (using = "CR" as a=20 shorthand for "conservative
>=20 reuse")
>
> I don't believe that CR = needs to be=20 a MUST.  The only time this has
> = any
>=20 real value is in configurations that use SCSI persistent=20 reservations
> (and
> where new SCSI = target=20 reservation features are enabled -- NB.  these
> = features=20 are yet to be approved but are working their way through = the
>=20 process). I don't think these are going to be (even in the future)=20 the
> majority of installations.  There are many = ways then=20 that CR could be
> something that is not generally = available in=20 most drivers but is added
> by
> = configuration=20 and perhaps even "value add" = (:-{)).
>
> In=20 short, I don't see a strong case for this to be a MUST.  So,=20 to
> David
> Black, my answer is that = having a=20 mechanism to enable this feature or
> = have
> it=20 as a "purchase requirement" is an acceptable mechanism to make=20 sure
> the
> feature is there when = needed, but=20 it is need not be a requirement of
> = the
>=20 protocol.  To Mallikarjun, I think I'm agreeing with you that so = long
> as
> there is a mechanism = defined, iSCSI=20 has done it's job.
>
> As for the = second issue=20 (raised by Mallikarjun), let's look at the
> = definition of CR.=20  What is means is that when an iSCSI initiator
>=20 (node)
> creates ISIDs for use in session identifiers, = it=20 attempts to reuse
> them
> = as
>=20 much as possible with different SCSI target ports (iSCSI target=20 portal
> groups).  This is the only way that a = SCSI target=20 or LU can see the
> same
> SCSI = initiator port=20 through two or more of its SCSI target ports --
>=20 that
> is, that the target can determine multiple = paths *from*=20 the same SCSI
> initiator port.   But, the model = for=20 generating ISIDs is not really at
> = the
> node=20 level but at the initiator portal group level.
> So, = IMO, the=20 conclusion that all hosts must then look "single = SCSI
>=20 ported"
> is too dramatic.  As I mentioned, =  ISIDs=20 are conceptually generated
> within
> = initiator=20 portal groups (that's why we defined the mechanism = for
>=20 generating
> ISIDs).  The conclusion I draw is = that=20 (assuming no more than one
> session
> = to any=20 given target portal group), an iSCSI initiator implementing=20 CR
> will
> have as many SCSI initiator = ports as=20 iSCSI initiator portal groups
> (independent HBAs?). =  Each=20 initiator portal group would generate one
>=20 ISID
> (that is different from that generated by/for = the other=20 initiator
> portal
> groups) and use CR = for=20 repeatability.  [This is consistent with a
>=20 model
> that mapped SCSI initiator ports to initiator = portal=20 groups, which we
> had
> to abandon = because the=20 "assuming no more than one session..." was no
> = acceptable as a=20 requirement!!!]  This independence of ISIDs for = each
>=20 initiator portal group allows each initiator portal group to=20 open
> sessions
> with *every* target = portal=20 group it knows about without having to
> = worry
>=20 about interfering with other sessions. [This has shades of=20 the
> "partitioning" rule for ISIDs that has been = discussed ad=20 nauseum!!!]
>
> (I have a feeling that = this note=20 is not well composed -- it is the
> holidays, you = know).=20  I hope I've addressed everyone's concerns and = we
>=20 can
> lay this one to = rest.
>
>=20 Jim Hafner
>
>
> John=20 Hufferd
> 12/25/2001 08:49 = AM
>
>=20 To:   "Eddy Quicksall"=20 <Eddy_Quicksall@iVivity.com>
> cc:   Jim=20 Hafner/Almaden/IBM@IBMUS
> From: John Hufferd/San=20 Jose/IBM@IBMUS
> Subject:  Re: FW: iSCSI: = "conservative=20 reuse" requirement  (Document
> = link:
>=20       Jim Hafner)
>
> = You are=20 correct.  The section was created by Jim Hafner, and via=20 this
> note
> I will ask him if he = could answer=20 Mallikarjun Directly since I did not
> understand his=20 issue.
>
> .
> = .
>=20 .
> John L. Hufferd
> Senior Technical = Staff=20 Member (STSM)
> IBM/SSG San Jose Ca
> = Main=20 Office (408) 256-0403, Tie: 276-0403,  eFax: (408)=20 904-4688
> Home Office (408) 997-6136, Cell: (408)=20 499-9702
> Internet address:=20 hufferd@us.ibm.com
>
>
> = "Eddy=20 Quicksall" <Eddy_Quicksall@iVivity.com> on 12/24/2001=20 06:06:44
> PM
>
> To: =   John=20 Hufferd/San Jose/IBM@IBMUS
> cc:
> = Subject:=20  FW: iSCSI: "conservative reuse"=20 = requirement
>
>
>
<= TT>>=20 John,
>
> Were you the author of = "conservative=20 reuse"? I am wondering about some
> issues. Maybe you = could=20 educate me somewhat ...
>
> I started = this=20 subject in a different thread by saying that it may = be
> good=20 to make "conservative reuse" a = MUST.
>
> I got=20 one objection from Santosh below. Then David Black picked it=20 up
> by basically agreeing with me. Then Mallikarjun = objected=20 to that.
>
> It seems like the = objective would=20 be to give targets a way to figure
> out that two or = more=20 sessions are coming from the same Initiator Port.
> = That is=20 needed support persistent = reservations.
>
> If=20 an initiator does not use "conservative reuse", I don't = think
>=20 targets will be able to make that=20 determination.
>
>=20 Comments?
>
>=20 Eddy
>
> -----Original=20 Message-----
> From: Mallikarjun C.=20 [mailto:cbm@rose.hp.com]
> Sent: Monday, December 24, = 2001=20 12:47 AM
> To: Black_David@emc.com
> = Cc:=20 ips@ece.cmu.edu
> Subject: Re: iSCSI: "conservative = reuse"=20 requirement
>
> > I think this is = headed=20 towards "conservative reuse" being a MUST if
> > = we're=20 serious about support for shared persistent=20 reservations.
>
> Mandating = "conservative reuse"=20 appears to force initiators to always
> = act
> as=20 a single initiator port (wrt one target; assuming only one=20 session
> as
> an
> = example) per=20 initiator device - which rules out the case of an
>=20 initiator
>
> intentionally wanting to = present a=20 different port to each target
> = portal
>=20 group.
>
> IMHO, if iSCSI provides an=20 architected mechanism to support shared
> persistent=20 reservations ("conservative reuse"),  that should = be
>=20 completely
> adequate to meet the expectations to be a = legal=20 SCSI protocol.
> --
>=20 Mallikarjun
>
> Mallikarjun=20 Chadalapaka
> Networked Storage = Architecture
>=20 Network Storage Solutions Organization
> = Hewlett-Packard MS=20 5668
> Roseville CA = 95747
>
>=20 ----- Original Message -----
> From:=20 <Black_David@emc.com>
> To:=20 <santoshr@cup.hp.com>
> Cc:=20 <ips@ece.cmu.edu>
> Sent: Friday, December 21, = 2001 4:50=20 PM
> Subject: iSCSI: "conservative reuse"=20 requirement
>
>
> > = Santosh=20 Rao writes:
> >
> > > I am = opposed to=20 the suggestion that "conservative re-use" of ISIDs
>=20 be
> > > made a MUST. This is really only = required when=20 initiators need to
> be
> > > = using the=20 new T10 Reservation scheme that can be shared
> > = >=20 across initiator ports.
> >
> > = Those=20 reservations are a Target feature.  With this approach,=20 the
> ability
> > to use the target = feature=20 depends on details of the initiator
> >=20 implementation.
> > More below ...
> = >
> > > For those initiators that don't care = about=20 this type of
> reservation,
> > > = conservative re-use is of no use and initiators may like to=20 assign
> > > ISID's in a per-initiator node = fashion,=20 thereby, being able to use
> these
> = > >=20 ISIDs as a lookup index for the sessions on that initiator=20 node.
> > >
> > > Hence, I = suggest=20 that "conservative re-use" be worded as
> > > = "encouraged=20 to use" or something to that effect, but not MUST = USE.
> >=20 >
> > > Comments ?
>=20 >
> > The "initiator" is more than one entity. =  The=20 iSCSI HBA/NIC and
> driver
> > = doesn't know=20 whether shared persistent reservations are being = used
>=20 and
> > shouldn't have to care - they're just more = SCSI=20 commands to
> transport.
> > Some = other=20 entity (e.g., clustering software) will be generating = the
>=20 > shared persistent reservations.  This raise the possible=20 scenario
> > involving a target that supports the = new shared=20 persistent
> reservations
> > and an = entity=20 that wants to use them.  The entity detects (via = SCSI
>=20 means,
> >=20 e.g., something in a mode page) that the Target supports=20 shared
>=20 persistent
> > reservations, tries to use them, = only to=20 discover that they don't
> work
> > = because=20 the iSCSI HBA/NIC doesn't implement "conservative = reuse".
>=20 >
> > I'm worried about this causing both=20 interoperability issues and
> = possible
> >=20 T10 issues -- from a T10 viewpoint, if shared = persistent
>=20 reservations
> > don't work, the initiating entity = should=20 have some SCSI-level means
> > of determining this = ... if=20 that means exists only on the Target, the
> > above = scenario=20 is iSCSI's problem (Target can't query Initiator to
> = >=20 determine whether it does "conservative reuse"), and having = a
>=20 separate
> > initiator side means that the entity = has to=20 check only for iSCSI
> (and
> > not = for any=20 other SCSI transport) does not seem like the right
> = >=20 approach.
> >
> > I think this is = headed=20 towards "conservative reuse" being a MUST if
> > = we're=20 serious about support for shared persistent = reservations.
>=20 >
> > Comments?
> >=20 --David
> >=20 ---------------------------------------------------
> = >=20 David L. Black, Senior Technologist
> > EMC = Corporation, 42=20 South St., Hopkinton, MA  01748
> > +1 (508) = 249-6449=20 *NEW*      FAX: +1 (508) 497-8500
> = >=20 black_david@emc.com         Cell: +1 (978)=20 394-7754
> >=20 ---------------------------------------------------
>=20 >
>=20 = >
>
>
>
<= /FONT>

------_=_NextPart_001_01C193C5.540245C0-- From owner-ips@ece.cmu.edu Wed Jan 2 16:55: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 QAA11728 for ; Wed, 2 Jan 2002 16:55:15 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g02L7tH01001 for ips-outgoing; Wed, 2 Jan 2002 16:07:55 -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 g02L7rg00996 for ; Wed, 2 Jan 2002 16:07:53 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel11.hp.com (Postfix) with ESMTP id 4C8E3E00467; Wed, 2 Jan 2002 13:07:47 -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 NAA10303; Wed, 2 Jan 2002 13:09:20 -0800 (PST) Message-Id: <200201022109.NAA10303@core.rose.hp.com> Date: Wed, 02 Jan 2002 13:21:13 -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: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: "conservative reuse" requirement References: <277DD60FB639D511AC0400B0D068B71E029372C8@CORPMX14> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Now that I'm back from vacation, let me offer some (delayed) comments on this. I also read Jim's reply where he appeared to mostly agree with me. >...as long as it presented > each of them to all target ports... I disagree with your assumption that an initiator must "present" *all* its ports to every target port in a target device. Each distinct initiator port (signified by a unique ISID) may want to talk to only one target port (i.e. one portal group) - that's a typical usage of multi-HBA (i.e. multi-port) hosts talking to multi-FC port targets today. As far as I can understand, a mandatory "conservative reuse" would preclude this usage. Please comment if your visualization of conservative reuse is different. OTOH, I can see that the ability of *one* initiator SCSI port to establish nexii with multiple target SCSI ports in a target device is highly desirable (perhaps even T10-required shortly). IMO, iSCSI had already met this need by defining and enabling "conservative reuse", and that's where we should stop. I would actually advocate wording along the lines of - "When a given initiator implementation seeks to present a single SCSI port abstraction to multiple target portal groups (thus multiple SCSI target ports) of an iSCSI target node, conservative reuse is the means to realize it. Conservative reuse hence MUST be used in this case." and leave it at that. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Black_David@emc.com wrote: > > Not exactly. "Conservative Reuse" would allow an initiator > to present multiple initiator ports, as long as it presented > each of them to all target ports (assuming that the connectivity > exists). Why would an Initiator want to present different > ports to different target portal groups? I don't think there's > another example in which SCSI behaves this way in practice. > > --David > > > -----Original Message----- > > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > > Sent: Monday, December 24, 2001 12:47 AM > > To: Black_David@emc.com > > Cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: "conservative reuse" requirement > > > > > > > I think this is headed towards "conservative reuse" being a MUST if > > > we're serious about support for shared persistent reservations. > > > > Mandating "conservative reuse" appears to force initiators to > > always act > > as a single initiator port (wrt one target; assuming only one > > session as an > > example) per initiator device - which rules out the case of > > an initiator > > intentionally wanting to present a different port to each > > target portal group. > > > > IMHO, if iSCSI provides an architected mechanism to support shared > > persistent reservations ("conservative reuse"), that should > > be completely > > adequate to meet the expectations to be a legal SCSI protocol. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > > > > ----- Original Message ----- > > From: > > To: > > Cc: > > Sent: Friday, December 21, 2001 4:50 PM > > Subject: iSCSI: "conservative reuse" requirement > > > > > > > Santosh Rao writes: > > > > > > > I am opposed to the suggestion that "conservative re-use" > > of ISIDs be > > > > made a MUST. This is really only required when initiators > > need to be > > > > using the new T10 Reservation scheme that can be shared > > > > across initiator ports. > > > > > > Those reservations are a Target feature. With this > > approach, the ability > > > to use the target feature depends on details of the initiator > > > implementation. > > > More below ... > > > > > > > For those initiators that don't care about this type of > > reservation, > > > > conservative re-use is of no use and initiators may like to assign > > > > ISID's in a per-initiator node fashion, thereby, being > > able to use these > > > > ISIDs as a lookup index for the sessions on that initiator node. > > > > > > > > Hence, I suggest that "conservative re-use" be worded as > > > > "encouraged to use" or something to that effect, but not MUST USE. > > > > > > > > Comments ? > > > > > > The "initiator" is more than one entity. The iSCSI HBA/NIC > > and driver > > > doesn't know whether shared persistent reservations are > > being used and > > > shouldn't have to care - they're just more SCSI commands to > > transport. > > > Some other entity (e.g., clustering software) will be generating the > > > shared persistent reservations. This raise the possible scenario > > > involving a target that supports the new shared persistent > > reservations > > > and an entity that wants to use them. The entity detects > > (via SCSI means, > > > e.g., something in a mode page) that the Target supports > > shared persistent > > > reservations, tries to use them, only to discover that they > > don't work > > > because the iSCSI HBA/NIC doesn't implement "conservative reuse". > > > > > > I'm worried about this causing both interoperability issues > > and possible > > > T10 issues -- from a T10 viewpoint, if shared persistent > > reservations > > > don't work, the initiating entity should have some SCSI-level means > > > of determining this ... if that means exists only on the Target, the > > > above scenario is iSCSI's problem (Target can't query Initiator to > > > determine whether it does "conservative reuse"), and having > > a separate > > > initiator side means that the entity has to check only for > > iSCSI (and > > > not for any other SCSI transport) does not seem like the right > > > approach. > > > > > > I think this is headed towards "conservative reuse" being a MUST if > > > we're serious about support for shared persistent reservations. > > > > > > Comments? > > > --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 Jan 2 17:53: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 RAA12534 for ; Wed, 2 Jan 2002 17:53:03 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g02M9W904441 for ips-outgoing; Wed, 2 Jan 2002 17:09:32 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g02M9Tg04432 for ; Wed, 2 Jan 2002 17:09:29 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Jan 2002 17:09:23 -0500 Message-ID: <25369470B6F0D41194820002B328BDD22022BB@ATLOPS> From: Eddy Quicksall To: cbm@rose.hp.com, Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: "conservative reuse" requirement Date: Wed, 2 Jan 2002 17:09:23 -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's not the way I understand "conservative reuse". I understand it as saying that the endpoint at the initiator should use the same ISID when it is talking to different iSCSI Target Portal Groups. This is basic to SCSI Initiator Ports as they have Initiator Port Identifiers that serve the same purpose (technically the Initiator Port Identifier is the iSCSI InitiatorName+ISID but on a given initiator, you can factor out the InitiatorName). Eddy -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com] Sent: Wednesday, January 02, 2002 4:21 PM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: "conservative reuse" requirement Now that I'm back from vacation, let me offer some (delayed) comments on this. I also read Jim's reply where he appeared to mostly agree with me. >...as long as it presented > each of them to all target ports... I disagree with your assumption that an initiator must "present" *all* its ports to every target port in a target device. Each distinct initiator port (signified by a unique ISID) may want to talk to only one target port (i.e. one portal group) - that's a typical usage of multi-HBA (i.e. multi-port) hosts talking to multi-FC port targets today. As far as I can understand, a mandatory "conservative reuse" would preclude this usage. Please comment if your visualization of conservative reuse is different. OTOH, I can see that the ability of *one* initiator SCSI port to establish nexii with multiple target SCSI ports in a target device is highly desirable (perhaps even T10-required shortly). IMO, iSCSI had already met this need by defining and enabling "conservative reuse", and that's where we should stop. I would actually advocate wording along the lines of - "When a given initiator implementation seeks to present a single SCSI port abstraction to multiple target portal groups (thus multiple SCSI target ports) of an iSCSI target node, conservative reuse is the means to realize it. Conservative reuse hence MUST be used in this case." and leave it at that. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Black_David@emc.com wrote: > > Not exactly. "Conservative Reuse" would allow an initiator > to present multiple initiator ports, as long as it presented > each of them to all target ports (assuming that the connectivity > exists). Why would an Initiator want to present different > ports to different target portal groups? I don't think there's > another example in which SCSI behaves this way in practice. > > --David > > > -----Original Message----- > > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > > Sent: Monday, December 24, 2001 12:47 AM > > To: Black_David@emc.com > > Cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: "conservative reuse" requirement > > > > > > > I think this is headed towards "conservative reuse" being a MUST if > > > we're serious about support for shared persistent reservations. > > > > Mandating "conservative reuse" appears to force initiators to > > always act > > as a single initiator port (wrt one target; assuming only one > > session as an > > example) per initiator device - which rules out the case of > > an initiator > > intentionally wanting to present a different port to each > > target portal group. > > > > IMHO, if iSCSI provides an architected mechanism to support shared > > persistent reservations ("conservative reuse"), that should > > be completely > > adequate to meet the expectations to be a legal SCSI protocol. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > > > > ----- Original Message ----- > > From: > > To: > > Cc: > > Sent: Friday, December 21, 2001 4:50 PM > > Subject: iSCSI: "conservative reuse" requirement > > > > > > > Santosh Rao writes: > > > > > > > I am opposed to the suggestion that "conservative re-use" > > of ISIDs be > > > > made a MUST. This is really only required when initiators > > need to be > > > > using the new T10 Reservation scheme that can be shared > > > > across initiator ports. > > > > > > Those reservations are a Target feature. With this > > approach, the ability > > > to use the target feature depends on details of the initiator > > > implementation. > > > More below ... > > > > > > > For those initiators that don't care about this type of > > reservation, > > > > conservative re-use is of no use and initiators may like to assign > > > > ISID's in a per-initiator node fashion, thereby, being > > able to use these > > > > ISIDs as a lookup index for the sessions on that initiator node. > > > > > > > > Hence, I suggest that "conservative re-use" be worded as > > > > "encouraged to use" or something to that effect, but not MUST USE. > > > > > > > > Comments ? > > > > > > The "initiator" is more than one entity. The iSCSI HBA/NIC > > and driver > > > doesn't know whether shared persistent reservations are > > being used and > > > shouldn't have to care - they're just more SCSI commands to > > transport. > > > Some other entity (e.g., clustering software) will be generating the > > > shared persistent reservations. This raise the possible scenario > > > involving a target that supports the new shared persistent > > reservations > > > and an entity that wants to use them. The entity detects > > (via SCSI means, > > > e.g., something in a mode page) that the Target supports > > shared persistent > > > reservations, tries to use them, only to discover that they > > don't work > > > because the iSCSI HBA/NIC doesn't implement "conservative reuse". > > > > > > I'm worried about this causing both interoperability issues > > and possible > > > T10 issues -- from a T10 viewpoint, if shared persistent > > reservations > > > don't work, the initiating entity should have some SCSI-level means > > > of determining this ... if that means exists only on the Target, the > > > above scenario is iSCSI's problem (Target can't query Initiator to > > > determine whether it does "conservative reuse"), and having > > a separate > > > initiator side means that the entity has to check only for > > iSCSI (and > > > not for any other SCSI transport) does not seem like the right > > > approach. > > > > > > I think this is headed towards "conservative reuse" being a MUST if > > > we're serious about support for shared persistent reservations. > > > > > > Comments? > > > --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 Jan 2 19:04: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 TAA13151 for ; Wed, 2 Jan 2002 19:04:40 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g02NMbx08373 for ips-outgoing; Wed, 2 Jan 2002 18:22:37 -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 g02NMVg08365 for ; Wed, 2 Jan 2002 18:22:31 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Jan 2002 18:22:26 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029372DC@CORPMX14> From: Black_David@emc.com To: nitin.dhingra@dcmtech.co.in, ips@ece.cmu.edu Subject: RE: iScsi: Date: Wed, 2 Jan 2002 18:10: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 I don't understand this - what exactly is broken that you think needs to be fixed? Many SCSI targets do implement access controls at the logical unit level, which is in T10's domain, not iSCSI's. --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: Nitin Dhingra [mailto:nitin.dhingra@dcmtech.co.in] > Sent: Wednesday, January 02, 2002 12:40 AM > To: ips@ece.cmu.edu > Subject: iScsi: > > > Why don't you put a restriction on the read/write access to a target? > This can solve some of the synchronization problems that can occur... > > And Yeah Happy New Year to All... > > - Nitin > From owner-ips@ece.cmu.edu Wed Jan 2 19:06: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 TAA13164 for ; Wed, 2 Jan 2002 19:06:12 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g02NvXt10084 for ips-outgoing; Wed, 2 Jan 2002 18:57:33 -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.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g02NvVg10078 for ; Wed, 2 Jan 2002 18:57:31 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Jan 2002 18:52:55 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029372DD@CORPMX14> From: Black_David@emc.com To: cbm@rose.hp.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: "conservative reuse" requirement Date: Wed, 2 Jan 2002 18:45: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 This topic is not exactly amenable to short summaries ... > I disagree with your assumption that an initiator must > "present" *all* its ports to every target port in a target > device. Each distinct initiator port (signified by a unique > ISID) may want to talk to only one target port (i.e. one portal > group) - that's a typical usage of multi-HBA (i.e. multi-port) > hosts talking to multi-FC port targets today. As far as I > can understand, a mandatory "conservative reuse" would > preclude this usage. Please comment if your visualization > of conservative reuse is different. The concern I have is based on the source of the connectivity constraints. To begin with, I disagree with the notion that a FC imitator port "may want to talk to only one target port"; Fibre Channel does not work that way because the connectivity constraints are imposed externally to the ports. For the case of an m-way HBA host talking to a n-way FC port target, "conservative reuse" is attempted by the HBAs (each port has exactly one WWN), and if less than the full m x n set of connections results, it is due to an external absence of connectivity - either each HBA port is connected to one target FC port, or the fabric(s) involved are zoned in a fashion that this is the resulting logical connectivity. In both cases, an HBA following the rules connects to everything that it is allowed to connect to. I have no problem with external physical or logical (e.g., VLAN, or even iSNS) connectivity constraints preventing all possible connections between a multi-port initiator and a multi-port target. What I have a problem with is an implementation making an internal decision that it will *never*: present a single SCSI port abstraction to multiple target portal groups (thus multiple SCSI target ports) of an iSCSI target node, no matter what its administrators and users may want. IMHO, that's not the implementation's decision to make - it needs to be made externally by the administrator who configures the system. In particular, if an implementation is operating over a single IP interface, there has been discussion on this list of using a different ISID for every target portal group that it connects to - shared persistent reservations will never work right if that is done, and there is nothing that the administrator can do in that situation to get them to work ... I think this needs to be prohibited if we're serious about following T10's direction on persistent shared reservations, unless T10 is going to provide a way to query the initiator to discover that it does not support shared persistent reservations. So, I would allow the scenario of interest (each Initiator port connects to only one Target port), but only in the fashion currently found in other SCSI transports where every possible connection is attempted, and the reasons that not every connection is established are external (and configurable, modulo physical constraints). The crucial aspect of this is that if "conservative reuse" does not happen (breaking shared persistent reservations), the reason that it does not happen MUST be externally configurable as opposed to being an unchangeable internal characteristic of the implementation. With luck, this makes a little more sense. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Wednesday, January 02, 2002 4:21 PM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: "conservative reuse" requirement > > > Now that I'm back from vacation, let me offer some (delayed) > comments on this. I also read Jim's reply where he appeared > to mostly agree with me. > > >...as long as it presented > > each of them to all target ports... > > I disagree with your assumption that an initiator must > "present" *all* its ports to every target port in a target > device. Each distinct initiator port (signified by a unique > ISID) may want to talk to only one target port (i.e. one portal > group) - that's a typical usage of multi-HBA (i.e. multi-port) > hosts talking to multi-FC port targets today. As far as I > can understand, a mandatory "conservative reuse" would > preclude this usage. Please comment if your visualization > of conservative reuse is different. > > OTOH, I can see that the ability of *one* initiator SCSI > port to establish nexii with multiple target SCSI ports in > a target device is highly desirable (perhaps even T10-required > shortly). IMO, iSCSI had already met this need by defining > and enabling "conservative reuse", and that's where we should > stop. I would actually advocate wording along the lines of - > > "When a given initiator implementation seeks to present > a single SCSI port abstraction to multiple target portal > groups (thus multiple SCSI target ports) of an iSCSI target > node, conservative reuse is the means to realize it. > Conservative reuse hence MUST be used in this case." > > and leave it at that. > -- > Mallikarjun > > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > > Black_David@emc.com wrote: > > > > Not exactly. "Conservative Reuse" would allow an initiator > > to present multiple initiator ports, as long as it presented > > each of them to all target ports (assuming that the connectivity > > exists). Why would an Initiator want to present different > > ports to different target portal groups? I don't think there's > > another example in which SCSI behaves this way in practice. > > > > --David > > > > > -----Original Message----- > > > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > > > Sent: Monday, December 24, 2001 12:47 AM > > > To: Black_David@emc.com > > > Cc: ips@ece.cmu.edu > > > Subject: Re: iSCSI: "conservative reuse" requirement > > > > > > > > > > I think this is headed towards "conservative reuse" > being a MUST if > > > > we're serious about support for shared persistent reservations. > > > > > > Mandating "conservative reuse" appears to force initiators to > > > always act > > > as a single initiator port (wrt one target; assuming only one > > > session as an > > > example) per initiator device - which rules out the case of > > > an initiator > > > intentionally wanting to present a different port to each > > > target portal group. > > > > > > IMHO, if iSCSI provides an architected mechanism to support shared > > > persistent reservations ("conservative reuse"), that should > > > be completely > > > adequate to meet the expectations to be a legal SCSI protocol. > > > -- > > > Mallikarjun > > > > > > Mallikarjun Chadalapaka > > > Networked Storage Architecture > > > Network Storage Solutions Organization > > > Hewlett-Packard MS 5668 > > > Roseville CA 95747 > > > > > > ----- Original Message ----- > > > From: > > > To: > > > Cc: > > > Sent: Friday, December 21, 2001 4:50 PM > > > Subject: iSCSI: "conservative reuse" requirement > > > > > > > > > > Santosh Rao writes: > > > > > > > > > I am opposed to the suggestion that "conservative re-use" > > > of ISIDs be > > > > > made a MUST. This is really only required when initiators > > > need to be > > > > > using the new T10 Reservation scheme that can be shared > > > > > across initiator ports. > > > > > > > > Those reservations are a Target feature. With this > > > approach, the ability > > > > to use the target feature depends on details of the initiator > > > > implementation. > > > > More below ... > > > > > > > > > For those initiators that don't care about this type of > > > reservation, > > > > > conservative re-use is of no use and initiators may > like to assign > > > > > ISID's in a per-initiator node fashion, thereby, being > > > able to use these > > > > > ISIDs as a lookup index for the sessions on that > initiator node. > > > > > > > > > > Hence, I suggest that "conservative re-use" be worded as > > > > > "encouraged to use" or something to that effect, but > not MUST USE. > > > > > > > > > > Comments ? > > > > > > > > The "initiator" is more than one entity. The iSCSI HBA/NIC > > > and driver > > > > doesn't know whether shared persistent reservations are > > > being used and > > > > shouldn't have to care - they're just more SCSI commands to > > > transport. > > > > Some other entity (e.g., clustering software) will be > generating the > > > > shared persistent reservations. This raise the > possible scenario > > > > involving a target that supports the new shared persistent > > > reservations > > > > and an entity that wants to use them. The entity detects > > > (via SCSI means, > > > > e.g., something in a mode page) that the Target supports > > > shared persistent > > > > reservations, tries to use them, only to discover that they > > > don't work > > > > because the iSCSI HBA/NIC doesn't implement > "conservative reuse". > > > > > > > > I'm worried about this causing both interoperability issues > > > and possible > > > > T10 issues -- from a T10 viewpoint, if shared persistent > > > reservations > > > > don't work, the initiating entity should have some > SCSI-level means > > > > of determining this ... if that means exists only on > the Target, the > > > > above scenario is iSCSI's problem (Target can't query > Initiator to > > > > determine whether it does "conservative reuse"), and having > > > a separate > > > > initiator side means that the entity has to check only for > > > iSCSI (and > > > > not for any other SCSI transport) does not seem like the right > > > > approach. > > > > > > > > I think this is headed towards "conservative reuse" > being a MUST if > > > > we're serious about support for shared persistent reservations. > > > > > > > > Comments? > > > > --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 Jan 2 19:59: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 TAA13538 for ; Wed, 2 Jan 2002 19:59:16 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g030IMx11028 for ips-outgoing; Wed, 2 Jan 2002 19:18:22 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from HQMAILNODE1.COMMSTOR.Crossroads.com (65-68-235-67.crossroads.com [65.68.235.67] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g030IKg11024 for ; Wed, 2 Jan 2002 19:18:20 -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: data-out initiator transfer tags Date: Wed, 2 Jan 2002 18:18:19 -0600 Message-ID: Thread-Topic: iSCSI: data-out initiator transfer tags Thread-Index: AcGT7CMIvlgHIv/YEdWG0QDQt11lDQ== From: "Buck Landry" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g030ILg11025 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Is it required that the initiator transfer tag (ITT) for a data-out pdu be identical to the ITT of the scsi command pdu it is associated with? I would assume so for consistency's sake, but have seen implementations that assumed the target would use the data-out pdu's target transfer tag to look up the associated command. Thanks, Buck From owner-ips@ece.cmu.edu Wed Jan 2 20:42: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 UAA13901 for ; Wed, 2 Jan 2002 20:42:02 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g030wuO12847 for ips-outgoing; Wed, 2 Jan 2002 19:58:56 -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 g030wng12840 for ; Wed, 2 Jan 2002 19:58:54 -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 TAA81880; Wed, 2 Jan 2002 19:55:37 -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 g030wYh21746; Wed, 2 Jan 2002 17:58:34 -0700 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: "conservative reuse" requirement To: cbm@rose.hp.com Cc: Black_David@emc.com, ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Wed, 2 Jan 2002 16:57:49 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 01/02/2002 05:58:33 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mallikarjun, Comments in line between [Huff/] and [\Huff]. . . . 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 "Mallikarjun C." @ece.cmu.edu on 01/02/2002 01:21:13 PM Please respond to cbm@rose.hp.com Sent by: owner-ips@ece.cmu.edu To: Black_David@emc.com cc: ips@ece.cmu.edu Subject: Re: iSCSI: "conservative reuse" requirement Now that I'm back from vacation, let me offer some (delayed) comments on this. I also read Jim's reply where he appeared to mostly agree with me. >...as long as it presented > each of them to all target ports... I disagree with your assumption that an initiator must "present" *all* its ports to every target port in a target device. Each distinct initiator port (signified by a unique ISID) may want to talk to only one target port (i.e. one portal group) - that's a typical usage of multi-HBA (i.e. multi-port) hosts talking to multi-FC port targets today. As far as I can understand, a mandatory "conservative reuse" would preclude this usage. Please comment if your visualization of conservative reuse is different. [Huff/] We have now fallen into the problem that Jim, Julian, Marjorie, and I spent the Holidays exchanging e-Mails about. You use the term Initiator to represent the Total Initiator Node (and indeed our draft definitions encourage that view). However, some others, when they talk, use the SCSI interpretation of the word Initiator, which is the SCSI Initiator Port. So as Marjorie has clearly pointed out to me, I need to be more precise, and I think the rest of us also. We need to fully qualify the term Initiator when we use it, in these types of discussions. We need to say iSCSI Initiator Node, or SCSI Initiator Port etc. So let me try that below, in hopes of perhaps clearing up some concepts. The use of Conservative Reuse applies to the how the Name of the SCSI Initiator Port will be chosen. The Name of the SCSI Initiator Port is made up of the iSCSI Initiator Node Name and the ISID. We are attempting to ensure that any one SCSI Initiator Port will not pick various different ISIDs in a manner that will prevent the Persistent Reserves from being reestablished across a Session Restart. To do that we strongly suggest that the Vendor follow the Type and Vendor ID approach to creating and ISID as specified in version 9 of the Draft. Also they should pick the 16 bit Qualifier part in a way that will usually be the same number each time a Session from that SCSI Initiator Port is restarted. The easiest way to do this is for the iSCSI Process to Identify the SCSI Initiator Port with the same ISID Qualifier every time an iSCSI Session is started with any SCSI Target Port (via its iSCSI Target Portal Group). When this is done, everything works. This is called Conservative Reuse since when we start/restart a session we are not choosing a different ISID. Please note I did not restrict the actions of any other SCSI Initiator Port within the iSCSI Initiator Node. They can each have their own ISID and use the iSCSI Transport to connect to what ever SCSI Target Nodes they wish. If those other iSCSI Initiators have HBAs which have been made by the same vendor (and if that vendor does not support Multiple Connections per Session across the HBAs), it is the Vendors responsibility to chose an ISID Qualifier for its second (and subsequent) SCSI Initiator Port, which does not conflict with the first one. When done correctly, then if by chance, the second SCSI Initiator Port connects to the same SCSI Target Port to which the First one connected, they will each be seen, by the Target, as different Sessions from different SCSI Initiator Ports and things are completely legal. In this case, as it is in Fibre Channel, the Host (iSCSI Initiator Node) will have to be very careful how work is handed out to the different SCSI Initiator Ports, so that Work arrives in the correct order and there is no conflicts with Reserves. (The process that does that balancing between the HBAs is what, in Fibre Channel, we have called a Wedge Driver). So what I have said above, is that when we carefully qualify the Term Initiator, we can see that Conservative Reuse does NOT cause any restrictions on the way we use the Sessions within an iSCSI Initiator Node. [\Huff] OTOH, I can see that the ability of *one* initiator SCSI port to establish nexii with multiple target SCSI ports in a target device is highly desirable (perhaps even T10-required shortly). IMO, iSCSI had already met this need by defining and enabling "conservative reuse", and that's where we should stop. I would actually advocate wording along the lines of - "When a given initiator implementation seeks to present a single SCSI port abstraction to multiple target portal groups (thus multiple SCSI target ports) of an iSCSI target node, conservative reuse is the means to realize it. Conservative reuse hence MUST be used in this case." and leave it at that. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Black_David@emc.com wrote: > > Not exactly. "Conservative Reuse" would allow an initiator > to present multiple initiator ports, as long as it presented > each of them to all target ports (assuming that the connectivity > exists). Why would an Initiator want to present different > ports to different target portal groups? I don't think there's > another example in which SCSI behaves this way in practice. > > --David > > > -----Original Message----- > > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > > Sent: Monday, December 24, 2001 12:47 AM > > To: Black_David@emc.com > > Cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: "conservative reuse" requirement > > > > > > > I think this is headed towards "conservative reuse" being a MUST if > > > we're serious about support for shared persistent reservations. > > > > Mandating "conservative reuse" appears to force initiators to > > always act > > as a single initiator port (wrt one target; assuming only one > > session as an > > example) per initiator device - which rules out the case of > > an initiator > > intentionally wanting to present a different port to each > > target portal group. > > > > IMHO, if iSCSI provides an architected mechanism to support shared > > persistent reservations ("conservative reuse"), that should > > be completely > > adequate to meet the expectations to be a legal SCSI protocol. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > > > > ----- Original Message ----- > > From: > > To: > > Cc: > > Sent: Friday, December 21, 2001 4:50 PM > > Subject: iSCSI: "conservative reuse" requirement > > > > > > > Santosh Rao writes: > > > > > > > I am opposed to the suggestion that "conservative re-use" > > of ISIDs be > > > > made a MUST. This is really only required when initiators > > need to be > > > > using the new T10 Reservation scheme that can be shared > > > > across initiator ports. > > > > > > Those reservations are a Target feature. With this > > approach, the ability > > > to use the target feature depends on details of the initiator > > > implementation. > > > More below ... > > > > > > > For those initiators that don't care about this type of > > reservation, > > > > conservative re-use is of no use and initiators may like to assign > > > > ISID's in a per-initiator node fashion, thereby, being > > able to use these > > > > ISIDs as a lookup index for the sessions on that initiator node. > > > > > > > > Hence, I suggest that "conservative re-use" be worded as > > > > "encouraged to use" or something to that effect, but not MUST USE. > > > > > > > > Comments ? > > > > > > The "initiator" is more than one entity. The iSCSI HBA/NIC > > and driver > > > doesn't know whether shared persistent reservations are > > being used and > > > shouldn't have to care - they're just more SCSI commands to > > transport. > > > Some other entity (e.g., clustering software) will be generating the > > > shared persistent reservations. This raise the possible scenario > > > involving a target that supports the new shared persistent > > reservations > > > and an entity that wants to use them. The entity detects > > (via SCSI means, > > > e.g., something in a mode page) that the Target supports > > shared persistent > > > reservations, tries to use them, only to discover that they > > don't work > > > because the iSCSI HBA/NIC doesn't implement "conservative reuse". > > > > > > I'm worried about this causing both interoperability issues > > and possible > > > T10 issues -- from a T10 viewpoint, if shared persistent > > reservations > > > don't work, the initiating entity should have some SCSI-level means > > > of determining this ... if that means exists only on the Target, the > > > above scenario is iSCSI's problem (Target can't query Initiator to > > > determine whether it does "conservative reuse"), and having > > a separate > > > initiator side means that the entity has to check only for > > iSCSI (and > > > not for any other SCSI transport) does not seem like the right > > > approach. > > > > > > I think this is headed towards "conservative reuse" being a MUST if > > > we're serious about support for shared persistent reservations. > > > > > > Comments? > > > --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 Jan 2 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 VAA14111 for ; Wed, 2 Jan 2002 21:19:13 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g031cCr14634 for ips-outgoing; Wed, 2 Jan 2002 20:38:12 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g031cBg14630 for ; Wed, 2 Jan 2002 20:38:11 -0500 (EST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.99.140.24]) by e32.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id UAA156234 for ; Wed, 2 Jan 2002 20:35:13 -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 g031c8h116140 for ; Wed, 2 Jan 2002 18:38:08 -0700 X-Priority: 1 (High) Importance: Normal Subject: iSCSI:ExpDataSN 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, 2 Jan 2002 17:37:24 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 01/02/2002 06:38:08 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, the current Draft section 3.4.7 clearly states that ExpDataSN applies to Reads (Data-In PDUs). Though it does not say only Reads, it does not make much since for anything else. The Appendix B on the other hand has a number of examples that show the final Status on a Write Operation, returning ExpDataSN. These examples should probably be updated to remove the returning of the ExpDataSN on the Ending SCSI Response PDU for Write Operations. We might also consider adding words to 3.4.7 that says "This field is Reserved when responding to Writes (Data-Out) Operations. " especially since the Appendix shows it did seem confusing to someone. . . . 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 Wed Jan 2 21:21: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 VAA14132 for ; Wed, 2 Jan 2002 21:21:13 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g031qWR15240 for ips-outgoing; Wed, 2 Jan 2002 20:52:32 -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 g031qVg15236 for ; Wed, 2 Jan 2002 20:52:31 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel9.hp.com (Postfix) with ESMTP id 5540CE002B3; Wed, 2 Jan 2002 20:52:25 -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 RAA12390; Wed, 2 Jan 2002 17:53:58 -0800 (PST) Message-ID: <002901c193f9$49a822a0$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: Cc: References: <277DD60FB639D511AC0400B0D068B71E029372DD@CORPMX14> Subject: Re: iSCSI: "conservative reuse" requirement Date: Wed, 2 Jan 2002 17:52:22 -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 David, Thanks for the message. Let me comment on what I agree with first. >if "conservative reuse" does not > happen (breaking shared persistent reservations), the reason that > it does not happen MUST be externally configurable as opposed to > being an unchangeable internal characteristic of the implementation. Agreed. If I understand you correctly, you're concerned that NICs that are hard-coded not to allow single initiator port abstraction (i.e. that don't do conservative reuse) will break the new shared persistent reservations. I agree that it currently is an issue, I propose that we have a NIC requirement in the implementation notes (like the node name configurability requirement) that says something like - Every iSCSI NIC MUST provide a means of enabling a strict "conservative reuse" of ISIDs across different target portal groups. In the case of OSVs doing this in software, one would have to assume that they cater to the app requirements that are likely to be deployed on that O/S. IMHO, my proposed formulation (bottom) addresses that adequately. With that said, here's the idea (repeated in several places) that I have a problem with - > every possible connection is > attempted, and the reasons that not every connection is established > are external (and configurable, modulo physical constraints). First off, I am not sure what you meant by "connection" here, and "presented" in your previous message. I took it that you meant "establishing a SCSI nexus". If that's indeed so, the assertion that it's only the external factors that decide nexii is not always true. Consider the case of an FC initiator port discovering target ports using an FC Name Server, and an iSCSI initiator port discovering target ports using a "SendTargets" command. In either case, the initiator SCSI port may not really establish a nexus with a discovered target SCSI port, unless the application (or even the SCSI class driver) really wants to do an I/O (starting with an open() system call in Unix systems). But in any case, it appears to be in the implementation territory. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ----- Original Message ----- From: To: Cc: Sent: Wednesday, January 02, 2002 3:45 PM Subject: RE: iSCSI: "conservative reuse" requirement > This topic is not exactly amenable to short summaries ... > > > I disagree with your assumption that an initiator must > > "present" *all* its ports to every target port in a target > > device. Each distinct initiator port (signified by a unique > > ISID) may want to talk to only one target port (i.e. one portal > > group) - that's a typical usage of multi-HBA (i.e. multi-port) > > hosts talking to multi-FC port targets today. As far as I > > can understand, a mandatory "conservative reuse" would > > preclude this usage. Please comment if your visualization > > of conservative reuse is different. > > The concern I have is based on the source of the connectivity > constraints. To begin with, I disagree with the notion that > a FC imitator port "may want to talk to only one target port"; > Fibre Channel does not work that way because the connectivity > constraints are imposed externally to the ports. For the > case of an m-way HBA host talking to a n-way FC port target, > "conservative reuse" is attempted by the HBAs (each port has > exactly one WWN), and if less than the full m x n set of connections > results, it is due to an external absence of connectivity - > either each HBA port is connected to one target FC port, or > the fabric(s) involved are zoned in a fashion that this is > the resulting logical connectivity. In both cases, an HBA > following the rules connects to everything that it is allowed > to connect to. > > I have no problem with external physical or logical (e.g., VLAN, > or even iSNS) connectivity constraints preventing all possible > connections between a multi-port initiator and a multi-port target. > What I have a problem with is an implementation making an > internal decision that it will *never*: > > present a single SCSI port abstraction to multiple target > portal groups (thus multiple SCSI target ports) of an iSCSI > target node, > > no matter what its administrators and users may want. IMHO, > that's not the implementation's decision to make - it needs to > be made externally by the administrator who configures the > system. In particular, if an implementation is operating over > a single IP interface, there has been discussion on this list > of using a different ISID for every target portal group that > it connects to - shared persistent reservations will never work > right if that is done, and there is nothing that the administrator > can do in that situation to get them to work ... I think this needs > to be prohibited if we're serious about following T10's direction > on persistent shared reservations, unless T10 is going to > provide a way to query the initiator to discover that it does > not support shared persistent reservations. > > So, I would allow the scenario of interest (each Initiator port > connects to only one Target port), but only in the fashion currently > found in other SCSI transports where every possible connection is > attempted, and the reasons that not every connection is established > are external (and configurable, modulo physical constraints). The > crucial aspect of this is that if "conservative reuse" does not > happen (breaking shared persistent reservations), the reason that > it does not happen MUST be externally configurable as opposed to > being an unchangeable internal characteristic of the implementation. > > With luck, this makes a little more sense. > > Thanks, > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > black_david@emc.com Cell: +1 (978) 394-7754 > --------------------------------------------------- > > > > -----Original Message----- > > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > > Sent: Wednesday, January 02, 2002 4:21 PM > > To: Black_David@emc.com > > Cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: "conservative reuse" requirement > > > > > > Now that I'm back from vacation, let me offer some (delayed) > > comments on this. I also read Jim's reply where he appeared > > to mostly agree with me. > > > > >...as long as it presented > > > each of them to all target ports... > > > > I disagree with your assumption that an initiator must > > "present" *all* its ports to every target port in a target > > device. Each distinct initiator port (signified by a unique > > ISID) may want to talk to only one target port (i.e. one portal > > group) - that's a typical usage of multi-HBA (i.e. multi-port) > > hosts talking to multi-FC port targets today. As far as I > > can understand, a mandatory "conservative reuse" would > > preclude this usage. Please comment if your visualization > > of conservative reuse is different. > > > > OTOH, I can see that the ability of *one* initiator SCSI > > port to establish nexii with multiple target SCSI ports in > > a target device is highly desirable (perhaps even T10-required > > shortly). IMO, iSCSI had already met this need by defining > > and enabling "conservative reuse", and that's where we should > > stop. I would actually advocate wording along the lines of - > > > > "When a given initiator implementation seeks to present > > a single SCSI port abstraction to multiple target portal > > groups (thus multiple SCSI target ports) of an iSCSI target > > node, conservative reuse is the means to realize it. > > Conservative reuse hence MUST be used in this case." > > > > and leave it at that. > > -- > > Mallikarjun > > > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > MS 5668 Hewlett-Packard, Roseville. > > cbm@rose.hp.com > > > > > > Black_David@emc.com wrote: > > > > > > Not exactly. "Conservative Reuse" would allow an initiator > > > to present multiple initiator ports, as long as it presented > > > each of them to all target ports (assuming that the connectivity > > > exists). Why would an Initiator want to present different > > > ports to different target portal groups? I don't think there's > > > another example in which SCSI behaves this way in practice. > > > > > > --David > > > > > > > -----Original Message----- > > > > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > > > > Sent: Monday, December 24, 2001 12:47 AM > > > > To: Black_David@emc.com > > > > Cc: ips@ece.cmu.edu > > > > Subject: Re: iSCSI: "conservative reuse" requirement > > > > > > > > > > > > > I think this is headed towards "conservative reuse" > > being a MUST if > > > > > we're serious about support for shared persistent reservations. > > > > > > > > Mandating "conservative reuse" appears to force initiators to > > > > always act > > > > as a single initiator port (wrt one target; assuming only one > > > > session as an > > > > example) per initiator device - which rules out the case of > > > > an initiator > > > > intentionally wanting to present a different port to each > > > > target portal group. > > > > > > > > IMHO, if iSCSI provides an architected mechanism to support shared > > > > persistent reservations ("conservative reuse"), that should > > > > be completely > > > > adequate to meet the expectations to be a legal SCSI protocol. > > > > -- > > > > Mallikarjun > > > > > > > > Mallikarjun Chadalapaka > > > > Networked Storage Architecture > > > > Network Storage Solutions Organization > > > > Hewlett-Packard MS 5668 > > > > Roseville CA 95747 > > > > > > > > ----- Original Message ----- > > > > From: > > > > To: > > > > Cc: > > > > Sent: Friday, December 21, 2001 4:50 PM > > > > Subject: iSCSI: "conservative reuse" requirement > > > > > > > > > > > > > Santosh Rao writes: > > > > > > > > > > > I am opposed to the suggestion that "conservative re-use" > > > > of ISIDs be > > > > > > made a MUST. This is really only required when initiators > > > > need to be > > > > > > using the new T10 Reservation scheme that can be shared > > > > > > across initiator ports. > > > > > > > > > > Those reservations are a Target feature. With this > > > > approach, the ability > > > > > to use the target feature depends on details of the initiator > > > > > implementation. > > > > > More below ... > > > > > > > > > > > For those initiators that don't care about this type of > > > > reservation, > > > > > > conservative re-use is of no use and initiators may > > like to assign > > > > > > ISID's in a per-initiator node fashion, thereby, being > > > > able to use these > > > > > > ISIDs as a lookup index for the sessions on that > > initiator node. > > > > > > > > > > > > Hence, I suggest that "conservative re-use" be worded as > > > > > > "encouraged to use" or something to that effect, but > > not MUST USE. > > > > > > > > > > > > Comments ? > > > > > > > > > > The "initiator" is more than one entity. The iSCSI HBA/NIC > > > > and driver > > > > > doesn't know whether shared persistent reservations are > > > > being used and > > > > > shouldn't have to care - they're just more SCSI commands to > > > > transport. > > > > > Some other entity (e.g., clustering software) will be > > generating the > > > > > shared persistent reservations. This raise the > > possible scenario > > > > > involving a target that supports the new shared persistent > > > > reservations > > > > > and an entity that wants to use them. The entity detects > > > > (via SCSI means, > > > > > e.g., something in a mode page) that the Target supports > > > > shared persistent > > > > > reservations, tries to use them, only to discover that they > > > > don't work > > > > > because the iSCSI HBA/NIC doesn't implement > > "conservative reuse". > > > > > > > > > > I'm worried about this causing both interoperability issues > > > > and possible > > > > > T10 issues -- from a T10 viewpoint, if shared persistent > > > > reservations > > > > > don't work, the initiating entity should have some > > SCSI-level means > > > > > of determining this ... if that means exists only on > > the Target, the > > > > > above scenario is iSCSI's problem (Target can't query > > Initiator to > > > > > determine whether it does "conservative reuse"), and having > > > > a separate > > > > > initiator side means that the entity has to check only for > > > > iSCSI (and > > > > > not for any other SCSI transport) does not seem like the right > > > > > approach. > > > > > > > > > > I think this is headed towards "conservative reuse" > > being a MUST if > > > > > we're serious about support for shared persistent reservations. > > > > > > > > > > Comments? > > > > > --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 Jan 2 21: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 VAA14291 for ; Wed, 2 Jan 2002 21:31:50 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g032Cfr16073 for ips-outgoing; Wed, 2 Jan 2002 21:12:41 -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 g032Cdg16068 for ; Wed, 2 Jan 2002 21:12:39 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel10.hp.com (Postfix) with ESMTP id E503E400370; Wed, 2 Jan 2002 18:12: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 SAA13575; Wed, 2 Jan 2002 18:14:07 -0800 (PST) Message-ID: <002d01c193fc$1a40a390$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "John Hufferd" Cc: References: Subject: Re: iSCSI: "conservative reuse" requirement Date: Wed, 2 Jan 2002 18:12:32 -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 John, >This is called Conservative Reuse > since when we start/restart a session we are not choosing a different ISID. That doesn't seem to be what's meant by rev09 when it says in section 9.1.1 - " the same ISID should be used in the Login process to multiple target portal groups (of the same iSCSI Target or different iSCSI Targets)." and further it says - "The principle of conservative reuse "encourages" reuse to other target portal groups. When a SCSI target device sees the same (InitiatorName, ISID) pair in different sessions to different target portal groups, it can identify the underlying SCSI Initiator Port on each session as the same SCSI port (in effect, it can recognize multiple paths from the same source)." >The Name of the SCSI Initiator Port is made > up of the iSCSI Initiator Node Name and the ISID. Just a nit - also includes the letter 'i'! > If those other iSCSI Initiators have HBAs which have been made by the same ^^^^^^^ Somehow it appears to me that this isn't "carefully qualified", :-) Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ----- Original Message ----- From: "John Hufferd" To: Cc: ; Sent: Wednesday, January 02, 2002 4:57 PM Subject: Re: iSCSI: "conservative reuse" requirement > > Mallikarjun, > Comments in line between [Huff/] and [\Huff]. > > . > . > . > 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 > > > "Mallikarjun C." @ece.cmu.edu on 01/02/2002 01:21:13 PM > > Please respond to cbm@rose.hp.com > > Sent by: owner-ips@ece.cmu.edu > > > To: Black_David@emc.com > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: "conservative reuse" requirement > > > > Now that I'm back from vacation, let me offer some (delayed) > comments on this. I also read Jim's reply where he appeared > to mostly agree with me. > > >...as long as it presented > > each of them to all target ports... > > I disagree with your assumption that an initiator must > "present" *all* its ports to every target port in a target > device. Each distinct initiator port (signified by a unique > ISID) may want to talk to only one target port (i.e. one portal > group) - that's a typical usage of multi-HBA (i.e. multi-port) > hosts talking to multi-FC port targets today. As far as I > can understand, a mandatory "conservative reuse" would > preclude this usage. Please comment if your visualization > of conservative reuse is different. > > [Huff/] > We have now fallen into the problem that Jim, Julian, Marjorie, and I spent > the Holidays exchanging e-Mails about. You use the term Initiator to > represent the Total Initiator Node (and indeed our draft definitions > encourage that view). However, some others, when they talk, use the SCSI > interpretation of the word Initiator, which is the SCSI Initiator Port. So > as Marjorie has clearly pointed out to me, I need to be more precise, and I > think the rest of us also. We need to fully qualify the term Initiator > when we use it, in these types of discussions. We need to say iSCSI > Initiator Node, or SCSI Initiator Port etc. So let me try that below, in > hopes of perhaps clearing up some concepts. > > The use of Conservative Reuse applies to the how the Name of the SCSI > Initiator Port will be chosen. The Name of the SCSI Initiator Port is made > up of the iSCSI Initiator Node Name and the ISID. > > We are attempting to ensure that any one SCSI Initiator Port will not pick > various different ISIDs in a manner that will prevent the Persistent > Reserves from being reestablished across a Session Restart. To do that we > strongly suggest that the Vendor follow the Type and Vendor ID approach to > creating and ISID as specified in version 9 of the Draft. Also they should > pick the 16 bit Qualifier part in a way that will usually be the same > number each time a Session from that SCSI Initiator Port is restarted. The > easiest way to do this is for the iSCSI Process to Identify the SCSI > Initiator Port with the same ISID Qualifier every time an iSCSI Session is > started with any SCSI Target Port (via its iSCSI Target Portal Group). > > When this is done, everything works. This is called Conservative Reuse > since when we start/restart a session we are not choosing a different ISID. > > Please note I did not restrict the actions of any other SCSI Initiator Port > within the iSCSI Initiator Node. They can each have their own ISID and use > the iSCSI Transport to connect to what ever SCSI Target Nodes they wish. > If those other iSCSI Initiators have HBAs which have been made by the same > vendor (and if that vendor does not support Multiple Connections per > Session across the HBAs), it is the Vendors responsibility to chose an ISID > Qualifier for its second (and subsequent) SCSI Initiator Port, which does > not conflict with the first one. When done correctly, then if by chance, > the second SCSI Initiator Port connects to the same SCSI Target Port to > which the First one connected, they will each be seen, by the Target, as > different Sessions from different SCSI Initiator Ports and things are > completely legal. > > In this case, as it is in Fibre Channel, the Host (iSCSI Initiator Node) > will have to be very careful how work is handed out to the different SCSI > Initiator Ports, so that Work arrives in the correct order and there is no > conflicts with Reserves. (The process that does that balancing between the > HBAs is what, in Fibre Channel, we have called a Wedge Driver). > > So what I have said above, is that when we carefully qualify the Term > Initiator, we can see that Conservative Reuse does NOT cause any > restrictions on the way we use the Sessions within an iSCSI Initiator Node. > [\Huff] > > OTOH, I can see that the ability of *one* initiator SCSI > port to establish nexii with multiple target SCSI ports in > a target device is highly desirable (perhaps even T10-required > shortly). IMO, iSCSI had already met this need by defining > and enabling "conservative reuse", and that's where we should > stop. I would actually advocate wording along the lines of - > > "When a given initiator implementation seeks to present > a single SCSI port abstraction to multiple target portal > groups (thus multiple SCSI target ports) of an iSCSI target > node, conservative reuse is the means to realize it. > Conservative reuse hence MUST be used in this case." > > and leave it at that. > -- > Mallikarjun > > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > > Black_David@emc.com wrote: > > > > Not exactly. "Conservative Reuse" would allow an initiator > > to present multiple initiator ports, as long as it presented > > each of them to all target ports (assuming that the connectivity > > exists). Why would an Initiator want to present different > > ports to different target portal groups? I don't think there's > > another example in which SCSI behaves this way in practice. > > > > --David > > > > > -----Original Message----- > > > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > > > Sent: Monday, December 24, 2001 12:47 AM > > > To: Black_David@emc.com > > > Cc: ips@ece.cmu.edu > > > Subject: Re: iSCSI: "conservative reuse" requirement > > > > > > > > > > I think this is headed towards "conservative reuse" being a MUST if > > > > we're serious about support for shared persistent reservations. > > > > > > Mandating "conservative reuse" appears to force initiators to > > > always act > > > as a single initiator port (wrt one target; assuming only one > > > session as an > > > example) per initiator device - which rules out the case of > > > an initiator > > > intentionally wanting to present a different port to each > > > target portal group. > > > > > > IMHO, if iSCSI provides an architected mechanism to support shared > > > persistent reservations ("conservative reuse"), that should > > > be completely > > > adequate to meet the expectations to be a legal SCSI protocol. > > > -- > > > Mallikarjun > > > > > > Mallikarjun Chadalapaka > > > Networked Storage Architecture > > > Network Storage Solutions Organization > > > Hewlett-Packard MS 5668 > > > Roseville CA 95747 > > > > > > ----- Original Message ----- > > > From: > > > To: > > > Cc: > > > Sent: Friday, December 21, 2001 4:50 PM > > > Subject: iSCSI: "conservative reuse" requirement > > > > > > > > > > Santosh Rao writes: > > > > > > > > > I am opposed to the suggestion that "conservative re-use" > > > of ISIDs be > > > > > made a MUST. This is really only required when initiators > > > need to be > > > > > using the new T10 Reservation scheme that can be shared > > > > > across initiator ports. > > > > > > > > Those reservations are a Target feature. With this > > > approach, the ability > > > > to use the target feature depends on details of the initiator > > > > implementation. > > > > More below ... > > > > > > > > > For those initiators that don't care about this type of > > > reservation, > > > > > conservative re-use is of no use and initiators may like to assign > > > > > ISID's in a per-initiator node fashion, thereby, being > > > able to use these > > > > > ISIDs as a lookup index for the sessions on that initiator node. > > > > > > > > > > Hence, I suggest that "conservative re-use" be worded as > > > > > "encouraged to use" or something to that effect, but not MUST USE. > > > > > > > > > > Comments ? > > > > > > > > The "initiator" is more than one entity. The iSCSI HBA/NIC > > > and driver > > > > doesn't know whether shared persistent reservations are > > > being used and > > > > shouldn't have to care - they're just more SCSI commands to > > > transport. > > > > Some other entity (e.g., clustering software) will be generating the > > > > shared persistent reservations. This raise the possible scenario > > > > involving a target that supports the new shared persistent > > > reservations > > > > and an entity that wants to use them. The entity detects > > > (via SCSI means, > > > > e.g., something in a mode page) that the Target supports > > > shared persistent > > > > reservations, tries to use them, only to discover that they > > > don't work > > > > because the iSCSI HBA/NIC doesn't implement "conservative reuse". > > > > > > > > I'm worried about this causing both interoperability issues > > > and possible > > > > T10 issues -- from a T10 viewpoint, if shared persistent > > > reservations > > > > don't work, the initiating entity should have some SCSI-level means > > > > of determining this ... if that means exists only on the Target, the > > > > above scenario is iSCSI's problem (Target can't query Initiator to > > > > determine whether it does "conservative reuse"), and having > > > a separate > > > > initiator side means that the entity has to check only for > > > iSCSI (and > > > > not for any other SCSI transport) does not seem like the right > > > > approach. > > > > > > > > I think this is headed towards "conservative reuse" being a MUST if > > > > we're serious about support for shared persistent reservations. > > > > > > > > Comments? > > > > --David > > > > --------------------------------------------------- > > > > David L. Black, Senior Technologist > > > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > > > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > > > > black_david@emc.com Cell: +1 (978) 394-7754 > > > > --------------------------------------------------- > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Thu Jan 3 00: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 AAA18164 for ; Thu, 3 Jan 2002 00:51:14 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0353cp23000 for ips-outgoing; Thu, 3 Jan 2002 00:03:38 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dcmtechdom.dcmtech.co.in ([203.190.136.130]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0353Xg22993 for ; Thu, 3 Jan 2002 00:03:35 -0500 (EST) Received: by DCMTECHDOM with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jan 2002 10:36:51 +0530 Message-ID: <7FADCB99FC82D41199F9000629A85D1A0293A9BF@DCMTECHDOM> From: Nitin Dhingra To: "'Black_David@emc.com'" , ips@ece.cmu.edu Subject: RE: iScsi: Date: Thu, 3 Jan 2002 10:36:50 +0530 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 Well, let's take a case where you have one target and many initiators connected that target And as iScsi is at block level, so if more than one initiator have requested to write at the same block address at the same time at the same target this can create synchronization problems, don't you think? Shouldn't you give an option like most other protocols like NFS does, where you have a separate optional layer for locking/synchronization... Don't you think this should be handled by iScsi?? - Nitin -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Wednesday, January 02, 2002 3:10 PM To: nitin.dhingra@dcmtech.co.in; ips@ece.cmu.edu Subject: RE: iScsi: I don't understand this - what exactly is broken that you think needs to be fixed? Many SCSI targets do implement access controls at the logical unit level, which is in T10's domain, not iSCSI's. --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: Nitin Dhingra [mailto:nitin.dhingra@dcmtech.co.in] > Sent: Wednesday, January 02, 2002 12:40 AM > To: ips@ece.cmu.edu > Subject: iScsi: > > > Why don't you put a restriction on the read/write access to a target? > This can solve some of the synchronization problems that can occur... > > And Yeah Happy New Year to All... > > - Nitin > From owner-ips@ece.cmu.edu Thu Jan 3 03:55: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 DAA27967 for ; Thu, 3 Jan 2002 03:55:29 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g03874i00184 for ips-outgoing; Thu, 3 Jan 2002 03:07:04 -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 g03872g00178 for ; Thu, 3 Jan 2002 03:07: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 JAA87930 for ; Thu, 3 Jan 2002 09:06: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 g0387cj88640 for ; Thu, 3 Jan 2002 09:07:38 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: data-out initiator transfer tags X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 3 Jan 2002 10:07:35 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 03/01/2002 10:07:43, Serialize complete at 03/01/2002 10:07:43 Content-Type: multipart/alternative; boundary="=_alternative 002BFE34C2256B36_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 002BFE34C2256B36_= Content-Type: text/plain; charset="us-ascii" Buck, Yes ITT in data and command have to be the same. And yes the targets will use the TTT to speed-up the look-up and match data to buffers. Julo "Buck Landry" Sent by: owner-ips@ece.cmu.edu 03-01-02 02:18 To: cc: Subject: iSCSI: data-out initiator transfer tags Is it required that the initiator transfer tag (ITT) for a data-out pdu be identical to the ITT of the scsi command pdu it is associated with? I would assume so for consistency's sake, but have seen implementations that assumed the target would use the data-out pdu's target transfer tag to look up the associated command. Thanks, Buck --=_alternative 002BFE34C2256B36_= Content-Type: text/html; charset="us-ascii"
Buck,

Yes ITT in data and command have to be the same.
And yes the targets will use the TTT to speed-up the look-up and match data to buffers.

Julo


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

03-01-02 02:18

       
        To:        <ips@ece.cmu.edu>
        cc:        
        Subject:        iSCSI: data-out initiator transfer tags

       


Is it required that the initiator transfer tag (ITT) for a data-out pdu be identical to the ITT of the scsi command pdu it is associated with?

I would assume so for consistency's sake, but have seen implementations that assumed the target would use the data-out pdu's target transfer tag to look up the associated command.

Thanks,
Buck



--=_alternative 002BFE34C2256B36_=-- From owner-ips@ece.cmu.edu Thu Jan 3 03:55: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 DAA27981 for ; Thu, 3 Jan 2002 03:55:37 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g038Omc00875 for ips-outgoing; Thu, 3 Jan 2002 03:24:48 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from host32.cedant.com (host32.cedant.com [209.239.32.20]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g038Ojg00866 for ; Thu, 3 Jan 2002 03:24:45 -0500 (EST) Received: from sahara (63.sanjose-15rs16rt.ca.dial-access.att.net [12.81.7.63]) by host32.cedant.com (8.10.2/8.10.2) with ESMTP id g038OCC05254; Thu, 3 Jan 2002 03:24:17 -0500 Message-ID: <200201030039160880.079BABA2@opulentsystems.com> In-Reply-To: <7FADCB99FC82D41199F9000629A85D1A0293A9BF@DCMTECHDOM> References: <7FADCB99FC82D41199F9000629A85D1A0293A9BF@DCMTECHDOM> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Thu, 03 Jan 2002 00:39:16 -0800 Reply-To: sganguly@opulentsystems.com From: "Sukanta Ganguly" To: "Nitin Dhingra" , "'Black_David@emc.com'" , "IPS" Subject: RE: iScsi: 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 g038Okg00867 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Without iSCSI, in a normal circumstance where you have one target device and multiple HBA's acting as initiator, Who handles the synchronization? How is iSCSI bring up this issue. Isn't is already handled ? SG *********** REPLY SEPARATOR *********** On 1/3/2002 at 10:36 AM Nitin Dhingra wrote: >Well, let's take a case >where you have one target and many initiators connected that target > >And as iScsi is at block level, so if more than one initiator have >requested >to write at the same block address at the same time at the same target >this can create synchronization problems, don't you think? > >Shouldn't you give an option like most other protocols like NFS does, >where you have a separate optional layer for locking/synchronization... > >Don't you think this should be handled by iScsi?? > >- Nitin > > -----Original Message----- >From: Black_David@emc.com [mailto:Black_David@emc.com] >Sent: Wednesday, January 02, 2002 3:10 PM >To: nitin.dhingra@dcmtech.co.in; ips@ece.cmu.edu >Subject: RE: iScsi: > >I don't understand this - what exactly is broken that you think >needs to be fixed? Many SCSI targets do implement access controls >at the logical unit level, which is in T10's domain, not iSCSI's. > >--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: Nitin Dhingra [mailto:nitin.dhingra@dcmtech.co.in] >> Sent: Wednesday, January 02, 2002 12:40 AM >> To: ips@ece.cmu.edu >> Subject: iScsi: >> >> >> Why don't you put a restriction on the read/write access to a target? >> This can solve some of the synchronization problems that can occur... >> >> And Yeah Happy New Year to All... >> >> - Nitin >> From owner-ips@ece.cmu.edu Thu Jan 3 06:40: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 GAA29299 for ; Thu, 3 Jan 2002 06:40:56 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g03BQ7M18962 for ips-outgoing; Thu, 3 Jan 2002 06:26: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 g03BQ5g18957 for ; Thu, 3 Jan 2002 06:26: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 GAA92118; Thu, 3 Jan 2002 06:23:02 -0500 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.99.140.13]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g03BPr4248240; Thu, 3 Jan 2002 04:25:58 -0700 X-Priority: 1 (High) Importance: Normal Subject: RE: iScsi: To: Nitin Dhingra Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Thu, 3 Jan 2002 03:25:03 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 01/03/2002 04:25:58 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I think you need to understand how SCSI on Shared Devices work. If you do not coordinate either via a Shared File System or Shared Data Base, or SCSI Reserves, you clearly have a problem. But this is a well known issue and has been solved years ago with multiple SCSI Bus connections to the same Storage Controller, and currently applies to Fiber Channel as well as iSCSI. Nothing new is needed in the iSCSI protocol. . . . 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 Nitin Dhingra @ece.cmu.edu on 01/02/2002 09:06:50 PM Sent by: owner-ips@ece.cmu.edu To: "'Black_David@emc.com'" , ips@ece.cmu.edu cc: Subject: RE: iScsi: Well, let's take a case where you have one target and many initiators connected that target And as iScsi is at block level, so if more than one initiator have requested to write at the same block address at the same time at the same target this can create synchronization problems, don't you think? Shouldn't you give an option like most other protocols like NFS does, where you have a separate optional layer for locking/synchronization... Don't you think this should be handled by iScsi?? - Nitin -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Wednesday, January 02, 2002 3:10 PM To: nitin.dhingra@dcmtech.co.in; ips@ece.cmu.edu Subject: RE: iScsi: I don't understand this - what exactly is broken that you think needs to be fixed? Many SCSI targets do implement access controls at the logical unit level, which is in T10's domain, not iSCSI's. --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: Nitin Dhingra [mailto:nitin.dhingra@dcmtech.co.in] > Sent: Wednesday, January 02, 2002 12:40 AM > To: ips@ece.cmu.edu > Subject: iScsi: > > > Why don't you put a restriction on the read/write access to a target? > This can solve some of the synchronization problems that can occur... > > And Yeah Happy New Year to All... > > - Nitin > From owner-ips@ece.cmu.edu Thu Jan 3 06:45: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 GAA29345 for ; Thu, 3 Jan 2002 06:45:51 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g03Atdo17869 for ips-outgoing; Thu, 3 Jan 2002 05:55:39 -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 g03AtXg17864 for ; Thu, 3 Jan 2002 05:55:33 -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 FAA27112; Thu, 3 Jan 2002 05:52:28 -0500 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.99.140.13]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g03AtO497326; Thu, 3 Jan 2002 03:55:24 -0700 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: "conservative reuse" requirement To: "Mallikarjun C." Cc: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Thu, 3 Jan 2002 02:54:35 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 01/03/2002 03:55:24 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk In regards to the first (the important) point you made. Perhaps an example would be best. (Since I think what I said is completely consistent with the draft.) Suppose the vendor "xxx" assigns the qualifier "1" to the SCSI Initiator Port's ISID. Then suppose the IANA Enterprise Number is 5. The name of the SCSI Initiator Port then might be "main_node"+i+ISID where ISID is made up of type= 1, vendor=5, qualifier=1. Or in other words ISID=0x010000050001. So lets suppose the vendor had an HBA/Device Driver combo that assigns the SCSI Initiator Port to be "main_node"+i+0x010000050001. Now this same Initiator Node Name and ISID can be used with every Session that is connected via the Same HBA/Device Driver (which is in this case, the SCSI Initiator Port). They only thing it can not do is connect to the same SCSI Target Port more then once. If the iSCSI Initiator Node wants another connection to the same SCSI Target Port it must establish another SCSI Initiator Port and change the qualifier. That means that the new SCSI Initiator Port might be called "main_node"+i+0x010000050002. Further, every session that the new SCSI initiator creates will have the same name SCSI Initiator Port Name. This New SCSI Initiator Port can be via another HBA/Device Driver, or even via the original HBA/Device Driver. So it is possible for the Conservative Reuse to be used with a Single iSCSI Initiator Node, yet have more then one SCSI Initiator Port each uniquely defined, and with each having its own single ISID, which it uses for all of its connections. In this case the iSCSI Initiator Node would have more then one session to the same iSCSI Target Node, via the same SCSI Target Port. I think that is exactly what I intended to say in the previous note and is consistent with the Version 9 of 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 "Mallikarjun C." on 01/02/2002 06:12:32 PM To: John Hufferd/San Jose/IBM@IBMUS cc: Subject: Re: iSCSI: "conservative reuse" requirement John, >This is called Conservative Reuse > since when we start/restart a session we are not choosing a different ISID. That doesn't seem to be what's meant by rev09 when it says in section 9.1.1 - " the same ISID should be used in the Login process to multiple target portal groups (of the same iSCSI Target or different iSCSI Targets)." and further it says - "The principle of conservative reuse "encourages" reuse to other target portal groups. When a SCSI target device sees the same (InitiatorName, ISID) pair in different sessions to different target portal groups, it can identify the underlying SCSI Initiator Port on each session as the same SCSI port (in effect, it can recognize multiple paths from the same source)." >The Name of the SCSI Initiator Port is made > up of the iSCSI Initiator Node Name and the ISID. Just a nit - also includes the letter 'i'! > If those other iSCSI Initiators have HBAs which have been made by the same ^^^^^^^ Somehow it appears to me that this isn't "carefully qualified", :-) Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ----- Original Message ----- From: "John Hufferd" To: Cc: ; Sent: Wednesday, January 02, 2002 4:57 PM Subject: Re: iSCSI: "conservative reuse" requirement > > Mallikarjun, > Comments in line between [Huff/] and [\Huff]. > > . > . > . > 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 > > > "Mallikarjun C." @ece.cmu.edu on 01/02/2002 01:21:13 PM > > Please respond to cbm@rose.hp.com > > Sent by: owner-ips@ece.cmu.edu > > > To: Black_David@emc.com > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: "conservative reuse" requirement > > > > Now that I'm back from vacation, let me offer some (delayed) > comments on this. I also read Jim's reply where he appeared > to mostly agree with me. > > >...as long as it presented > > each of them to all target ports... > > I disagree with your assumption that an initiator must > "present" *all* its ports to every target port in a target > device. Each distinct initiator port (signified by a unique > ISID) may want to talk to only one target port (i.e. one portal > group) - that's a typical usage of multi-HBA (i.e. multi-port) > hosts talking to multi-FC port targets today. As far as I > can understand, a mandatory "conservative reuse" would > preclude this usage. Please comment if your visualization > of conservative reuse is different. > > [Huff/] > We have now fallen into the problem that Jim, Julian, Marjorie, and I spent > the Holidays exchanging e-Mails about. You use the term Initiator to > represent the Total Initiator Node (and indeed our draft definitions > encourage that view). However, some others, when they talk, use the SCSI > interpretation of the word Initiator, which is the SCSI Initiator Port. So > as Marjorie has clearly pointed out to me, I need to be more precise, and I > think the rest of us also. We need to fully qualify the term Initiator > when we use it, in these types of discussions. We need to say iSCSI > Initiator Node, or SCSI Initiator Port etc. So let me try that below, in > hopes of perhaps clearing up some concepts. > > The use of Conservative Reuse applies to the how the Name of the SCSI > Initiator Port will be chosen. The Name of the SCSI Initiator Port is made > up of the iSCSI Initiator Node Name and the ISID. > > We are attempting to ensure that any one SCSI Initiator Port will not pick > various different ISIDs in a manner that will prevent the Persistent > Reserves from being reestablished across a Session Restart. To do that we > strongly suggest that the Vendor follow the Type and Vendor ID approach to > creating and ISID as specified in version 9 of the Draft. Also they should > pick the 16 bit Qualifier part in a way that will usually be the same > number each time a Session from that SCSI Initiator Port is restarted. The > easiest way to do this is for the iSCSI Process to Identify the SCSI > Initiator Port with the same ISID Qualifier every time an iSCSI Session is > started with any SCSI Target Port (via its iSCSI Target Portal Group). > > When this is done, everything works. This is called Conservative Reuse > since when we start/restart a session we are not choosing a different ISID. > > Please note I did not restrict the actions of any other SCSI Initiator Port > within the iSCSI Initiator Node. They can each have their own ISID and use > the iSCSI Transport to connect to what ever SCSI Target Nodes they wish. > If those other iSCSI Initiators have HBAs which have been made by the same > vendor (and if that vendor does not support Multiple Connections per > Session across the HBAs), it is the Vendors responsibility to chose an ISID > Qualifier for its second (and subsequent) SCSI Initiator Port, which does > not conflict with the first one. When done correctly, then if by chance, > the second SCSI Initiator Port connects to the same SCSI Target Port to > which the First one connected, they will each be seen, by the Target, as > different Sessions from different SCSI Initiator Ports and things are > completely legal. > > In this case, as it is in Fibre Channel, the Host (iSCSI Initiator Node) > will have to be very careful how work is handed out to the different SCSI > Initiator Ports, so that Work arrives in the correct order and there is no > conflicts with Reserves. (The process that does that balancing between the > HBAs is what, in Fibre Channel, we have called a Wedge Driver). > > So what I have said above, is that when we carefully qualify the Term > Initiator, we can see that Conservative Reuse does NOT cause any > restrictions on the way we use the Sessions within an iSCSI Initiator Node. > [\Huff] > > OTOH, I can see that the ability of *one* initiator SCSI > port to establish nexii with multiple target SCSI ports in > a target device is highly desirable (perhaps even T10-required > shortly). IMO, iSCSI had already met this need by defining > and enabling "conservative reuse", and that's where we should > stop. I would actually advocate wording along the lines of - > > "When a given initiator implementation seeks to present > a single SCSI port abstraction to multiple target portal > groups (thus multiple SCSI target ports) of an iSCSI target > node, conservative reuse is the means to realize it. > Conservative reuse hence MUST be used in this case." > > and leave it at that. > -- > Mallikarjun > > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > > Black_David@emc.com wrote: > > > > Not exactly. "Conservative Reuse" would allow an initiator > > to present multiple initiator ports, as long as it presented > > each of them to all target ports (assuming that the connectivity > > exists). Why would an Initiator want to present different > > ports to different target portal groups? I don't think there's > > another example in which SCSI behaves this way in practice. > > > > --David > > > > > -----Original Message----- > > > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > > > Sent: Monday, December 24, 2001 12:47 AM > > > To: Black_David@emc.com > > > Cc: ips@ece.cmu.edu > > > Subject: Re: iSCSI: "conservative reuse" requirement > > > > > > > > > > I think this is headed towards "conservative reuse" being a MUST if > > > > we're serious about support for shared persistent reservations. > > > > > > Mandating "conservative reuse" appears to force initiators to > > > always act > > > as a single initiator port (wrt one target; assuming only one > > > session as an > > > example) per initiator device - which rules out the case of > > > an initiator > > > intentionally wanting to present a different port to each > > > target portal group. > > > > > > IMHO, if iSCSI provides an architected mechanism to support shared > > > persistent reservations ("conservative reuse"), that should > > > be completely > > > adequate to meet the expectations to be a legal SCSI protocol. > > > -- > > > Mallikarjun > > > > > > Mallikarjun Chadalapaka > > > Networked Storage Architecture > > > Network Storage Solutions Organization > > > Hewlett-Packard MS 5668 > > > Roseville CA 95747 > > > > > > ----- Original Message ----- > > > From: > > > To: > > > Cc: > > > Sent: Friday, December 21, 2001 4:50 PM > > > Subject: iSCSI: "conservative reuse" requirement > > > > > > > > > > Santosh Rao writes: > > > > > > > > > I am opposed to the suggestion that "conservative re-use" > > > of ISIDs be > > > > > made a MUST. This is really only required when initiators > > > need to be > > > > > using the new T10 Reservation scheme that can be shared > > > > > across initiator ports. > > > > > > > > Those reservations are a Target feature. With this > > > approach, the ability > > > > to use the target feature depends on details of the initiator > > > > implementation. > > > > More below ... > > > > > > > > > For those initiators that don't care about this type of > > > reservation, > > > > > conservative re-use is of no use and initiators may like to assign > > > > > ISID's in a per-initiator node fashion, thereby, being > > > able to use these > > > > > ISIDs as a lookup index for the sessions on that initiator node. > > > > > > > > > > Hence, I suggest that "conservative re-use" be worded as > > > > > "encouraged to use" or something to that effect, but not MUST USE. > > > > > > > > > > Comments ? > > > > > > > > The "initiator" is more than one entity. The iSCSI HBA/NIC > > > and driver > > > > doesn't know whether shared persistent reservations are > > > being used and > > > > shouldn't have to care - they're just more SCSI commands to > > > transport. > > > > Some other entity (e.g., clustering software) will be generating the > > > > shared persistent reservations. This raise the possible scenario > > > > involving a target that supports the new shared persistent > > > reservations > > > > and an entity that wants to use them. The entity detects > > > (via SCSI means, > > > > e.g., something in a mode page) that the Target supports > > > shared persistent > > > > reservations, tries to use them, only to discover that they > > > don't work > > > > because the iSCSI HBA/NIC doesn't implement "conservative reuse". > > > > > > > > I'm worried about this causing both interoperability issues > > > and possible > > > > T10 issues -- from a T10 viewpoint, if shared persistent > > > reservations > > > > don't work, the initiating entity should have some SCSI-level means > > > > of determining this ... if that means exists only on the Target, the > > > > above scenario is iSCSI's problem (Target can't query Initiator to > > > > determine whether it does "conservative reuse"), and having > > > a separate > > > > initiator side means that the entity has to check only for > > > iSCSI (and > > > > not for any other SCSI transport) does not seem like the right > > > > approach. > > > > > > > > I think this is headed towards "conservative reuse" being a MUST if > > > > we're serious about support for shared persistent reservations. > > > > > > > > Comments? > > > > --David > > > > --------------------------------------------------- > > > > David L. Black, Senior Technologist > > > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > > > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > > > > black_david@emc.com Cell: +1 (978) 394-7754 > > > > --------------------------------------------------- > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Thu Jan 3 07:39:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29309 for ; Thu, 3 Jan 2002 06:40:58 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g03BGks18612 for ips-outgoing; Thu, 3 Jan 2002 06:16:46 -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 g03BGhg18605 for ; Thu, 3 Jan 2002 06:16:43 -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 GAA145688; Thu, 3 Jan 2002 06:13:24 -0500 Received: from d03nm014.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 g03BG94243136; Thu, 3 Jan 2002 04:16:09 -0700 Importance: Normal Subject: Re: iSCSI: "conservative reuse" requirement To: "Mallikarjun C." Cc: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Thu, 3 Jan 2002 03:15:23 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 01/03/2002 04:16:08 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mallikarjun, Perhaps I have spotted the problem we are having with the notes we are exchanging. If you read the section below with the eye that says that the words iSCSI Target is defined (in the iSCSI Draft) to be what we are calling the iSCSI Target Node, I think you will see that what I am saying and what the Draft Said is basically 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 "Mallikarjun C." @ece.cmu.edu on 01/02/2002 06:12:32 PM Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS cc: Subject: Re: iSCSI: "conservative reuse" requirement John, >This is called Conservative Reuse > since when we start/restart a session we are not choosing a different ISID. That doesn't seem to be what's meant by rev09 when it says in section 9.1.1 - " the same ISID should be used in the Login process to multiple target portal groups (of the same iSCSI Target or different iSCSI Targets)." and further it says - "The principle of conservative reuse "encourages" reuse to other target portal groups. When a SCSI target device sees the same (InitiatorName, ISID) pair in different sessions to different target portal groups, it can identify the underlying SCSI Initiator Port on each session as the same SCSI port (in effect, it can recognize multiple paths from the same source)." >The Name of the SCSI Initiator Port is made > up of the iSCSI Initiator Node Name and the ISID. Just a nit - also includes the letter 'i'! > If those other iSCSI Initiators have HBAs which have been made by the same ^^^^^^^ Somehow it appears to me that this isn't "carefully qualified", :-) Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ----- Original Message ----- From: "John Hufferd" To: Cc: ; Sent: Wednesday, January 02, 2002 4:57 PM Subject: Re: iSCSI: "conservative reuse" requirement > > Mallikarjun, > Comments in line between [Huff/] and [\Huff]. > > . > . > . > 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 > > > "Mallikarjun C." @ece.cmu.edu on 01/02/2002 01:21:13 PM > > Please respond to cbm@rose.hp.com > > Sent by: owner-ips@ece.cmu.edu > > > To: Black_David@emc.com > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: "conservative reuse" requirement > > > > Now that I'm back from vacation, let me offer some (delayed) > comments on this. I also read Jim's reply where he appeared > to mostly agree with me. > > >...as long as it presented > > each of them to all target ports... > > I disagree with your assumption that an initiator must > "present" *all* its ports to every target port in a target > device. Each distinct initiator port (signified by a unique > ISID) may want to talk to only one target port (i.e. one portal > group) - that's a typical usage of multi-HBA (i.e. multi-port) > hosts talking to multi-FC port targets today. As far as I > can understand, a mandatory "conservative reuse" would > preclude this usage. Please comment if your visualization > of conservative reuse is different. > > [Huff/] > We have now fallen into the problem that Jim, Julian, Marjorie, and I spent > the Holidays exchanging e-Mails about. You use the term Initiator to > represent the Total Initiator Node (and indeed our draft definitions > encourage that view). However, some others, when they talk, use the SCSI > interpretation of the word Initiator, which is the SCSI Initiator Port. So > as Marjorie has clearly pointed out to me, I need to be more precise, and I > think the rest of us also. We need to fully qualify the term Initiator > when we use it, in these types of discussions. We need to say iSCSI > Initiator Node, or SCSI Initiator Port etc. So let me try that below, in > hopes of perhaps clearing up some concepts. > > The use of Conservative Reuse applies to the how the Name of the SCSI > Initiator Port will be chosen. The Name of the SCSI Initiator Port is made > up of the iSCSI Initiator Node Name and the ISID. > > We are attempting to ensure that any one SCSI Initiator Port will not pick > various different ISIDs in a manner that will prevent the Persistent > Reserves from being reestablished across a Session Restart. To do that we > strongly suggest that the Vendor follow the Type and Vendor ID approach to > creating and ISID as specified in version 9 of the Draft. Also they should > pick the 16 bit Qualifier part in a way that will usually be the same > number each time a Session from that SCSI Initiator Port is restarted. The > easiest way to do this is for the iSCSI Process to Identify the SCSI > Initiator Port with the same ISID Qualifier every time an iSCSI Session is > started with any SCSI Target Port (via its iSCSI Target Portal Group). > > When this is done, everything works. This is called Conservative Reuse > since when we start/restart a session we are not choosing a different ISID. > > Please note I did not restrict the actions of any other SCSI Initiator Port > within the iSCSI Initiator Node. They can each have their own ISID and use > the iSCSI Transport to connect to what ever SCSI Target Nodes they wish. > If those other iSCSI Initiators have HBAs which have been made by the same > vendor (and if that vendor does not support Multiple Connections per > Session across the HBAs), it is the Vendors responsibility to chose an ISID > Qualifier for its second (and subsequent) SCSI Initiator Port, which does > not conflict with the first one. When done correctly, then if by chance, > the second SCSI Initiator Port connects to the same SCSI Target Port to > which the First one connected, they will each be seen, by the Target, as > different Sessions from different SCSI Initiator Ports and things are > completely legal. > > In this case, as it is in Fibre Channel, the Host (iSCSI Initiator Node) > will have to be very careful how work is handed out to the different SCSI > Initiator Ports, so that Work arrives in the correct order and there is no > conflicts with Reserves. (The process that does that balancing between the > HBAs is what, in Fibre Channel, we have called a Wedge Driver). > > So what I have said above, is that when we carefully qualify the Term > Initiator, we can see that Conservative Reuse does NOT cause any > restrictions on the way we use the Sessions within an iSCSI Initiator Node. > [\Huff] > > OTOH, I can see that the ability of *one* initiator SCSI > port to establish nexii with multiple target SCSI ports in > a target device is highly desirable (perhaps even T10-required > shortly). IMO, iSCSI had already met this need by defining > and enabling "conservative reuse", and that's where we should > stop. I would actually advocate wording along the lines of - > > "When a given initiator implementation seeks to present > a single SCSI port abstraction to multiple target portal > groups (thus multiple SCSI target ports) of an iSCSI target > node, conservative reuse is the means to realize it. > Conservative reuse hence MUST be used in this case." > > and leave it at that. > -- > Mallikarjun > > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > > Black_David@emc.com wrote: > > > > Not exactly. "Conservative Reuse" would allow an initiator > > to present multiple initiator ports, as long as it presented > > each of them to all target ports (assuming that the connectivity > > exists). Why would an Initiator want to present different > > ports to different target portal groups? I don't think there's > > another example in which SCSI behaves this way in practice. > > > > --David > > > > > -----Original Message----- > > > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > > > Sent: Monday, December 24, 2001 12:47 AM > > > To: Black_David@emc.com > > > Cc: ips@ece.cmu.edu > > > Subject: Re: iSCSI: "conservative reuse" requirement > > > > > > > > > > I think this is headed towards "conservative reuse" being a MUST if > > > > we're serious about support for shared persistent reservations. > > > > > > Mandating "conservative reuse" appears to force initiators to > > > always act > > > as a single initiator port (wrt one target; assuming only one > > > session as an > > > example) per initiator device - which rules out the case of > > > an initiator > > > intentionally wanting to present a different port to each > > > target portal group. > > > > > > IMHO, if iSCSI provides an architected mechanism to support shared > > > persistent reservations ("conservative reuse"), that should > > > be completely > > > adequate to meet the expectations to be a legal SCSI protocol. > > > -- > > > Mallikarjun > > > > > > Mallikarjun Chadalapaka > > > Networked Storage Architecture > > > Network Storage Solutions Organization > > > Hewlett-Packard MS 5668 > > > Roseville CA 95747 > > > > > > ----- Original Message ----- > > > From: > > > To: > > > Cc: > > > Sent: Friday, December 21, 2001 4:50 PM > > > Subject: iSCSI: "conservative reuse" requirement > > > > > > > > > > Santosh Rao writes: > > > > > > > > > I am opposed to the suggestion that "conservative re-use" > > > of ISIDs be > > > > > made a MUST. This is really only required when initiators > > > need to be > > > > > using the new T10 Reservation scheme that can be shared > > > > > across initiator ports. > > > > > > > > Those reservations are a Target feature. With this > > > approach, the ability > > > > to use the target feature depends on details of the initiator > > > > implementation. > > > > More below ... > > > > > > > > > For those initiators that don't care about this type of > > > reservation, > > > > > conservative re-use is of no use and initiators may like to assign > > > > > ISID's in a per-initiator node fashion, thereby, being > > > able to use these > > > > > ISIDs as a lookup index for the sessions on that initiator node. > > > > > > > > > > Hence, I suggest that "conservative re-use" be worded as > > > > > "encouraged to use" or something to that effect, but not MUST USE. > > > > > > > > > > Comments ? > > > > > > > > The "initiator" is more than one entity. The iSCSI HBA/NIC > > > and driver > > > > doesn't know whether shared persistent reservations are > > > being used and > > > > shouldn't have to care - they're just more SCSI commands to > > > transport. > > > > Some other entity (e.g., clustering software) will be generating the > > > > shared persistent reservations. This raise the possible scenario > > > > involving a target that supports the new shared persistent > > > reservations > > > > and an entity that wants to use them. The entity detects > > > (via SCSI means, > > > > e.g., something in a mode page) that the Target supports > > > shared persistent > > > > reservations, tries to use them, only to discover that they > > > don't work > > > > because the iSCSI HBA/NIC doesn't implement "conservative reuse". > > > > > > > > I'm worried about this causing both interoperability issues > > > and possible > > > > T10 issues -- from a T10 viewpoint, if shared persistent > > > reservations > > > > don't work, the initiating entity should have some SCSI-level means > > > > of determining this ... if that means exists only on the Target, the > > > > above scenario is iSCSI's problem (Target can't query Initiator to > > > > determine whether it does "conservative reuse"), and having > > > a separate > > > > initiator side means that the entity has to check only for > > > iSCSI (and > > > > not for any other SCSI transport) does not seem like the right > > > > approach. > > > > > > > > I think this is headed towards "conservative reuse" being a MUST if > > > > we're serious about support for shared persistent reservations. > > > > > > > > Comments? > > > > --David > > > > --------------------------------------------------- > > > > David L. Black, Senior Technologist > > > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > > > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > > > > black_david@emc.com Cell: +1 (978) 394-7754 > > > > --------------------------------------------------- > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Thu Jan 3 12:11: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 MAA06212 for ; Thu, 3 Jan 2002 12:11:20 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g03GbGJ04177 for ips-outgoing; Thu, 3 Jan 2002 11:37:16 -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.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g03GbFg04173 for ; Thu, 3 Jan 2002 11:37:15 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jan 2002 11:32:38 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029372E0@CORPMX14> From: Black_David@emc.com To: nitin.dhingra@dcmtech.co.in, ips@ece.cmu.edu Subject: RE: iScsi: Date: Thu, 3 Jan 2002 11:24:57 -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 > Well, let's take a case > where you have one target and many initiators connected that target > > And as iScsi is at block level, so if more than one initiator have requested > to write at the same block address at the same time at the same target > this can create synchronization problems, don't you think? > > Shouldn't you give an option like most other protocols like NFS does, > where you have a separate optional layer for locking/synchronization... > > Don't you think this should be handled by iScsi?? NO!!! Believing that SCSI should operate like NFS is a major mistake; they are completely different classes of protocols solving very different problems. Adding a locking/synchronization layer would introduce an immense amount of cruft to the Target implementations. When data is shared over SCSI, the coordination generally happens at a coarser level (e.g., persistent reservations) or at a higher level (e.g., some sort of distributed filesystem code, two examples are Tivoli's SANergy and EMC's HighRoad). As John Hufferd wrote: > I think you need to understand how SCSI on Shared Devices work. If you do > not coordinate either via a Shared File System or Shared Data Base, or SCSI > Reserves, you clearly have a problem. But this is a well known issue and > has been solved years ago with multiple SCSI Bus connections to the same > Storage Controller, and currently applies to Fiber Channel as well as > iSCSI. Nothing new is needed in the iSCSI protocol. I completely agree with John. Beyond this, if one wants to make this sort of major functional change to SCSI, T10 is the right forum - this type of work cannot and will not be done in the IETF, if for no other reason than the IPS WG charter has wording that forbids it. A strong architectural understanding of SCSI is a major prerequisite to attempting to make this sort of change. Within the past year or so, there was a proposal made to T10 to do this sort of thing for SCSI in general, and (IMHO) the proponents' lack of this architectural understanding is one of the reasons it never went anywhere. I would also recommend looking at the work on the OSD SCSI command set that is in progress in T10 (which is digging in a related area), but I would caution that there appears to be a distinct lack of enthusiasm and interest in implementing that command set. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Jan 3 12:11: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 MAA06223 for ; Thu, 3 Jan 2002 12:11:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g03GDcR02668 for ips-outgoing; Thu, 3 Jan 2002 11:13:38 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g03GDag02664 for ; Thu, 3 Jan 2002 11:13:36 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jan 2002 11:13:29 -0500 Message-ID: <25369470B6F0D41194820002B328BDD22022D1@ATLOPS> From: Eddy Quicksall To: Nitin Dhingra , ips@ece.cmu.edu Subject: RE: iScsi: Date: Thu, 3 Jan 2002 11:13: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 Think of it this way ... if NFS is used to communicate with a server then iSCSI is a transport that the NFS server uses to access the storage. NFS has already resolved the issue you site before it hits iSCSI. I don't think we intend to have iSCSI do the full job of NFS ... in cases where NFS is not being used, there would be some other higher layer that would coordinate the I/O and I believe that clustering software does that. Does that make sense? Eddy -----Original Message----- From: Nitin Dhingra [mailto:nitin.dhingra@dcmtech.co.in] Sent: Thursday, January 03, 2002 12:07 AM To: 'Black_David@emc.com'; ips@ece.cmu.edu Subject: RE: iScsi: Well, let's take a case where you have one target and many initiators connected that target And as iScsi is at block level, so if more than one initiator have requested to write at the same block address at the same time at the same target this can create synchronization problems, don't you think? Shouldn't you give an option like most other protocols like NFS does, where you have a separate optional layer for locking/synchronization... Don't you think this should be handled by iScsi?? - Nitin -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Wednesday, January 02, 2002 3:10 PM To: nitin.dhingra@dcmtech.co.in; ips@ece.cmu.edu Subject: RE: iScsi: I don't understand this - what exactly is broken that you think needs to be fixed? Many SCSI targets do implement access controls at the logical unit level, which is in T10's domain, not iSCSI's. --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: Nitin Dhingra [mailto:nitin.dhingra@dcmtech.co.in] > Sent: Wednesday, January 02, 2002 12:40 AM > To: ips@ece.cmu.edu > Subject: iScsi: > > > Why don't you put a restriction on the read/write access to a target? > This can solve some of the synchronization problems that can occur... > > And Yeah Happy New Year to All... > > - Nitin > From owner-ips@ece.cmu.edu Thu Jan 3 12:11: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 MAA06234 for ; Thu, 3 Jan 2002 12:11:34 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g03G4SX02013 for ips-outgoing; Thu, 3 Jan 2002 11:04: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 (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g03G4Pg02005 for ; Thu, 3 Jan 2002 11:04:26 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jan 2002 11:04:19 -0500 Message-ID: <25369470B6F0D41194820002B328BDD22022D0@ATLOPS> From: Eddy Quicksall To: John Hufferd , cbm@rose.hp.com Cc: Black_David@emc.com, ips@ece.cmu.edu Subject: RE: iSCSI: "conservative reuse" requirement Date: Thu, 3 Jan 2002 11:04: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 John, I like your wording here much better. I was thinking that if we could relate directly to SAM-2, wouldn't that solve these problems? SAM-2 has a SCSI Initiator Device with an Initiator Device Name; and the device has one or more SCSI Initiator Ports, each of which have an Initiator Port Identifier and an optional Initiator Port Name. IMHO, SAM-2's Initiator Device Name should be our InitiatorName, the Initiator Port Identifier should be the ISID and the Initiator Port Name should be the concatenation of InitiatorName+i+ISID. The Initiator Port Name has to be World Wide Unique but the Initiator Port Identifier does not. That would really make things relate well. Given that they relate well, understanding of SAM-2 would give better understanding of "conservative reuse" and simplify the clause. Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Wednesday, January 02, 2002 7:58 PM To: cbm@rose.hp.com Cc: Black_David@emc.com; ips@ece.cmu.edu Subject: Re: iSCSI: "conservative reuse" requirement Mallikarjun, Comments in line between [Huff/] and [\Huff]. . . . 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 "Mallikarjun C." @ece.cmu.edu on 01/02/2002 01:21:13 PM Please respond to cbm@rose.hp.com Sent by: owner-ips@ece.cmu.edu To: Black_David@emc.com cc: ips@ece.cmu.edu Subject: Re: iSCSI: "conservative reuse" requirement Now that I'm back from vacation, let me offer some (delayed) comments on this. I also read Jim's reply where he appeared to mostly agree with me. >...as long as it presented > each of them to all target ports... I disagree with your assumption that an initiator must "present" *all* its ports to every target port in a target device. Each distinct initiator port (signified by a unique ISID) may want to talk to only one target port (i.e. one portal group) - that's a typical usage of multi-HBA (i.e. multi-port) hosts talking to multi-FC port targets today. As far as I can understand, a mandatory "conservative reuse" would preclude this usage. Please comment if your visualization of conservative reuse is different. [Huff/] We have now fallen into the problem that Jim, Julian, Marjorie, and I spent the Holidays exchanging e-Mails about. You use the term Initiator to represent the Total Initiator Node (and indeed our draft definitions encourage that view). However, some others, when they talk, use the SCSI interpretation of the word Initiator, which is the SCSI Initiator Port. So as Marjorie has clearly pointed out to me, I need to be more precise, and I think the rest of us also. We need to fully qualify the term Initiator when we use it, in these types of discussions. We need to say iSCSI Initiator Node, or SCSI Initiator Port etc. So let me try that below, in hopes of perhaps clearing up some concepts. The use of Conservative Reuse applies to the how the Name of the SCSI Initiator Port will be chosen. The Name of the SCSI Initiator Port is made up of the iSCSI Initiator Node Name and the ISID. We are attempting to ensure that any one SCSI Initiator Port will not pick various different ISIDs in a manner that will prevent the Persistent Reserves from being reestablished across a Session Restart. To do that we strongly suggest that the Vendor follow the Type and Vendor ID approach to creating and ISID as specified in version 9 of the Draft. Also they should pick the 16 bit Qualifier part in a way that will usually be the same number each time a Session from that SCSI Initiator Port is restarted. The easiest way to do this is for the iSCSI Process to Identify the SCSI Initiator Port with the same ISID Qualifier every time an iSCSI Session is started with any SCSI Target Port (via its iSCSI Target Portal Group). When this is done, everything works. This is called Conservative Reuse since when we start/restart a session we are not choosing a different ISID. Please note I did not restrict the actions of any other SCSI Initiator Port within the iSCSI Initiator Node. They can each have their own ISID and use the iSCSI Transport to connect to what ever SCSI Target Nodes they wish. If those other iSCSI Initiators have HBAs which have been made by the same vendor (and if that vendor does not support Multiple Connections per Session across the HBAs), it is the Vendors responsibility to chose an ISID Qualifier for its second (and subsequent) SCSI Initiator Port, which does not conflict with the first one. When done correctly, then if by chance, the second SCSI Initiator Port connects to the same SCSI Target Port to which the First one connected, they will each be seen, by the Target, as different Sessions from different SCSI Initiator Ports and things are completely legal. In this case, as it is in Fibre Channel, the Host (iSCSI Initiator Node) will have to be very careful how work is handed out to the different SCSI Initiator Ports, so that Work arrives in the correct order and there is no conflicts with Reserves. (The process that does that balancing between the HBAs is what, in Fibre Channel, we have called a Wedge Driver). So what I have said above, is that when we carefully qualify the Term Initiator, we can see that Conservative Reuse does NOT cause any restrictions on the way we use the Sessions within an iSCSI Initiator Node. [\Huff] OTOH, I can see that the ability of *one* initiator SCSI port to establish nexii with multiple target SCSI ports in a target device is highly desirable (perhaps even T10-required shortly). IMO, iSCSI had already met this need by defining and enabling "conservative reuse", and that's where we should stop. I would actually advocate wording along the lines of - "When a given initiator implementation seeks to present a single SCSI port abstraction to multiple target portal groups (thus multiple SCSI target ports) of an iSCSI target node, conservative reuse is the means to realize it. Conservative reuse hence MUST be used in this case." and leave it at that. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Black_David@emc.com wrote: > > Not exactly. "Conservative Reuse" would allow an initiator > to present multiple initiator ports, as long as it presented > each of them to all target ports (assuming that the connectivity > exists). Why would an Initiator want to present different > ports to different target portal groups? I don't think there's > another example in which SCSI behaves this way in practice. > > --David > > > -----Original Message----- > > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > > Sent: Monday, December 24, 2001 12:47 AM > > To: Black_David@emc.com > > Cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: "conservative reuse" requirement > > > > > > > I think this is headed towards "conservative reuse" being a MUST if > > > we're serious about support for shared persistent reservations. > > > > Mandating "conservative reuse" appears to force initiators to > > always act > > as a single initiator port (wrt one target; assuming only one > > session as an > > example) per initiator device - which rules out the case of > > an initiator > > intentionally wanting to present a different port to each > > target portal group. > > > > IMHO, if iSCSI provides an architected mechanism to support shared > > persistent reservations ("conservative reuse"), that should > > be completely > > adequate to meet the expectations to be a legal SCSI protocol. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > > > > ----- Original Message ----- > > From: > > To: > > Cc: > > Sent: Friday, December 21, 2001 4:50 PM > > Subject: iSCSI: "conservative reuse" requirement > > > > > > > Santosh Rao writes: > > > > > > > I am opposed to the suggestion that "conservative re-use" > > of ISIDs be > > > > made a MUST. This is really only required when initiators > > need to be > > > > using the new T10 Reservation scheme that can be shared > > > > across initiator ports. > > > > > > Those reservations are a Target feature. With this > > approach, the ability > > > to use the target feature depends on details of the initiator > > > implementation. > > > More below ... > > > > > > > For those initiators that don't care about this type of > > reservation, > > > > conservative re-use is of no use and initiators may like to assign > > > > ISID's in a per-initiator node fashion, thereby, being > > able to use these > > > > ISIDs as a lookup index for the sessions on that initiator node. > > > > > > > > Hence, I suggest that "conservative re-use" be worded as > > > > "encouraged to use" or something to that effect, but not MUST USE. > > > > > > > > Comments ? > > > > > > The "initiator" is more than one entity. The iSCSI HBA/NIC > > and driver > > > doesn't know whether shared persistent reservations are > > being used and > > > shouldn't have to care - they're just more SCSI commands to > > transport. > > > Some other entity (e.g., clustering software) will be generating the > > > shared persistent reservations. This raise the possible scenario > > > involving a target that supports the new shared persistent > > reservations > > > and an entity that wants to use them. The entity detects > > (via SCSI means, > > > e.g., something in a mode page) that the Target supports > > shared persistent > > > reservations, tries to use them, only to discover that they > > don't work > > > because the iSCSI HBA/NIC doesn't implement "conservative reuse". > > > > > > I'm worried about this causing both interoperability issues > > and possible > > > T10 issues -- from a T10 viewpoint, if shared persistent > > reservations > > > don't work, the initiating entity should have some SCSI-level means > > > of determining this ... if that means exists only on the Target, the > > > above scenario is iSCSI's problem (Target can't query Initiator to > > > determine whether it does "conservative reuse"), and having > > a separate > > > initiator side means that the entity has to check only for > > iSCSI (and > > > not for any other SCSI transport) does not seem like the right > > > approach. > > > > > > I think this is headed towards "conservative reuse" being a MUST if > > > we're serious about support for shared persistent reservations. > > > > > > Comments? > > > --David > > > --------------------------------------------------- > > > David L. Black, Senior Technologist > > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > > > black_david@emc.com Cell: +1 (978) 394-7754 > > > --------------------------------------------------- > > > > > > > > From owner-ips@ece.cmu.edu Thu Jan 3 12: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 MAA06350 for ; Thu, 3 Jan 2002 12:17:20 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g03GKqS03146 for ips-outgoing; Thu, 3 Jan 2002 11:20:52 -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 g03GKpg03142 for ; Thu, 3 Jan 2002 11:20:51 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jan 2002 11:20:45 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029372DF@CORPMX14> From: Black_David@emc.com To: cbm@rose.hp.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: "conservative reuse" requirement Date: Thu, 3 Jan 2002 11:08:34 -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 > Thanks for the message. Let me comment on what I agree with first. > > >if "conservative reuse" does not > > happen (breaking shared persistent reservations), the reason that > > it does not happen MUST be externally configurable as opposed to > > being an unchangeable internal characteristic of the implementation. > > Agreed. If I understand you correctly, you're concerned that NICs > that are hard-coded not to allow single initiator port abstraction (i.e. that > don't do conservative reuse) will break the new shared persistent reservations. > I agree that it currently is an issue, I propose that we have a NIC requirement > in the implementation notes (like the node name configurability requirement) > that says something like - Every iSCSI NIC MUST provide a means of > enabling a strict "conservative reuse" of ISIDs across different target portal > groups. Good. Once that's done, what's the value in permitting operating modes other than "conservative reuse"? The risk of multiple operating modes is that there'll be: - The mode that works, and - The mode that complies with the standards. Having only one mode avoids this problem. Don't laugh too loudly - versions of this situation are occurring in Fibre Channel switches today. > With that said, here's the idea (repeated in several places) > that I have a problem with - > > every possible connection is > > attempted, and the reasons that not every connection is established > > are external (and configurable, modulo physical constraints). > > First off, I am not sure what you meant by "connection" here, and "presented" > in your previous message. I took it that you meant "establishing a SCSI nexus". > If that's indeed so, the assertion that it's only the external factors that decide > nexii is not always true. Consider the case of an FC initiator > port discovering target ports using an FC Name Server, and an iSCSI initiator > port discovering target ports using a "SendTargets" command. In either case, > the initiator SCSI port may not really establish a nexus with a discovered > target SCSI port, unless the application (or > even the SCSI class driver) really wants to do an I/O (starting with an open() > system call in Unix systems). I strongly disagree with that. Virtually all commercial OS implementations of SCSI do aggressive establishments of the nexii as part of the boot sequence, as SCSI code tends to expect a "bus walker" to find devices in the boot sequence, and make sure they work. Put a trace analyzer to work on a boot and watch all the TEST UNIT READY and similar commands flow by. Is anyone making significant changes to this "bus walker" boot paradigm out there? There's also a subtle issue to watch out for here in that this delays error discovery - if the shared persistent reservations are being used by cluster software, discovering that the alternate path nexus can't be established when trying to fail over to it is way too late. For things like quorum volumes, I'm fairly sure that cluster software checks all the access paths at initialization time, but can someone familiar with cluster software comment on whether the alternate access paths needed for failover of application volumes are checked in advance, vs. relying on the OS to complain if the SCSI connection to the device didn't set up correctly? > But in any case, it appears to be in the implementation territory. That's something I can agree with - namely that when nexii are established is an orthogonal issue to the session identifiers used to establish them, although I would caution implementers that there's a lot of code out there that operates under the "bus walker" paradigm and hence wants to see nexii (sessions) established aggressively. In a code stack that doesn't operate under the "bus walker" paradigm, "conservative reuse" is still applicable, as it need only constrain what ISIDs have to be used, and not when they are used. Taking a whack at requirements, I think there are at least two of them: - MUST support "conservative reuse" without requiring any iSCSI sessions to be terminated in order to set up the required sessions (i.e., one can take the ISID from an existing session and a target portal group to which that ISID is not in use and set up an iSCSI session with that ISID without having to terminate any existing session for ISID usage reasons - this is tricky to state precisely when the possibility of allowing sessions to be set up on the fly well after booting is allowed). - SHOULD use "conservative reuse" in setting up sessions from the same Initiator Portal Group (set of IP addresses) to different Target Portal Groups (i.e., reuse an existing ISID in preference to creating a new one). I presume the "mapping police" will let us know if Initiator Portal Group is not the right term for the second requirement ;-). Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Jan 3 14:08: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 OAA08463 for ; Thu, 3 Jan 2002 14:08:59 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g03ICXH09275 for ips-outgoing; Thu, 3 Jan 2002 13:12:33 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g03ICUg09268 for ; Thu, 3 Jan 2002 13:12:31 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jan 2002 13:12:24 -0500 Message-ID: <25369470B6F0D41194820002B328BDD22022D7@ATLOPS> From: Eddy Quicksall To: Black_David@emc.com, cbm@rose.hp.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: "conservative reuse" requirement Date: Thu, 3 Jan 2002 13:12:22 -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 - SHOULD use "conservative reuse" in setting up sessions from the same Initiator Portal Group (set of IP addresses) to different Target Portal Groups (i.e., reuse an existing ISID in preference to creating a new one). This gets my vote. Eddy -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Thursday, January 03, 2002 11:09 AM To: cbm@rose.hp.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: "conservative reuse" requirement > Thanks for the message. Let me comment on what I agree with first. > > >if "conservative reuse" does not > > happen (breaking shared persistent reservations), the reason that > > it does not happen MUST be externally configurable as opposed to > > being an unchangeable internal characteristic of the implementation. > > Agreed. If I understand you correctly, you're concerned that NICs > that are hard-coded not to allow single initiator port abstraction (i.e. that > don't do conservative reuse) will break the new shared persistent reservations. > I agree that it currently is an issue, I propose that we have a NIC requirement > in the implementation notes (like the node name configurability requirement) > that says something like - Every iSCSI NIC MUST provide a means of > enabling a strict "conservative reuse" of ISIDs across different target portal > groups. Good. Once that's done, what's the value in permitting operating modes other than "conservative reuse"? The risk of multiple operating modes is that there'll be: - The mode that works, and - The mode that complies with the standards. Having only one mode avoids this problem. Don't laugh too loudly - versions of this situation are occurring in Fibre Channel switches today. > With that said, here's the idea (repeated in several places) > that I have a problem with - > > every possible connection is > > attempted, and the reasons that not every connection is established > > are external (and configurable, modulo physical constraints). > > First off, I am not sure what you meant by "connection" here, and "presented" > in your previous message. I took it that you meant "establishing a SCSI nexus". > If that's indeed so, the assertion that it's only the external factors that decide > nexii is not always true. Consider the case of an FC initiator > port discovering target ports using an FC Name Server, and an iSCSI initiator > port discovering target ports using a "SendTargets" command. In either case, > the initiator SCSI port may not really establish a nexus with a discovered > target SCSI port, unless the application (or > even the SCSI class driver) really wants to do an I/O (starting with an open() > system call in Unix systems). I strongly disagree with that. Virtually all commercial OS implementations of SCSI do aggressive establishments of the nexii as part of the boot sequence, as SCSI code tends to expect a "bus walker" to find devices in the boot sequence, and make sure they work. Put a trace analyzer to work on a boot and watch all the TEST UNIT READY and similar commands flow by. Is anyone making significant changes to this "bus walker" boot paradigm out there? There's also a subtle issue to watch out for here in that this delays error discovery - if the shared persistent reservations are being used by cluster software, discovering that the alternate path nexus can't be established when trying to fail over to it is way too late. For things like quorum volumes, I'm fairly sure that cluster software checks all the access paths at initialization time, but can someone familiar with cluster software comment on whether the alternate access paths needed for failover of application volumes are checked in advance, vs. relying on the OS to complain if the SCSI connection to the device didn't set up correctly? > But in any case, it appears to be in the implementation territory. That's something I can agree with - namely that when nexii are established is an orthogonal issue to the session identifiers used to establish them, although I would caution implementers that there's a lot of code out there that operates under the "bus walker" paradigm and hence wants to see nexii (sessions) established aggressively. In a code stack that doesn't operate under the "bus walker" paradigm, "conservative reuse" is still applicable, as it need only constrain what ISIDs have to be used, and not when they are used. Taking a whack at requirements, I think there are at least two of them: - MUST support "conservative reuse" without requiring any iSCSI sessions to be terminated in order to set up the required sessions (i.e., one can take the ISID from an existing session and a target portal group to which that ISID is not in use and set up an iSCSI session with that ISID without having to terminate any existing session for ISID usage reasons - this is tricky to state precisely when the possibility of allowing sessions to be set up on the fly well after booting is allowed). - SHOULD use "conservative reuse" in setting up sessions from the same Initiator Portal Group (set of IP addresses) to different Target Portal Groups (i.e., reuse an existing ISID in preference to creating a new one). I presume the "mapping police" will let us know if Initiator Portal Group is not the right term for the second requirement ;-). Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Jan 3 14:45: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 OAA09480 for ; Thu, 3 Jan 2002 14:45:39 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g03Isw411824 for ips-outgoing; Thu, 3 Jan 2002 13:54:58 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g03Isug11820 for ; Thu, 3 Jan 2002 13:54:56 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel8.hp.com (Postfix) with ESMTP id A1D3CE00615; Thu, 3 Jan 2002 13:54:46 -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 KAA01268; Thu, 3 Jan 2002 10:56:20 -0800 (PST) Message-Id: <200201031856.KAA01268@core.rose.hp.com> Date: Thu, 03 Jan 2002 11:08:14 -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: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: "conservative reuse" requirement References: <277DD60FB639D511AC0400B0D068B71E029372DF@CORPMX14> 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 we're getting close to wrapping this up. >Once that's done, what's the value in permitting operating modes > other than "conservative reuse"? I thought we already discussed this - that of two initiator NICs each establishing a session (acting as independent initiator ports) to a different target portal group. >Is anyone > making significant changes to this "bus walker" boot paradigm out there? Not that I know of. But keep in mind that the nexii established for the boot discovery process may not have to be kept around persistently by initiators (as a matter of fact, I know that HP-UX does not). There are also other cases - DLKM drivers, dynamically discovered targets etc - which do not have nexii from boot time. But again, I prefer to leave it there since this is a little orthogonal to the current issue. > - SHOULD use "conservative reuse" in setting up sessions I guess this is okay, the other alternative/complement is wording (proposed earlier in this thread) that focuses on where conservative reuse is a MUST. > - SHOULD use "conservative reuse" in setting up sessions from the same > Initiator Portal Group (set of IP addresses) to different Target > Portal Groups In the sense you used "initiator portal group" here, it ought to be defined (otherwise, simply use "initiator node" in your sentence) as "the set of initiator portals sharing the same ISID Type & ISID Naming Authority values and sharing one ISID Qualifier name space, and that allow a session to span an arbitrary subset of the portals." IOW, if two NICs A and B from the same vendor (so same Type and Naming Authority) are present in a host (so share the ISID Qualifier space, perhaps with a s/w "ISID allocator" in the host or whatever), but can not span a session across them, then they are technically two independent "initiator portal groups". Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Black_David@emc.com wrote: > > > Thanks for the message. Let me comment on what I agree with first. > > > > >if "conservative reuse" does not > > > happen (breaking shared persistent reservations), the reason that > > > it does not happen MUST be externally configurable as opposed to > > > being an unchangeable internal characteristic of the implementation. > > > > Agreed. If I understand you correctly, you're concerned that NICs > > that are hard-coded not to allow single initiator port abstraction (i.e. > that > > don't do conservative reuse) will break the new shared persistent > reservations. > > I agree that it currently is an issue, I propose that we have a NIC > requirement > > in the implementation notes (like the node name configurability > requirement) > > that says something like - Every iSCSI NIC MUST provide a means of > > enabling a strict "conservative reuse" of ISIDs across different target > portal > > groups. > > Good. Once that's done, what's the value in permitting operating modes > other than "conservative reuse"? The risk of multiple operating modes is > that there'll be: > - The mode that works, and > - The mode that complies with the standards. > Having only one mode avoids this problem. Don't laugh too loudly - > versions of this situation are occurring in Fibre Channel switches > today. > > > With that said, here's the idea (repeated in several places) > > that I have a problem with - > > > every possible connection is > > > attempted, and the reasons that not every connection is established > > > are external (and configurable, modulo physical constraints). > > > > First off, I am not sure what you meant by "connection" here, and > "presented" > > in your previous message. I took it that you meant "establishing a SCSI > nexus". > > If that's indeed so, the assertion that it's only the external factors > that decide > > nexii is not always true. Consider the case of an FC initiator > > port discovering target ports using an FC Name Server, and an iSCSI > initiator > > port discovering target ports using a "SendTargets" command. In either > case, > > the initiator SCSI port may not really establish a nexus with a discovered > > target SCSI port, unless the application (or > > even the SCSI class driver) really wants to do an I/O (starting with an > open() > > system call in Unix systems). > > I strongly disagree with that. Virtually all commercial OS implementations > of SCSI do aggressive establishments of the nexii as part of the boot > sequence, > as SCSI code tends to expect a "bus walker" to find devices in the boot > sequence, and make sure they work. Put a trace analyzer to work on a boot > and watch all the TEST UNIT READY and similar commands flow by. Is anyone > making significant changes to this "bus walker" boot paradigm out there? > > There's also a subtle issue to watch out for here in that this delays > error discovery - if the shared persistent reservations are being > used by cluster software, discovering that the alternate path nexus can't > be established when trying to fail over to it is way too late. For things > like quorum volumes, I'm fairly sure that cluster software checks all the > access paths at initialization time, but can someone familiar with cluster > software comment on whether the alternate access paths needed for failover > of application volumes are checked in advance, vs. relying on the OS to > complain if the SCSI connection to the device didn't set up correctly? > > > But in any case, it appears to be in the implementation territory. > > That's something I can agree with - namely that when nexii are established > is an orthogonal issue to the session identifiers used to establish > them, although I would caution implementers that there's a lot of code > out there that operates under the "bus walker" paradigm and hence wants > to see nexii (sessions) established aggressively. In a code stack that > doesn't operate under the "bus walker" paradigm, "conservative reuse" > is still applicable, as it need only constrain what ISIDs have to be > used, and not when they are used. > > Taking a whack at requirements, I think there are at least two of them: > - MUST support "conservative reuse" without requiring any iSCSI sessions > to be terminated in order to set up the required sessions (i.e., > one can take the ISID from an existing session and a target portal > group to which that ISID is not in use and set up an iSCSI session > with that ISID without having to terminate any existing session for > ISID usage reasons - this is tricky to state precisely when the > possibility of allowing sessions to be set up on the fly well after > booting is allowed). > - SHOULD use "conservative reuse" in setting up sessions from the same > Initiator Portal Group (set of IP addresses) to different Target > Portal Groups (i.e., reuse an existing ISID in preference to > creating a new one). > I presume the "mapping police" will let us know if Initiator Portal Group > is not the right term for the second requirement ;-). > > Thanks, > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > black_david@emc.com Cell: +1 (978) 394-7754 > --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Jan 3 14:47: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 OAA09579 for ; Thu, 3 Jan 2002 14:47:43 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g03JQK013730 for ips-outgoing; Thu, 3 Jan 2002 14:26:20 -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 g03JQJg13726 for ; Thu, 3 Jan 2002 14:26:19 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jan 2002 14:26:13 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029372E5@CORPMX14> From: Black_David@emc.com To: cbm@rose.hp.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: "conservative reuse" requirement Date: Thu, 3 Jan 2002 14:13: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 > >Once that's done, what's the value in permitting operating modes > > other than "conservative reuse"? > > I thought we already discussed this - that of two initiator NICs > each establishing a session (acting as independent initiator ports) > to a different target portal group. That's actually the same "operating mode" as far as I'm concerned - one assigns a separate ISID to each NIC, and then some sort of configuration restriction prevents each NIC from talking to both Target Portal Groups (i.e., if one of the NICs could talk to both Target Portal Groups, it would use the same ISID(s) for its session(s) to both TPGs). One NIC with one session to each of two different Target Portal Groups really ought to be using the same ISID for each session. > > - SHOULD use "conservative reuse" in setting up sessions > > I guess this is okay, the other alternative/complement is wording > (proposed earlier in this thread) that focuses on where conservative > reuse is a MUST. I think a complementary "MUST implement" and "SHOULD use" are needed: - MUST implement "conservative reuse" of ISIDs in a fashion that doesn't require session teardown. In the above example, it would be wrong to have to reset one of the NICs in order to get it to use the same ISID to talk to both Target Portal Groups. - SHOULD use "conservative reuse" of ISIDs in setting up sessions (i.e., in the absence of some sort of configuration setting that forces "conservative reuse"). The MUST is needed to avoid the "two operating modes" problem. The SHOULD is to encourage persistent shared reserves to "just work" without annoying additional configuration fiddling, and may need an additional MUST to force "conservative reuse". It would be simpler to make "conservative reuse" a "MUST use", but I've heard objections to that ... so the above is what the alternative appears to look like. > > > - SHOULD use "conservative reuse" in setting up sessions from the same > > Initiator Portal Group (set of IP addresses) to different Target > > Portal Groups > > In the sense you used "initiator portal group" here, it ought > to be defined (otherwise, simply use "initiator node" in your sentence) > as "the set of initiator portals sharing the same ISID Type & ISID > Naming Authority values and sharing one ISID Qualifier name space, > and that allow a session to span an arbitrary subset of the portals." That sounds about right, thanks. > IOW, if two NICs A and B from the same vendor (so same Type and Naming > Authority) are present in a host (so share the ISID Qualifier space, > perhaps with a s/w "ISID allocator" in the host or whatever), but can > not span a session across them, then they are technically two independent > "initiator portal groups". Yes, that specific example is definitely ok. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Jan 3 15:31: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 PAA10583 for ; Thu, 3 Jan 2002 15:31:36 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g03Jl5A15108 for ips-outgoing; Thu, 3 Jan 2002 14:47:05 -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 g03Jl0g15099 for ; Thu, 3 Jan 2002 14:47:01 -0500 (EST) Received: from xparelay2.corp.hp.com (xparelay2.corp.hp.com [15.58.137.112]) by palrel10.hp.com (Postfix) with ESMTP id 135D74008B0; Thu, 3 Jan 2002 11:46:55 -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 C24224000B6; Thu, 3 Jan 2002 11:46:27 -0800 (PST) Received: by xpabh1.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jan 2002 11:46:54 -0800 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF2E8@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Black_David@emc.com'" , cbm@rose.hp.com Cc: ips@ece.cmu.edu Subject: iSCSI: establish a nexus with everything you see? Date: Thu, 3 Jan 2002 11:46:53 -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've changed the subject line cause we're going off on a tangent that isn't really associated with conservative reuse. > > If that's indeed so, the assertion that it's only the external factors > > that decide > > nexii is not always true. Consider the case of an FC initiator > > port discovering target ports using an FC Name Server, and an iSCSI > > initiator port discovering target ports using a "SendTargets" > > command. In either case, > > the initiator SCSI port may not really establish a nexus > > with a discovered target SCSI port, unless the application (or > > even the SCSI class driver) really wants to do an I/O > >(starting with an open() system call in Unix systems). > > I strongly disagree with that. Virtually all commercial OS implementations > of SCSI do aggressive establishments of the nexii as part of the boot sequence, > as SCSI code tends to expect a "bus walker" to find devices in the boot > sequence, and make sure they work. Put a trace analyzer to work on a boot > and watch all the TEST UNIT READY and similar commands flow by. Is anyone > making significant changes to this "bus walker" boot paradigm out there? I disagree with your notion of the "aggressive establishments" behavior being good and desirable. In practical implementations, it causes many problems for FC networks when these over-zealous implementations grab disks that aren't intended for them. Elaborate zoning methods were developed to try to alleviate these problems and haven't necessarily helped due to the complexity of configuring larger FC networks. Companies have made money developing software that reside between the host SCSI layer and FC drivers that "see" all the FC disks, but only establish nexus with those that have been properly allocated to this host :-) When you say "Virtually all commercial OS implementations" you must mean MS and Sun OS? Cause I can think of others that don't establish SCSI nexus in this manner. The whole concept of "plug-n-play" belies the notion that SCSI nexus must exist at boot time. > There's also a subtle issue to watch out for here in that this delays > error discovery - if the shared persistent reservations are being > used by cluster software, discovering that the alternate path nexus can't > be established when trying to fail over to it is way too late. For things > like quorum volumes, I'm fairly sure that cluster software checks all the > access paths at initialization time, but can someone familiar with cluster > software comment on whether the alternate access paths needed for failover > of application volumes are checked in advance, vs. relying on the OS to > complain if the SCSI connection to the device didn't set up correctly? Cluster software is a whole nother ballgame. I don't see how this is tied to the "agressive establishment" idea, except loosely. I'd expect a network with clustering software to be set up much differently than a simpler "singly attached storage" environment. Early iSCSI clustering networks may have to have SCSI nexus "preconfigured" in some manner to efficiently boot and bring up all alternate paths. Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard From owner-ips@ece.cmu.edu Thu Jan 3 15:35: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 PAA10698 for ; Thu, 3 Jan 2002 15:35:04 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g03K28T16100 for ips-outgoing; Thu, 3 Jan 2002 15:02:08 -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 g03K25g16092 for ; Thu, 3 Jan 2002 15:02: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 F1E0BE005F0; Thu, 3 Jan 2002 12:01:59 -0800 (PST) Received: from xpabh3.corp.hp.com (xpabh3.corp.hp.com [15.58.136.223]) by xparelay2.corp.hp.com (Postfix) with ESMTP id A7CAB4000B5; Thu, 3 Jan 2002 12:01:32 -0800 (PST) Received: by xpabh3.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jan 2002 12:01:59 -0800 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF2E9@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Black_David@emc.com'" Cc: ips@ece.cmu.edu Subject: RE: iSCSI: establish a nexus with everything you see? Date: Thu, 3 Jan 2002 12:01:56 -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 More than reasonable :-) Agreed. > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Thursday, January 03, 2002 11:42 AM > To: marjorie_krueger@hp.com > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI: establish a nexus with everything you see? > > > Marj, > > I think the fastest way to resolve this one is to agree that > both alternatives are plausible and leave it at that. The > "conservative reuse" issues don't require resolving aggressive > vs. lazy connection establishment behavior, and the less > we constrain how existing SCSI code expects to operate (i.e., > we should allow both alternatives), the better iSCSI will > fit into existing systems. Does that sound reasonable? > > Thanks, > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > black_david@emc.com Cell: +1 (978) 394-7754 > --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Jan 3 15: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 PAA10901 for ; Thu, 3 Jan 2002 15:43:39 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g03JrwD15562 for ips-outgoing; Thu, 3 Jan 2002 14:53:58 -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.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g03Jrug15558 for ; Thu, 3 Jan 2002 14:53:56 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jan 2002 14:49:19 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029372E9@CORPMX14> From: Black_David@emc.com To: marjorie_krueger@hp.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: establish a nexus with everything you see? Date: Thu, 3 Jan 2002 14:41: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 Marj, I think the fastest way to resolve this one is to agree that both alternatives are plausible and leave it at that. The "conservative reuse" issues don't require resolving aggressive vs. lazy connection establishment behavior, and the less we constrain how existing SCSI code expects to operate (i.e., we should allow both alternatives), the better iSCSI will fit into existing systems. Does that sound reasonable? 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: KRUEGER,MARJORIE (HP-Roseville,ex1) > [mailto:marjorie_krueger@hp.com] > Sent: Thursday, January 03, 2002 2:47 PM > To: 'Black_David@emc.com'; cbm@rose.hp.com > Cc: ips@ece.cmu.edu > Subject: iSCSI: establish a nexus with everything you see? > > > I've changed the subject line cause we're going off on a > tangent that isn't > really associated with conservative reuse. > > > > If that's indeed so, the assertion that it's only the > external factors > > > that decide > > > nexii is not always true. Consider the case of an FC initiator > > > port discovering target ports using an FC Name Server, > and an iSCSI > > > initiator port discovering target ports using a "SendTargets" > > > command. In either case, > > > the initiator SCSI port may not really establish a nexus > > > with a discovered target SCSI port, unless the application (or > > > even the SCSI class driver) really wants to do an I/O > > >(starting with an open() system call in Unix systems). > > > > I strongly disagree with that. Virtually all commercial OS > implementations > > of SCSI do aggressive establishments of the nexii as part > of the boot > sequence, > > as SCSI code tends to expect a "bus walker" to find devices > in the boot > > sequence, and make sure they work. Put a trace analyzer to > work on a boot > > and watch all the TEST UNIT READY and similar commands flow > by. Is anyone > > making significant changes to this "bus walker" boot > paradigm out there? > > I disagree with your notion of the "aggressive > establishments" behavior > being good and desirable. In practical implementations, it > causes many > problems for FC networks when these over-zealous > implementations grab disks > that aren't intended for them. Elaborate zoning methods were > developed to > try to alleviate these problems and haven't necessarily > helped due to the > complexity of configuring larger FC networks. Companies have > made money > developing software that reside between the host SCSI layer > and FC drivers > that "see" all the FC disks, but only establish nexus with > those that have > been properly allocated to this host :-) > > When you say "Virtually all commercial OS implementations" > you must mean MS > and Sun OS? Cause I can think of others that don't establish > SCSI nexus in > this manner. The whole concept of "plug-n-play" belies the > notion that SCSI > nexus must exist at boot time. > > > There's also a subtle issue to watch out for here in that > this delays > > error discovery - if the shared persistent reservations are being > > used by cluster software, discovering that the alternate > path nexus can't > > be established when trying to fail over to it is way too > late. For things > > like quorum volumes, I'm fairly sure that cluster software > checks all the > > access paths at initialization time, but can someone > familiar with cluster > > software comment on whether the alternate access paths > needed for failover > > of application volumes are checked in advance, vs. relying > on the OS to > > complain if the SCSI connection to the device didn't set up > correctly? > > Cluster software is a whole nother ballgame. I don't see how > this is tied > to the "agressive establishment" idea, except loosely. I'd > expect a network > with clustering software to be set up much differently than a simpler > "singly attached storage" environment. Early iSCSI > clustering networks may > have to have SCSI nexus "preconfigured" in some manner to > efficiently boot > and bring up all alternate paths. > > Marjorie Krueger > Networked Storage Architecture > Networked Storage Solutions Org. > Hewlett-Packard > From owner-ips@ece.cmu.edu Thu Jan 3 17: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 RAA12825 for ; Thu, 3 Jan 2002 17:43:55 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g03Lr5D22916 for ips-outgoing; Thu, 3 Jan 2002 16:53:05 -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@www.splentec.com [207.219.118.226]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g03Lr2g22911 for ; Thu, 3 Jan 2002 16:53:02 -0500 (EST) Received: from splentec.com (canoe.splentec.com [207.219.118.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g03LpOU11151 for ; Thu, 3 Jan 2002 16:51:24 -0500 Message-ID: <3C34D2BD.91C6FF19@splentec.com> Date: Thu, 03 Jan 2002 16:53:01 -0500 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: iSCSI Subject: iSCSI: A couple of definitions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit 1. CID: The second sentence refers to ``this connection'' and there doesn't seem to be any connections in context. Since ``within'' is used as a preposition, shouldn't the sentence read as follows: It is a unique ID identifying a connection within the session for the initiator. 2. iSCSI Transfer Direction: ``with regard to'' has identical meaning to ``with respect to''. But isn't ``with respect to'' more common in mathematical and computer science literature, and ``with regard to'' being more common in the humanities and social sciences? Shouldn't the first sentence read: The iSCSI transfer direction is defined with respect to the initiator. -- -l From owner-ips@ece.cmu.edu Thu Jan 3 20: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 UAA14567 for ; Thu, 3 Jan 2002 20:12:06 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g040VKW01074 for ips-outgoing; Thu, 3 Jan 2002 19:31:20 -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 g040VIg01068 for ; Thu, 3 Jan 2002 19:31:18 -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 OAA120682 for ; Thu, 3 Jan 2002 14:32:36 -0500 Received: from d03nm041.boulder.ibm.com (d03nm041.boulder.ibm.com [9.99.140.41]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g03JZF862982 for ; Thu, 3 Jan 2002 12:35:15 -0700 Subject: iSCSI: ERL=1 question. To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Prasenjit Sarkar" Date: Thu, 3 Jan 2002 11:36:46 -0800 X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.8 |June 18, 2001) at 01/03/2002 11:35:14 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Assume the following scenario where I and T stand for initiator and target respectively. 1. I->T: Scsi Cmd 2. T->I: Scsi Data (DataSN:0) 3. T->I: Scsi Status (Good) Assume there is a data digest problem for the data with DataSN:0, so 4. I->T: Data Snack for DataSN:0 The target for some reason cannot respond with the data, so according to the spec 5: T->I: Reject with reason DATA_SNACK_REJECT 6. T->I: Scsi Status (iSCSI response: SNACK rejected -> SCSI READ Error) The questions are as follows: A. Is SAM ambivalent of the fact that there can be two statii for the same command? (I dont have a problem if SAM doesnt) B, Does the second SCSI status have the same StatSN as the first? Likely, it does not, but it should be clearly stated that a SCSI status with higher stat_sn overrides one with the lower stat_sn. C. I'm looking for motivation here: why does the target (rather than the initiator) generate the second status? Couldnt the initiator also do the same on receiving the DATA_SNACK_REJECT? Prasenjit Sarkar Research Staff Member IBM Almaden Research San Jose From owner-ips@ece.cmu.edu Thu Jan 3 21: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 VAA15221 for ; Thu, 3 Jan 2002 21:10:47 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g041JJI03228 for ips-outgoing; Thu, 3 Jan 2002 20:19:19 -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 g041JHg03221 for ; Thu, 3 Jan 2002 20:19:17 -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 RAA29561; Thu, 3 Jan 2002 17:19:11 -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 RAA15254; Thu, 3 Jan 2002 17:03:12 -0800 (PST) Received: by aimexc07.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jan 2002 17:19:10 -0800 Message-ID: From: "Ranganathan, Deva" To: "'Prasenjit Sarkar'" , ips@ece.cmu.edu Subject: RE: iSCSI: ERL=1 question. Date: Thu, 3 Jan 2002 17:19:10 -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 >C. I'm looking for motivation here: why does the target (rather than the >initiator) generate the second status? Couldnt the initiator also do the >same on receiving the DATA_SNACK_REJECT? I am with Prasanjith on the thought that the iSCSI initiator layer ignore the status sent from the target, when the SNACK is rejected, is a good idea. I dont like having the target send two statii. Unless there is a specific reason that the target SHOULD send two statii, we SHOULD have the initiator handle this scenario. Any comments? Thanks Deva -----Original Message----- From: Prasenjit Sarkar [mailto:psarkar@almaden.ibm.com] Sent: Thursday, January 03, 2002 11:37 AM To: ips@ece.cmu.edu Subject: iSCSI: ERL=1 question. Assume the following scenario where I and T stand for initiator and target respectively. 1. I->T: Scsi Cmd 2. T->I: Scsi Data (DataSN:0) 3. T->I: Scsi Status (Good) Assume there is a data digest problem for the data with DataSN:0, so 4. I->T: Data Snack for DataSN:0 The target for some reason cannot respond with the data, so according to the spec 5: T->I: Reject with reason DATA_SNACK_REJECT 6. T->I: Scsi Status (iSCSI response: SNACK rejected -> SCSI READ Error) The questions are as follows: A. Is SAM ambivalent of the fact that there can be two statii for the same command? (I dont have a problem if SAM doesnt) B, Does the second SCSI status have the same StatSN as the first? Likely, it does not, but it should be clearly stated that a SCSI status with higher stat_sn overrides one with the lower stat_sn. C. I'm looking for motivation here: why does the target (rather than the initiator) generate the second status? Couldnt the initiator also do the same on receiving the DATA_SNACK_REJECT? Prasenjit Sarkar Research Staff Member IBM Almaden Research San Jose From owner-ips@ece.cmu.edu Thu Jan 3 21:53: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 VAA16496 for ; Thu, 3 Jan 2002 21:53:23 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g042QN606236 for ips-outgoing; Thu, 3 Jan 2002 21:26:23 -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 g042QMg06232 for ; Thu, 3 Jan 2002 21:26:22 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jan 2002 21:26:16 -0500 Message-ID: <237F216B8983D211AD7800A0C9E5B0AC01FF205B@SISI1MX1> From: S_Krishna@emc.com To: ips@ece.cmu.edu Subject: remove Date: Thu, 3 Jan 2002 21:17:22 -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 remove From owner-ips@ece.cmu.edu Thu Jan 3 21:53: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 VAA16507 for ; Thu, 3 Jan 2002 21:53:26 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0423h305141 for ips-outgoing; Thu, 3 Jan 2002 21:03:43 -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 g0423gg05136 for ; Thu, 3 Jan 2002 21:03:42 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e33.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA115184; Thu, 3 Jan 2002 19:59:41 -0600 Received: from d03nm041.boulder.ibm.com (d03nm041.boulder.ibm.com [9.99.140.41]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g0422S8108844; Thu, 3 Jan 2002 19:02:28 -0700 Subject: Re: iSCSI: ERL=1 question. To: Santosh Rao Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Prasenjit Sarkar" Date: Thu, 3 Jan 2002 18:03:59 -0800 X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.8 |June 18, 2001) at 01/03/2002 06:02:28 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I'm assuming Santosh wanted to reply to the entire group, so I am forwarding his response to the mailing list. Santosh's argument is to provide the (unstated) rule that data assembly is the domain of a lower iSCSI layer whose job is to filter out duplicate SCSI status PDUs. I would gladly accept this argument except that a standard should present a generic rule which should be independent of how a protocol is implemented. I would prefer a rule based on stat_sn ordering or any other equivalent rather than one based on ideal iSCSI layering. Santosh's motivation of having a seamless way of completing commands is probably not true as initiators are allowed to generate SCSI responses. Prasenjit Sarkar Research Staff Member IBM Almaden Research San Jose Santosh Rao cc: Sent by: Subject: Re: iSCSI: ERL=1 question. santoshr@cup.h p.com 01/03/2002 05:00 PM Prasenjit, Responses inline. Regards, Santosh Prasenjit Sarkar wrote: > > Assume the following scenario where I and T stand for initiator and target > respectively. > > 1. I->T: Scsi Cmd > > 2. T->I: Scsi Data (DataSN:0) > > 3. T->I: Scsi Status (Good) > > Assume there is a data digest problem for the data with DataSN:0, so > > 4. I->T: Data Snack for DataSN:0 > > The target for some reason cannot respond with the data, so according to > the spec > > 5: T->I: Reject with reason DATA_SNACK_REJECT > > 6. T->I: Scsi Status (iSCSI response: SNACK rejected -> SCSI READ Error) > > The questions are as follows: > > A. Is SAM ambivalent of the fact that there can be two statii for the same > command? (I dont have a problem if SAM doesnt) I'm not certain on what SAM says on this one. However, one can envision that the iscsi i/o finite state machine would enter into some state upon encountering a datasn hole, say, data_snack_sent, and it should ignore any scsi status received while in this state. The lower pdu receive and re-assembly module should have passed format and digest checks (assuming the frame came thru fine) and so, the local value of exp_statsn should have gotten updated within this initiator instance's iscsi connection finite state machine. Thus..... i) since the 1st status was ignored while awaiting a data_snack response, only 1 scsi status ends up being processed by the i/o finite state m/c. ii) there will not be a statsn hole, since the previous status was received successfully by the receive path, resulting in an update to exp_statsn. however, the staus was discarded within the i/o fsm. > > B, Does the second SCSI status have the same StatSN as the first? Likely, > it does not, but it should be clearly stated that a SCSI status with higher > stat_sn overrides one with the lower stat_sn. See above. > > C. I'm looking for motivation here: why does the target (rather than the > initiator) generate the second status? Couldnt the initiator also do the > same on receiving the DATA_SNACK_REJECT? So that all I/Os receive a single method of completion via the SCSI status, I guess. -- ################################## 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 Jan 3 22:31: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 WAA17882 for ; Thu, 3 Jan 2002 22:31:30 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g042jGs07078 for ips-outgoing; Thu, 3 Jan 2002 21:45:16 -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 g042jEg07073 for ; Thu, 3 Jan 2002 21:45:14 -0500 (EST) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel13.hp.com (Postfix) with ESMTP id 1FA1AE00412; Thu, 3 Jan 2002 18:45:09 -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 SAA23592; Thu, 3 Jan 2002 18:45:04 -0800 (PST) Message-ID: <3C35175A.5ED1CBBE@cup.hp.com> Date: Thu, 03 Jan 2002 18:45:46 -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: Prasenjit Sarkar Cc: ips@ece.cmu.edu Subject: Re: iSCSI: ERL=1 question. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Prasenjit, Regarding your question (B).... Anytime the initiator's receive path successfully receives a pdu and passes format and digest error tests, the local state information of exp_cmdsn, max_cmdsn, statsn should be updated based on the values that are carried in that pdu and the rules specified in Section 2.2.2. Thus, in your below context, when the first scsi status pdu was received, the exp_statsn should have gotten updated and there should not have been any hole in statsn sequence. What am I missing (?) Regarding your question (A)... You may have read more into my answer than was intended. It is not the job of the lower layered pdu assembly path to filter out duplicate scsi status pdu's. Rather, this intelligence would lie within the module (finite state machine) that implemented the i/o path logic. While a data_snack has been sent and the i/o state machine is awaiting missing data pdu's , any received scsi status for that exchange must not be sent up to the SCSI ULP. Upon successful receipt of all the missing data pdu[s], the status can then be conveyed to the ULP. (I don't have a strong opinion either way, if we should have to state the above in the draft, or leave it unsaid as implementation specifics. I guess, at some point we cross over into the realm of an implementation guide vs a protocol specification :) - Santosh Prasenjit Sarkar wrote: > > I'm assuming Santosh wanted to reply to the entire group, so I am > forwarding his response to the mailing list. > > Santosh's argument is to provide the (unstated) rule that data assembly is > the domain of a lower iSCSI layer whose job is to filter out duplicate SCSI > status PDUs. I would gladly accept this argument except that a standard > should present a generic rule which should be independent of how a protocol > is implemented. I would prefer a rule based on stat_sn ordering or any > other equivalent rather than one based on ideal iSCSI layering. > > Santosh's motivation of having a seamless way of completing commands is > probably not true as initiators are allowed to generate SCSI responses. > > Prasenjit Sarkar > Research Staff Member > IBM Almaden Research > San Jose > > > Santosh Rao > hp.com> cc: > Sent by: Subject: Re: iSCSI: ERL=1 question. > santoshr@cup.h > p.com > > > 01/03/2002 > 05:00 PM > > > > Prasenjit, > > Responses inline. > > Regards, > Santosh > > Prasenjit Sarkar wrote: > > > > Assume the following scenario where I and T stand for initiator and > target > > respectively. > > > > 1. I->T: Scsi Cmd > > > > 2. T->I: Scsi Data (DataSN:0) > > > > 3. T->I: Scsi Status (Good) > > > > Assume there is a data digest problem for the data with DataSN:0, so > > > > 4. I->T: Data Snack for DataSN:0 > > > > The target for some reason cannot respond with the data, so according to > > the spec > > > > 5: T->I: Reject with reason DATA_SNACK_REJECT > > > > 6. T->I: Scsi Status (iSCSI response: SNACK rejected -> SCSI READ Error) > > > > The questions are as follows: > > > > A. Is SAM ambivalent of the fact that there can be two statii for the > same > > command? (I dont have a problem if SAM doesnt) > > I'm not certain on what SAM says on this one. However, one can envision > that the iscsi i/o finite state machine would enter into some state upon > encountering a datasn hole, say, data_snack_sent, and it should ignore > any scsi status received while in this state. > The lower pdu receive and re-assembly module should have passed format > and digest checks (assuming the frame came thru fine) and so, the local > value of exp_statsn should have gotten updated within this initiator > instance's iscsi connection finite state machine. > > Thus..... > i) since the 1st status was ignored while awaiting a data_snack > response, only 1 scsi status ends up being processed by the i/o finite > state m/c. > > ii) there will not be a statsn hole, since the previous status was > received successfully by the receive path, resulting in an update to > exp_statsn. however, the staus was discarded within the i/o fsm. > > > > > B, Does the second SCSI status have the same StatSN as the first? Likely, > > it does not, but it should be clearly stated that a SCSI status with > higher > > stat_sn overrides one with the lower stat_sn. > > See above. > > > > > C. I'm looking for motivation here: why does the target (rather than the > > initiator) generate the second status? Couldnt the initiator also do the > > same on receiving the DATA_SNACK_REJECT? > > So that all I/Os receive a single method of completion via the SCSI > status, I guess. > > -- > ################################## > 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 Thu Jan 3 23:59: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 XAA19502 for ; Thu, 3 Jan 2002 23:58:56 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g044HRW10791 for ips-outgoing; Thu, 3 Jan 2002 23:17:27 -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 g044HNg10786 for ; Thu, 3 Jan 2002 23:17:23 -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 XAA30236; Thu, 3 Jan 2002 23:14:24 -0500 Received: from d03nm041.boulder.ibm.com (d03nm041.boulder.ibm.com [9.99.140.41]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g044HK8264466; Thu, 3 Jan 2002 21:17:21 -0700 Subject: Re: iSCSI: ERL=1 question. To: Santosh Rao Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Prasenjit Sarkar" Date: Thu, 3 Jan 2002 20:17:11 -0800 X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.8 |June 18, 2001) at 01/03/2002 08:17:20 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, Regarding (B), I did not even venture to imply that there would be a stat_sn hole. I'm a little confused about your data snack recovery rule, but that is besides the point and I can discuss this offline with you. My chief concern is that ERL 1 leaves open the possibility for duplicate SCSI status PDUs. There are three solutions: 1. Leave it to implementors who can use their judgement to decide which status to ignore. 2. Formulate a tight rule: status PDU with higher stat_sn number always wins. 3. Change the standard so that duplication does not happen. I would like the standard to at least discuss this and then state what path they chose and why (with good reason of course). I do not think that this is merely an implementation issue. My preference is of course: 3,2,1. Prasenjit Sarkar Research Staff Member IBM Almaden Research San Jose Santosh Rao cc: ips@ece.cmu.edu Sent by: Subject: Re: iSCSI: ERL=1 question. owner-ips@ece. cmu.edu 01/03/2002 06:45 PM Prasenjit, Regarding your question (B).... Anytime the initiator's receive path successfully receives a pdu and passes format and digest error tests, the local state information of exp_cmdsn, max_cmdsn, statsn should be updated based on the values that are carried in that pdu and the rules specified in Section 2.2.2. Thus, in your below context, when the first scsi status pdu was received, the exp_statsn should have gotten updated and there should not have been any hole in statsn sequence. What am I missing (?) Regarding your question (A)... You may have read more into my answer than was intended. It is not the job of the lower layered pdu assembly path to filter out duplicate scsi status pdu's. Rather, this intelligence would lie within the module (finite state machine) that implemented the i/o path logic. While a data_snack has been sent and the i/o state machine is awaiting missing data pdu's , any received scsi status for that exchange must not be sent up to the SCSI ULP. Upon successful receipt of all the missing data pdu[s], the status can then be conveyed to the ULP. (I don't have a strong opinion either way, if we should have to state the above in the draft, or leave it unsaid as implementation specifics. I guess, at some point we cross over into the realm of an implementation guide vs a protocol specification :) - Santosh Prasenjit Sarkar wrote: > > I'm assuming Santosh wanted to reply to the entire group, so I am > forwarding his response to the mailing list. > > Santosh's argument is to provide the (unstated) rule that data assembly is > the domain of a lower iSCSI layer whose job is to filter out duplicate SCSI > status PDUs. I would gladly accept this argument except that a standard > should present a generic rule which should be independent of how a protocol > is implemented. I would prefer a rule based on stat_sn ordering or any > other equivalent rather than one based on ideal iSCSI layering. > > Santosh's motivation of having a seamless way of completing commands is > probably not true as initiators are allowed to generate SCSI responses. > > Prasenjit Sarkar > Research Staff Member > IBM Almaden Research > San Jose > > > Santosh Rao > hp.com> cc: > Sent by: Subject: Re: iSCSI: ERL=1 question. > santoshr@cup.h > p.com > > > 01/03/2002 > 05:00 PM > > > > Prasenjit, > > Responses inline. > > Regards, > Santosh > > Prasenjit Sarkar wrote: > > > > Assume the following scenario where I and T stand for initiator and > target > > respectively. > > > > 1. I->T: Scsi Cmd > > > > 2. T->I: Scsi Data (DataSN:0) > > > > 3. T->I: Scsi Status (Good) > > > > Assume there is a data digest problem for the data with DataSN:0, so > > > > 4. I->T: Data Snack for DataSN:0 > > > > The target for some reason cannot respond with the data, so according to > > the spec > > > > 5: T->I: Reject with reason DATA_SNACK_REJECT > > > > 6. T->I: Scsi Status (iSCSI response: SNACK rejected -> SCSI READ Error) > > > > The questions are as follows: > > > > A. Is SAM ambivalent of the fact that there can be two statii for the > same > > command? (I dont have a problem if SAM doesnt) > > I'm not certain on what SAM says on this one. However, one can envision > that the iscsi i/o finite state machine would enter into some state upon > encountering a datasn hole, say, data_snack_sent, and it should ignore > any scsi status received while in this state. > The lower pdu receive and re-assembly module should have passed format > and digest checks (assuming the frame came thru fine) and so, the local > value of exp_statsn should have gotten updated within this initiator > instance's iscsi connection finite state machine. > > Thus..... > i) since the 1st status was ignored while awaiting a data_snack > response, only 1 scsi status ends up being processed by the i/o finite > state m/c. > > ii) there will not be a statsn hole, since the previous status was > received successfully by the receive path, resulting in an update to > exp_statsn. however, the staus was discarded within the i/o fsm. > > > > > B, Does the second SCSI status have the same StatSN as the first? Likely, > > it does not, but it should be clearly stated that a SCSI status with > higher > > stat_sn overrides one with the lower stat_sn. > > See above. > > > > > C. I'm looking for motivation here: why does the target (rather than the > > initiator) generate the second status? Couldnt the initiator also do the > > same on receiving the DATA_SNACK_REJECT? > > So that all I/Os receive a single method of completion via the SCSI > status, I guess. > > -- > ################################## > 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 Fri Jan 4 10:20: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 KAA05172 for ; Fri, 4 Jan 2002 10:20:08 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g04EWHY15808 for ips-outgoing; Fri, 4 Jan 2002 09:32:17 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g04EWEg15802 for ; Fri, 4 Jan 2002 09:32:14 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jan 2002 09:32:07 -0500 Message-ID: <25369470B6F0D41194820002B328BDD22022E8@ATLOPS> From: Eddy Quicksall To: Prasenjit Sarkar , Santosh Rao Cc: ips@ece.cmu.edu Subject: RE: iSCSI: ERL=1 question. Date: Fri, 4 Jan 2002 09:32: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 I hate to get blasted but here goes ... :) I would prefer that iSCSI Response and SCSI Status are mutually exclusive. Let the initiator generate the appropriate SCSI Status for the ULP given the iSCSI Response. It used to be that way. Maybe someone could tell us why it was changed. If there is a very good reason for them not to be mutually exclusive, then my code would just overlay the first status with the second and everything would work properly. Maybe a note could be added to the spec to make people aware that this could occur. Eddy -----Original Message----- From: Prasenjit Sarkar [mailto:psarkar@almaden.ibm.com] Sent: Thursday, January 03, 2002 11:17 PM To: Santosh Rao Cc: ips@ece.cmu.edu Subject: Re: iSCSI: ERL=1 question. Santosh, Regarding (B), I did not even venture to imply that there would be a stat_sn hole. I'm a little confused about your data snack recovery rule, but that is besides the point and I can discuss this offline with you. My chief concern is that ERL 1 leaves open the possibility for duplicate SCSI status PDUs. There are three solutions: 1. Leave it to implementors who can use their judgement to decide which status to ignore. 2. Formulate a tight rule: status PDU with higher stat_sn number always wins. 3. Change the standard so that duplication does not happen. I would like the standard to at least discuss this and then state what path they chose and why (with good reason of course). I do not think that this is merely an implementation issue. My preference is of course: 3,2,1. Prasenjit Sarkar Research Staff Member IBM Almaden Research San Jose Santosh Rao cc: ips@ece.cmu.edu Sent by: Subject: Re: iSCSI: ERL=1 question. owner-ips@ece. cmu.edu 01/03/2002 06:45 PM Prasenjit, Regarding your question (B).... Anytime the initiator's receive path successfully receives a pdu and passes format and digest error tests, the local state information of exp_cmdsn, max_cmdsn, statsn should be updated based on the values that are carried in that pdu and the rules specified in Section 2.2.2. Thus, in your below context, when the first scsi status pdu was received, the exp_statsn should have gotten updated and there should not have been any hole in statsn sequence. What am I missing (?) Regarding your question (A)... You may have read more into my answer than was intended. It is not the job of the lower layered pdu assembly path to filter out duplicate scsi status pdu's. Rather, this intelligence would lie within the module (finite state machine) that implemented the i/o path logic. While a data_snack has been sent and the i/o state machine is awaiting missing data pdu's , any received scsi status for that exchange must not be sent up to the SCSI ULP. Upon successful receipt of all the missing data pdu[s], the status can then be conveyed to the ULP. (I don't have a strong opinion either way, if we should have to state the above in the draft, or leave it unsaid as implementation specifics. I guess, at some point we cross over into the realm of an implementation guide vs a protocol specification :) - Santosh Prasenjit Sarkar wrote: > > I'm assuming Santosh wanted to reply to the entire group, so I am > forwarding his response to the mailing list. > > Santosh's argument is to provide the (unstated) rule that data assembly is > the domain of a lower iSCSI layer whose job is to filter out duplicate SCSI > status PDUs. I would gladly accept this argument except that a standard > should present a generic rule which should be independent of how a protocol > is implemented. I would prefer a rule based on stat_sn ordering or any > other equivalent rather than one based on ideal iSCSI layering. > > Santosh's motivation of having a seamless way of completing commands is > probably not true as initiators are allowed to generate SCSI responses. > > Prasenjit Sarkar > Research Staff Member > IBM Almaden Research > San Jose > > > Santosh Rao > hp.com> cc: > Sent by: Subject: Re: iSCSI: ERL=1 question. > santoshr@cup.h > p.com > > > 01/03/2002 > 05:00 PM > > > > Prasenjit, > > Responses inline. > > Regards, > Santosh > > Prasenjit Sarkar wrote: > > > > Assume the following scenario where I and T stand for initiator and > target > > respectively. > > > > 1. I->T: Scsi Cmd > > > > 2. T->I: Scsi Data (DataSN:0) > > > > 3. T->I: Scsi Status (Good) > > > > Assume there is a data digest problem for the data with DataSN:0, so > > > > 4. I->T: Data Snack for DataSN:0 > > > > The target for some reason cannot respond with the data, so according to > > the spec > > > > 5: T->I: Reject with reason DATA_SNACK_REJECT > > > > 6. T->I: Scsi Status (iSCSI response: SNACK rejected -> SCSI READ Error) > > > > The questions are as follows: > > > > A. Is SAM ambivalent of the fact that there can be two statii for the > same > > command? (I dont have a problem if SAM doesnt) > > I'm not certain on what SAM says on this one. However, one can envision > that the iscsi i/o finite state machine would enter into some state upon > encountering a datasn hole, say, data_snack_sent, and it should ignore > any scsi status received while in this state. > The lower pdu receive and re-assembly module should have passed format > and digest checks (assuming the frame came thru fine) and so, the local > value of exp_statsn should have gotten updated within this initiator > instance's iscsi connection finite state machine. > > Thus..... > i) since the 1st status was ignored while awaiting a data_snack > response, only 1 scsi status ends up being processed by the i/o finite > state m/c. > > ii) there will not be a statsn hole, since the previous status was > received successfully by the receive path, resulting in an update to > exp_statsn. however, the staus was discarded within the i/o fsm. > > > > > B, Does the second SCSI status have the same StatSN as the first? Likely, > > it does not, but it should be clearly stated that a SCSI status with > higher > > stat_sn overrides one with the lower stat_sn. > > See above. > > > > > C. I'm looking for motivation here: why does the target (rather than the > > initiator) generate the second status? Couldnt the initiator also do the > > same on receiving the DATA_SNACK_REJECT? > > So that all I/Os receive a single method of completion via the SCSI > status, I guess. > > -- > ################################## > 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 Fri Jan 4 14:36: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 OAA12138 for ; Fri, 4 Jan 2002 14:36:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g04It2R00897 for ips-outgoing; Fri, 4 Jan 2002 13:55:02 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from relay2.softcomca.com (relay.softcomca.com [168.144.1.68] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g04Isug00888 for ; Fri, 4 Jan 2002 13:54:56 -0500 (EST) Received: from m2w067 ([168.144.108.67]) by relay2.softcomca.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 4 Jan 2002 13:54:52 -0500 X-Originating-IP: 64.170.220.19 X-URL: http://www.mail2web.com/ Subject: RE: iScsi: From: "rakesh@qpackets.com" Date: Fri, 4 Jan 2002 13:54:45 -0500 To: "nitin.dhingra@dcmtech.co.in" , "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: 04 Jan 2002 18:54:52.0419 (UTC) FILETIME=[4AE05530:01C19551] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by ece.cmu.edu id g04Isug00889 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit A block device driver is not designed to perform any data coherency or integrity. It is the higher layers like the volume manager's or the TSD's which are supposed to do any reserve's and or any other such technique(s) to perform the said operations. Original Message: ----------------- From: Nitin Dhingra nitin.dhingra@dcmtech.co.in Date: Wed, 2 Jan 2002 11:09:46 +0530 To: ips@ece.cmu.edu Subject: iScsi: Why don't you put a restriction on the read/write access to a target? This can solve some of the synchronization problems that can occur... And Yeah Happy New Year to All... - Nitin -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . From owner-ips@ece.cmu.edu Fri Jan 4 14:42: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 OAA12252 for ; Fri, 4 Jan 2002 14:42:28 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g04J1m901299 for ips-outgoing; Fri, 4 Jan 2002 14:01:48 -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 g04J1jg01290 for ; Fri, 4 Jan 2002 14:01:45 -0500 (EST) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jan 2002 14:04:19 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029372F6@CORPMX14> From: Black_David@emc.com To: roweber@acm.org, ips@ece.cmu.edu Subject: RE: FCIP: Short Frame Security Solution Proposal Date: Fri, 4 Jan 2002 13:49:24 -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 Ralph, > Black_David@emc.com wrote [responses embedded]: > > > I think this is a workable approach. A few comments: > > > > - There are a dependencies among a number of components > > on who supports what, some of which are under T11's > > control. If it turns out that the T11 aspects of this > > are not mandatory to implement, ... [... snip ...] > > I think multiple TCP > > connections in a single FCIP session need to be disallowed > > if this authentication cannot be performed by the > > implementation (i.e., is not implemented) - putting in a > > note to this effect regardless of what T11 does might be > > a good idea to decouple FCIP from FC-BB-2 in this area. > > As currently worded, the FCIP Entity ALWAYS asks the FC Entity > for authentication of a second to n-th connection and the > FC Entity ALWAYS responds, yes or no. I fail to see how a > note such as the one suggested would be viewed as anything > more than advisory to FC-BB-2. The FCIP Entity has (in theory) > no knowledge of how much or how little work the FC Entity > does to generate its response to the request for connection > authentication. What I had in mind was advice to implementers that if the FC Entity does not check the nonce over the initial connection with its peer FC entity, then the answer to the FCIP entity SHOULD be "no". This could also be considered as advice to BB-2. > > - Any nonce must be validated ("yes, that's my connection") > > at most once. If the FC Entity on the other end of the > > first connection is capable of saying "yes" twice to the > > same nonce, there's an obvious replay attack. > > I had sought to cut this type of attack off at the SF level > (long before the FC Entity at the other end gets a nonce > to validate) with the following words. > > }...} To further increase the difficulty of snooping > }...} TCP connections, an FCIP Entity that receives > }...} a duplicate nonce shall close the connection > }...} on which that nonce was received immediately > }...} without causing the SW_ILS to be sent. > > To me, this seems superior for a couple of reasons: > > o It places the requirement in FCIP, closer to the source > of the problem. > o It eliminates an unnecessary authentication transaction > with the FC Entity at the other end. Ok, but also see the discussion below on the "who presents the nonce first" race. > > - Some words will need to be added about a nasty race > > condition in which the attacker opens up a connection up > > to the point of sending the short frame, watches a real > > connection get set up to the point that the attacker sees > > the short frame on the real connection; the attacker > > extracts and uses the nonce, and TCP tricks (e.g., corrupt > > the TCP packet containing the nonce to cause a checksum > > failure, or send a well-timed RST). The short answer to > > dealing with this is "use IKE and also ESP encryption if > > warranted" when this sort of attack is a concern. > > Would it not be better to include a broad caution along the > lines of: > > Warning: The authentication mechanism described here is not > designed to thwart sophisticated security threats. The IP > security mechanisms described in section 9 should be enabled > in environments where security threats are suspected. Both. The race is sufficiently related to the WWN short frame that it should be specifically mentioned. There are other authentication mechanisms that are not subject to this race. > > - I think it's necessary to authentication the first TCP > > connection (up to FCAP or whatever) before sending the ILS > > that would authenticate a subsequent one, but details beyond > > that (e.g., can one send the SYN for the second TCP connection > > before the first connection authenticates) are probably up to > > implementations. > > I had hoped to have covered the case I think is being described > above by the following language (note the words "previously > authenticated"): > > }...} In situations where security > }...} risks are possible, the FC Entity shall transmit > }...} the information provided by the FCIP Entity via a new > }...} SW_ILS on a previously authenticated TCP connection > }...} (FCIP Data Engine) enabled for Class F frames. > > "Previously authenticated" may be vague, but it is intended to > cover both authentication via FCAP and authentication against > another F Class connection using this process. > > Consider that case where a long lived FCIP Link starts out > with one F Class connection. Next, using the authentication > process described in this proposal and two or more Class 2/3 > connections are added to the FCIP Link. As time goes by the F > Class connection becomes unreliable and the Entities at both > ends decide to close it and switch one of the Class 2/3 > connections to Class F service. > > The connection switched to F Class service has been duly > authenticated, but not by FCAP. It seems perfectly reasonable > that the switched F Class connection can serve to authenticate > new connect requests. Yes, "previously authenticated" is a bit vague. This discussion is fine, and adding the example from the discussion above would be helpful. 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 Jan 4 15:24:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12148 for ; Fri, 4 Jan 2002 14:36:22 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g04ItJJ00920 for ips-outgoing; Fri, 4 Jan 2002 13:55:19 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g04ItGg00914 for ; Fri, 4 Jan 2002 13:55:16 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jan 2002 13:55:10 -0500 Message-ID: <25369470B6F0D41194820002B328BDD220230C@ATLOPS> From: Eddy Quicksall To: "ips@ece. cmu. edu (E-mail)" Subject: iSCSI: incorrect offset in SNACK Request Date: Fri, 4 Jan 2002 13:55:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19551.5316FE70" 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_01C19551.5316FE70 Content-Type: text/plain; charset="iso-8859-1" If you haven't already noticed, the offset of the last Reserved in SNACK Request should be 40 and not 32. Eddy ------_=_NextPart_001_01C19551.5316FE70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

If you haven’t already noticed, the offset of the last Reserved in = SNACK Request should be 40 and not 32.

 

=

Eddy=

------_=_NextPart_001_01C19551.5316FE70-- From owner-ips@ece.cmu.edu Fri Jan 4 16:04: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 QAA13710 for ; Fri, 4 Jan 2002 16:04:05 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g04KEfT05753 for ips-outgoing; Fri, 4 Jan 2002 15:14:41 -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 g04KEcg05745 for ; Fri, 4 Jan 2002 15:14:38 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel11.hp.com (Postfix) with ESMTP id A0432E00757; Fri, 4 Jan 2002 12:14:32 -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 MAA16824; Fri, 4 Jan 2002 12:16:06 -0800 (PST) Message-Id: <200201042016.MAA16824@core.rose.hp.com> Date: Fri, 04 Jan 2002 12:28:02 -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: Prasenjit Sarkar Cc: ips Subject: Re: iSCSI: ERL=1 question. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Prasenjit, I tend to agree with you. The "must send status after SNACK reject" rule you pointed out was originally introduced to avoid infinite loops where an initiator continually asks for data re-transmit, and target keeps rebuffing (for transient internal reasons, since data SNACK is legal for ErrorRecoveryLevel=1). The intent was to force the I/O completion, precluding SNACK retries. In the case you describe, the target already delivered the status, so I propose that all we need to ensure is that there are no SNACK retries. Initiator should be able to internally assume a "Data-SNACK reject" reason - it does so today anyway if no recovery for the lost data is attempted. Here is the new text for consideration (to replace the bullet (a) text on page 134 in section 8.4 of rev09) - a) Request the desired data PDU through SNACK. In its turn, the target MUST either resend the data PDU or, reject the SNACK with a Reject PDU with a reason-code of "Data-SNACK Reject" in which case (i) if the status had not already been sent for the command, the target MUST terminate the command with an iSCSI command response reason of "SNACK rejected". (ii)if the status was already sent, no further action is necessary for the target. Initiator in this case MUST internally signal the completion with the "Data-SNACK reject" reason disregarding any received status PDU, but must wait for the status to be received before doing so. [OR]..... Note that there's one paranoid case here in sub-bullet (ii) above where a status SNACK (if status is also lost...) will cause the target to report the original status again (SNACK demands a replica) with a successful completion. But in reality, the intervening "Data-SNACK Reject" had already sealed the fate of the I/O on the initiator. The retransmitted status merely fills the StatSN hole and gives the initiator the determinism to re-use the ITT. The wording in sub-bullet (ii) will cover this paranoid case as well. Comments? To Santosh: > > upon > > encountering a datasn hole, say, data_snack_sent, and it should ignore > > any scsi status received while in this state. I wouldn't recommend that! If the Data SNACK were successful, this status is the final status for the I/O. Discarding the status would mean setting the stage for a(n unnecessary) status SNACK in future. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Prasenjit Sarkar wrote: > > Santosh, > > Regarding (B), I did not even venture to imply that there would be a > stat_sn hole. > > I'm a little confused about your data snack recovery rule, but that is > besides the point and I can discuss this offline with you. > > My chief concern is that ERL 1 leaves open the possibility for duplicate > SCSI status PDUs. There are three solutions: > > 1. Leave it to implementors who can use their judgement to decide which > status to ignore. > 2. Formulate a tight rule: status PDU with higher stat_sn number always > wins. > 3. Change the standard so that duplication does not happen. > > I would like the standard to at least discuss this and then state what path > they chose and why (with good reason of course). I do not think that this > is merely an implementation issue. > > My preference is of course: 3,2,1. > > Prasenjit Sarkar > Research Staff Member > IBM Almaden Research > San Jose > > > Santosh Rao > hp.com> cc: ips@ece.cmu.edu > Sent by: Subject: Re: iSCSI: ERL=1 question. > owner-ips@ece. > cmu.edu > > > 01/03/2002 > 06:45 PM > > > > Prasenjit, > > Regarding your question (B).... > > Anytime the initiator's receive path successfully receives a pdu and > passes format and digest error tests, the local state information of > exp_cmdsn, max_cmdsn, statsn should be updated based on the values that > are carried in that pdu and the rules specified in Section 2.2.2. > > Thus, in your below context, when the first scsi status pdu was > received, the exp_statsn should have gotten updated and there should not > have been any hole in statsn sequence. What am I missing (?) > > Regarding your question (A)... > > You may have read more into my answer than was intended. > > It is not the job of the lower layered pdu assembly path to filter out > duplicate scsi status pdu's. Rather, this intelligence would lie within > the module (finite state machine) that implemented the i/o path logic. > > While a data_snack has been sent and the i/o state machine is awaiting > missing data pdu's , any received scsi status for that exchange must not > be sent up to the SCSI ULP. Upon successful receipt of all the missing > data pdu[s], the status can then be conveyed to the ULP. > > (I don't have a strong opinion either way, if we should have to state > the above in the draft, or leave it unsaid as implementation specifics. > I guess, at some point we cross over into the realm of an implementation > guide vs a protocol specification :) > > - Santosh > > Prasenjit Sarkar wrote: > > > > I'm assuming Santosh wanted to reply to the entire group, so I am > > forwarding his response to the mailing list. > > > > Santosh's argument is to provide the (unstated) rule that data assembly > is > > the domain of a lower iSCSI layer whose job is to filter out duplicate > SCSI > > status PDUs. I would gladly accept this argument except that a standard > > should present a generic rule which should be independent of how a > protocol > > is implemented. I would prefer a rule based on stat_sn ordering or any > > other equivalent rather than one based on ideal iSCSI layering. > > > > Santosh's motivation of having a seamless way of completing commands is > > probably not true as initiators are allowed to generate SCSI responses. > > > > Prasenjit Sarkar > > Research Staff Member > > IBM Almaden Research > > San Jose > > > > > > Santosh Rao > > Sarkar/Almaden/IBM@IBMUS > > hp.com> cc: > > Sent by: Subject: Re: iSCSI: ERL=1 > question. > > santoshr@cup.h > > p.com > > > > > > 01/03/2002 > > 05:00 PM > > > > > > > > Prasenjit, > > > > Responses inline. > > > > Regards, > > Santosh > > > > Prasenjit Sarkar wrote: > > > > > > Assume the following scenario where I and T stand for initiator and > > target > > > respectively. > > > > > > 1. I->T: Scsi Cmd > > > > > > 2. T->I: Scsi Data (DataSN:0) > > > > > > 3. T->I: Scsi Status (Good) > > > > > > Assume there is a data digest problem for the data with DataSN:0, so > > > > > > 4. I->T: Data Snack for DataSN:0 > > > > > > The target for some reason cannot respond with the data, so according > to > > > the spec > > > > > > 5: T->I: Reject with reason DATA_SNACK_REJECT > > > > > > 6. T->I: Scsi Status (iSCSI response: SNACK rejected -> SCSI READ > Error) > > > > > > The questions are as follows: > > > > > > A. Is SAM ambivalent of the fact that there can be two statii for the > > same > > > command? (I dont have a problem if SAM doesnt) > > > > I'm not certain on what SAM says on this one. However, one can envision > > that the iscsi i/o finite state machine would enter into some state upon > > encountering a datasn hole, say, data_snack_sent, and it should ignore > > any scsi status received while in this state. > > The lower pdu receive and re-assembly module should have passed format > > and digest checks (assuming the frame came thru fine) and so, the local > > value of exp_statsn should have gotten updated within this initiator > > instance's iscsi connection finite state machine. > > > > Thus..... > > i) since the 1st status was ignored while awaiting a data_snack > > response, only 1 scsi status ends up being processed by the i/o finite > > state m/c. > > > > ii) there will not be a statsn hole, since the previous status was > > received successfully by the receive path, resulting in an update to > > exp_statsn. however, the staus was discarded within the i/o fsm. > > > > > > > > B, Does the second SCSI status have the same StatSN as the first? > Likely, > > > it does not, but it should be clearly stated that a SCSI status with > > higher > > > stat_sn overrides one with the lower stat_sn. > > > > See above. > > > > > > > > C. I'm looking for motivation here: why does the target (rather than > the > > > initiator) generate the second status? Couldnt the initiator also do > the > > > same on receiving the DATA_SNACK_REJECT? > > > > So that all I/Os receive a single method of completion via the SCSI > > status, I guess. > > > > -- > > ################################## > > 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 Fri Jan 4 18:26: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 SAA15998 for ; Fri, 4 Jan 2002 18:26:26 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g04MdVX13907 for ips-outgoing; Fri, 4 Jan 2002 17:39:31 -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 g04MdTg13902 for ; Fri, 4 Jan 2002 17:39:30 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel7.hp.com (Postfix) with ESMTP id D0FB7E00334 for ; Fri, 4 Jan 2002 17:39:23 -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 OAA11001 for ; Fri, 4 Jan 2002 14:40:57 -0800 (PST) Message-Id: <200201042240.OAA11001@core.rose.hp.com> Date: Fri, 04 Jan 2002 14:52:53 -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: ERL=1 question. References: <200201042016.MAA16824@core.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 Just one minor change in the text. In sub-bullet (ii), replace "Data-SNACK reject" with "SNACK rejected". The former is a Reject reason code, and the latter is an iSCSI response reason with a defined key-ASC-ASCQ in section 3.4.3. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com "Mallikarjun C." wrote: > > Prasenjit, > > I tend to agree with you. > > The "must send status after SNACK reject" rule you pointed out was > originally introduced to avoid infinite loops where an initiator > continually asks for data re-transmit, and target keeps rebuffing > (for transient internal reasons, since data SNACK is legal for > ErrorRecoveryLevel=1). The intent was to force the I/O completion, > precluding SNACK retries. > > In the case you describe, the target already delivered the status, so > I propose that all we need to ensure is that there are no SNACK retries. > Initiator should be able to internally assume a "Data-SNACK reject" > reason - it does so today anyway if no recovery for the lost data is > attempted. > > Here is the new text for consideration (to replace the bullet (a) text > on page 134 in section 8.4 of rev09) - > > a) Request the desired data PDU through SNACK. In its turn, > the target MUST either resend the data PDU or, reject the > SNACK with a Reject PDU with a reason-code of "Data-SNACK > Reject" in which case > (i) if the status had not already been sent for the > command, the target MUST terminate the command with > an iSCSI command response reason of "SNACK rejected". > (ii)if the status was already sent, no further action is > necessary for the target. Initiator in this case > MUST internally signal the completion with the "Data-SNACK > reject" reason disregarding any received status PDU, > but must wait for the status to be received before doing > so. > [OR]..... > > Note that there's one paranoid case here in sub-bullet (ii) above > where a status SNACK (if status is also lost...) will cause the target > to report the original status again (SNACK demands a replica) with a > successful completion. But in reality, the intervening "Data-SNACK > Reject" had already sealed the fate of the I/O on the initiator. > The retransmitted status merely fills the StatSN hole and gives the > initiator the determinism to re-use the ITT. > > The wording in sub-bullet (ii) will cover this paranoid case as well. > > Comments? > > To Santosh: > > > > upon > > > encountering a datasn hole, say, data_snack_sent, and it should ignore > > > any scsi status received while in this state. > > I wouldn't recommend that! If the Data SNACK were successful, this > status > is the final status for the I/O. Discarding the status would mean > setting > the stage for a(n unnecessary) status SNACK in future. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > Prasenjit Sarkar wrote: > > > > Santosh, > > > > Regarding (B), I did not even venture to imply that there would be a > > stat_sn hole. > > > > I'm a little confused about your data snack recovery rule, but that is > > besides the point and I can discuss this offline with you. > > > > My chief concern is that ERL 1 leaves open the possibility for duplicate > > SCSI status PDUs. There are three solutions: > > > > 1. Leave it to implementors who can use their judgement to decide which > > status to ignore. > > 2. Formulate a tight rule: status PDU with higher stat_sn number always > > wins. > > 3. Change the standard so that duplication does not happen. > > > > I would like the standard to at least discuss this and then state what path > > they chose and why (with good reason of course). I do not think that this > > is merely an implementation issue. > > > > My preference is of course: 3,2,1. > > > > Prasenjit Sarkar > > Research Staff Member > > IBM Almaden Research > > San Jose > > > > > > Santosh Rao > > > hp.com> cc: ips@ece.cmu.edu > > Sent by: Subject: Re: iSCSI: ERL=1 question. > > owner-ips@ece. > > cmu.edu > > > > > > 01/03/2002 > > 06:45 PM > > > > > > > > Prasenjit, > > > > Regarding your question (B).... > > > > Anytime the initiator's receive path successfully receives a pdu and > > passes format and digest error tests, the local state information of > > exp_cmdsn, max_cmdsn, statsn should be updated based on the values that > > are carried in that pdu and the rules specified in Section 2.2.2. > > > > Thus, in your below context, when the first scsi status pdu was > > received, the exp_statsn should have gotten updated and there should not > > have been any hole in statsn sequence. What am I missing (?) > > > > Regarding your question (A)... > > > > You may have read more into my answer than was intended. > > > > It is not the job of the lower layered pdu assembly path to filter out > > duplicate scsi status pdu's. Rather, this intelligence would lie within > > the module (finite state machine) that implemented the i/o path logic. > > > > While a data_snack has been sent and the i/o state machine is awaiting > > missing data pdu's , any received scsi status for that exchange must not > > be sent up to the SCSI ULP. Upon successful receipt of all the missing > > data pdu[s], the status can then be conveyed to the ULP. > > > > (I don't have a strong opinion either way, if we should have to state > > the above in the draft, or leave it unsaid as implementation specifics. > > I guess, at some point we cross over into the realm of an implementation > > guide vs a protocol specification :) > > > > - Santosh > > > > Prasenjit Sarkar wrote: > > > > > > I'm assuming Santosh wanted to reply to the entire group, so I am > > > forwarding his response to the mailing list. > > > > > > Santosh's argument is to provide the (unstated) rule that data assembly > > is > > > the domain of a lower iSCSI layer whose job is to filter out duplicate > > SCSI > > > status PDUs. I would gladly accept this argument except that a standard > > > should present a generic rule which should be independent of how a > > protocol > > > is implemented. I would prefer a rule based on stat_sn ordering or any > > > other equivalent rather than one based on ideal iSCSI layering. > > > > > > Santosh's motivation of having a seamless way of completing commands is > > > probably not true as initiators are allowed to generate SCSI responses. > > > > > > Prasenjit Sarkar > > > Research Staff Member > > > IBM Almaden Research > > > San Jose > > > > > > > > > Santosh Rao > > > > Sarkar/Almaden/IBM@IBMUS > > > hp.com> cc: > > > Sent by: Subject: Re: iSCSI: ERL=1 > > question. > > > santoshr@cup.h > > > p.com > > > > > > > > > 01/03/2002 > > > 05:00 PM > > > > > > > > > > > > Prasenjit, > > > > > > Responses inline. > > > > > > Regards, > > > Santosh > > > > > > Prasenjit Sarkar wrote: > > > > > > > > Assume the following scenario where I and T stand for initiator and > > > target > > > > respectively. > > > > > > > > 1. I->T: Scsi Cmd > > > > > > > > 2. T->I: Scsi Data (DataSN:0) > > > > > > > > 3. T->I: Scsi Status (Good) > > > > > > > > Assume there is a data digest problem for the data with DataSN:0, so > > > > > > > > 4. I->T: Data Snack for DataSN:0 > > > > > > > > The target for some reason cannot respond with the data, so according > > to > > > > the spec > > > > > > > > 5: T->I: Reject with reason DATA_SNACK_REJECT > > > > > > > > 6. T->I: Scsi Status (iSCSI response: SNACK rejected -> SCSI READ > > Error) > > > > > > > > The questions are as follows: > > > > > > > > A. Is SAM ambivalent of the fact that there can be two statii for the > > > same > > > > command? (I dont have a problem if SAM doesnt) > > > > > > I'm not certain on what SAM says on this one. However, one can envision > > > that the iscsi i/o finite state machine would enter into some state upon > > > encountering a datasn hole, say, data_snack_sent, and it should ignore > > > any scsi status received while in this state. > > > The lower pdu receive and re-assembly module should have passed format > > > and digest checks (assuming the frame came thru fine) and so, the local > > > value of exp_statsn should have gotten updated within this initiator > > > instance's iscsi connection finite state machine. > > > > > > Thus..... > > > i) since the 1st status was ignored while awaiting a data_snack > > > response, only 1 scsi status ends up being processed by the i/o finite > > > state m/c. > > > > > > ii) there will not be a statsn hole, since the previous status was > > > received successfully by the receive path, resulting in an update to > > > exp_statsn. however, the staus was discarded within the i/o fsm. > > > > > > > > > > > B, Does the second SCSI status have the same StatSN as the first? > > Likely, > > > > it does not, but it should be clearly stated that a SCSI status with > > > higher > > > > stat_sn overrides one with the lower stat_sn. > > > > > > See above. > > > > > > > > > > > C. I'm looking for motivation here: why does the target (rather than > > the > > > > initiator) generate the second status? Couldnt the initiator also do > > the > > > > same on receiving the DATA_SNACK_REJECT? > > > > > > So that all I/Os receive a single method of completion via the SCSI > > > status, I guess. > > > > > > -- > > > ################################## > > > 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 Sat Jan 5 08:05: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 IAA04213 for ; Sat, 5 Jan 2002 08:05:06 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g05CKae27212 for ips-outgoing; Sat, 5 Jan 2002 07:20:36 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g05CKXg27202 for ; Sat, 5 Jan 2002 07:20:33 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Sat, 5 Jan 2002 07:20:26 -0500 Message-ID: <25369470B6F0D41194820002B328BDD2202319@ATLOPS> From: Eddy Quicksall To: "julian_satran@il. ibm. com (E-mail)" , "Ralph Weber (E-mail)" Cc: "ips@ece. cmu. edu (E-mail)" Subject: iSCSI: response/status used together Date: Sat, 5 Jan 2002 07:20:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C195E3.5A5D3FE0" 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_01C195E3.5A5D3FE0 Content-Type: text/plain; charset="iso-8859-1" There was a change made in draft 7 as follows: - SCSI response made to fit having both a Status and a Response field. Needed for target errors that result in a check condition and ACA. In line with SAM2 that requires both fields (former versions where modeled on FCP). Can someone give me a case where both response and status can be set together? Also, it seems that ACA is reported via status; so what is the referenced statement referring to? Also, the spec says status "is valid only if the Response Code is Command Completed at target". So, that makes me wonder more about why they need to be separate. I assume the initiator should check the response for 0 before checking the status and then ignore the status if the response is not 0. Eddy _____ ------_=_NextPart_001_01C195E3.5A5D3FE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

There was a change made in draft 7 as follows:<= /p>

 

 - SCSI response made to fit = having both a Status and a Response <= /p>

 field. Needed for target = errors that result in a check <= /p>

 condition and ACA. In line = with SAM2 that requires both fields <= /p>

 (former versions where modeled = on FCP).

 

Can someone give me a case where both response and status can be set = together?

 

Also, it seems that ACA is reported via status; so what is the referenced = statement referring to?

 

Also, the spec says status “is valid only if the Response Code is = Command Completed at target”. So, that makes me wonder more about why they need to = be separate. I assume the initiator should check the response for 0 before checking = the status and then ignore the status if the response is not 0.

 

Eddy

 

 

 

 

=
------_=_NextPart_001_01C195E3.5A5D3FE0-- From owner-ips@ece.cmu.edu Sat Jan 5 12:13:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05935 for ; Sat, 5 Jan 2002 12:13:17 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g05GY1j06541 for ips-outgoing; Sat, 5 Jan 2002 11:34:01 -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 g05GXxg06531 for ; Sat, 5 Jan 2002 11:33:59 -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 RAA34114 for ; Sat, 5 Jan 2002 17:33: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 g05GYfP190144 for ; Sat, 5 Jan 2002 17:34:41 +0100 Subject: Re: iSCSI: Checking the I bit To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Sat, 5 Jan 2002 15:45:26 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 05/01/2002 18:34:44 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I think we have a (silent) consensus on making it 0 :-) Julo "Eddy Quicksall" To: "ips@ece. cmu. edu \(E-mail\)" Subject: iSCSI: Checking the I bit Sent by: owner-ips@ece. cmu.edu 13-12-01 13:26 Is it necessary for the initiator to check the I bit in every response? If an initiator does not need it, then I don't want to take the extra time to check it. I think this is consistent with the thinking of all attendees of the UNH Plug Fest because the report from UNH IOL was that "all companies failed that test". I would like to propose adding some wording to 3.2.1.1 similar to "It is not necessary to check this bit for 1 if the implementation in the initiator does not need its use". Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Sat Jan 5 12:17: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 MAA05987 for ; Sat, 5 Jan 2002 12:17:54 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g05GY7406550 for ips-outgoing; Sat, 5 Jan 2002 11:34: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 g05GXxg06532 for ; Sat, 5 Jan 2002 11:33:59 -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 RAA34116 for ; Sat, 5 Jan 2002 17:33: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 g05GYfP54112 for ; Sat, 5 Jan 2002 17:34:41 +0100 Subject: Re: iSCSI: AHS drop bit To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Sat, 5 Jan 2002 16:10:25 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 05/01/2002 18:34:44 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mallikarjun, The bit was really meant to enable dropping the additional header and not the whole request if ignored but rejecting the whole request. We don't have any use for it but some "vendor specific" extensions may. I suggest we change the wording of non-ISCSI non-iSCSI/vendor specific Julo "Mallikarjun C." To: ips Subject: iSCSI: AHS drop bit Sent by: owner-ips@ece. cmu.edu 14-12-01 22:48 Please respond to cbm Julian, Section 3.2.2.1 says the following on the AHS drop bit - bit 7 - Drop Bit - if set to 1 this AHS may be ignored if not understood; if set to 0 this AHS must be rejected if not understood. - I suspect it is the entire command that was meant to be failed, not just the AHS... - If it is a SCSI operation that is being failed, I suggest that the target should end the command with an appropriate SCSI CHECK CONDITION - so the command sequence window can advance at the transport level (and the inability of the target to support say extended CDB is known end-to-end, to prevent fruitless SCSI retries). - This bit may be useful for AHS code "Non-iSCSI extensions", but I could not see how it can be used for the defined iSCSI operations. If it is indeed so, I would actually suggest dropping this feature. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com From owner-ips@ece.cmu.edu Sat Jan 5 12:19: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 MAA06002 for ; Sat, 5 Jan 2002 12:19:06 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g05GXo906520 for ips-outgoing; Sat, 5 Jan 2002 11:33:50 -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 g05GXlg06515 for ; Sat, 5 Jan 2002 11:33: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 RAA26380 for ; Sat, 5 Jan 2002 17:33:39 +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 g05GYSP54106 for ; Sat, 5 Jan 2002 17:34:28 +0100 Subject: Re: iSCSI: A couple of definitions To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Sat, 5 Jan 2002 12:07:49 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 05/01/2002 18:34:31 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk thanks - julo Luben Tuikov c.com> cc: Sent by: Subject: iSCSI: A couple of definitions owner-ips@ece. cmu.edu 03-01-02 23:53 1. CID: The second sentence refers to ``this connection'' and there doesn't seem to be any connections in context. Since ``within'' is used as a preposition, shouldn't the sentence read as follows: It is a unique ID identifying a connection within the session for the initiator. 2. iSCSI Transfer Direction: ``with regard to'' has identical meaning to ``with respect to''. But isn't ``with respect to'' more common in mathematical and computer science literature, and ``with regard to'' being more common in the humanities and social sciences? Shouldn't the first sentence read: The iSCSI transfer direction is defined with respect to the initiator. -- -l From owner-ips@ece.cmu.edu Sat Jan 5 12: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 MAA06013 for ; Sat, 5 Jan 2002 12:19:13 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g05GXrs06526 for ips-outgoing; Sat, 5 Jan 2002 11:33:53 -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 g05GXpg06521 for ; Sat, 5 Jan 2002 11:33:51 -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 RAA13646 for ; Sat, 5 Jan 2002 17:33: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 g05GYWP45994 for ; Sat, 5 Jan 2002 17:34:32 +0100 Subject: RE: iSCSI: ERL=1 question. To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Sat, 5 Jan 2002 15:26:53 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 05/01/2002 18:34:35 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy, As it stands they are mutually exclusive. But by keeping 2 fields we leave our options open. It also maps to SAM - SAM has both a response and a status in the model procedure call and restricting the validity of status to good responses is made in text. Regards, Julo Eddy Quicksall Sent by: cc: ips@ece.cmu.edu owner-ips@ece.cmu. Subject: RE: iSCSI: ERL=1 question. edu 04-01-02 16:32 I hate to get blasted but here goes ... :) I would prefer that iSCSI Response and SCSI Status are mutually exclusive. Let the initiator generate the appropriate SCSI Status for the ULP given the iSCSI Response. It used to be that way. Maybe someone could tell us why it was changed. If there is a very good reason for them not to be mutually exclusive, then my code would just overlay the first status with the second and everything would work properly. Maybe a note could be added to the spec to make people aware that this could occur. Eddy -----Original Message----- From: Prasenjit Sarkar [mailto:psarkar@almaden.ibm.com] Sent: Thursday, January 03, 2002 11:17 PM To: Santosh Rao Cc: ips@ece.cmu.edu Subject: Re: iSCSI: ERL=1 question. Santosh, Regarding (B), I did not even venture to imply that there would be a stat_sn hole. I'm a little confused about your data snack recovery rule, but that is besides the point and I can discuss this offline with you. My chief concern is that ERL 1 leaves open the possibility for duplicate SCSI status PDUs. There are three solutions: 1. Leave it to implementors who can use their judgement to decide which status to ignore. 2. Formulate a tight rule: status PDU with higher stat_sn number always wins. 3. Change the standard so that duplication does not happen. I would like the standard to at least discuss this and then state what path they chose and why (with good reason of course). I do not think that this is merely an implementation issue. My preference is of course: 3,2,1. Prasenjit Sarkar Research Staff Member IBM Almaden Research San Jose Santosh Rao cc: ips@ece.cmu.edu Sent by: Subject: Re: iSCSI: ERL=1 question. owner-ips@ece. cmu.edu 01/03/2002 06:45 PM Prasenjit, Regarding your question (B).... Anytime the initiator's receive path successfully receives a pdu and passes format and digest error tests, the local state information of exp_cmdsn, max_cmdsn, statsn should be updated based on the values that are carried in that pdu and the rules specified in Section 2.2.2. Thus, in your below context, when the first scsi status pdu was received, the exp_statsn should have gotten updated and there should not have been any hole in statsn sequence. What am I missing (?) Regarding your question (A)... You may have read more into my answer than was intended. It is not the job of the lower layered pdu assembly path to filter out duplicate scsi status pdu's. Rather, this intelligence would lie within the module (finite state machine) that implemented the i/o path logic. While a data_snack has been sent and the i/o state machine is awaiting missing data pdu's , any received scsi status for that exchange must not be sent up to the SCSI ULP. Upon successful receipt of all the missing data pdu[s], the status can then be conveyed to the ULP. (I don't have a strong opinion either way, if we should have to state the above in the draft, or leave it unsaid as implementation specifics. I guess, at some point we cross over into the realm of an implementation guide vs a protocol specification :) - Santosh Prasenjit Sarkar wrote: > > I'm assuming Santosh wanted to reply to the entire group, so I am > forwarding his response to the mailing list. > > Santosh's argument is to provide the (unstated) rule that data assembly is > the domain of a lower iSCSI layer whose job is to filter out duplicate SCSI > status PDUs. I would gladly accept this argument except that a standard > should present a generic rule which should be independent of how a protocol > is implemented. I would prefer a rule based on stat_sn ordering or any > other equivalent rather than one based on ideal iSCSI layering. > > Santosh's motivation of having a seamless way of completing commands is > probably not true as initiators are allowed to generate SCSI responses. > > Prasenjit Sarkar > Research Staff Member > IBM Almaden Research > San Jose > > > Santosh Rao > hp.com> cc: > Sent by: Subject: Re: iSCSI: ERL=1 question. > santoshr@cup.h > p.com > > > 01/03/2002 > 05:00 PM > > > > Prasenjit, > > Responses inline. > > Regards, > Santosh > > Prasenjit Sarkar wrote: > > > > Assume the following scenario where I and T stand for initiator and > target > > respectively. > > > > 1. I->T: Scsi Cmd > > > > 2. T->I: Scsi Data (DataSN:0) > > > > 3. T->I: Scsi Status (Good) > > > > Assume there is a data digest problem for the data with DataSN:0, so > > > > 4. I->T: Data Snack for DataSN:0 > > > > The target for some reason cannot respond with the data, so according to > > the spec > > > > 5: T->I: Reject with reason DATA_SNACK_REJECT > > > > 6. T->I: Scsi Status (iSCSI response: SNACK rejected -> SCSI READ Error) > > > > The questions are as follows: > > > > A. Is SAM ambivalent of the fact that there can be two statii for the > same > > command? (I dont have a problem if SAM doesnt) > > I'm not certain on what SAM says on this one. However, one can envision > that the iscsi i/o finite state machine would enter into some state upon > encountering a datasn hole, say, data_snack_sent, and it should ignore > any scsi status received while in this state. > The lower pdu receive and re-assembly module should have passed format > and digest checks (assuming the frame came thru fine) and so, the local > value of exp_statsn should have gotten updated within this initiator > instance's iscsi connection finite state machine. > > Thus..... > i) since the 1st status was ignored while awaiting a data_snack > response, only 1 scsi status ends up being processed by the i/o finite > state m/c. > > ii) there will not be a statsn hole, since the previous status was > received successfully by the receive path, resulting in an update to > exp_statsn. however, the staus was discarded within the i/o fsm. > > > > > B, Does the second SCSI status have the same StatSN as the first? Likely, > > it does not, but it should be clearly stated that a SCSI status with > higher > > stat_sn overrides one with the lower stat_sn. > > See above. > > > > > C. I'm looking for motivation here: why does the target (rather than the > > initiator) generate the second status? Couldnt the initiator also do the > > same on receiving the DATA_SNACK_REJECT? > > So that all I/Os receive a single method of completion via the SCSI > status, I guess. > > -- > ################################## > 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 Sat Jan 5 16:13: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 QAA07448 for ; Sat, 5 Jan 2002 16:13:54 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g05KO2Y15561 for ips-outgoing; Sat, 5 Jan 2002 15:24:02 -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 g05KO0g15557 for ; Sat, 5 Jan 2002 15:24:00 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel13.hp.com (Postfix) with ESMTP id 9256CE001CD for ; Sat, 5 Jan 2002 12:23:54 -0800 (PST) Received: from swathi (pal1nai160162.nsr.hp.com [15.244.160.162]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id MAA26342 for ; Sat, 5 Jan 2002 12:25:28 -0800 (PST) Message-ID: <003101c19626$e4b11a20$a2a0f40f@rose.hp.com> From: "Mallikarjun C." To: References: Subject: Re: iSCSI: AHS drop bit Date: Sat, 5 Jan 2002 12:23:52 -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 Julian, > We don't have any use for it but some "vendor specific" extensions may. That then begs the question - should/can we anticipate vendor-specific needs and provide for them in the spec? My preference is to do away with AHS drop bit - since it doesn't seem useful to either iSCSI or SCSI. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ----- Original Message ----- From: "Julian Satran" To: Sent: Saturday, January 05, 2002 6:10 AM Subject: Re: iSCSI: AHS drop bit > Mallikarjun, > > The bit was really meant to enable dropping the additional header and not > the whole request if ignored but rejecting the whole request. > We don't have any use for it but some "vendor specific" extensions may. > > I suggest we change the wording of non-ISCSI non-iSCSI/vendor specific > > Julo > > > > "Mallikarjun > C." To: ips > om> Subject: iSCSI: AHS drop bit > Sent by: > owner-ips@ece. > cmu.edu > > > 14-12-01 22:48 > Please respond > to cbm > > > > > > Julian, > > Section 3.2.2.1 says the following on the AHS drop bit - > bit 7 - Drop Bit - if set to 1 this AHS may be ignored if not > understood; if set to 0 this AHS must be rejected if not > understood. > > - I suspect it is the entire command that was meant to be failed, not > just the AHS... > > - If it is a SCSI operation that is being failed, I suggest that > the target should end the command with an appropriate SCSI CHECK > CONDITION - so the command sequence window can advance at the > transport level (and the inability of the target to support say > extended CDB is known end-to-end, to prevent fruitless SCSI retries). > > - This bit may be useful for AHS code "Non-iSCSI extensions", but > I could not see how it can be used for the defined iSCSI operations. > If it is indeed so, I would actually suggest dropping this feature. > > Regards. > -- > Mallikarjun > > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > > > > From owner-ips@ece.cmu.edu Sun Jan 6 18:09: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 SAA27270 for ; Sun, 6 Jan 2002 18:09:18 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g06M3Ih21890 for ips-outgoing; Sun, 6 Jan 2002 17:03: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 g06M3Gg21886 for ; Sun, 6 Jan 2002 17:03:17 -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 QAA11242 for ; Sun, 6 Jan 2002 16:59:53 -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 g06M2iq119408 for ; Sun, 6 Jan 2002 15:02:44 -0700 X-Priority: 1 (High) Importance: Normal Subject: iSCSI: Markers To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Sun, 6 Jan 2002 13:57:56 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 01/06/2002 03:02:44 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk When we were in Salt Lake City, we decided to hold a discussion on the Reflector regarding Markers. I think it is probably time to hold that discussion. Therefore, I will start it out. First I want to thank Julian for going to the trouble to document the proposal for COWS. This now gives us two Marker proposals to consider. They are the Fixed Interval Markers (FIM) and the Constant Overhead Word Stuffing (COWS) proposals. Having said that, lets examine each one and determine their usefulness. 1. Markers (FIM or COWS) are only needed by Hardware HBAs that are attempting to limit the amount of Reassembly Buffers they need on-board. This will always be a probabilistic determination by the vendors, but the purpose of Markers are to hold down the amount of total RAM needed, especially when factored into a probabilistic determination. 2. The use of Markers are negotiated per connection, and per direction. It is therefore possible for a software implementation to send markers, but not have to accept them. 3. When CRC Digest are negotiated to be used, it does no good to send out Markers since the hardware side will have to have Reassembly Buffers to compute the CRC Digest. Therefore, Markers do not help anything when CRCs are used on a connection. 4. FIM can be implemented easily in software, and with an out going Scatter/Gather technique could send PDUs across a network to a Hardware HBA destination without requiring additional moves or touching each byte. 5. Software iSCSI implementations should always negotiate NOT to receive markers since Markers do not help the SW in any way. 6. Hardware HBAs can also implement FIM easily, and HW can do it easily in both directions. Therefore, if FIM is the approved Marker proposal, a HW HBA should send FIM whenever it sends iSCSI Commands and/or Data to other HW HBAs (assuming iWARP is not an available option), and the other HW HBAs wants them. 7. I do not foresee many installations using CRC Digests with Laptops and Desktops, since the overhead will probably be noticeable, and most installations do not judge Desktop and Laptop data to be key corporate assets (I am not saying that opinion is right, or that it is Universal, just that is a prevalent opinion). 8. A single software node would not be fast enough to cause a significant load or a significant memory requirement for the Reassembly Buffers. However, the combination of many (perhaps Desktops and Laptops spread across a real or virtual campus) can bring on a large load and the need for many Reassembly Buffers. The resultant amount of small Reassembly Buffers could make the Total requirement very High (thus raising the cost of the HBA). 9. Given the need for Desktops and Laptops to avoid noticeable degradation, and the probability that they will not be using CRC, means that the use of FIM is a compatible option when working across a network from a SW Node to an iSCSI HW HBA implemented Storage Controller. 10. COWS was also designed to be easily implemented in Software and in Hardware. 11. COWS will require the iSCSI Software implementations to touch each byte, as it looks for matches to its Framing Pattern within the PDUs. 12. When CRC-32 digests are being computed, the Software will have to touch ever byte anyway, so the additional overhead to look for matches to the Framing Pattern is negligible. On the other hand FIM also works well with SW CRC-32 Digest computation. 13. But the premies I set above (which is clearly up to debate), is that Desktops and Laptops will not usually compute the CRC Digest. 14. COWS has the ability to have its pointing Markers, which point to the Framing Pattern Matches, point either forward or backwards. When being processed by software, the direction does not matter. So since the Markers should only be used on outgoing PDUs, the approprate direction of the pointers is what ever the destination needs. 15. Many vendors, especially at the higher speeds, are implementing a pipe line design. The pipeline receive process, will most likely want the COWS pointers to be forward pointing (pointing in the direction of the end of the PDU). Since the SW does not care, forward pointers should be fine. 16. If the HW Pipelining iSCSI HBA is to send COWS Markers to another HW Pipelining HBA, there may be a problem. The outgoing pipeline would prefer to have the pointers pointing backwards, but the receiving pipeline would prefer to have the pointers going forwards. Therefore with COWS, either the sending or the receiving HW Pipelining HBA will be unhappy and pipeline design will get very much more complicated. 17. Everyone likes iWARP better, but it requires changes to the Host SW TCP/IP stacks in the case of SW Initiators. Since these SW installations are probably going to be Desktops and Laptops, these systems will very likely have some non current version of the OS, (such as windows 2k, ME, etc.). Hence it is unlikely that they will have iWARP in the majority of the SW TCP/IP Stacks). 18. If, for some reason, a Server uses Software iSCSI, it will probably have the latest and greatest OS software, and if that is true, and if iWARP is approved by the IETF then it will probably have the TCP/IP extensions that are required by iWARP. It will therefore use iWARP instead of any Marker solution. 19. If the Server uses Software iSCSI, and if iWARP is not approved by the IETF, then COWS or FIM are both reasonable choices for the Server, if the Server also uses the CRC option. If CRC is not used on the Server, FIM is a better match with the Server SW iSCSI. 19. iWARP is probably going to stay in IETF "experimental mode" for some time into the future. And without iWARP being specified by iSCSI as -- at least, "MAY Implement" and "MAY use", the HW to HW mode will still need a Marker solution. 20. Therefore, we are left with Markers as the only technique we can count on to aid and assist the iSCSI HW HBAs, keep their "on-board" RAM requirements to a minimum. Based on the above I come to the following conclusions: 1. Markers are needed. 2. FIM works best with the probable SW environment, and has the lowest overhead (since they will probably not use CRC Digests). 3. Since if CRC is used, the HW needs its Reassembly Buffers anyway, so there is no reason to use COWS, or any type of Marker. 4. FIM can work well between HW HBAs without significant impact to pipeline design. Therefore, I recommend that the Draft continue to define FIM. Also, I recommend that the FIM type of Markers be "MUST Implement" on the Out-Going direction, and "MAY Implement" on the incoming direction". Further, I recommend the Draft say that FIM "MAY be used" in any direction, depending on the negotiations. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Mon Jan 7 02:02: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 CAA06284 for ; Mon, 7 Jan 2002 02:02:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g076Cko10440 for ips-outgoing; Mon, 7 Jan 2002 01:12:46 -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 g076Cgg10431 for ; Mon, 7 Jan 2002 01:12:43 -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 HAA14638 for ; Mon, 7 Jan 2002 07:12: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 g076DMv22344 for ; Mon, 7 Jan 2002 07:13:22 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: Markers X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Mon, 7 Jan 2002 08:13:25 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 07/01/2002 08:13:28, Serialize complete at 07/01/2002 08:13:28 Content-Type: multipart/alternative; boundary="=_alternative 0021A514C2256B3A_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0021A514C2256B3A_= Content-Type: text/plain; charset="us-ascii" Some comments in text - Julo John Hufferd/San Jose/IBM@IBMUS Sent by: owner-ips@ece.cmu.edu 06-01-02 23:57 To: ips@ece.cmu.edu cc: Subject: iSCSI: Markers When we were in Salt Lake City, we decided to hold a discussion on the Reflector regarding Markers. I think it is probably time to hold that discussion. Therefore, I will start it out. First I want to thank Julian for going to the trouble to document the proposal for COWS. This now gives us two Marker proposals to consider. They are the Fixed Interval Markers (FIM) and the Constant Overhead Word Stuffing (COWS) proposals. Having said that, lets examine each one and determine their usefulness. 1. Markers (FIM or COWS) are only needed by Hardware HBAs that are attempting to limit the amount of Reassembly Buffers they need on-board. This will always be a probabilistic determination by the vendors, but the purpose of Markers are to hold down the amount of total RAM needed, especially when factored into a probabilistic determination. 2. The use of Markers are negotiated per connection, and per direction. It is therefore possible for a software implementation to send markers, but not have to accept them. +++ that is specially important for software implementations ++ 3. When CRC Digest are negotiated to be used, it does no good to send out Markers since the hardware side will have to have Reassembly Buffers to compute the CRC Digest. Therefore, Markers do not help anything when CRCs are used on a connection. +++ That is not correct - Framing mechanisms are used to avoid an RTT related size for the receive buffer not avoinding a one-PDU buffer. Both FIM and COWS will help reducing HBA ememory requirements even when using CRC. When Using CRC a PDU reassembly buffer is unavoidale but it can be limited by the MaxRcvPDU. +++ 4. FIM can be implemented easily in software, and with an out going Scatter/Gather technique could send PDUs across a network to a Hardware HBA destination without requiring additional moves or touching each byte. 5. Software iSCSI implementations should always negotiate NOT to receive markers since Markers do not help the SW in any way. 6. Hardware HBAs can also implement FIM easily, and HW can do it easily in both directions. Therefore, if FIM is the approved Marker proposal, a HW HBA should send FIM whenever it sends iSCSI Commands and/or Data to other HW HBAs (assuming iWARP is not an available option), and the other HW HBAs wants them. 7. I do not foresee many installations using CRC Digests with Laptops and Desktops, since the overhead will probably be noticeable, and most installations do not judge Desktop and Laptop data to be key corporate assets (I am not saying that opinion is right, or that it is Universal, just that is a prevalent opinion). +++CRCs are not relevant +++ 8. A single software node would not be fast enough to cause a significant load or a significant memory requirement for the Reassembly Buffers. However, the combination of many (perhaps Desktops and Laptops spread across a real or virtual campus) can bring on a large load and the need for many Reassembly Buffers. The resultant amount of small Reassembly Buffers could make the Total requirement very High (thus raising the cost of the HBA). 9. Given the need for Desktops and Laptops to avoid noticeable degradation, and the probability that they will not be using CRC, means that the use of FIM is a compatible option when working across a network from a SW Node to an iSCSI HW HBA implemented Storage Controller. 10. COWS was also designed to be easily implemented in Software and in Hardware. 11. COWS will require the iSCSI Software implementations to touch each byte, as it looks for matches to its Framing Pattern within the PDUs. +++ except when implemented within the CRC, checksum where no ADDITIONAL touch is involved +++ 12. When CRC-32 digests are being computed, the Software will have to touch ever byte anyway, so the additional overhead to look for matches to the Framing Pattern is negligible. On the other hand FIM also works well with SW CRC-32 Digest computation. 13. But the premies I set above (which is clearly up to debate), is that Desktops and Laptops will not usually compute the CRC Digest. 14. COWS has the ability to have its pointing Markers, which point to the Framing Pattern Matches, point either forward or backwards. When being processed by software, the direction does not matter. So since the Markers should only be used on outgoing PDUs, the approprate direction of the pointers is what ever the destination needs. 15. Many vendors, especially at the higher speeds, are implementing a pipe line design. The pipeline receive process, will most likely want the COWS pointers to be forward pointing (pointing in the direction of the end of the PDU). Since the SW does not care, forward pointers should be fine. 16. If the HW Pipelining iSCSI HBA is to send COWS Markers to another HW Pipelining HBA, there may be a problem. The outgoing pipeline would prefer to have the pointers pointing backwards, but the receiving pipeline would prefer to have the pointers going forwards. Therefore with COWS, either the sending or the receiving HW Pipelining HBA will be unhappy and pipeline design will get very much more complicated. 17. Everyone likes iWARP better, but it requires changes to the Host SW TCP/IP stacks in the case of SW Initiators. Since these SW installations are probably going to be Desktops and Laptops, these systems will very likely have some non current version of the OS, (such as windows 2k, ME, etc.). Hence it is unlikely that they will have iWARP in the majority of the SW TCP/IP Stacks). +++iWARP needs framing as well and I would guess the technique will be close to what COWS is. Future convergence speaks for COWS+++ 18. If, for some reason, a Server uses Software iSCSI, it will probably have the latest and greatest OS software, and if that is true, and if iWARP is approved by the IETF then it will probably have the TCP/IP extensions that are required by iWARP. It will therefore use iWARP instead of any Marker solution. 19. If the Server uses Software iSCSI, and if iWARP is not approved by the IETF, then COWS or FIM are both reasonable choices for the Server, if the Server also uses the CRC option. If CRC is not used on the Server, FIM is a better match with the Server SW iSCSI. 19. iWARP is probably going to stay in IETF "experimental mode" for some time into the future. And without iWARP being specified by iSCSI as -- at least, "MAY Implement" and "MAY use", the HW to HW mode will still need a Marker solution. 20. Therefore, we are left with Markers as the only technique we can count on to aid and assist the iSCSI HW HBAs, keep their "on-board" RAM requirements to a minimum. Based on the above I come to the following conclusions: 1. Markers are needed. 2. FIM works best with the probable SW environment, and has the lowest overhead (since they will probably not use CRC Digests). +++CRCs are not relevant+++ 3. Since if CRC is used, the HW needs its Reassembly Buffers anyway, so there is no reason to use COWS, or any type of Marker. +++ again the same confusion betwen the PDU buffer and the RTT related holding are in the absence of Markers+++ 4. FIM can work well between HW HBAs without significant impact to pipeline design. +++ Somebody already said that FIMs are like democracy - imperfect, ugly but work+++ +++ However COWS are not that much heavier if carefully implemented and might get us faster to converge on a framing model+++ Therefore, I recommend that the Draft continue to define FIM. Also, I recommend that the FIM type of Markers be "MUST Implement" on the Out-Going direction, and "MAY Implement" on the incoming direction". Further, I recommend the Draft say that FIM "MAY be used" in any direction, depending on the negotiations. . . . 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 0021A514C2256B3A_= Content-Type: text/html; charset="us-ascii"
Some comments in text - Julo


John Hufferd/San Jose/IBM@IBMUS
Sent by: owner-ips@ece.cmu.edu

06-01-02 23:57

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI: Markers

       


When we were in Salt Lake City, we decided to hold a discussion on the
Reflector regarding Markers.  I think it is probably time to hold that
discussion.  Therefore, I will start it out.

First I want to thank Julian for going to the trouble to document the
proposal for COWS.  This now gives us two Marker proposals to consider.
They are the Fixed Interval Markers (FIM) and the Constant Overhead Word
Stuffing (COWS) proposals.

Having said that, lets examine each one and determine their usefulness.

1. Markers (FIM or COWS) are only needed by Hardware HBAs that are
attempting to limit the amount of Reassembly Buffers they need on-board.
This will always be a probabilistic determination by the vendors, but the
purpose of Markers are to hold down the amount of total RAM needed,
especially when factored into a probabilistic determination.
2. The use of Markers are negotiated per connection, and per direction.  It
is therefore possible for a software implementation to send markers, but
not have to accept them.
+++ that is specially important for software implementations ++
3. When CRC Digest are negotiated to be used, it does no good to send out
Markers since the hardware side will have to have Reassembly Buffers to
compute the CRC Digest.  Therefore, Markers do not help anything when CRCs
are used on a connection.
+++ That is not correct - Framing mechanisms are used to avoid an RTT related size for the receive buffer not avoinding  a one-PDU buffer. Both FIM and COWS will help reducing HBA ememory requirements even when using CRC.  When Using CRC a PDU reassembly buffer is unavoidale but it can be limited by the MaxRcvPDU. +++

4. FIM can be implemented easily in software, and with an out going
Scatter/Gather technique could send PDUs across a network to a Hardware HBA
destination without requiring additional moves or touching each byte.
5. Software iSCSI implementations should always negotiate NOT to receive
markers since Markers do not help the SW in any way.
6. Hardware HBAs can also implement FIM easily, and HW can do it easily in
both directions.  Therefore, if FIM is the approved Marker proposal, a HW
HBA should send FIM whenever it sends iSCSI Commands and/or Data to other
HW HBAs (assuming iWARP is not an available option), and the other HW HBAs
wants them.
7. I do not foresee many installations using CRC Digests with Laptops and
Desktops, since the overhead will probably be noticeable, and most
installations do not judge Desktop and Laptop data to be key corporate
assets (I am not saying that opinion is right, or that it is Universal,
just that is a prevalent opinion).
+++CRCs are not relevant +++
8. A single software node would not be fast enough to cause a significant
load or a significant  memory requirement for the Reassembly Buffers.
However, the combination of many (perhaps Desktops and Laptops spread
across a real or virtual campus) can bring on a large load and the need for
many Reassembly Buffers.  The resultant amount of small Reassembly Buffers
could make the Total requirement very High (thus raising the cost of the
HBA).
9. Given the need for Desktops and Laptops to avoid noticeable degradation,
and the probability that they will not be using CRC, means that the use of
FIM is a compatible option when working across a network from a SW Node to
an iSCSI HW HBA implemented Storage Controller.
10. COWS was also designed to be easily implemented in Software and in
Hardware.
11. COWS will require the iSCSI Software implementations to touch each
byte, as it looks for matches to its Framing Pattern within the PDUs.
+++ except when implemented within the CRC, checksum where no ADDITIONAL touch is involved +++
12. When CRC-32 digests are being computed, the Software will have to touch
ever byte anyway, so the additional overhead to look for matches to the
Framing Pattern is negligible.  On the other hand FIM also works well with
SW CRC-32 Digest computation.
13. But the premies I set above (which is clearly up to debate), is that
Desktops and Laptops will not usually compute the CRC Digest.
14. COWS has the ability to have its pointing Markers, which point to the
Framing Pattern Matches, point either forward or backwards.  When being
processed by software, the direction does not matter.  So since the Markers
should only be used on outgoing PDUs, the approprate direction of the
pointers is what ever the destination needs.
15. Many vendors, especially at the higher speeds, are implementing a pipe
line design.  The pipeline receive process, will most likely want the COWS
pointers to be forward pointing (pointing in the direction of the end of
the PDU).  Since the SW does not care, forward pointers should be fine.
16. If the HW Pipelining iSCSI HBA is to send COWS Markers to another HW
Pipelining HBA, there may be a problem.  The outgoing pipeline would prefer
to have the pointers pointing backwards, but the receiving pipeline would
prefer to have the pointers going forwards.  Therefore with COWS, either
the sending or the receiving HW Pipelining HBA will be unhappy and pipeline
design will get very much more complicated.
17. Everyone likes iWARP better, but it requires changes to the Host SW
TCP/IP stacks in the case of SW Initiators.  Since these SW installations
are probably going to be Desktops and Laptops, these systems will very
likely have some non current version of the OS, (such as windows 2k, ME,
etc.).  Hence it is unlikely that they will have iWARP in the majority of
the SW TCP/IP Stacks).
+++iWARP needs framing as well and I would guess the technique will be close to what COWS is.  Future convergence speaks for COWS+++
18. If, for some reason, a Server uses Software iSCSI, it will probably
have the latest and greatest OS software, and if that is true, and if iWARP
is approved by the IETF then it will probably have the TCP/IP extensions
that are required by iWARP.  It will therefore use iWARP instead of any
Marker solution.
19. If the Server uses Software iSCSI,  and if iWARP is not approved by the
IETF, then COWS or FIM are both  reasonable choices  for the Server, if the
Server also uses the CRC option.  If CRC is not used on the Server, FIM is
a better match with the Server SW iSCSI.
19. iWARP is probably going to stay in IETF "experimental mode" for some
time into the future.  And without iWARP being specified by iSCSI as -- at
least, "MAY Implement" and "MAY use", the HW to HW mode will still need a
Marker solution.
20. Therefore, we are left with Markers as the only technique we can count
on to aid and assist the iSCSI HW HBAs, keep their "on-board" RAM
requirements to a minimum.

Based on the above I come to the following conclusions:
1. Markers are needed.
2. FIM works best with the probable SW environment, and has the lowest
overhead (since they will probably not use CRC Digests).
+++CRCs are not relevant+++
3. Since if CRC is used, the HW needs its Reassembly Buffers anyway, so
there is no reason to use COWS, or any type of Marker.
+++ again the same confusion betwen the PDU buffer and the RTT related holding are in the absence of Markers+++
4. FIM can work well between HW HBAs without significant impact to pipeline
design.
+++ Somebody already said that FIMs are like democracy - imperfect, ugly but work+++
+++ However COWS are not that much heavier if carefully implemented and might get us faster to converge on a framing model+++

Therefore, I recommend that the Draft continue to define FIM.  Also, I
recommend that the FIM type of Markers be "MUST Implement" on the Out-Going
direction, and "MAY Implement" on the incoming direction".   Further, I
recommend the Draft say that FIM "MAY be used" in any direction, depending
on the negotiations.

.
.
.
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 0021A514C2256B3A_=-- From owner-ips@ece.cmu.edu Mon Jan 7 06:03: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 GAA12899 for ; Mon, 7 Jan 2002 06:03:22 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g07A7ua29932 for ips-outgoing; Mon, 7 Jan 2002 05:07:56 -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 g07A7sg29928 for ; Mon, 7 Jan 2002 05:07:55 -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 FAA153168 for ; Mon, 7 Jan 2002 05:04:55 -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 g07A7p5111242 for ; Mon, 7 Jan 2002 03:07:51 -0700 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: Markers 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: Mon, 7 Jan 2002 02:07:05 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 01/07/2002 03:07:51 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 g07A7tg29929 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Julian, There are two different issues with regards to CRC. One is on the sender side, and if Markers are done in Software, of course it matters if CRC is done, since if the sender does not use CRC, the cost of COWS is very high. The second point is about the Receiving Side. I did not understand your point, so I would appreciate you expanding on your comment that the Target Side would still get value out of Markers even if they use CRC. I can understand that there would be some additional value, especially in TCP Segment errors. By permitting some additional TCP Segments to arrive during the retry, but most of the value is lost because the Full Reassembly Buffer is needed for CRC. So now that I confess, that I do not completely understand your point, perhaps you could step me through your view of the value in the presents of CRC on a HW HBA/Chip. I think it is important that we are able to quantify the value. With regards to iWARP, I was using that name as an alias for the technique explained in the framing Draft (at http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-ulp-frame-01.txt). But except for the last part of COWS, there is little resemblance between that and COWS. The framing does NOT use Word replacement. They only have a 8 byte header in common. That brings me to another point. If FIM needs to double its Markers (two words instead of one), would not COWS also need to double its Header Markers, for the same reason? . . . 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 01/06/2002 10:13:25 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: iSCSI: Markers Some comments in text - Julo John Hufferd/San Jose/IBM@IBMUS         To:        ips@ece.cmu.edu Sent by:         cc: owner-ips@ece.cmu.         Subject:        iSCSI: Markers edu 06-01-02 23:57 When we were in Salt Lake City, we decided to hold a discussion on the Reflector regarding Markers.  I think it is probably time to hold that discussion.  Therefore, I will start it out. First I want to thank Julian for going to the trouble to document the proposal for COWS.  This now gives us two Marker proposals to consider. They are the Fixed Interval Markers (FIM) and the Constant Overhead Word Stuffing (COWS) proposals. Having said that, lets examine each one and determine their usefulness. 1. Markers (FIM or COWS) are only needed by Hardware HBAs that are attempting to limit the amount of Reassembly Buffers they need on-board. This will always be a probabilistic determination by the vendors, but the purpose of Markers are to hold down the amount of total RAM needed, especially when factored into a probabilistic determination. 2. The use of Markers are negotiated per connection, and per direction.  It is therefore possible for a software implementation to send markers, but not have to accept them. +++ that is specially important for software implementations ++ 3. When CRC Digest are negotiated to be used, it does no good to send out Markers since the hardware side will have to have Reassembly Buffers to compute the CRC Digest.  Therefore, Markers do not help anything when CRCs are used on a connection. +++ That is not correct - Framing mechanisms are used to avoid an RTT related size for the receive buffer not avoinding  a one-PDU buffer. Both FIM and COWS will help reducing HBA ememory requirements even when using CRC.  When Using CRC a PDU reassembly buffer is unavoidale but it can be limited by the MaxRcvPDU. +++ 4. FIM can be implemented easily in software, and with an out going Scatter/Gather technique could send PDUs across a network to a Hardware HBA destination without requiring additional moves or touching each byte. 5. Software iSCSI implementations should always negotiate NOT to receive markers since Markers do not help the SW in any way. 6. Hardware HBAs can also implement FIM easily, and HW can do it easily in both directions.  Therefore, if FIM is the approved Marker proposal, a HW HBA should send FIM whenever it sends iSCSI Commands and/or Data to other HW HBAs (assuming iWARP is not an available option), and the other HW HBAs wants them. 7. I do not foresee many installations using CRC Digests with Laptops and Desktops, since the overhead will probably be noticeable, and most installations do not judge Desktop and Laptop data to be key corporate assets (I am not saying that opinion is right, or that it is Universal, just that is a prevalent opinion). +++CRCs are not relevant +++ 8. A single software node would not be fast enough to cause a significant load or a significant  memory requirement for the Reassembly Buffers. However, the combination of many (perhaps Desktops and Laptops spread across a real or virtual campus) can bring on a large load and the need for many Reassembly Buffers.  The resultant amount of small Reassembly Buffers could make the Total requirement very High (thus raising the cost of the HBA). 9. Given the need for Desktops and Laptops to avoid noticeable degradation, and the probability that they will not be using CRC, means that the use of FIM is a compatible option when working across a network from a SW Node to an iSCSI HW HBA implemented Storage Controller. 10. COWS was also designed to be easily implemented in Software and in Hardware. 11. COWS will require the iSCSI Software implementations to touch each byte, as it looks for matches to its Framing Pattern within the PDUs. +++ except when implemented within the CRC, checksum where no ADDITIONAL touch is involved +++ 12. When CRC-32 digests are being computed, the Software will have to touch ever byte anyway, so the additional overhead to look for matches to the Framing Pattern is negligible.  On the other hand FIM also works well with SW CRC-32 Digest computation. 13. But the premies I set above (which is clearly up to debate), is that Desktops and Laptops will not usually compute the CRC Digest. 14. COWS has the ability to have its pointing Markers, which point to the Framing Pattern Matches, point either forward or backwards.  When being processed by software, the direction does not matter.  So since the Markers should only be used on outgoing PDUs, the approprate direction of the pointers is what ever the destination needs. 15. Many vendors, especially at the higher speeds, are implementing a pipe line design.  The pipeline receive process, will most likely want the COWS pointers to be forward pointing (pointing in the direction of the end of the PDU).  Since the SW does not care, forward pointers should be fine. 16. If the HW Pipelining iSCSI HBA is to send COWS Markers to another HW Pipelining HBA, there may be a problem.  The outgoing pipeline would prefer to have the pointers pointing backwards, but the receiving pipeline would prefer to have the pointers going forwards.  Therefore with COWS, either the sending or the receiving HW Pipelining HBA will be unhappy and pipeline design will get very much more complicated. 17. Everyone likes iWARP better, but it requires changes to the Host SW TCP/IP stacks in the case of SW Initiators.  Since these SW installations are probably going to be Desktops and Laptops, these systems will very likely have some non current version of the OS, (such as windows 2k, ME, etc.).  Hence it is unlikely that they will have iWARP in the majority of the SW TCP/IP Stacks). +++iWARP needs framing as well and I would guess the technique will be close to what COWS is.  Future convergence speaks for COWS+++ 18. If, for some reason, a Server uses Software iSCSI, it will probably have the latest and greatest OS software, and if that is true, and if iWARP is approved by the IETF then it will probably have the TCP/IP extensions that are required by iWARP.  It will therefore use iWARP instead of any Marker solution. 19. If the Server uses Software iSCSI,  and if iWARP is not approved by the IETF, then COWS or FIM are both  reasonable choices  for the Server, if the Server also uses the CRC option.  If CRC is not used on the Server, FIM is a better match with the Server SW iSCSI. 19. iWARP is probably going to stay in IETF "experimental mode" for some time into the future.  And without iWARP being specified by iSCSI as -- at least, "MAY Implement" and "MAY use", the HW to HW mode will still need a Marker solution. 20. Therefore, we are left with Markers as the only technique we can count on to aid and assist the iSCSI HW HBAs, keep their "on-board" RAM requirements to a minimum. Based on the above I come to the following conclusions: 1. Markers are needed. 2. FIM works best with the probable SW environment, and has the lowest overhead (since they will probably not use CRC Digests). +++CRCs are not relevant+++ 3. Since if CRC is used, the HW needs its Reassembly Buffers anyway, so there is no reason to use COWS, or any type of Marker. +++ again the same confusion betwen the PDU buffer and the RTT related holding are in the absence of Markers+++ 4. FIM can work well between HW HBAs without significant impact to pipeline design. +++ Somebody already said that FIMs are like democracy - imperfect, ugly but work+++ +++ However COWS are not that much heavier if carefully implemented and might get us faster to converge on a framing model+++ Therefore, I recommend that the Draft continue to define FIM.  Also, I recommend that the FIM type of Markers be "MUST Implement" on the Out-Going direction, and "MAY Implement" on the incoming direction".   Further, I recommend the Draft say that FIM "MAY be used" in any direction, depending on the negotiations. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Mon Jan 7 09:29: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 JAA15284 for ; Mon, 7 Jan 2002 09:29:34 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g07DXXU07543 for ips-outgoing; Mon, 7 Jan 2002 08:33:33 -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 g07DXVg07538 for ; Mon, 7 Jan 2002 08:33:31 -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 OAA28028 for ; Mon, 7 Jan 2002 14:33:24 +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 g07DYBv152688 for ; Mon, 7 Jan 2002 14:34:11 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: Markers X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Mon, 7 Jan 2002 15:34:13 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 07/01/2002 15:34:17, Serialize complete at 07/01/2002 15:34:17 Content-Type: multipart/alternative; boundary="=_alternative 004A157CC2256B3A_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004A157CC2256B3A_= Content-Type: text/plain; charset="us-ascii" John, The markers are supposed to help you get fat to the next PDU and start assembling and placing it. It does not alleviate the need for a PDU assembly buffer - that you need anyhow - it alleviates the need to keep TCP packets along when you have lost an iSCSI PDU header. Once you have an iSCSI PDU header you need only the (as short as you want) PDU reassembly. If you do not have an iSCSI header you have potentially to keep around an RTT dependent amount of data. Markers are here to reduce the later to an amount that is not a function of Bandwidth*RTT. Regards, Julo John Hufferd@IBMUS 07-01-02 12:07 To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu From: John Hufferd/San Jose/IBM@IBMUS Subject: Re: iSCSI: Markers Julian, There are two different issues with regards to CRC. One is on the sender side, and if Markers are done in Software, of course it matters if CRC is done, since if the sender does not use CRC, the cost of COWS is very high. The second point is about the Receiving Side. I did not understand your point, so I would appreciate you expanding on your comment that the Target Side would still get value out of Markers even if they use CRC. I can understand that there would be some additional value, especially in TCP Segment errors. By permitting some additional TCP Segments to arrive during the retry, but most of the value is lost because the Full Reassembly Buffer is needed for CRC. So now that I confess, that I do not completely understand your point, perhaps you could step me through your view of the value in the presents of CRC on a HW HBA/Chip. I think it is important that we are able to quantify the value. With regards to iWARP, I was using that name as an alias for the technique explained in the framing Draft (at http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-ulp-frame-01.txt). But except for the last part of COWS, there is little resemblance between that and COWS. The framing does NOT use Word replacement. They only have a 8 byte header in common. That brings me to another point. If FIM needs to double its Markers (two words instead of one), would not COWS also need to double its Header Markers, for the same reason? . . . 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 Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: iSCSI: Markers Some comments in text - Julo John Hufferd/San Jose/IBM@IBMUS Sent by: owner-ips@ece.cmu.edu 06-01-02 23:57 To: ips@ece.cmu.edu cc: Subject: iSCSI: Markers When we were in Salt Lake City, we decided to hold a discussion on the Reflector regarding Markers. I think it is probably time to hold that discussion. Therefore, I will start it out. First I want to thank Julian for going to the trouble to document the proposal for COWS. This now gives us two Marker proposals to consider. They are the Fixed Interval Markers (FIM) and the Constant Overhead Word Stuffing (COWS) proposals. Having said that, lets examine each one and determine their usefulness. 1. Markers (FIM or COWS) are only needed by Hardware HBAs that are attempting to limit the amount of Reassembly Buffers they need on-board. This will always be a probabilistic determination by the vendors, but the purpose of Markers are to hold down the amount of total RAM needed, especially when factored into a probabilistic determination. 2. The use of Markers are negotiated per connection, and per direction. It is therefore possible for a software implementation to send markers, but not have to accept them. +++ that is specially important for software implementations ++ 3. When CRC Digest are negotiated to be used, it does no good to send out Markers since the hardware side will have to have Reassembly Buffers to compute the CRC Digest. Therefore, Markers do not help anything when CRCs are used on a connection. +++ That is not correct - Framing mechanisms are used to avoid an RTT related size for the receive buffer not avoinding a one-PDU buffer. Both FIM and COWS will help reducing HBA ememory requirements even when using CRC. When Using CRC a PDU reassembly buffer is unavoidale but it can be limited by the MaxRcvPDU. +++ 4. FIM can be implemented easily in software, and with an out going Scatter/Gather technique could send PDUs across a network to a Hardware HBA destination without requiring additional moves or touching each byte. 5. Software iSCSI implementations should always negotiate NOT to receive markers since Markers do not help the SW in any way. 6. Hardware HBAs can also implement FIM easily, and HW can do it easily in both directions. Therefore, if FIM is the approved Marker proposal, a HW HBA should send FIM whenever it sends iSCSI Commands and/or Data to other HW HBAs (assuming iWARP is not an available option), and the other HW HBAs wants them. 7. I do not foresee many installations using CRC Digests with Laptops and Desktops, since the overhead will probably be noticeable, and most installations do not judge Desktop and Laptop data to be key corporate assets (I am not saying that opinion is right, or that it is Universal, just that is a prevalent opinion). +++CRCs are not relevant +++ 8. A single software node would not be fast enough to cause a significant load or a significant memory requirement for the Reassembly Buffers. However, the combination of many (perhaps Desktops and Laptops spread across a real or virtual campus) can bring on a large load and the need for many Reassembly Buffers. The resultant amount of small Reassembly Buffers could make the Total requirement very High (thus raising the cost of the HBA). 9. Given the need for Desktops and Laptops to avoid noticeable degradation, and the probability that they will not be using CRC, means that the use of FIM is a compatible option when working across a network from a SW Node to an iSCSI HW HBA implemented Storage Controller. 10. COWS was also designed to be easily implemented in Software and in Hardware. 11. COWS will require the iSCSI Software implementations to touch each byte, as it looks for matches to its Framing Pattern within the PDUs. +++ except when implemented within the CRC, checksum where no ADDITIONAL touch is involved +++ 12. When CRC-32 digests are being computed, the Software will have to touch ever byte anyway, so the additional overhead to look for matches to the Framing Pattern is negligible. On the other hand FIM also works well with SW CRC-32 Digest computation. 13. But the premies I set above (which is clearly up to debate), is that Desktops and Laptops will not usually compute the CRC Digest. 14. COWS has the ability to have its pointing Markers, which point to the Framing Pattern Matches, point either forward or backwards. When being processed by software, the direction does not matter. So since the Markers should only be used on outgoing PDUs, the approprate direction of the pointers is what ever the destination needs. 15. Many vendors, especially at the higher speeds, are implementing a pipe line design. The pipeline receive process, will most likely want the COWS pointers to be forward pointing (pointing in the direction of the end of the PDU). Since the SW does not care, forward pointers should be fine. 16. If the HW Pipelining iSCSI HBA is to send COWS Markers to another HW Pipelining HBA, there may be a problem. The outgoing pipeline would prefer to have the pointers pointing backwards, but the receiving pipeline would prefer to have the pointers going forwards. Therefore with COWS, either the sending or the receiving HW Pipelining HBA will be unhappy and pipeline design will get very much more complicated. 17. Everyone likes iWARP better, but it requires changes to the Host SW TCP/IP stacks in the case of SW Initiators. Since these SW installations are probably going to be Desktops and Laptops, these systems will very likely have some non current version of the OS, (such as windows 2k, ME, etc.). Hence it is unlikely that they will have iWARP in the majority of the SW TCP/IP Stacks). +++iWARP needs framing as well and I would guess the technique will be close to what COWS is. Future convergence speaks for COWS+++ 18. If, for some reason, a Server uses Software iSCSI, it will probably have the latest and greatest OS software, and if that is true, and if iWARP is approved by the IETF then it will probably have the TCP/IP extensions that are required by iWARP. It will therefore use iWARP instead of any Marker solution. 19. If the Server uses Software iSCSI, and if iWARP is not approved by the IETF, then COWS or FIM are both reasonable choices for the Server, if the Server also uses the CRC option. If CRC is not used on the Server, FIM is a better match with the Server SW iSCSI. 19. iWARP is probably going to stay in IETF "experimental mode" for some time into the future. And without iWARP being specified by iSCSI as -- at least, "MAY Implement" and "MAY use", the HW to HW mode will still need a Marker solution. 20. Therefore, we are left with Markers as the only technique we can count on to aid and assist the iSCSI HW HBAs, keep their "on-board" RAM requirements to a minimum. Based on the above I come to the following conclusions: 1. Markers are needed. 2. FIM works best with the probable SW environment, and has the lowest overhead (since they will probably not use CRC Digests). +++CRCs are not relevant+++ 3. Since if CRC is used, the HW needs its Reassembly Buffers anyway, so there is no reason to use COWS, or any type of Marker. +++ again the same confusion betwen the PDU buffer and the RTT related holding are in the absence of Markers+++ 4. FIM can work well between HW HBAs without significant impact to pipeline design. +++ Somebody already said that FIMs are like democracy - imperfect, ugly but work+++ +++ However COWS are not that much heavier if carefully implemented and might get us faster to converge on a framing model+++ Therefore, I recommend that the Draft continue to define FIM. Also, I recommend that the FIM type of Markers be "MUST Implement" on the Out-Going direction, and "MAY Implement" on the incoming direction". Further, I recommend the Draft say that FIM "MAY be used" in any direction, depending on the negotiations. . . . 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 004A157CC2256B3A_= Content-Type: text/html; charset="us-ascii"
John,

The markers are supposed to help you get fat to the next PDU and start assembling and placing it.
It does not alleviate the need for a PDU assembly buffer - that you need anyhow - it alleviates the need to keep
TCP packets along when you have lost an iSCSI PDU header.

Once you have an iSCSI PDU header you need only the (as short as you want) PDU reassembly.

If you do not have an iSCSI header you have potentially to keep around an RTT dependent amount of data.
Markers are here to reduce the later to an amount that is not a function of Bandwidth*RTT.

Regards,
Julo


John Hufferd@IBMUS

07-01-02 12:07


        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        From:        John Hufferd/San Jose/IBM@IBMUS
        Subject:        Re: iSCSI: MarkersLink
 





Julian,
There are two different issues with regards to CRC.  

One is on the sender side, and if Markers are done in Software, of course it matters if CRC is done, since if the sender does not use CRC, the cost of COWS is very high.

The second point is about the Receiving Side.  I did not understand your point, so I would appreciate you expanding on your comment that the Target Side would still get value out of Markers even if they use CRC.  I can understand that there would be some additional value, especially in TCP Segment errors.  By permitting some additional TCP Segments to arrive during the retry, but most of the value is lost because the Full Reassembly Buffer is needed for CRC.  So now that I confess, that I do not completely understand your point, perhaps you could step me through your view of the value in the presents of CRC on a HW HBA/Chip.   I think it is important that we are able to quantify the value.
With regards to iWARP, I was using that name as an alias for the technique explained in the framing Draft (at http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-ulp-frame-01.txt).  But except for the last part of COWS, there is little resemblance between that and COWS.  The framing does NOT use Word replacement.  They only have a 8 byte header in common.  

That brings me to another point.  If FIM needs to double its Markers (two words instead of one), would not COWS also need to double its Header Markers, for the same reason?


.
.
.
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

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

To:        ips@ece.cmu.edu
cc:        
Subject:        Re: iSCSI: Markers




Some comments in text - Julo


John Hufferd/San Jose/IBM@IBMUS
Sent by: owner-ips@ece.cmu.edu

06-01-02 23:57
       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI: Markers

       


When we were in Salt Lake City, we decided to hold a discussion on the
Reflector regarding Markers.  I think it is probably time to hold that
discussion.  Therefore, I will start it out.

First I want to thank Julian for going to the trouble to document the
proposal for COWS.  This now gives us two Marker proposals to consider.
They are the Fixed Interval Markers (FIM) and the Constant Overhead Word
Stuffing (COWS) proposals.

Having said that, lets examine each one and determine their usefulness.

1. Markers (FIM or COWS) are only needed by Hardware HBAs that are
attempting to limit the amount of Reassembly Buffers they need on-board.
This will always be a probabilistic determination by the vendors, but the
purpose of Markers are to hold down the amount of total RAM needed,
especially when factored into a probabilistic determination.
2. The use of Markers are negotiated per connection, and per direction.  It
is therefore possible for a software implementation to send markers, but
not have to accept them.
+++ that is specially important for software implementations ++
3. When CRC Digest are negotiated to be used, it does no good to send out
Markers since the hardware side will have to have Reassembly Buffers to
compute the CRC Digest.  Therefore, Markers do not help anything when CRCs
are used on a connection.
+++ That is not correct - Framing mechanisms are used to avoid an RTT related size for the receive buffer not avoinding  a one-PDU buffer. Both FIM and COWS will help reducing HBA ememory requirements even when using CRC.  When Using CRC a PDU reassembly buffer is unavoidale but it can be limited by the MaxRcvPDU. +++

4. FIM can be implemented easily in software, and with an out going
Scatter/Gather technique could send PDUs across a network to a Hardware HBA
destination without requiring additional moves or touching each byte.
5. Software iSCSI implementations should always negotiate NOT to receive
markers since Markers do not help the SW in any way.
6. Hardware HBAs can also implement FIM easily, and HW can do it easily in
both directions.  Therefore, if FIM is the approved Marker proposal, a HW
HBA should send FIM whenever it sends iSCSI Commands and/or Data to other
HW HBAs (assuming iWARP is not an available option), and the other HW HBAs
wants them.
7. I do not foresee many installations using CRC Digests with Laptops and
Desktops, since the overhead will probably be noticeable, and most
installations do not judge Desktop and Laptop data to be key corporate
assets (I am not saying that opinion is right, or that it is Universal,
just that is a prevalent opinion).
+++CRCs are not relevant +++
8. A single software node would not be fast enough to cause a significant
load or a significant  memory requirement for the Reassembly Buffers.
However, the combination of many (perhaps Desktops and Laptops spread
across a real or virtual campus) can bring on a large load and the need for
many Reassembly Buffers.  The resultant amount of small Reassembly Buffers
could make the Total requirement very High (thus raising the cost of the
HBA).
9. Given the need for Desktops and Laptops to avoid noticeable degradation,
and the probability that they will not be using CRC, means that the use of
FIM is a compatible option when working across a network from a SW Node to
an iSCSI HW HBA implemented Storage Controller.
10. COWS was also designed to be easily implemented in Software and in
Hardware.
11. COWS will require the iSCSI Software implementations to touch each
byte, as it looks for matches to its Framing Pattern within the PDUs.
+++ except when implemented within the CRC, checksum where no ADDITIONAL touch is involved +++
12. When CRC-32 digests are being computed, the Software will have to touch
ever byte anyway, so the additional overhead to look for matches to the
Framing Pattern is negligible.  On the other hand FIM also works well with
SW CRC-32 Digest computation.
13. But the premies I set above (which is clearly up to debate), is that
Desktops and Laptops will not usually compute the CRC Digest.
14. COWS has the ability to have its pointing Markers, which point to the
Framing Pattern Matches, point either forward or backwards.  When being
processed by software, the direction does not matter.  So since the Markers
should only be used on outgoing PDUs, the approprate direction of the
pointers is what ever the destination needs.
15. Many vendors, especially at the higher speeds, are implementing a pipe
line design.  The pipeline receive process, will most likely want the COWS
pointers to be forward pointing (pointing in the direction of the end of
the PDU).  Since the SW does not care, forward pointers should be fine.
16. If the HW Pipelining iSCSI HBA is to send COWS Markers to another HW
Pipelining HBA, there may be a problem.  The outgoing pipeline would prefer
to have the pointers pointing backwards, but the receiving pipeline would
prefer to have the pointers going forwards.  Therefore with COWS, either
the sending or the receiving HW Pipelining HBA will be unhappy and pipeline
design will get very much more complicated.
17. Everyone likes iWARP better, but it requires changes to the Host SW
TCP/IP stacks in the case of SW Initiators.  Since these SW installations
are probably going to be Desktops and Laptops, these systems will very
likely have some non current version of the OS, (such as windows 2k, ME,
etc.).  Hence it is unlikely that they will have iWARP in the majority of
the SW TCP/IP Stacks).
+++iWARP needs framing as well and I would guess the technique will be close to what COWS is.  Future convergence speaks for COWS+++
18. If, for some reason, a Server uses Software iSCSI, it will probably
have the latest and greatest OS software, and if that is true, and if iWARP
is approved by the IETF then it will probably have the TCP/IP extensions
that are required by iWARP.  It will therefore use iWARP instead of any
Marker solution.
19. If the Server uses Software iSCSI,  and if iWARP is not approved by the
IETF, then COWS or FIM are both  reasonable choices  for the Server, if the
Server also uses the CRC option.  If CRC is not used on the Server, FIM is
a better match with the Server SW iSCSI.
19. iWARP is probably going to stay in IETF "experimental mode" for some
time into the future.  And without iWARP being specified by iSCSI as -- at
least, "MAY Implement" and "MAY use", the HW to HW mode will still need a
Marker solution.
20. Therefore, we are left with Markers as the only technique we can count
on to aid and assist the iSCSI HW HBAs, keep their "on-board" RAM
requirements to a minimum.

Based on the above I come to the following conclusions:
1. Markers are needed.
2. FIM works best with the probable SW environment, and has the lowest
overhead (since they will probably not use CRC Digests).
+++CRCs are not relevant+++
3. Since if CRC is used, the HW needs its Reassembly Buffers anyway, so
there is no reason to use COWS, or any type of Marker.
+++ again the same confusion betwen the PDU buffer and the RTT related holding are in the absence of Markers+++
4. FIM can work well between HW HBAs without significant impact to pipeline
design.
+++ Somebody already said that FIMs are like democracy - imperfect, ugly but work+++
+++ However COWS are not that much heavier if carefully implemented and might get us faster to converge on a framing model+++

Therefore, I recommend that the Draft continue to define FIM.  Also, I
recommend that the FIM type of Markers be "MUST Implement" on the Out-Going
direction, and "MAY Implement" on the incoming direction".   Further, I
recommend the Draft say that FIM "MAY be used" in any direction, depending
on the negotiations.

.
.
.
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 004A157CC2256B3A_=-- From owner-ips@ece.cmu.edu Mon Jan 7 13:28: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 NAA23558 for ; Mon, 7 Jan 2002 13:28:44 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g07Hp6222844 for ips-outgoing; Mon, 7 Jan 2002 12:51:06 -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 g07E72g09046 for ; Mon, 7 Jan 2002 09:07:02 -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 JAA14447; Mon, 7 Jan 2002 09:06:59 -0500 (EST) Message-Id: <200201071406.JAA14447@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-07.txt Date: Mon, 07 Jan 2002 09:06:59 -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-07.txt Pages : 61 Date : 04-Jan-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-07.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-07.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-07.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: <20020104143446.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-security-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-security-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020104143446.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Mon Jan 7 13:29: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 NAA23586 for ; Mon, 7 Jan 2002 13:29:45 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g07HLWw20958 for ips-outgoing; Mon, 7 Jan 2002 12:21:32 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar2ab.compuserve.com (siaar2ab.compuserve.com [149.174.40.138]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g07HLSg20952 for ; Mon, 7 Jan 2002 12:21:29 -0500 (EST) Received: (from mailgate@localhost) by siaar2ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id MAA05144 for ips@ece.cmu.edu; Mon, 7 Jan 2002 12:21:20 -0500 (EST) Received: from compuserve.com (dal-tgn-tvq-vty10.as.wcom.net [216.192.240.10]) by siaar2ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id MAA04987 for ; Mon, 7 Jan 2002 12:21:06 -0500 (EST) Message-ID: <3C39DA02.639F9AC4@compuserve.com> Date: Mon, 07 Jan 2002 11:25:22 -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: Re: FCIP: Short Frame Security Solution Proposal References: <277DD60FB639D511AC0400B0D068B71E029372F6@CORPMX14> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, 2 out of your 3 comments pertain to the content of FC-BB-2 and as such incorporating them in something must wait for the proposal to introduce the other half of this in FC-BB-2. My intention is that said proposal will be finished in time to meet the two-week rule for the T11 meeting in Huntington Beach. I will announce the availability of the proposal on this reflector. The one comment that suggests adding text to the FCIP draft is as follows: > > > - Some words will need to be added about a nasty race > > > condition in which the attacker opens up a connection up > > > to the point of sending the short frame, watches a real > > > connection get set up to the point that the attacker sees > > > the short frame on the real connection; the attacker > > > extracts and uses the nonce, and TCP tricks (e.g., corrupt > > > the TCP packet containing the nonce to cause a checksum > > > failure, or send a well-timed RST). The short answer to > > > dealing with this is "use IKE and also ESP encryption if > > > warranted" when this sort of attack is a concern. > > > > Would it not be better to include a broad caution along the > > lines of: > > > > Warning: The authentication mechanism described here is not > > designed to thwart sophisticated security threats. The IP > > security mechanisms described in section 9 should be enabled > > in environments where security threats are suspected. > > Both. The race is sufficiently related to the WWN short frame > that it should be specifically mentioned. There are other > authentication mechanisms that are not subject to this race. Interestingly enough, this is need not be as wide open a race as one might first think because the recipient of the TCP connect request may timeout and close the connection if the SF is not received in 90 seconds or longer. None the less, words about the race condition have been added to the FCIP revision in development. The specific new text (and the paragraph preceding it) are as follows: * The FCIP Entity MAY apply a timeout of not less than 90 seconds * to the waiting for the FCIP Special Frame bytes and if the timeout * expires the FCIP Entity SHALL close the TCP Connection and notify * the FC Entity with the reason for the closure. * * Note: One method for attacking the security of the FCIP Link * formation process depends on keeping a TCP connect request open * without sending an FCIP Special Frame. Implementations should bear * this in mind in the handling of TCP connect requests where the FCIP * Special Frame is not sent in a timely manner. Thanks. Ralph... Black_David@emc.com wrote: > Ralph, > > > Black_David@emc.com wrote [responses embedded]: > > > > > I think this is a workable approach. A few comments: > > > > > > - There are a dependencies among a number of components > > > on who supports what, some of which are under T11's > > > control. If it turns out that the T11 aspects of this > > > are not mandatory to implement, ... > > [... snip ...] > > > > I think multiple TCP > > > connections in a single FCIP session need to be disallowed > > > if this authentication cannot be performed by the > > > implementation (i.e., is not implemented) - putting in a > > > note to this effect regardless of what T11 does might be > > > a good idea to decouple FCIP from FC-BB-2 in this area. > > > > As currently worded, the FCIP Entity ALWAYS asks the FC Entity > > for authentication of a second to n-th connection and the > > FC Entity ALWAYS responds, yes or no. I fail to see how a > > note such as the one suggested would be viewed as anything > > more than advisory to FC-BB-2. The FCIP Entity has (in theory) > > no knowledge of how much or how little work the FC Entity > > does to generate its response to the request for connection > > authentication. > > What I had in mind was advice to implementers that if the FC > Entity does not check the nonce over the initial connection with > its peer FC entity, then the answer to the FCIP entity SHOULD > be "no". This could also be considered as advice to BB-2. > > > > - Any nonce must be validated ("yes, that's my connection") > > > at most once. If the FC Entity on the other end of the > > > first connection is capable of saying "yes" twice to the > > > same nonce, there's an obvious replay attack. > > > > I had sought to cut this type of attack off at the SF level > > (long before the FC Entity at the other end gets a nonce > > to validate) with the following words. > > > > }...} To further increase the difficulty of snooping > > }...} TCP connections, an FCIP Entity that receives > > }...} a duplicate nonce shall close the connection > > }...} on which that nonce was received immediately > > }...} without causing the SW_ILS to be sent. > > > > To me, this seems superior for a couple of reasons: > > > > o It places the requirement in FCIP, closer to the source > > of the problem. > > o It eliminates an unnecessary authentication transaction > > with the FC Entity at the other end. > > Ok, but also see the discussion below on the "who presents > the nonce first" race. > > > > - Some words will need to be added about a nasty race > > > condition in which the attacker opens up a connection up > > > to the point of sending the short frame, watches a real > > > connection get set up to the point that the attacker sees > > > the short frame on the real connection; the attacker > > > extracts and uses the nonce, and TCP tricks (e.g., corrupt > > > the TCP packet containing the nonce to cause a checksum > > > failure, or send a well-timed RST). The short answer to > > > dealing with this is "use IKE and also ESP encryption if > > > warranted" when this sort of attack is a concern. > > > > Would it not be better to include a broad caution along the > > lines of: > > > > Warning: The authentication mechanism described here is not > > designed to thwart sophisticated security threats. The IP > > security mechanisms described in section 9 should be enabled > > in environments where security threats are suspected. > > Both. The race is sufficiently related to the WWN short frame > that it should be specifically mentioned. There are other > authentication mechanisms that are not subject to this race. > > > > - I think it's necessary to authentication the first TCP > > > connection (up to FCAP or whatever) before sending the ILS > > > that would authenticate a subsequent one, but details beyond > > > that (e.g., can one send the SYN for the second TCP connection > > > before the first connection authenticates) are probably up to > > > implementations. > > > > I had hoped to have covered the case I think is being described > > above by the following language (note the words "previously > > authenticated"): > > > > }...} In situations where security > > }...} risks are possible, the FC Entity shall transmit > > }...} the information provided by the FCIP Entity via a new > > }...} SW_ILS on a previously authenticated TCP connection > > }...} (FCIP Data Engine) enabled for Class F frames. > > > > "Previously authenticated" may be vague, but it is intended to > > cover both authentication via FCAP and authentication against > > another F Class connection using this process. > > > > Consider that case where a long lived FCIP Link starts out > > with one F Class connection. Next, using the authentication > > process described in this proposal and two or more Class 2/3 > > connections are added to the FCIP Link. As time goes by the F > > Class connection becomes unreliable and the Entities at both > > ends decide to close it and switch one of the Class 2/3 > > connections to Class F service. > > > > The connection switched to F Class service has been duly > > authenticated, but not by FCAP. It seems perfectly reasonable > > that the switched F Class connection can serve to authenticate > > new connect requests. > > Yes, "previously authenticated" is a bit vague. This discussion > is fine, and adding the example from the discussion above would be > helpful. > > 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 Jan 7 13:31: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 NAA23657 for ; Mon, 7 Jan 2002 13:31:35 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g07Hp2u22836 for ips-outgoing; Mon, 7 Jan 2002 12:51:02 -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 g07E70g09040 for ; Mon, 7 Jan 2002 09:07:00 -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 JAA14428; Mon, 7 Jan 2002 09:06:52 -0500 (EST) Message-Id: <200201071406.JAA14428@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-05.txt Date: Mon, 07 Jan 2002 09:06:52 -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, V. Chau, M. O'Donnell, C. Monia, M. Merhar Filename : draft-ietf-ips-fcencapsulation-05.txt Pages : 15 Date : 04-Jan-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-05.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-05.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-05.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: <20020104143424.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-fcencapsulation-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-fcencapsulation-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020104143424.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Mon Jan 7 14:19: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 OAA25357 for ; Mon, 7 Jan 2002 14:19:48 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g07IHG524390 for ips-outgoing; Mon, 7 Jan 2002 13:17:16 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lightsand.com ([64.214.104.163]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g07IHEg24386 for ; Mon, 7 Jan 2002 13:17:14 -0500 (EST) Received: from MURALIRLAPTOP ([192.168.2.60]) by lightsand.com (8.9.3+Sun/8.9.1) with SMTP id KAA28271 for ; Mon, 7 Jan 2002 10:17:07 -0800 (PST) From: "Murali Rajagopal" To: Subject: FCIP: Jna 2 2002 Teleconf Call Minutes Date: Mon, 7 Jan 2002 10:16:49 -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.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Minutes: Taken by Don Fraser, Compaq FCIP Con-Call Wednesday, January 02, 2002 1 PM PST Attendance: Murali Rajagopal, Bill Krieg, Andy Helland, Anil Rijhsinghani, Jim Nelson, Venkat Rangan, Milan Merhar, Raj Bhagwat, Ken Hirata, David Peterson, Bob Snively, Larry Lamers, Ralph Weber, Don Fraser Agenda with notes: 1. Short Frame Proposal Comments: 30 Min Discussion on email comments from Dave Peterson and Bob Snively re the various SF proposals. The discussions confirmed: a) FCIP document needs to specify requirement for a random nonce, but not the method. The implementation should not allow it to be possible to guess the next number, see RFC 1750. Note RFC is a 30 page informational RFC that on first glance looks harmless. b) Will expand the FC entity field size to 64 bits. This new space will hold a port name but should not be required to be the port name. There should be no checking of the values because the B-port model does not have a port name. Carry forward to BB-2 as well. c) There is no reason to specify how to name the FC Entity. Discussion around adding one or more reserved words back into the SF for example to allow for a CRC. Impact may be that one implementation uses it and is therefore non-interoperable with those that do use them. Consensus was to not add in any reserved words with Larry objecting. Version number of protocol to be version number of short frame. There was agreement that the first connection must be authenticated prior to starting any additional connections between the pair of devices. To prevent a possible race condition in the creation of a connection, the document will require that duplicate nonces, and re-use of nonces on new connections must be prevented. Ralph will write it up. Will change name from Short Frame (SF) to Special Frame (SF) 2. Comments on 07 draft: 20 Min (moved from item 3 to 2) Don's comments by page: In general, drop all added timers, etc as they belong in FC-BB-2 page 20, #1 accepted, #2 drop timer, #3 drop page 25, #1 drop timer, #2 ok page 30, shall provide mechanism with acknowledgement page 31, #1 move to FC-BB2, add reference to FC-BB-2, #2 ok page 37, both add only the notification with reason page 48, add only the notification with reason code page 50, add the reason code and notifications para 8.2 discussion and will be further discussed at a later date due to implication for path split, some would delete the paragraph others would require it. * Agreed that there is a one to one correspondence between the link end point, its data engine, and the TCP connection direction. * May need to delete it, as there is no time to define how to combine two links, even if it could be proved that this is needed. Bob to forward some rational for dropping 8.2. * Need to have FC-BB tell the FCIP device to build a new connection rather than figure out how to tell the FCIP side to merge two connections. * Consensus to remove, 8-2 Venkat brought up that there are some potential timing issues with section 9 due to delays in the common security specification from the IPS Security Working Group. It was decided to proceed and then if the IPS side is not ready, so be it. Class 4 list to be sent to Gary Stevens and ask him to review. 3. Discussion on FCIP Requirements to FC-BB-2: 30 Min - deferred to next week due to length of discussion on item 2. 4. Gadzoox to plan Next Call Don Fraser Solutions Architect Wide Area SAN Engineering Team Compaq Enterprise Storage Products Group Phone: 719.548.3272 Pager: 1.800.759.8888 pin 114.8840 or short email to 1148840@skytel.com From owner-ips@ece.cmu.edu Mon Jan 7 15:32: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 PAA27229 for ; Mon, 7 Jan 2002 15:32:19 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g07JKst28347 for ips-outgoing; Mon, 7 Jan 2002 14:20:54 -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 g07JKrg28342 for ; Mon, 7 Jan 2002 14:20:53 -0500 (EST) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Jan 2002 14:23:29 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0293730B@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: Two administrative items Date: Mon, 7 Jan 2002 14:08:22 -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 (1) Anyone who presented in Salt Lake City and who has not sent me their presentation needs to do so ASAP. The final version of the minutes and all presentations will go to the secretariat this week. (2) We need to reduce author count on our drafts. Authorship should be reserved for those who have made substantial text and/or intellectual contributions to drafts. Others should be acknowledged in the Acknowledgements sections. The iSCSI, FCIP, IPS Security and iSCSI naming drafts all have at a dozen or more authors, and need to be cut down by a factor of 2 or more. Based on the source of this request at the plenary in Salt Lake City, we may well be facing the choice of reducing these author counts ourselves, or having the RFC Editor "help" us do it while they're in the queue for publication, thus holding things up at a very late stage in the process. To set an example, my name should be moved from the author list of the Security draft to the acknowledgements section, even though there are half a dozen or so paragraphs in that draft that I wrote. 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 Jan 7 17:23: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 RAA29600 for ; Mon, 7 Jan 2002 17:23:59 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g07LICv05591 for ips-outgoing; Mon, 7 Jan 2002 16:18:12 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g07LI9g05583 for ; Mon, 7 Jan 2002 16:18:09 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.99.140.22]) by e32.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA04846 for ; Mon, 7 Jan 2002 14:47:39 -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 g07JoYs161426 for ; Mon, 7 Jan 2002 12:50:34 -0700 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: Markers 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: Mon, 7 Jan 2002 11:49:47 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 01/07/2002 12:50: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 g07LIAg05585 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit OK, Julian, I buy that argument. I think that you have made the point that the value of Markers is Greater then I was giving credit for, in iSCSI/TOE integrated HBAs that are operating in CRC mode. That is great, since I am afraid we will not see the Framing stuff for some time. So the questions are which form of markers is the best. My vote comes down on the side of Fixed Interval Markers (FIM). For the following reasons: On the SW sending side, FIM works with low overhead whether CRC is being used or not. COWS, is a dramatic overhead unless the SW is performing CRC computation anyway. The COWS has a built in conflict with the Pipeline HW HBA, that has two different needs regarding the direction of the Pointers when talking to another partner HW HBA that uses a Pipeline approach. . . . 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 01/07/2002 05:34:13 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: iSCSI: Markers John, The markers are supposed to help you get fat to the next PDU and start assembling and placing it. It does not alleviate the need for a PDU assembly buffer - that you need anyhow - it alleviates the need to keep TCP packets along when you have lost an iSCSI PDU header. Once you have an iSCSI PDU header you need only the (as short as you want) PDU reassembly. If you do not have an iSCSI header you have potentially to keep around an RTT dependent amount of data. Markers are here to reduce the later to an amount that is not a function of Bandwidth*RTT. Regards, Julo John         To:        Julian Satran/Haifa/IBM@IBMIL Hufferd@IB         cc:        ips@ece.cmu.edu MUS         From:        John Hufferd/San Jose/IBM@IBMUS 07-01-02         Subject:        Re: iSCSI: MarkersLink 12:07 Julian, There are two different issues with regards to CRC. One is on the sender side, and if Markers are done in Software, of course it matters if CRC is done, since if the sender does not use CRC, the cost of COWS is very high. The second point is about the Receiving Side.  I did not understand your point, so I would appreciate you expanding on your comment that the Target Side would still get value out of Markers even if they use CRC.  I can understand that there would be some additional value, especially in TCP Segment errors.  By permitting some additional TCP Segments to arrive during the retry, but most of the value is lost because the Full Reassembly Buffer is needed for CRC.  So now that I confess, that I do not completely understand your point, perhaps you could step me through your view of the value in the presents of CRC on a HW HBA/Chip.   I think it is important that we are able to quantify the value. With regards to iWARP, I was using that name as an alias for the technique explained in the framing Draft (at http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-ulp-frame-01.txt). But except for the last part of COWS, there is little resemblance between that and COWS.  The framing does NOT use Word replacement.  They only have a 8 byte header in common. That brings me to another point.  If FIM needs to double its Markers (two words instead of one), would not COWS also need to double its Header Markers, for the same reason? . . . 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 Sent by:        owner-ips@ece.cmu.edu To:        ips@ece.cmu.edu cc: Subject:        Re: iSCSI: Markers Some comments in text - Julo John Hufferd/San Jose/IBM@IBMUS         To:        ips@ece.cmu.edu Sent by:         cc: owner-ips@ece.cmu         Subject:        iSCSI: Markers .edu 06-01-02 23:57 When we were in Salt Lake City, we decided to hold a discussion on the Reflector regarding Markers.  I think it is probably time to hold that discussion.  Therefore, I will start it out. First I want to thank Julian for going to the trouble to document the proposal for COWS.  This now gives us two Marker proposals to consider. They are the Fixed Interval Markers (FIM) and the Constant Overhead Word Stuffing (COWS) proposals. Having said that, lets examine each one and determine their usefulness. 1. Markers (FIM or COWS) are only needed by Hardware HBAs that are attempting to limit the amount of Reassembly Buffers they need on-board. This will always be a probabilistic determination by the vendors, but the purpose of Markers are to hold down the amount of total RAM needed, especially when factored into a probabilistic determination. 2. The use of Markers are negotiated per connection, and per direction.  It is therefore possible for a software implementation to send markers, but not have to accept them. +++ that is specially important for software implementations ++ 3. When CRC Digest are negotiated to be used, it does no good to send out Markers since the hardware side will have to have Reassembly Buffers to compute the CRC Digest.  Therefore, Markers do not help anything when CRCs are used on a connection. +++ That is not correct - Framing mechanisms are used to avoid an RTT related size for the receive buffer not avoinding  a one-PDU buffer. Both FIM and COWS will help reducing HBA ememory requirements even when using CRC.  When Using CRC a PDU reassembly buffer is unavoidale but it can be limited by the MaxRcvPDU. +++ 4. FIM can be implemented easily in software, and with an out going Scatter/Gather technique could send PDUs across a network to a Hardware HBA destination without requiring additional moves or touching each byte. 5. Software iSCSI implementations should always negotiate NOT to receive markers since Markers do not help the SW in any way. 6. Hardware HBAs can also implement FIM easily, and HW can do it easily in both directions.  Therefore, if FIM is the approved Marker proposal, a HW HBA should send FIM whenever it sends iSCSI Commands and/or Data to other HW HBAs (assuming iWARP is not an available option), and the other HW HBAs wants them. 7. I do not foresee many installations using CRC Digests with Laptops and Desktops, since the overhead will probably be noticeable, and most installations do not judge Desktop and Laptop data to be key corporate assets (I am not saying that opinion is right, or that it is Universal, just that is a prevalent opinion). +++CRCs are not relevant +++ 8. A single software node would not be fast enough to cause a significant load or a significant  memory requirement for the Reassembly Buffers. However, the combination of many (perhaps Desktops and Laptops spread across a real or virtual campus) can bring on a large load and the need for many Reassembly Buffers.  The resultant amount of small Reassembly Buffers could make the Total requirement very High (thus raising the cost of the HBA). 9. Given the need for Desktops and Laptops to avoid noticeable degradation, and the probability that they will not be using CRC, means that the use of FIM is a compatible option when working across a network from a SW Node to an iSCSI HW HBA implemented Storage Controller. 10. COWS was also designed to be easily implemented in Software and in Hardware. 11. COWS will require the iSCSI Software implementations to touch each byte, as it looks for matches to its Framing Pattern within the PDUs. +++ except when implemented within the CRC, checksum where no ADDITIONAL touch is involved +++ 12. When CRC-32 digests are being computed, the Software will have to touch ever byte anyway, so the additional overhead to look for matches to the Framing Pattern is negligible.  On the other hand FIM also works well with SW CRC-32 Digest computation. 13. But the premies I set above (which is clearly up to debate), is that Desktops and Laptops will not usually compute the CRC Digest. 14. COWS has the ability to have its pointing Markers, which point to the Framing Pattern Matches, point either forward or backwards.  When being processed by software, the direction does not matter.  So since the Markers should only be used on outgoing PDUs, the approprate direction of the pointers is what ever the destination needs. 15. Many vendors, especially at the higher speeds, are implementing a pipe line design.  The pipeline receive process, will most likely want the COWS pointers to be forward pointing (pointing in the direction of the end of the PDU).  Since the SW does not care, forward pointers should be fine. 16. If the HW Pipelining iSCSI HBA is to send COWS Markers to another HW Pipelining HBA, there may be a problem.  The outgoing pipeline would prefer to have the pointers pointing backwards, but the receiving pipeline would prefer to have the pointers going forwards.  Therefore with COWS, either the sending or the receiving HW Pipelining HBA will be unhappy and pipeline design will get very much more complicated. 17. Everyone likes iWARP better, but it requires changes to the Host SW TCP/IP stacks in the case of SW Initiators.  Since these SW installations are probably going to be Desktops and Laptops, these systems will very likely have some non current version of the OS, (such as windows 2k, ME, etc.).  Hence it is unlikely that they will have iWARP in the majority of the SW TCP/IP Stacks). +++iWARP needs framing as well and I would guess the technique will be close to what COWS is.  Future convergence speaks for COWS+++ 18. If, for some reason, a Server uses Software iSCSI, it will probably have the latest and greatest OS software, and if that is true, and if iWARP is approved by the IETF then it will probably have the TCP/IP extensions that are required by iWARP.  It will therefore use iWARP instead of any Marker solution. 19. If the Server uses Software iSCSI,  and if iWARP is not approved by the IETF, then COWS or FIM are both  reasonable choices  for the Server, if the Server also uses the CRC option.  If CRC is not used on the Server, FIM is a better match with the Server SW iSCSI. 19. iWARP is probably going to stay in IETF "experimental mode" for some time into the future.  And without iWARP being specified by iSCSI as -- at least, "MAY Implement" and "MAY use", the HW to HW mode will still need a Marker solution. 20. Therefore, we are left with Markers as the only technique we can count on to aid and assist the iSCSI HW HBAs, keep their "on-board" RAM requirements to a minimum. Based on the above I come to the following conclusions: 1. Markers are needed. 2. FIM works best with the probable SW environment, and has the lowest overhead (since they will probably not use CRC Digests). +++CRCs are not relevant+++ 3. Since if CRC is used, the HW needs its Reassembly Buffers anyway, so there is no reason to use COWS, or any type of Marker. +++ again the same confusion betwen the PDU buffer and the RTT related holding are in the absence of Markers+++ 4. FIM can work well between HW HBAs without significant impact to pipeline design. +++ Somebody already said that FIMs are like democracy - imperfect, ugly but work+++ +++ However COWS are not that much heavier if carefully implemented and might get us faster to converge on a framing model+++ Therefore, I recommend that the Draft continue to define FIM.  Also, I recommend that the FIM type of Markers be "MUST Implement" on the Out-Going direction, and "MAY Implement" on the incoming direction".   Further, I recommend the Draft say that FIM "MAY be used" in any direction, depending on the negotiations. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Mon Jan 7 19:43: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 TAA01909 for ; Mon, 7 Jan 2002 19:43:19 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g07Nq0M14101 for ips-outgoing; Mon, 7 Jan 2002 18:52:00 -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 g07KQig02681 for ; Mon, 7 Jan 2002 15:26:44 -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); Mon, 7 Jan 2002 12:26:38 -0800 Received: from 157.54.5.25 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 07 Jan 2002 12:26:38 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 7 Jan 2002 12:26:38 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 7 Jan 2002 12:26:38 -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); Mon, 7 Jan 2002 12:24:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6115.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: iSCSI: Format of LUN in iSCSI PDU Date: Mon, 7 Jan 2002 12:24:41 -0800 Message-ID: Thread-Topic: iSCSI: Format of LUN in iSCSI PDU thread-index: AcGXr/604krHTmLRTVyCVf6dNzuUSQACNQkg From: "Lakshmi Ramasubramanian" To: X-OriginalArrivalTime: 07 Jan 2002 20:24:42.0128 (UTC) FILETIME=[56A1E900:01C197B9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g07KQjg02682 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Section 3.2.1.6 LUN : The LUN field is 64-bits and it is to be formatted in accordance with [SAM2]. Section 3. iSCSI PDU Formats : Any field appearing in this document assumes that the most significant byte is the lowest numbered byte. So, the first byte, as given in SAM2, should be set in LUN[0] or it should be set in LUN[7]? thanks! -lakshmi From owner-ips@ece.cmu.edu Tue Jan 8 02:55: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 CAA17270 for ; Tue, 8 Jan 2002 02:55:58 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0870ri02627 for ips-outgoing; Tue, 8 Jan 2002 02:00:53 -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 g0870pg02619 for ; Tue, 8 Jan 2002 02:00:51 -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 IAA39802 for ; Tue, 8 Jan 2002 08:00: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 g0871Yd29228 for ; Tue, 8 Jan 2002 08:01:34 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: Markers X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 8 Jan 2002 09:01:31 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 08/01/2002 09:01:38, Serialize complete at 08/01/2002 09:01:38 Content-Type: multipart/alternative; boundary="=_alternative 0025B058C2256B3B_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0025B058C2256B3B_= Content-Type: text/plain; charset="us-ascii" John, FIM works now and COWS is not as bad as you paint it - as most software stacks touch the data at least once (no exceptions!). As for the pipeline argument - it must have something to do with Alaska - as I don't get it :-) If you want a vote - I can't - my heart is thorn ... Julo John Hufferd@IBMUS 07-01-02 21:49 To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu From: John Hufferd/San Jose/IBM@IBMUS Subject: Re: iSCSI: Markers OK, Julian, I buy that argument. I think that you have made the point that the value of Markers is Greater then I was giving credit for, in iSCSI/TOE integrated HBAs that are operating in CRC mode. That is great, since I am afraid we will not see the Framing stuff for some time. So the questions are which form of markers is the best. My vote comes down on the side of Fixed Interval Markers (FIM). For the following reasons: On the SW sending side, FIM works with low overhead whether CRC is being used or not. COWS, is a dramatic overhead unless the SW is performing CRC computation anyway. The COWS has a built in conflict with the Pipeline HW HBA, that has two different needs regarding the direction of the Pointers when talking to another partner HW HBA that uses a Pipeline approach. . . . 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 Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: iSCSI: Markers John, The markers are supposed to help you get fat to the next PDU and start assembling and placing it. It does not alleviate the need for a PDU assembly buffer - that you need anyhow - it alleviates the need to keep TCP packets along when you have lost an iSCSI PDU header. Once you have an iSCSI PDU header you need only the (as short as you want) PDU reassembly. If you do not have an iSCSI header you have potentially to keep around an RTT dependent amount of data. Markers are here to reduce the later to an amount that is not a function of Bandwidth*RTT. Regards, Julo John Hufferd@IBMUS 07-01-02 12:07 To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu From: John Hufferd/San Jose/IBM@IBMUS Subject: Re: iSCSI: MarkersLink Julian, There are two different issues with regards to CRC. One is on the sender side, and if Markers are done in Software, of course it matters if CRC is done, since if the sender does not use CRC, the cost of COWS is very high. The second point is about the Receiving Side. I did not understand your point, so I would appreciate you expanding on your comment that the Target Side would still get value out of Markers even if they use CRC. I can understand that there would be some additional value, especially in TCP Segment errors. By permitting some additional TCP Segments to arrive during the retry, but most of the value is lost because the Full Reassembly Buffer is needed for CRC. So now that I confess, that I do not completely understand your point, perhaps you could step me through your view of the value in the presents of CRC on a HW HBA/Chip. I think it is important that we are able to quantify the value. With regards to iWARP, I was using that name as an alias for the technique explained in the framing Draft (at http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-ulp-frame-01.txt). But except for the last part of COWS, there is little resemblance between that and COWS. The framing does NOT use Word replacement. They only have a 8 byte header in common. That brings me to another point. If FIM needs to double its Markers (two words instead of one), would not COWS also need to double its Header Markers, for the same reason? . . . 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 Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: iSCSI: Markers Some comments in text - Julo John Hufferd/San Jose/IBM@IBMUS Sent by: owner-ips@ece.cmu.edu 06-01-02 23:57 To: ips@ece.cmu.edu cc: Subject: iSCSI: Markers When we were in Salt Lake City, we decided to hold a discussion on the Reflector regarding Markers. I think it is probably time to hold that discussion. Therefore, I will start it out. First I want to thank Julian for going to the trouble to document the proposal for COWS. This now gives us two Marker proposals to consider. They are the Fixed Interval Markers (FIM) and the Constant Overhead Word Stuffing (COWS) proposals. Having said that, lets examine each one and determine their usefulness. 1. Markers (FIM or COWS) are only needed by Hardware HBAs that are attempting to limit the amount of Reassembly Buffers they need on-board. This will always be a probabilistic determination by the vendors, but the purpose of Markers are to hold down the amount of total RAM needed, especially when factored into a probabilistic determination. 2. The use of Markers are negotiated per connection, and per direction. It is therefore possible for a software implementation to send markers, but not have to accept them. +++ that is specially important for software implementations ++ 3. When CRC Digest are negotiated to be used, it does no good to send out Markers since the hardware side will have to have Reassembly Buffers to compute the CRC Digest. Therefore, Markers do not help anything when CRCs are used on a connection. +++ That is not correct - Framing mechanisms are used to avoid an RTT related size for the receive buffer not avoinding a one-PDU buffer. Both FIM and COWS will help reducing HBA ememory requirements even when using CRC. When Using CRC a PDU reassembly buffer is unavoidale but it can be limited by the MaxRcvPDU. +++ 4. FIM can be implemented easily in software, and with an out going Scatter/Gather technique could send PDUs across a network to a Hardware HBA destination without requiring additional moves or touching each byte. 5. Software iSCSI implementations should always negotiate NOT to receive markers since Markers do not help the SW in any way. 6. Hardware HBAs can also implement FIM easily, and HW can do it easily in both directions. Therefore, if FIM is the approved Marker proposal, a HW HBA should send FIM whenever it sends iSCSI Commands and/or Data to other HW HBAs (assuming iWARP is not an available option), and the other HW HBAs wants them. 7. I do not foresee many installations using CRC Digests with Laptops and Desktops, since the overhead will probably be noticeable, and most installations do not judge Desktop and Laptop data to be key corporate assets (I am not saying that opinion is right, or that it is Universal, just that is a prevalent opinion). +++CRCs are not relevant +++ 8. A single software node would not be fast enough to cause a significant load or a significant memory requirement for the Reassembly Buffers. However, the combination of many (perhaps Desktops and Laptops spread across a real or virtual campus) can bring on a large load and the need for many Reassembly Buffers. The resultant amount of small Reassembly Buffers could make the Total requirement very High (thus raising the cost of the HBA). 9. Given the need for Desktops and Laptops to avoid noticeable degradation, and the probability that they will not be using CRC, means that the use of FIM is a compatible option when working across a network from a SW Node to an iSCSI HW HBA implemented Storage Controller. 10. COWS was also designed to be easily implemented in Software and in Hardware. 11. COWS will require the iSCSI Software implementations to touch each byte, as it looks for matches to its Framing Pattern within the PDUs. +++ except when implemented within the CRC, checksum where no ADDITIONAL touch is involved +++ 12. When CRC-32 digests are being computed, the Software will have to touch ever byte anyway, so the additional overhead to look for matches to the Framing Pattern is negligible. On the other hand FIM also works well with SW CRC-32 Digest computation. 13. But the premies I set above (which is clearly up to debate), is that Desktops and Laptops will not usually compute the CRC Digest. 14. COWS has the ability to have its pointing Markers, which point to the Framing Pattern Matches, point either forward or backwards. When being processed by software, the direction does not matter. So since the Markers should only be used on outgoing PDUs, the approprate direction of the pointers is what ever the destination needs. 15. Many vendors, especially at the higher speeds, are implementing a pipe line design. The pipeline receive process, will most likely want the COWS pointers to be forward pointing (pointing in the direction of the end of the PDU). Since the SW does not care, forward pointers should be fine. 16. If the HW Pipelining iSCSI HBA is to send COWS Markers to another HW Pipelining HBA, there may be a problem. The outgoing pipeline would prefer to have the pointers pointing backwards, but the receiving pipeline would prefer to have the pointers going forwards. Therefore with COWS, either the sending or the receiving HW Pipelining HBA will be unhappy and pipeline design will get very much more complicated. 17. Everyone likes iWARP better, but it requires changes to the Host SW TCP/IP stacks in the case of SW Initiators. Since these SW installations are probably going to be Desktops and Laptops, these systems will very likely have some non current version of the OS, (such as windows 2k, ME, etc.). Hence it is unlikely that they will have iWARP in the majority of the SW TCP/IP Stacks). +++iWARP needs framing as well and I would guess the technique will be close to what COWS is. Future convergence speaks for COWS+++ 18. If, for some reason, a Server uses Software iSCSI, it will probably have the latest and greatest OS software, and if that is true, and if iWARP is approved by the IETF then it will probably have the TCP/IP extensions that are required by iWARP. It will therefore use iWARP instead of any Marker solution. 19. If the Server uses Software iSCSI, and if iWARP is not approved by the IETF, then COWS or FIM are both reasonable choices for the Server, if the Server also uses the CRC option. If CRC is not used on the Server, FIM is a better match with the Server SW iSCSI. 19. iWARP is probably going to stay in IETF "experimental mode" for some time into the future. And without iWARP being specified by iSCSI as -- at least, "MAY Implement" and "MAY use", the HW to HW mode will still need a Marker solution. 20. Therefore, we are left with Markers as the only technique we can count on to aid and assist the iSCSI HW HBAs, keep their "on-board" RAM requirements to a minimum. Based on the above I come to the following conclusions: 1. Markers are needed. 2. FIM works best with the probable SW environment, and has the lowest overhead (since they will probably not use CRC Digests). +++CRCs are not relevant+++ 3. Since if CRC is used, the HW needs its Reassembly Buffers anyway, so there is no reason to use COWS, or any type of Marker. +++ again the same confusion betwen the PDU buffer and the RTT related holding are in the absence of Markers+++ 4. FIM can work well between HW HBAs without significant impact to pipeline design. +++ Somebody already said that FIMs are like democracy - imperfect, ugly but work+++ +++ However COWS are not that much heavier if carefully implemented and might get us faster to converge on a framing model+++ Therefore, I recommend that the Draft continue to define FIM. Also, I recommend that the FIM type of Markers be "MUST Implement" on the Out-Going direction, and "MAY Implement" on the incoming direction". Further, I recommend the Draft say that FIM "MAY be used" in any direction, depending on the negotiations. . . . 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 0025B058C2256B3B_= Content-Type: text/html; charset="us-ascii"
John,

FIM works now and COWS is not as bad as you paint it - as most software stacks touch the data at least once (no exceptions!).  As for the pipeline argument - it must have something to do with Alaska - as I don't get it :-)

If you want a vote - I can't - my heart is thorn ...

Julo


John Hufferd@IBMUS

07-01-02 21:49


        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        From:        John Hufferd/San Jose/IBM@IBMUS
        Subject:        Re: iSCSI: MarkersLink
 





OK, Julian,
I buy that argument.  I think that you have made the point that the value of Markers is Greater then I was giving credit for, in iSCSI/TOE integrated HBAs that are operating in CRC mode.   That is great, since I am afraid we will not see the Framing stuff for some time.

So the questions are which form of markers is the best.

My vote comes down on the side of Fixed Interval Markers (FIM). For the following reasons:

On the SW sending side, FIM works with low overhead whether CRC is being used or not.  COWS, is a dramatic overhead unless the SW is performing CRC computation anyway.

The COWS has a built in conflict with the Pipeline HW HBA, that has two different needs regarding the direction of the Pointers when talking to another partner  HW HBA that uses a Pipeline approach.  

.
.
.
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

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

To:        ips@ece.cmu.edu
cc:        
Subject:        Re: iSCSI: Markers




John,

The markers are supposed to help you get fat to the next PDU and start assembling and placing it.
It does not alleviate the need for a PDU assembly buffer - that you need anyhow - it alleviates the need to keep
TCP packets along when you have lost an iSCSI PDU header.

Once you have an iSCSI PDU header you need only the (as short as you want) PDU reassembly.

If you do not have an iSCSI header you have potentially to keep around an RTT dependent amount of data.
Markers are here to reduce the later to an amount that is not a function of Bandwidth*RTT.

Regards,
Julo


John Hufferd@IBMUS

07-01-02 12:07
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        From:        John Hufferd/San Jose/IBM@IBMUS
        Subject:        Re: iSCSI: MarkersLink
 





Julian,
There are two different issues with regards to CRC.  

One is on the sender side, and if Markers are done in Software, of course it matters if CRC is done, since if the sender does not use CRC, the cost of COWS is very high.

The second point is about the Receiving Side.  I did not understand your point, so I would appreciate you expanding on your comment that the Target Side would still get value out of Markers even if they use CRC.  I can understand that there would be some additional value, especially in TCP Segment errors.  By permitting some additional TCP Segments to arrive during the retry, but most of the value is lost because the Full Reassembly Buffer is needed for CRC.  So now that I confess, that I do not completely understand your point, perhaps you could step me through your view of the value in the presents of CRC on a HW HBA/Chip.   I think it is important that we are able to quantify the value.
 
With regards to iWARP, I was using that name as an alias for the technique explained in the framing Draft (at http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-ulp-frame-01.txt).  But except for the last part of COWS, there is little resemblance between that and COWS.  The framing does NOT use Word replacement.  They only have a 8 byte header in common.  

That brings me to another point.  If FIM needs to double its Markers (two words instead of one), would not COWS also need to double its Header Markers, for the same reason?


.
.
.
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
 

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

To:        ips@ece.cmu.edu
cc:        
Subject:        Re: iSCSI: Markers




Some comments in text - Julo


John Hufferd/San Jose/IBM@IBMUS
Sent by: owner-ips@ece.cmu.edu

06-01-02 23:57
       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI: Markers

       


When we were in Salt Lake City, we decided to hold a discussion on the
Reflector regarding Markers.  I think it is probably time to hold that
discussion.  Therefore, I will start it out.

First I want to thank Julian for going to the trouble to document the
proposal for COWS.  This now gives us two Marker proposals to consider.
They are the Fixed Interval Markers (FIM) and the Constant Overhead Word
Stuffing (COWS) proposals.

Having said that, lets examine each one and determine their usefulness.

1. Markers (FIM or COWS) are only needed by Hardware HBAs that are
attempting to limit the amount of Reassembly Buffers they need on-board.
This will always be a probabilistic determination by the vendors, but the
purpose of Markers are to hold down the amount of total RAM needed,
especially when factored into a probabilistic determination.
2. The use of Markers are negotiated per connection, and per direction.  It
is therefore possible for a software implementation to send markers, but
not have to accept them.
+++ that is specially important for software implementations ++
3. When CRC Digest are negotiated to be used, it does no good to send out
Markers since the hardware side will have to have Reassembly Buffers to
compute the CRC Digest.  Therefore, Markers do not help anything when CRCs
are used on a connection.
+++ That is not correct - Framing mechanisms are used to avoid an RTT related size for the receive buffer not avoinding  a one-PDU buffer. Both FIM and COWS will help reducing HBA ememory requirements even when using CRC.  When Using CRC a PDU reassembly buffer is unavoidale but it can be limited by the MaxRcvPDU. +++

4. FIM can be implemented easily in software, and with an out going
Scatter/Gather technique could send PDUs across a network to a Hardware HBA
destination without requiring additional moves or touching each byte.
5. Software iSCSI implementations should always negotiate NOT to receive
markers since Markers do not help the SW in any way.
6. Hardware HBAs can also implement FIM easily, and HW can do it easily in
both directions.  Therefore, if FIM is the approved Marker proposal, a HW
HBA should send FIM whenever it sends iSCSI Commands and/or Data to other
HW HBAs (assuming iWARP is not an available option), and the other HW HBAs
wants them.
7. I do not foresee many installations using CRC Digests with Laptops and
Desktops, since the overhead will probably be noticeable, and most
installations do not judge Desktop and Laptop data to be key corporate
assets (I am not saying that opinion is right, or that it is Universal,
just that is a prevalent opinion).
+++CRCs are not relevant +++
8. A single software node would not be fast enough to cause a significant
load or a significant  memory requirement for the Reassembly Buffers.
However, the combination of many (perhaps Desktops and Laptops spread
across a real or virtual campus) can bring on a large load and the need for
many Reassembly Buffers.  The resultant amount of small Reassembly Buffers
could make the Total requirement very High (thus raising the cost of the
HBA).
9. Given the need for Desktops and Laptops to avoid noticeable degradation,
and the probability that they will not be using CRC, means that the use of
FIM is a compatible option when working across a network from a SW Node to
an iSCSI HW HBA implemented Storage Controller.
10. COWS was also designed to be easily implemented in Software and in
Hardware.
11. COWS will require the iSCSI Software implementations to touch each
byte, as it looks for matches to its Framing Pattern within the PDUs.
+++ except when implemented within the CRC, checksum where no ADDITIONAL touch is involved +++
12. When CRC-32 digests are being computed, the Software will have to touch
ever byte anyway, so the additional overhead to look for matches to the
Framing Pattern is negligible.  On the other hand FIM also works well with
SW CRC-32 Digest computation.
13. But the premies I set above (which is clearly up to debate), is that
Desktops and Laptops will not usually compute the CRC Digest.
14. COWS has the ability to have its pointing Markers, which point to the
Framing Pattern Matches, point either forward or backwards.  When being
processed by software, the direction does not matter.  So since the Markers
should only be used on outgoing PDUs, the approprate direction of the
pointers is what ever the destination needs.
15. Many vendors, especially at the higher speeds, are implementing a pipe
line design.  The pipeline receive process, will most likely want the COWS
pointers to be forward pointing (pointing in the direction of the end of
the PDU).  Since the SW does not care, forward pointers should be fine.
16. If the HW Pipelining iSCSI HBA is to send COWS Markers to another HW
Pipelining HBA, there may be a problem.  The outgoing pipeline would prefer
to have the pointers pointing backwards, but the receiving pipeline would
prefer to have the pointers going forwards.  Therefore with COWS, either
the sending or the receiving HW Pipelining HBA will be unhappy and pipeline
design will get very much more complicated.
17. Everyone likes iWARP better, but it requires changes to the Host SW
TCP/IP stacks in the case of SW Initiators.  Since these SW installations
are probably going to be Desktops and Laptops, these systems will very
likely have some non current version of the OS, (such as windows 2k, ME,
etc.).  Hence it is unlikely that they will have iWARP in the majority of
the SW TCP/IP Stacks).
+++iWARP needs framing as well and I would guess the technique will be close to what COWS is.  Future convergence speaks for COWS+++
18. If, for some reason, a Server uses Software iSCSI, it will probably
have the latest and greatest OS software, and if that is true, and if iWARP
is approved by the IETF then it will probably have the TCP/IP extensions
that are required by iWARP.  It will therefore use iWARP instead of any
Marker solution.
19. If the Server uses Software iSCSI,  and if iWARP is not approved by the
IETF, then COWS or FIM are both  reasonable choices  for the Server, if the
Server also uses the CRC option.  If CRC is not used on the Server, FIM is
a better match with the Server SW iSCSI.
19. iWARP is probably going to stay in IETF "experimental mode" for some
time into the future.  And without iWARP being specified by iSCSI as -- at
least, "MAY Implement" and "MAY use", the HW to HW mode will still need a
Marker solution.
20. Therefore, we are left with Markers as the only technique we can count
on to aid and assist the iSCSI HW HBAs, keep their "on-board" RAM
requirements to a minimum.

Based on the above I come to the following conclusions:
1. Markers are needed.
2. FIM works best with the probable SW environment, and has the lowest
overhead (since they will probably not use CRC Digests).
+++CRCs are not relevant+++
3. Since if CRC is used, the HW needs its Reassembly Buffers anyway, so
there is no reason to use COWS, or any type of Marker.
+++ again the same confusion betwen the PDU buffer and the RTT related holding are in the absence of Markers+++
4. FIM can work well between HW HBAs without significant impact to pipeline
design.
+++ Somebody already said that FIMs are like democracy - imperfect, ugly but work+++
+++ However COWS are not that much heavier if carefully implemented and might get us faster to converge on a framing model+++

Therefore, I recommend that the Draft continue to define FIM.  Also, I
recommend that the FIM type of Markers be "MUST Implement" on the Out-Going
direction, and "MAY Implement" on the incoming direction".   Further, I
recommend the Draft say that FIM "MAY be used" in any direction, depending
on the negotiations.

.
.
.
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 0025B058C2256B3B_=-- From owner-ips@ece.cmu.edu Tue Jan 8 11:20: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 LAA27973 for ; Tue, 8 Jan 2002 11:20:06 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g08FMPW04975 for ips-outgoing; Tue, 8 Jan 2002 10:22:25 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hammer.brocade.com (asbestos.brocade.com [63.121.140.244]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g089TKg08175 for ; Tue, 8 Jan 2002 04:29:21 -0500 (EST) Received: (from root@localhost) by hammer.brocade.com (8.11.3/8.11.3) id g089QT400499; Tue, 8 Jan 2002 01:27:29 -0800 (PST) Date: Tue, 8 Jan 2002 01:27:29 -0800 (PST) Message-Id: <200201080927.g089QT400499@hammer.brocade.com> From: "Lakshmi Ramasubramanian" To: X-OriginalArrivalTime: 07 Jan 2002 20:24:42.0128 (UTC) FILETIME=[56A1E900:01C197B9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g07KQjg02682 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Section 3.2.1.6 LUN : The LUN field is 64-bits and it is to be formatted in accordance with [SAM2]. Section 3. iSCSI PDU Formats : Any field appearing in this document assumes that the most significant byte is the lowest numbered byte. So, the first byte, as given in SAM2, should be set in LUN[0] or it should be set in LUN[7]? thanks! -lakshmi From owner-ips@ece.cmu.edu Tue Jan 8 13: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 NAA03258 for ; Tue, 8 Jan 2002 13:15:06 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g08HCRq12807 for ips-outgoing; Tue, 8 Jan 2002 12:12:27 -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 g08HCOg12801 for ; Tue, 8 Jan 2002 12:12:25 -0500 (EST) Received: from deneb.dev.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g08HC9215221; Tue, 8 Jan 2002 12:12: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 g08HC9q31520; Tue, 8 Jan 2002 12:12:09 -0500 Message-ID: <15419.10345.480156.427934@pkoning.dev.equallogic.com> Date: Tue, 8 Jan 2002 12:12:09 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Paul Koning To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: Markers References: 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 >>>>> "Julian" == Julian Satran writes: Julian> John, FIM works now and COWS is not as bad as you paint it - Julian> as most software stacks touch the data at least once (no Julian> exceptions!). Yes, most software stacks touch the data at least once. But NOT ALL do. So no, COWS very definitely can be as bad as John painted it. paul From owner-ips@ece.cmu.edu Tue Jan 8 13:15: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 NAA03272 for ; Tue, 8 Jan 2002 13:15:44 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g08Hha114632 for ips-outgoing; Tue, 8 Jan 2002 12:43:36 -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 g08H1ag12204 for ; Tue, 8 Jan 2002 12:01:36 -0500 (EST) Received: from deneb.dev.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g08Gxuc15143; Tue, 8 Jan 2002 11:59:56 -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 g08GxtH29704; Tue, 8 Jan 2002 11:59:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15419.9611.81274.188282@pkoning.dev.equallogic.com> Date: Tue, 8 Jan 2002 11:59:55 -0500 (EST) From: Paul Koning To: hufferd@us.ibm.com Cc: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: Re: iSCSI: Markers References: 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 >>>>> "John" == John Hufferd writes: John> OK, Julian, I buy that argument. I think that you have made John> the point that the value of Markers is Greater then I was John> giving credit for, in iSCSI/TOE integrated HBAs that are John> operating in CRC mode. That is great, since I am afraid we John> will not see the Framing stuff for some time. John> So the questions are which form of markers is the best. John> My vote comes down on the side of Fixed Interval Markers John> (FIM). For the following reasons: John> On the SW sending side, FIM works with low overhead whether CRC John> is being used or not. COWS, is a dramatic overhead unless the John> SW is performing CRC computation anyway. John> The COWS has a built in conflict with the Pipeline HW HBA, that John> has two different needs regarding the direction of the Pointers John> when talking to another partner HW HBA that uses a Pipeline John> approach. I think you are making general assumptions about what is cheap in software that may be valid for SOME software implementations but are certainly not valid for others. In particular, FIM is NOT necessarily low overhead. Scatter/gather is a reasonably cheap mechanis IF it is available for this job. (Note that it is not all that cheap: adding a bunch of extra descriptor fetches to the I/O device's job is extra overhead, the scale of which depends on the hardware. The problem is that scatter/gather may not be available at all. If it is available in principle, it may have restrictions that clash with what FIM needs. (For example, a particular implementation may support breaking buffers up in many pieces, but all breaks must be on cache line boundaries. For a cache line size of 32, clearly you cannot use scatter/gather in that implementation to do FIM.) So FIM may force a full buffer copy, which is a major hit. As for COWS, it's clearly nasty. Even if you're doing CRC, it adds a significant increment to the processing cost. In conclusion, I am opposed to mandating markers. Adding such a large increment in processing overhead doesn't make sense to me, given that I don't see how it can be expected to save all that much memory in implementations that use it. (As far as I can see, the gain doesn't come anywhere near a factor of two. Is there any analysis available that discusses this in any detail -- covering not just the specific buffering needs of the reassembly side but also the other memory requirements in a node? It seems to me a node needs at least as much memory in the other direction -- quite possibly more if it's the storage end, given that a lot of the traffic is reads.) paul From owner-ips@ece.cmu.edu Tue Jan 8 13:19:26 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03400 for ; Tue, 8 Jan 2002 13:19:26 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g08HDxJ12903 for ips-outgoing; Tue, 8 Jan 2002 12:13:59 -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 g08HDtg12893 for ; Tue, 8 Jan 2002 12:13:55 -0500 (EST) Received: from deneb.dev.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g08HDlE15228 for ; Tue, 8 Jan 2002 12:13:47 -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 g08HDlx31565 for ; Tue, 8 Jan 2002 12:13:47 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15419.10443.41391.59234@pkoning.dev.equallogic.com> Date: Tue, 8 Jan 2002 12:13:47 -0500 (EST) From: Paul Koning To: ips@ece.cmu.edu Subject: Re: iSCSI: Markers 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 >>>>> "John" == John Hufferd writes: John> OK, Julian, I buy that argument. I think that you have made John> the point that the value of Markers is Greater then I was John> giving credit for, in iSCSI/TOE integrated HBAs that are John> operating in CRC mode. That is great, since I am afraid we John> will not see the Framing stuff for some time. John> So the questions are which form of markers is the best. John> My vote comes down on the side of Fixed Interval Markers John> (FIM). For the following reasons: John> On the SW sending side, FIM works with low overhead whether CRC John> is being used or not. COWS, is a dramatic overhead unless the John> SW is performing CRC computation anyway. John> The COWS has a built in conflict with the Pipeline HW HBA, that John> has two different needs regarding the direction of the Pointers John> when talking to another partner HW HBA that uses a Pipeline John> approach. I think you are making general assumptions about what is cheap in software that may be valid for SOME software implementations but are certainly not valid for others. In particular, FIM is NOT necessarily low overhead. Scatter/gather is a reasonably cheap mechanis IF it is available for this job. (Note that it is not all that cheap: adding a bunch of extra descriptor fetches to the I/O device's job is extra overhead, the scale of which depends on the hardware. The problem is that scatter/gather may not be available at all. If it is available in principle, it may have restrictions that clash with what FIM needs. (For example, a particular implementation may support breaking buffers up in many pieces, but all breaks must be on cache line boundaries. For a cache line size of 32, clearly you cannot use scatter/gather in that implementation to do FIM.) So FIM may force a full buffer copy, which is a major hit. As for COWS, it's clearly nasty. Even if you're doing CRC, it adds a significant increment to the processing cost. In conclusion, I am opposed to mandating markers. Adding such a large increment in processing overhead doesn't make sense to me, given that I don't see how it can be expected to save all that much memory in implementations that use it. (As far as I can see, the gain doesn't come anywhere near a factor of two. Is there any analysis available that discusses this in any detail -- covering not just the specific buffering needs of the reassembly side but also the other memory requirements in a node? It seems to me a node needs at least as much memory in the other direction -- quite possibly more if it's the storage end, given that a lot of the traffic is reads.) paul From owner-ips@ece.cmu.edu Tue Jan 8 14:28: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 OAA06533 for ; Tue, 8 Jan 2002 14:27:58 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g08InC318342 for ips-outgoing; Tue, 8 Jan 2002 13:49:12 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from emulex.emulex.com (emulex.emulex.com [138.239.112.1]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g08InAg18337 for ; Tue, 8 Jan 2002 13:49:10 -0500 (EST) Received: from xbl.ad.emulex.com (xbl.ma.emulex.com [172.16.12.11]) by emulex.emulex.com (8.9.1a/8.9.1) with ESMTP id KAA25818; Tue, 8 Jan 2002 10:49:13 -0800 (PST) Received: by xbl.ad.emulex.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2002 13:48:57 -0500 Message-ID: <3356669BBE90C448AD4645C843E2BF280A0587@xbl.ad.emulex.com> From: "Williams, Jim" To: "'John Hufferd'" , ips@ece.cmu.edu Subject: RE: iSCSI: Markers Date: Tue, 8 Jan 2002 13:48:53 -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: John Hufferd [mailto:hufferd@us.ibm.com] > Sent: Sunday, January 06, 2002 4:58 PM > To: ips@ece.cmu.edu > Subject: iSCSI: Markers > > > [...] > 16. If the HW Pipelining iSCSI HBA is to > send COWS Markers to another HW > Pipelining HBA, there may be a problem. > The outgoing pipeline would prefer > to have the pointers pointing backwards, > but the receiving pipeline would > prefer to have the pointers going forwards. > Therefore with COWS, either > the sending or the receiving HW Pipelining > HBA will be unhappy and pipeline > design will get very much more complicated. With the disclaimer that I am skeptical of the value of markers and definitely opposed to mandating them, I would add the following comment regarding COWS. I believe its more important to make the transmit side "happy" than the receive side. There are two reasons here. 1. It is desired to have much wider deployment of transmit side COWS, since the receive side is an option that many (most) vendors will choose not to support. Transmit side may want (need) to be supported anyway for the benefit of other implementations that require it. 2. NIC designers can defer fetching transmit data until late in the pipeline. All protocol processing, header formatting, and bookkeeping can be done prior to fetching the data. Therefore the transmit pipeline will have a small amount of time to fully implement the COWS algorithm. On the receive side pipeline, the COWS algorithm can be done in parallel with the protocol processing since that is done when all the data is present in the receive buffer. The receive COWS algorithm can be done in place in the receive buffer, so backward pointers are not a problem. An efficient transmit COWS algorithm requires that hardware check each word in the outgoing PDU, whereas an efficient receive algorithm requires checking only the pointer (other than exceptional cases). > 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 Jan 8 14:29:06 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06614 for ; Tue, 8 Jan 2002 14:29:06 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g08IHGX16453 for ips-outgoing; Tue, 8 Jan 2002 13:17:16 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g08IG6g16405 for ; Tue, 8 Jan 2002 13:16:06 -0500 (EST) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.148]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4617); Tue, 8 Jan 2002 10:16:00 -0800 Received: from 157.54.5.25 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 08 Jan 2002 10:15:58 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 8 Jan 2002 10:15:59 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 8 Jan 2002 10:15:59 -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); Tue, 8 Jan 2002 10:14:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6115.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: iSCSI: Format of LUN in iSCSI PDU Date: Tue, 8 Jan 2002 10:14:02 -0800 Message-ID: Thread-Topic: iSCSI: Format of LUN in iSCSI PDU thread-index: AcGXr/604krHTmLRTVyCVf6dNzuUSQACNQkgAC3mnKA= From: "Lakshmi Ramasubramanian" To: X-OriginalArrivalTime: 08 Jan 2002 18:14:02.0639 (UTC) FILETIME=[405891F0:01C19870] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g08IG6g16406 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Subject line seem to have got chopped in the message I posted earlier. Resending. -lakshmi -----Original Message----- From: Lakshmi Ramasubramanian Sent: Monday, January 07, 2002 12:25 PM To: ips@ece.cmu.edu Subject: iSCSI: Format of LUN in iSCSI PDU Section 3.2.1.6 LUN : The LUN field is 64-bits and it is to be formatted in accordance with [SAM2]. Section 3. iSCSI PDU Formats : Any field appearing in this document assumes that the most significant byte is the lowest numbered byte. So, the first byte, as given in SAM2, should be set in LUN[0] or it should be set in LUN[7]? thanks! -lakshmi From owner-ips@ece.cmu.edu Tue Jan 8 15:43: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 PAA09816 for ; Tue, 8 Jan 2002 15:43:06 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g08Jw9E22939 for ips-outgoing; Tue, 8 Jan 2002 14:58:09 -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 g08Jw4g22931 for ; Tue, 8 Jan 2002 14:58:08 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel6.hp.com (Postfix) with ESMTP id 427A360059F for ; Tue, 8 Jan 2002 14:57:58 -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 LAA03300 for ; Tue, 8 Jan 2002 11:59:32 -0800 (PST) Message-Id: <200201081959.LAA03300@core.rose.hp.com> Date: Tue, 08 Jan 2002 12:11:32 -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: iSCSI: task management response Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit All: The most recent task management text that Julian posted to the list (sub: iSCSI - last change for 2001!) deals with target reset authorization failure in an indirect way ("Function complete" with a "Not Authorized qualifier). I would favor one of two approaches in this order - a) "function authorization failure" response (i.e. doing away with the qualifier field), or b)"Function Rejected" response with a "Not authorized" qualifier Julian would be okay with either of the above, but thinks that some O/Ses (Windows?) were not able to deal with anything other than a "Function complete" for a target reset. My questions are - - can those O/S folks please speak up if this is still the case? - a "Function complete" response stripped of its qualifer (for legacy O/S consumption) would be incorrect, since the expected target reset semantics had not been met - how is this dealt with? If this is no longer an O/S issue now, I propose that we adopt (a) above. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com From owner-ips@ece.cmu.edu Tue Jan 8 15:46: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 PAA09911 for ; Tue, 8 Jan 2002 15:46:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g08JTZs21174 for ips-outgoing; Tue, 8 Jan 2002 14:29:35 -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 g08JTYg21170 for ; Tue, 8 Jan 2002 14:29:34 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel7.hp.com (Postfix) with ESMTP id 6D4A3E004AE for ; Tue, 8 Jan 2002 14:29:28 -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 LAA27259 for ; Tue, 8 Jan 2002 11:31:02 -0800 (PST) Message-Id: <200201081931.LAA27259@core.rose.hp.com> Date: Tue, 08 Jan 2002 11:43:02 -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@ece.cmu.edu Subject: Re: iSCSI: AHS drop bit References: <003101c19626$e4b11a20$a2a0f40f@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 Update on this... After an offline conversation with Julian, he agreed that the AHS drop bit can be removed. It will be removed in rev10. The room for current "Non-iSCSI extensions" would however be retained as "Vendor specific extensions". Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com "Mallikarjun C." wrote: > > Julian, > > > We don't have any use for it but some "vendor specific" extensions may. > > That then begs the question - should/can we anticipate vendor-specific needs > and provide for them in the spec? > > My preference is to do away with AHS drop bit - since it doesn't seem > useful to either iSCSI or SCSI. > > Regards. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 > > ----- Original Message ----- > From: "Julian Satran" > To: > Sent: Saturday, January 05, 2002 6:10 AM > Subject: Re: iSCSI: AHS drop bit > > > Mallikarjun, > > > > The bit was really meant to enable dropping the additional header and not > > the whole request if ignored but rejecting the whole request. > > We don't have any use for it but some "vendor specific" extensions may. > > > > I suggest we change the wording of non-ISCSI non-iSCSI/vendor specific > > > > Julo > > > > > > > > "Mallikarjun > > C." To: ips > > > om> Subject: iSCSI: AHS drop bit > > Sent by: > > owner-ips@ece. > > cmu.edu > > > > > > 14-12-01 22:48 > > Please respond > > to cbm > > > > > > > > > > > > Julian, > > > > Section 3.2.2.1 says the following on the AHS drop bit - > > bit 7 - Drop Bit - if set to 1 this AHS may be ignored if not > > understood; if set to 0 this AHS must be rejected if not > > understood. > > > > - I suspect it is the entire command that was meant to be failed, not > > just the AHS... > > > > - If it is a SCSI operation that is being failed, I suggest that > > the target should end the command with an appropriate SCSI CHECK > > CONDITION - so the command sequence window can advance at the > > transport level (and the inability of the target to support say > > extended CDB is known end-to-end, to prevent fruitless SCSI retries). > > > > - This bit may be useful for AHS code "Non-iSCSI extensions", but > > I could not see how it can be used for the defined iSCSI operations. > > If it is indeed so, I would actually suggest dropping this feature. > > > > Regards. > > -- > > Mallikarjun > > > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > MS 5668 Hewlett-Packard, Roseville. > > cbm@rose.hp.com > > > > > > > > > > From owner-ips@ece.cmu.edu Tue Jan 8 15:49: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 PAA09980 for ; Tue, 8 Jan 2002 15:49:05 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g08K1Uw23197 for ips-outgoing; Tue, 8 Jan 2002 15:01:30 -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 g08K1Ng23186 for ; Tue, 8 Jan 2002 15:01:28 -0500 (EST) Received: from amirdesktop (dhcp62 [172.21.2.62]) by astutenetworks.com (8.11.6/8.11.2) with SMTP id g08Kw5W08965; Tue, 8 Jan 2002 12:58:05 -0800 From: "Amir Shalit" To: "Williams, Jim" , "'John Hufferd'" , Subject: RE: iSCSI: Markers Date: Tue, 8 Jan 2002 12:58:02 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <3356669BBE90C448AD4645C843E2BF280A0587@xbl.ad.emulex.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I agree with what Jim and John are saying. I think COWS would present a major challenge to most software and more also hardware implementations. Software implementation may touch the data at least once for computing checksum but must change to do pattern matching. It's not clear to me that "off the shelf" network stacks can easily change (i.e. logistics, support, etc.). It gets much worse with hardware implementations since an existing CRC circuit can not change to support additional functions. A new H/W design that combines CRC and COWS may not make sense in terms of pipeline architecture as well as logic design. In addition, rearranging the data stream by swapping each appearance of the pattern with a link may be time consuming for the transmitter. I vote for Markers. -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Williams, Jim Sent: Tuesday, January 08, 2002 10:49 AM To: 'John Hufferd'; ips@ece.cmu.edu Subject: RE: iSCSI: Markers > -----Original Message----- > From: John Hufferd [mailto:hufferd@us.ibm.com] > Sent: Sunday, January 06, 2002 4:58 PM > To: ips@ece.cmu.edu > Subject: iSCSI: Markers > > > [...] > 16. If the HW Pipelining iSCSI HBA is to > send COWS Markers to another HW > Pipelining HBA, there may be a problem. > The outgoing pipeline would prefer > to have the pointers pointing backwards, > but the receiving pipeline would > prefer to have the pointers going forwards. > Therefore with COWS, either > the sending or the receiving HW Pipelining > HBA will be unhappy and pipeline > design will get very much more complicated. With the disclaimer that I am skeptical of the value of markers and definitely opposed to mandating them, I would add the following comment regarding COWS. I believe its more important to make the transmit side "happy" than the receive side. There are two reasons here. 1. It is desired to have much wider deployment of transmit side COWS, since the receive side is an option that many (most) vendors will choose not to support. Transmit side may want (need) to be supported anyway for the benefit of other implementations that require it. 2. NIC designers can defer fetching transmit data until late in the pipeline. All protocol processing, header formatting, and bookkeeping can be done prior to fetching the data. Therefore the transmit pipeline will have a small amount of time to fully implement the COWS algorithm. On the receive side pipeline, the COWS algorithm can be done in parallel with the protocol processing since that is done when all the data is present in the receive buffer. The receive COWS algorithm can be done in place in the receive buffer, so backward pointers are not a problem. An efficient transmit COWS algorithm requires that hardware check each word in the outgoing PDU, whereas an efficient receive algorithm requires checking only the pointer (other than exceptional cases). > 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 Jan 8 17:07: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 RAA11840 for ; Tue, 8 Jan 2002 17:07:10 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g08LMG828406 for ips-outgoing; Tue, 8 Jan 2002 16:22:17 -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 g08LMBg28394 for ; Tue, 8 Jan 2002 16:22:11 -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 g08LNJP15661; Tue, 8 Jan 2002 13:23:20 -0800 Message-Id: <200201082123.g08LNJP15661@Gregorio.Stanford.EDU> To: "Amir Shalit" cc: "Williams, Jim" , "'John Hufferd'" , ips@ece.cmu.edu Subject: Re: iSCSI: Markers In-reply-to: Your message of "Tue, 08 Jan 2002 12:58:02 PST." Date: Tue, 08 Jan 2002 13:18:30 -0800 From: Jonathan Stone Sender: owner-ips@ece.cmu.edu Precedence: bulk ....This may be a good point to observe that the original implementation of COBS was for a wireless radio link which struggled to deliver 19.2kbps of goodput to any individual end-station. I believe the first two (or three, depending on how one counts the appletalk implementation) of COBS all found the change in buffer sizes diffiult to integrate into other operations, and they all implemented COBS encoding/decoding as a copy between encoded and decoded buffers, not as an in-place operation. Even if a COWS data-touching loop is folded into another data-reading loop, COWS encoding/decoding still dirties all the cache lines being encoded or decoded, and will therefore has the same overhead as an additional copy. Performing COBS encoding/decoding in an outbouard accelerator also makes it impossible for those of us who don't trust our I/O busses to perform a `trust, but verify' integrity check: e.g., recomputing the TCP/IP checksum over the data stream as the HBA-cum-NIC deposits it in host memory. Indeed, the original COBS implementation(s) provided only framing; COBS framing was wrapped outside an end-to-end integrity check. I beleive Stuart is still on vacation, but I can ask him to comment on these issues when he gets back, if that would be worthwhile. From owner-ips@ece.cmu.edu Tue Jan 8 17:50: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 RAA12933 for ; Tue, 8 Jan 2002 17:50:39 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g08LxKw01126 for ips-outgoing; Tue, 8 Jan 2002 16:59:20 -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@www.splentec.com [207.219.118.226]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g08LxBg01108 for ; Tue, 8 Jan 2002 16:59:13 -0500 (EST) Received: from splentec.com (canoe.splentec.com [207.219.118.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g08Lv8U32109 for ; Tue, 8 Jan 2002 16:57:08 -0500 Message-ID: <3C3B6BA2.22B8F3A9@splentec.com> Date: Tue, 08 Jan 2002 16:58:58 -0500 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: iSCSI Subject: Chapter cf. correction & Logout Request Type<->Reason [iSCSI] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Section 2.2.3 iSCSI Login, paragraph 6, last sentence should probably refer to ``Chapter 5 Login Phase'' rather than to ``chapter 1''. Section 2.4 iSCSI Session Types and Appendix D section 33 refer to ``a close session type of logout request''. Shouldn't this phrase be ``logout request with reason "close the session"''? First, to be consistent with the rest of the document which uses the second phrase, and secondly since there is only one type of logout request, but with different _reasons_ (which would be the keyword). -- -l From owner-ips@ece.cmu.edu Tue Jan 8 18:29: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 SAA13784 for ; Tue, 8 Jan 2002 18:29:47 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g08MjLo03740 for ips-outgoing; Tue, 8 Jan 2002 17:45: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 g08MjKg03736 for ; Tue, 8 Jan 2002 17:45:20 -0500 (EST) Received: from deneb.dev.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g08MVKn18025; Tue, 8 Jan 2002 17:31:20 -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 g08MVKt16201; Tue, 8 Jan 2002 17:31:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15419.29496.305243.22381@pkoning.dev.equallogic.com> Date: Tue, 8 Jan 2002 17:31:20 -0500 (EST) From: Paul Koning To: hufferd@us.ibm.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: Markers References: 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 >>>>> "John" == John Hufferd writes: John> Paul, I did not understand your statement ... John> "...It seems to me a node needs at least as much memory in the John> other direction -- quite possibly more if it's the storage end, John> given that a lot of the traffic is reads.)" John> Are you talking about all the memory in the Node or the RAM on John> the HBA? The focus should be on the HBA, and generally, that John> memory is small in the outgoing direction. So perhaps I John> misunderstood your point. I meant the HBA. Would you expect TCP level retransmit to fetch the data from the host again? Yes, I guess then you could save the memory on the HBA. John> About the Mandating of markers. The proposal was that it John> should be required to implement (not required to use) in John> outgoing, and clearly it should be optional to use. In that John> manner, the approprate trade offs can be made at execution John> time. Yes, I know. I'm objecting to the "required to implement". It's problematic to have a feature that someone else can turn on (by asking for it when you're required to say "yes") and which has the side effect of destroying your performance. John> It seems to be a small impact to the code to just to support John> this on the outgoing flow. I did understand you comments about John> how some HW operates, and that needs to be considered in the John> executions time trade off. In most Desktops, laptops, that is John> probably not an important issue (with 1.5-2 GHz processors), John> but it could be a serious consideration for any servers that John> need to have a SW implementation. (Of course, many folks would John> tell the servers to get an HBA, but that is a different issue.) I'm talking about embedded systems, where throwing an outboard HBA into the picture makes things much bigger and more expensive, not to mention slower. In that example, turning on markers changes the transmit flow from a straightforward DMA of the data into a memory to memory copy with insertion of the markers every N bytes. That's a large increment in overhead. paul From owner-ips@ece.cmu.edu Tue Jan 8 18:30: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 SAA13827 for ; Tue, 8 Jan 2002 18:30:24 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g08NAmZ05142 for ips-outgoing; Tue, 8 Jan 2002 18:10:48 -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.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g08NAlg05137 for ; Tue, 8 Jan 2002 18:10:47 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2002 18:05:59 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0293731F@CORPMX14> From: Black_David@emc.com To: roweber@acm.org, ips@ece.cmu.edu Subject: RE: FCIP: Short Frame Security Solution Proposal Date: Tue, 8 Jan 2002 17:58: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 The timeout helps, but doesn't completely stop the race. Rather than alluding to its existence, I would explain the attack (see nonce on one connection, send it on another) and say that use of ESP confidentiality is the countermeasure when this is deemed to be an important risk. Thanks, --David > -----Original Message----- > From: Ralph Weber [mailto:ralphoweber@compuserve.com] > Sent: Monday, January 07, 2002 12:25 PM > To: IPS Reflector > Subject: Re: FCIP: Short Frame Security Solution Proposal > > > David, > > 2 out of your 3 comments pertain to the content of FC-BB-2 > and as such incorporating them in something must wait for > the proposal to introduce the other half of this in FC-BB-2. > My intention is that said proposal will be finished in > time to meet the two-week rule for the T11 meeting in > Huntington Beach. I will announce the availability of > the proposal on this reflector. > > The one comment that suggests adding text to the FCIP > draft is as follows: > > > > > - Some words will need to be added about a nasty race > > > > condition in which the attacker opens up a connection up > > > > to the point of sending the short frame, watches a real > > > > connection get set up to the point that the attacker sees > > > > the short frame on the real connection; the attacker > > > > extracts and uses the nonce, and TCP tricks (e.g., corrupt > > > > the TCP packet containing the nonce to cause a checksum > > > > failure, or send a well-timed RST). The short answer to > > > > dealing with this is "use IKE and also ESP encryption if > > > > warranted" when this sort of attack is a concern. > > > > > > Would it not be better to include a broad caution along the > > > lines of: > > > > > > Warning: The authentication mechanism described here is not > > > designed to thwart sophisticated security threats. The IP > > > security mechanisms described in section 9 should be enabled > > > in environments where security threats are suspected. > > > > Both. The race is sufficiently related to the WWN short frame > > that it should be specifically mentioned. There are other > > authentication mechanisms that are not subject to this race. > > Interestingly enough, this is need not be as wide open a race > as one might first think because the recipient of the TCP > connect request may timeout and close the connection if the > SF is not received in 90 seconds or longer. > > None the less, words about the race condition have been added > to the FCIP revision in development. The specific new text > (and the paragraph preceding it) are as follows: > > * The FCIP Entity MAY apply a timeout of not less than 90 seconds > * to the waiting for the FCIP Special Frame bytes and if the timeout > * expires the FCIP Entity SHALL close the TCP Connection and notify > * the FC Entity with the reason for the closure. > * > * Note: One method for attacking the security of the FCIP Link > * formation process depends on keeping a TCP connect request open > * without sending an FCIP Special Frame. Implementations should bear > * this in mind in the handling of TCP connect requests where the FCIP > * Special Frame is not sent in a timely manner. > > Thanks. > > Ralph... > > Black_David@emc.com wrote: > > > Ralph, > > > > > Black_David@emc.com wrote [responses embedded]: > > > > > > > I think this is a workable approach. A few comments: > > > > > > > > - There are a dependencies among a number of components > > > > on who supports what, some of which are under T11's > > > > control. If it turns out that the T11 aspects of this > > > > are not mandatory to implement, ... > > > > [... snip ...] > > > > > > I think multiple TCP > > > > connections in a single FCIP session need to be disallowed > > > > if this authentication cannot be performed by the > > > > implementation (i.e., is not implemented) - putting in a > > > > note to this effect regardless of what T11 does might be > > > > a good idea to decouple FCIP from FC-BB-2 in this area. > > > > > > As currently worded, the FCIP Entity ALWAYS asks the FC Entity > > > for authentication of a second to n-th connection and the > > > FC Entity ALWAYS responds, yes or no. I fail to see how a > > > note such as the one suggested would be viewed as anything > > > more than advisory to FC-BB-2. The FCIP Entity has (in theory) > > > no knowledge of how much or how little work the FC Entity > > > does to generate its response to the request for connection > > > authentication. > > > > What I had in mind was advice to implementers that if the FC > > Entity does not check the nonce over the initial connection with > > its peer FC entity, then the answer to the FCIP entity SHOULD > > be "no". This could also be considered as advice to BB-2. > > > > > > - Any nonce must be validated ("yes, that's my connection") > > > > at most once. If the FC Entity on the other end of the > > > > first connection is capable of saying "yes" twice to the > > > > same nonce, there's an obvious replay attack. > > > > > > I had sought to cut this type of attack off at the SF level > > > (long before the FC Entity at the other end gets a nonce > > > to validate) with the following words. > > > > > > }...} To further increase the difficulty of snooping > > > }...} TCP connections, an FCIP Entity that receives > > > }...} a duplicate nonce shall close the connection > > > }...} on which that nonce was received immediately > > > }...} without causing the SW_ILS to be sent. > > > > > > To me, this seems superior for a couple of reasons: > > > > > > o It places the requirement in FCIP, closer to the source > > > of the problem. > > > o It eliminates an unnecessary authentication transaction > > > with the FC Entity at the other end. > > > > Ok, but also see the discussion below on the "who presents > > the nonce first" race. > > > > > > - Some words will need to be added about a nasty race > > > > condition in which the attacker opens up a connection up > > > > to the point of sending the short frame, watches a real > > > > connection get set up to the point that the attacker sees > > > > the short frame on the real connection; the attacker > > > > extracts and uses the nonce, and TCP tricks (e.g., corrupt > > > > the TCP packet containing the nonce to cause a checksum > > > > failure, or send a well-timed RST). The short answer to > > > > dealing with this is "use IKE and also ESP encryption if > > > > warranted" when this sort of attack is a concern. > > > > > > Would it not be better to include a broad caution along the > > > lines of: > > > > > > Warning: The authentication mechanism described here is not > > > designed to thwart sophisticated security threats. The IP > > > security mechanisms described in section 9 should be enabled > > > in environments where security threats are suspected. > > > > Both. The race is sufficiently related to the WWN short frame > > that it should be specifically mentioned. There are other > > authentication mechanisms that are not subject to this race. > > > > > > - I think it's necessary to authentication the first TCP > > > > connection (up to FCAP or whatever) before sending the ILS > > > > that would authenticate a subsequent one, but details beyond > > > > that (e.g., can one send the SYN for the second TCP connection > > > > before the first connection authenticates) are probably up to > > > > implementations. > > > > > > I had hoped to have covered the case I think is being described > > > above by the following language (note the words "previously > > > authenticated"): > > > > > > }...} In situations where security > > > }...} risks are possible, the FC Entity shall transmit > > > }...} the information provided by the FCIP Entity via a new > > > }...} SW_ILS on a previously authenticated TCP connection > > > }...} (FCIP Data Engine) enabled for Class F frames. > > > > > > "Previously authenticated" may be vague, but it is intended to > > > cover both authentication via FCAP and authentication against > > > another F Class connection using this process. > > > > > > Consider that case where a long lived FCIP Link starts out > > > with one F Class connection. Next, using the authentication > > > process described in this proposal and two or more Class 2/3 > > > connections are added to the FCIP Link. As time goes by the F > > > Class connection becomes unreliable and the Entities at both > > > ends decide to close it and switch one of the Class 2/3 > > > connections to Class F service. > > > > > > The connection switched to F Class service has been duly > > > authenticated, but not by FCAP. It seems perfectly reasonable > > > that the switched F Class connection can serve to authenticate > > > new connect requests. > > > > Yes, "previously authenticated" is a bit vague. This discussion > > is fine, and adding the example from the discussion above would be > > helpful. > > > > 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 Jan 8 18:34: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 SAA13978 for ; Tue, 8 Jan 2002 18:34:49 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g08Mgcu03577 for ips-outgoing; Tue, 8 Jan 2002 17:42:38 -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 g08Mgag03572 for ; Tue, 8 Jan 2002 17:42:36 -0500 (EST) Received: from xparelay1.corp.hp.com (xparelay1.corp.hp.com [15.58.136.173]) by palrel11.hp.com (Postfix) with ESMTP id 4591CE0068F; Tue, 8 Jan 2002 14:42:30 -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 D2E346000BF; Tue, 8 Jan 2002 14:42:25 -0800 (PST) Received: by xpabh3.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2002 14:42:25 -0800 Message-ID: <499DC368E25AD411B3F100902740AD650AFC7D54@xrose03.rose.hp.com> From: "WENDT,JIM (HP-Roseville,ex1)" To: "'Jonathan Stone'" Cc: ips@ece.cmu.edu, Amir Shalit Subject: RE: iSCSI: Markers Date: Tue, 8 Jan 2002 14:42: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 > From: Jonathan Stone [mailto:jonathan@dsg.stanford.edu] > ... > Even if a COWS data-touching loop is folded into another data-reading > loop, COWS encoding/decoding still dirties all the cache lines being > encoded or decoded, and will therefore has the same overhead as an > additional copy. Since inline COWS encoding only has to write back chain links into buffer locations that contain the flag value (CFP), isn't the dirty-cache-line overhead proportional to the frequency of occurrence of the flag in the buffer? Given a 32-bit flag, it would seem that the probability of encountering a flag in the buffer would normally be quite low, and few if any cache lines would be dirty, hence the overhead would be just in the reads from the buffer - which could be hidden in another data reading loop. COWS does require writing an initial flag and chain link just in front of the buffer, but either a) that cache line may already be dirty because other PDU header fields have just been written, or b) part of building the PDU header can include writing the flag value and a default link chain that spans the whole PDU. [A follow up discussion point is that the original COBS scheme also appended a flag value to the end of the PDU, so that the initial chain link (CLCE) or final link chain could point to something associated with the current buffer. > Performing COBS encoding/decoding in an outbouard accelerator also > makes it impossible for those of us who don't trust our I/O busses to > perform a `trust, but verify' integrity check: e.g., recomputing the > TCP/IP checksum over the data stream as the HBA-cum-NIC deposits it > in host memory. Are you assuming that the HBA/NIC is depositing TCP segments into host memory, as an iSCSI HBA/NIC would be transferring iSCSI PDUs. What is your preferred model for integrity checking of NIC/HBA transfers across I/O buses in the face of some offloading of transport or ULP functionality? > Indeed, the original COBS implementation(s) provided only framing; > COBS framing was wrapped outside an end-to-end integrity check. This is also true for iSCSI/COWS, since the flag separates iSCSI PDUs and each iSCSI PDU contains (optional) header and data digests (CRCs). > I beleive Stuart is still on vacation, but I can ask him to comment on > these issues when he gets back, if that would be worthwhile. Absolutely. Jim From owner-ips@ece.cmu.edu Tue Jan 8 22:55: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 WAA19425 for ; Tue, 8 Jan 2002 22:55:43 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0931Jp15504 for ips-outgoing; Tue, 8 Jan 2002 22:01:19 -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 g0931Hg15500 for ; Tue, 8 Jan 2002 22:01:18 -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 TAA14537; Tue, 8 Jan 2002 19:01:06 -0800 (PST) Received: from aimexc03.corp.adaptec.com (aimexc03.corp.adaptec.com [162.62.62.43]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id SAA26693; Tue, 8 Jan 2002 18:44:58 -0800 (PST) Received: by aimexc03.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2002 19:01:00 -0800 Message-ID: <268DBFF7D2A3D411A37400D0B72E345FE71DD7@aimexc03.corp.adaptec.com> From: "Mudaliar, Hari" To: "'Julian Satran'" , ips@ece.cmu.edu Subject: iSCSI: 0.8 to 0.9 Change List Date: Tue, 8 Jan 2002 19:00:55 -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 Julian, While reviewing the 0.9 spec, we found that : 1. In 0.9, section 5.0 (Login phase) states that the SessionType parameter MAY be sent in the initial login request. In 0.8 this was a MUST. 2. In 0.9 the MSB bit of the Opcode field in all response packets is set to 0. In 0.8 this was set to 1. These are not mentioned in the change-list published in the 0.9 spec. The first one, especially, needs to be highlighted to avoid confusion at the upcoming plugfest. - Hari From owner-ips@ece.cmu.edu Wed Jan 9 02:25: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 CAA00490 for ; Wed, 9 Jan 2002 02:25:40 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g096TuP23906 for ips-outgoing; Wed, 9 Jan 2002 01:29:56 -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 g096Tsg23901 for ; Wed, 9 Jan 2002 01:29:55 -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 HAA18834 for ; Wed, 9 Jan 2002 07:29:47 +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 g096Ubr18360 for ; Wed, 9 Jan 2002 07:30:37 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: Markers X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 9 Jan 2002 08:30:37 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 09/01/2002 08:30:41, Serialize complete at 09/01/2002 08:30:41 Content-Type: multipart/alternative; boundary="=_alternative 00238192C2256B3C_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00238192C2256B3C_= Content-Type: text/plain; charset="us-ascii" One comment in text - julo Paul Koning Sent by: owner-ips@ece.cmu.edu 08-01-02 18:59 To: John Hufferd/San Jose/IBM@IBMUS cc: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu Subject: Re: iSCSI: Markers >>>>> "John" == John Hufferd writes: John> OK, Julian, I buy that argument. I think that you have made John> the point that the value of Markers is Greater then I was John> giving credit for, in iSCSI/TOE integrated HBAs that are John> operating in CRC mode. That is great, since I am afraid we John> will not see the Framing stuff for some time. John> So the questions are which form of markers is the best. John> My vote comes down on the side of Fixed Interval Markers John> (FIM). For the following reasons: John> On the SW sending side, FIM works with low overhead whether CRC John> is being used or not. COWS, is a dramatic overhead unless the John> SW is performing CRC computation anyway. John> The COWS has a built in conflict with the Pipeline HW HBA, that John> has two different needs regarding the direction of the Pointers John> when talking to another partner HW HBA that uses a Pipeline John> approach. I think you are making general assumptions about what is cheap in software that may be valid for SOME software implementations but are certainly not valid for others. In particular, FIM is NOT necessarily low overhead. Scatter/gather is a reasonably cheap mechanis IF it is available for this job. (Note that it is not all that cheap: adding a bunch of extra descriptor fetches to the I/O device's job is extra overhead, the scale of which depends on the hardware. The problem is that scatter/gather may not be available at all. If it is available in principle, it may have restrictions that clash with what FIM needs. (For example, a particular implementation may support breaking buffers up in many pieces, but all breaks must be on cache line boundaries. For a cache line size of 32, clearly you cannot use scatter/gather in that implementation to do FIM.) So FIM may force a full buffer copy, which is a major hit. As for COWS, it's clearly nasty. Even if you're doing CRC, it adds a significant increment to the processing cost. In conclusion, I am opposed to mandating markers. Adding such a large increment in processing overhead doesn't make sense to me, given that I don't see how it can be expected to save all that much memory in implementations that use it. (As far as I can see, the gain doesn't come anywhere near a factor of two. Is there any analysis available that discusses this in any detail -- covering not just the specific buffering needs of the reassembly side but also the other memory requirements in a node? It seems to me a node needs at least as much memory in the other direction -- quite possibly more if it's the storage end, given that a lot of the traffic is reads.) +++ the gain is not a factor of two - it is a not a constant - it is rather proportional to the bandwidth delay product. The rational is simple - once a header is lost without any framing mechanism the receiver has to accumulate data until the missing piece is recovered. This and other lists had long discussion threads on the subject - and if you care about it you may want to go over the archives. As David has said it is generaly agreed that this is not an issue at 1Gbs yet - but is a also agreed that this is a major issue at 10 Gb/s. That is why some of us think that a stronger statement about some form of framing is required. +++ paul --=_alternative 00238192C2256B3C_= Content-Type: text/html; charset="us-ascii"
One comment in text - julo


Paul Koning <pkoning@equallogic.com>
Sent by: owner-ips@ece.cmu.edu

08-01-02 18:59

       
        To:        John Hufferd/San Jose/IBM@IBMUS
        cc:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
        Subject:        Re: iSCSI: Markers

       


>>>>> "John" == John Hufferd <hufferd@us.ibm.com> writes:

John> OK, Julian, I buy that argument.  I think that you have made
John> the point that the value of Markers is Greater then I was
John> giving credit for, in iSCSI/TOE integrated HBAs that are
John> operating in CRC mode.  That is great, since I am afraid we
John> will not see the Framing stuff for some time.

John> So the questions are which form of markers is the best.

John> My vote comes down on the side of Fixed Interval Markers
John> (FIM). For the following reasons:

John> On the SW sending side, FIM works with low overhead whether CRC
John> is being used or not.  COWS, is a dramatic overhead unless the
John> SW is performing CRC computation anyway.

John> The COWS has a built in conflict with the Pipeline HW HBA, that
John> has two different needs regarding the direction of the Pointers
John> when talking to another partner HW HBA that uses a Pipeline
John> approach.

I think you are making general assumptions about what is cheap in
software that may be valid for SOME software implementations but are
certainly not valid for others.

In particular, FIM is NOT necessarily low overhead.  Scatter/gather is
a reasonably cheap mechanis IF it is available for this job.  (Note
that it is not all that cheap: adding a bunch of extra descriptor
fetches to the I/O device's job is extra overhead, the scale of which
depends on the hardware.

The problem is that scatter/gather may not be available at all.  If it
is available in principle, it may have restrictions that clash with
what FIM needs.  (For example, a particular implementation may support
breaking buffers up in many pieces, but all breaks must be on cache
line boundaries.  For a cache line size of 32, clearly you cannot use
scatter/gather in that implementation to do FIM.)

So FIM may force a full buffer copy, which is a major hit.

As for COWS, it's clearly nasty.  Even if you're doing CRC, it adds a
significant increment to the processing cost.

In conclusion, I am opposed to mandating markers.  Adding such a large
increment in processing overhead doesn't make sense to me, given that
I don't see how it can be expected to save all that much memory in
implementations that use it.  (As far as I can see, the gain doesn't
come anywhere near a factor of two.  Is there any analysis available
that discusses this in any detail -- covering not just the specific
buffering needs of the reassembly side but also the other memory
requirements in a node?  It seems to me a node needs at least as much
memory in the other direction -- quite possibly more if it's the
storage end, given that a lot of the traffic is reads.)

+++ the gain is not a factor of two - it is a not a constant - it is rather
proportional to the bandwidth delay product.
The rational is simple - once a header is lost without any framing mechanism
the receiver has to accumulate data until the missing piece is recovered.
This and other lists had long discussion threads on the subject - and if you care about it you may want to go over the archives.
As David has said it is generaly agreed that this is not an issue at 1Gbs yet - but is a also agreed that this is a major issue at 10 Gb/s.
That is why some of us think that a stronger statement about some form of framing is required.

+++

                paul

--=_alternative 00238192C2256B3C_=-- From owner-ips@ece.cmu.edu Wed Jan 9 09: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 JAA03936 for ; Wed, 9 Jan 2002 09:04:55 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g09DYAO20483 for ips-outgoing; Wed, 9 Jan 2002 08:34:10 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.147.1.144]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g09DY9g20478 for ; Wed, 9 Jan 2002 08:34:09 -0500 (EST) Received: from cs.uchicago.edu (h005018030f43.ne.mediaone.net [66.31.16.32]) by chmls06.mediaone.net (8.11.1/8.11.1) with ESMTP id g09DZ7Q04813 for ; Wed, 9 Jan 2002 08:35:07 -0500 (EST) Message-Id: <200201091335.g09DZ7Q04813@chmls06.mediaone.net> To: ips@ece.cmu.edu Subject: Re: iSCSI: Markers In-Reply-To: Message from Paul Koning of "Tue, 08 Jan 2002 12:13:47 EST." <15419.10443.41391.59234@pkoning.dev.equallogic.com> References: <15419.10443.41391.59234@pkoning.dev.equallogic.com> Date: Wed, 09 Jan 2002 08:34:04 -0500 From: Stephen Bailey Sender: owner-ips@ece.cmu.edu Precedence: bulk > As for COWS, it's clearly nasty. Even if you're doing CRC, it adds a > significant increment to the processing cost. Unfortunately, all the choices are nasty. Long time IETFers would probably make the point that this is an indication we are trying to do the wrong thing and should just use a message-based transport :^) That said, one position that many people thought was the least nasty was key/length-based TUF (with TCP sender segmentation support), or nothing at all (== full reassembly). A smaller number of `key' participants felt that an intermediary framing solution for stock TCP senders was necessary. We proposed COWS-based TUF to try to bring harmony to the spheres, but I'm not hearing the pleasant resonance (piano tuning is an emperical process, right?), so perhaps we didn't get it quite right. Absent any unification of sender segmentation-based and stock TCP framing (perhaps 0-touch sends ARE too much to give up), I'm strongly in the sender segmentation-based framing (TUF) or nothing at all camp. Steph From owner-ips@ece.cmu.edu Wed Jan 9 09:08: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 JAA04006 for ; Wed, 9 Jan 2002 09:08:51 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g09DOcL20079 for ips-outgoing; Wed, 9 Jan 2002 08:24:38 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls20.mediaone.net (chmls20.mediaone.net [24.147.1.156]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g09DObg20075 for ; Wed, 9 Jan 2002 08:24:37 -0500 (EST) Received: from cs.uchicago.edu (h005018030f43.ne.mediaone.net [66.31.16.32]) by chmls20.mediaone.net (8.11.1/8.11.1) with ESMTP id g09DQIx23505 for ; Wed, 9 Jan 2002 08:26:18 -0500 (EST) Message-Id: <200201091326.g09DQIx23505@chmls20.mediaone.net> To: ips@ece.cmu.edu Subject: Re: iSCSI: Markers In-Reply-To: Message from "John Hufferd" of "Sun, 06 Jan 2002 13:57:56 PST." References: Date: Wed, 09 Jan 2002 08:24:32 -0500 From: Stephen Bailey Sender: owner-ips@ece.cmu.edu Precedence: bulk > assuming iWARP is not an available option What John is referring to as iWarp is actually `TUF' (TCP ULP Framing). iWarp is a putative RDMA on IP transports protocol, which is not what we're talking about. All the TCP framing proposals we're discussing have: 1) an in-stream format To this, TUF adds: 2) a TCP sender segmentation behavior The in-stream formats so far are: o fixed-interval markers (FIM) o random key/length headers (TUF's FPDU) o COWS header + marker knockout chain In addition to Julian's COWS proposal, Costa & I also did one: http://www.cs.uchicago.edu/~steph/draft-bailey-tsvwg-cows-00.txt It's substantially similar to Julian's, with a couple differences: o pointers are only forward o payload length is 16-bit length (trivial to make it up to 2^30-1 tho) o payload size is byte-granular o marker is defined a priori (I like Julian's idea of being able to exchange markers if desired---we'd add that) Our COWS was defined as an alternative to (replacement of) TUF's current in-stream format. Compelling benefits of the COWS in-stream format from our standpoint are: o the SAME in-stream format is works with or without TCP sender segmentation support o no chance of a false positive from key/length validation The first point is particularly important. COWS can be used to validate the PDU contaiment property if the TCP sender is TUF-compliant, and it can be used for marker-like (better, actually) resynchronization if the TCP sender is stock. Before the COWS proposal, we always had two different in-stream representations (markers, & key/lengths) for different purposes. The primary disadvantage of the COWS in-stream format is: o prohibits 0-touch software senders I had suggested that if everybody liked COWS, we would update TUF to use it, and even if TUF remains experimental, iSCSI could define the same in-stream format for its framing (replacing markers). That way, there would really be only ONE in-stream format in the universe, though it might be redundantly defined in two places. For iSCSI, a single in-stream format that supports both modified and stock sender approachs seems nice. Implementations can easily migrate from stock to modified TCP senders (ask one of the authors of the TUF draft if you don't understand why modified TCP sender segmentation is good). For the rest of the world it would be nice (essential in my opinion) if the same framing technique could be used for iSCSI and other protocols (e.g. iWarp). System vendors that support iSCSI just might want to support NAS too, which could mean DAFS (on iWarp). Chip vendors CERTAINLY want to maximize return from their TOE investment which means being able support various accelerated protocols with the same hardware. Wouldn't it be stupid if we had a proliferation of framing alternatives just because the world originally seemed flat? The tradeoff of 0-touch versus a single format clearly has powerful arguments pulling either way. I'm personally ambivalent. Mostly, I want to make sure everybody in the iSCSI community is sufficiently informed about what's at stake. Steph From owner-ips@ece.cmu.edu Wed Jan 9 09:51: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 JAA04726 for ; Wed, 9 Jan 2002 09:51:50 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g09E1IL21894 for ips-outgoing; Wed, 9 Jan 2002 09:01: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 (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g09E1Gg21889 for ; Wed, 9 Jan 2002 09:01:16 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jan 2002 09:01:10 -0500 Message-ID: <25369470B6F0D41194820002B328BDD220235E@ATLOPS> From: Eddy Quicksall To: Lakshmi Ramasubramanian , ips@ece.cmu.edu Subject: RE: iSCSI: Format of LUN in iSCSI PDU Date: Wed, 9 Jan 2002 09:01:09 -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 section 3 is talking about integers, not SCSI fields. I think the authors meant for this field to be a SCSI field. So it would be in the order specified by SAM2. Eddy -----Original Message----- From: Lakshmi Ramasubramanian [mailto:nramas@windows.microsoft.com] Sent: Monday, January 07, 2002 3:25 PM To: ips@ece.cmu.edu Subject: iSCSI: Format of LUN in iSCSI PDU Section 3.2.1.6 LUN : The LUN field is 64-bits and it is to be formatted in accordance with [SAM2]. Section 3. iSCSI PDU Formats : Any field appearing in this document assumes that the most significant byte is the lowest numbered byte. So, the first byte, as given in SAM2, should be set in LUN[0] or it should be set in LUN[7]? thanks! -lakshmi From owner-ips@ece.cmu.edu Wed Jan 9 12:18: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 MAA07481 for ; Wed, 9 Jan 2002 12:18:29 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g09G74S29129 for ips-outgoing; Wed, 9 Jan 2002 11:07:04 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from aegis.indstorage.com ([208.132.17.2]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g09G72g29124 for ; Wed, 9 Jan 2002 11:07:03 -0500 (EST) Received: from markb2k (markb2k.indstorage.com [192.168.1.66]) by aegis.indstorage.com (8.11.0/8.11.0) with SMTP id g09G5u723583; Wed, 9 Jan 2002 09:05:56 -0700 Reply-To: From: "Mark Bradley" To: "Stephen Bailey" , Subject: RE: iSCSI: Markers Date: Wed, 9 Jan 2002 09:04:25 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <200201091335.g09DZ7Q04813@chmls06.mediaone.net> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Stephen Bailey > Unfortunately, all the choices are nasty. Long time IETFers would > probably make the point that this is an indication we are trying to do > the wrong thing and should just use a message-based transport :^) > Well, that was the early thinking (pre-pre-BOF and pre-IETF _at all_). The thinking at that time was that generic storage over IP was the goal and that SCSI over TCP/IP would be just a proof of concept. But, that's just water under the bridge, as things change.... -- markb From owner-ips@ece.cmu.edu Wed Jan 9 15:35:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14589 for ; Wed, 9 Jan 2002 15:35:43 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g09InTn06007 for ips-outgoing; Wed, 9 Jan 2002 13:49:29 -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 g09InPV05994; Wed, 9 Jan 2002 13:49:25 -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 TAA65744; Wed, 9 Jan 2002 19:49:15 +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 g09Io18118026; Wed, 9 Jan 2002 19:50:02 +0100 To: "Lakshmi Ramasubramanian" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 9 Jan 2002 20:50:00 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 09/01/2002 20:50:10, Serialize complete at 09/01/2002 20:50:10 Content-Type: multipart/alternative; boundary="=_alternative 0066D57EC2256B3C_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0066D57EC2256B3C_= Content-Type: text/plain; charset="us-ascii" Lakshmi, What is the "first" the MSB or the LSB? If you refer to the 8 byte LUN structure from SAM then LUN[0] is byte 8 in the iSCSI PDU and LUN[7] is byte 15. Julo "Lakshmi Ramasubramanian" Sent by: owner-ips@ece.cmu.edu 08-01-02 11:27 To: cc: Subject: Section 3.2.1.6 LUN : The LUN field is 64-bits and it is to be formatted in accordance with [SAM2]. Section 3. iSCSI PDU Formats : Any field appearing in this document assumes that the most significant byte is the lowest numbered byte. So, the first byte, as given in SAM2, should be set in LUN[0] or it should be set in LUN[7]? thanks! -lakshmi --=_alternative 0066D57EC2256B3C_= Content-Type: text/html; charset="us-ascii"
Lakshmi,

What is the "first" the MSB or the LSB?

If you refer to the 8 byte LUN structure from SAM then LUN[0] is byte 8 in the iSCSI PDU and LUN[7] is byte 15.


Julo


"Lakshmi Ramasubramanian" <nramas@windows.microsoft.com>
Sent by: owner-ips@ece.cmu.edu

08-01-02 11:27

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

       


Section 3.2.1.6 LUN :

The LUN field is 64-bits and it is to be
formatted in accordance with [SAM2].

Section 3. iSCSI PDU Formats :

Any field appearing in this document assumes that the most
significant byte is the lowest numbered byte.

So, the first byte, as given in SAM2, should be set in
LUN[0] or it should be set in LUN[7]?

thanks!
-lakshmi

--=_alternative 0066D57EC2256B3C_=-- From owner-ips@ece.cmu.edu Wed Jan 9 15:39: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 PAA14629 for ; Wed, 9 Jan 2002 15:39:44 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g09JtOA09795 for ips-outgoing; Wed, 9 Jan 2002 14:55:24 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from parmenion.hosting.pacbell.net (parmenion.hosting.pacbell.net [216.100.98.31]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g09JtMV09787 for ; Wed, 9 Jan 2002 14:55:22 -0500 (EST) Received: from gwendal.corp.silverbacksystems.com ([65.172.158.93]) by parmenion.hosting.pacbell.net id OAA19858; Wed, 9 Jan 2002 14:55:18 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Content-Type: text/plain; charset="iso-8859-1" From: Gwendal Grignou To: ips@ece.cmu.edu Subject: IscsiSessionStatsEntry MIB OBject contents Date: Wed, 9 Jan 2002 11:54:15 -0800 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <0201091154150J.01222@gwendal.corp.silverbacksystems.com> Content-Transfer-Encoding: 8bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hello, I have some questions regarding the contents of IscsiSessionStatsEntry : iscsiSsnRspPdus : "The count of Response PDUs that flowed on this session instance." Does it mean only SCSI response PDUs, or does it include "Login Response", "Task Managment Response", ... (almost everything but Data In and Data Out PDUs)? iscsiSsnCmdPdus : "The count of Command PDUs that flowed on this session instance." Does it mean SCSI Command PDUs only or does it include "Login Request", "Task Managment Request", ... iscsiSsnTxDataOctets : "The count of data octets that were transmitted by the local iSCSI node on this session instance." Does it means only Data sent for SCSI command (Immediate Data and Data Out), or all payload sent with any iSCSI request (including Nop Out) ? Same symetric question for iscsiSsnRxDataOctets. Regards, Gwendal. From owner-ips@ece.cmu.edu Wed Jan 9 18:29: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 SAA20439 for ; Wed, 9 Jan 2002 18:29:32 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g09MimX20318 for ips-outgoing; Wed, 9 Jan 2002 17:44:48 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g09MilV20312 for ; Wed, 9 Jan 2002 17:44:47 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA344548; Wed, 9 Jan 2002 17:41:41 -0500 Received: from d04nms25.raleigh.ibm.com (d04nms25.raleigh.ibm.com [9.27.5.77]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g09Midc287652; Wed, 9 Jan 2002 17:44:40 -0500 Importance: Normal Subject: Re: IscsiSessionStatsEntry MIB OBject contents To: Gwendal Grignou Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Thomas McSweeney" Date: Wed, 9 Jan 2002 17:44:38 -0500 X-MIMETrack: Serialize by Router on D04NMS25/04/M/IBM(Release 5.0.8 |June 18, 2001) at 01/09/2002 05:44:39 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Gwendal, Login PDU and Login Response PDU are not counted in iscsiSsnRspPdus or iscsiSsnCmdPdus because the session is not instantiated until full feature phase (after Login Response). There are separate counters for Login attempts - see the ...LoginStatsEntry definitions. All other PDUs are counted, including Data In and Data Out. I suppose we could discuss whether Logout and Logout Response should be counted, since they have separate counters in the MIB as well (see the ...LogoutStatsEntry definitions). As for the Data Octet counters, the easiest interpretation is that it refers to all octets in all PDU Data Segments. I think the count will be most useful if it counts only the bytes of data actually read from or written to the SCSI device (e.g., it includes only the Data Segments of Data Out and Data In PDUs). However, I suspect that the sum total of all other PDU Data Segments will be so small compared to the Data Out and Data In that it would not hurt to lump those in. Tom McSweeney iSCSI Development, Storage Systems Group, IBM Email: rf42tpme@us.ibm.com Phone: (USA) 919-254-5634 (tie line: 444-5634) Fax: (USA) 919-254-0391 (tie line: 444-0391) From owner-ips@ece.cmu.edu Wed Jan 9 18:33: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 SAA20548 for ; Wed, 9 Jan 2002 18:33:04 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g09NFIn22164 for ips-outgoing; Wed, 9 Jan 2002 18:15:18 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from intens2.pdcint (fw.siliquent.com [212.143.51.98]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g09NBkV21948 for ; Wed, 9 Jan 2002 18:11:46 -0500 (EST) Received: by INTENS2 with Internet Mail Service (5.5.1960.3) id ; Thu, 10 Jan 2002 01:14:26 +0200 Message-ID: From: Yaron Lederman To: "T10 (E-mail)" , "Ips (E-mail)" Cc: "David Black (E-mail)" Subject: SCSI MIB document locations Date: Thu, 10 Jan 2002 01:14:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk The first version of the SCSI MIB and a SCSI MIB UML object model is available at ftp://ftpeng.cisco.com/mbakke/ips/scsi-mib/. Please note that there might be differences between the object model and the MIB draft (after all - it models the MIB). Yaron From owner-ips@ece.cmu.edu Wed Jan 9 18: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 SAA20564 for ; Wed, 9 Jan 2002 18:33:59 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g09NNDo22552 for ips-outgoing; Wed, 9 Jan 2002 18:23:13 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from intens2.pdcint (fw.siliquent.com [212.143.51.98]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g09NFhV22184 for ; Wed, 9 Jan 2002 18:15:43 -0500 (EST) Received: by INTENS2 with Internet Mail Service (5.5.1960.3) id ; Thu, 10 Jan 2002 01:18:23 +0200 Message-ID: From: Yaron Lederman To: "T10 (E-mail)" , "Ips (E-mail)" Subject: SCSI MIB Input request Date: Thu, 10 Jan 2002 01:18:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk We would like to solicit input regarding the current statistics gathered in implementations for the following SCSI entities: Initiator, Target and Logical Units From owner-ips@ece.cmu.edu Wed Jan 9 21:01:22 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24446 for ; Wed, 9 Jan 2002 21:01:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0A0Ueg25847 for ips-outgoing; Wed, 9 Jan 2002 19:30:40 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from fw-202 (asbestos.brocade.com [63.121.140.244]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g0A0UcV25843 for ; Wed, 9 Jan 2002 19:30:38 -0500 (EST) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id QAA03848; Wed, 9 Jan 2002 16:30:00 -0800 (PST) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jan 2002 16:30:00 -0800 Message-ID: From: Robert Snively To: "'Black_David@emc.com'" , roweber@acm.org, ips@ece.cmu.edu Subject: RE: FCIP: Short Frame Security Solution Proposal Date: Wed, 9 Jan 2002 16:29:59 -0800 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk David, In poking through the relevant text of our latest author's draft (to be published early next week as an IETF draft), I found the following text, which I would have imagined would have addressed your concerns without any requirement to document the particular example you have hypothesized. This one is part of the description of the authentication procedure for creating additional connections. Warning: The authentication mechanism described here and in FC-BB-2 [4] is not designed to thwart sophisticated security threats. The IP security mechanisms described in section 9 should be enabled in environments where security threats are suspected. One of the reasons I would be reluctant to document the special case you have described is that, given the same kind of security threat you have described, there are probably a number of other cases with equal exposure if you were to choose to operate without turning on the appropriate IPSec security features. Bob > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Tuesday, January 08, 2002 2:58 PM > To: roweber@acm.org; ips@ece.cmu.edu > Subject: RE: FCIP: Short Frame Security Solution Proposal > > > The timeout helps, but doesn't completely stop the race. > Rather than alluding to its existence, I would explain the > attack (see nonce on one connection, send it on another) > and say that use of ESP confidentiality is the countermeasure > when this is deemed to be an important risk. > > Thanks, > --David > > > -----Original Message----- > > From: Ralph Weber [mailto:ralphoweber@compuserve.com] > > Sent: Monday, January 07, 2002 12:25 PM > > To: IPS Reflector > > Subject: Re: FCIP: Short Frame Security Solution Proposal > > > > > > David, > > > > 2 out of your 3 comments pertain to the content of FC-BB-2 > > and as such incorporating them in something must wait for > > the proposal to introduce the other half of this in FC-BB-2. > > My intention is that said proposal will be finished in > > time to meet the two-week rule for the T11 meeting in > > Huntington Beach. I will announce the availability of > > the proposal on this reflector. > > > > The one comment that suggests adding text to the FCIP > > draft is as follows: > > > > > > > - Some words will need to be added about a nasty race > > > > > condition in which the attacker opens up a connection up > > > > > to the point of sending the short frame, watches a real > > > > > connection get set up to the point that the attacker sees > > > > > the short frame on the real connection; the attacker > > > > > extracts and uses the nonce, and TCP tricks (e.g., corrupt > > > > > the TCP packet containing the nonce to cause a checksum > > > > > failure, or send a well-timed RST). The short answer to > > > > > dealing with this is "use IKE and also ESP encryption if > > > > > warranted" when this sort of attack is a concern. > > > > > > > > Would it not be better to include a broad caution along the > > > > lines of: > > > > > > > > Warning: The authentication mechanism described here is not > > > > designed to thwart sophisticated security threats. The IP > > > > security mechanisms described in section 9 should be enabled > > > > in environments where security threats are suspected. > > > > > > Both. The race is sufficiently related to the WWN short frame > > > that it should be specifically mentioned. There are other > > > authentication mechanisms that are not subject to this race. > > > > Interestingly enough, this is need not be as wide open a race > > as one might first think because the recipient of the TCP > > connect request may timeout and close the connection if the > > SF is not received in 90 seconds or longer. > > > > None the less, words about the race condition have been added > > to the FCIP revision in development. The specific new text > > (and the paragraph preceding it) are as follows: > > > > * The FCIP Entity MAY apply a timeout of not less than 90 seconds > > * to the waiting for the FCIP Special Frame bytes and if the timeout > > * expires the FCIP Entity SHALL close the TCP Connection and notify > > * the FC Entity with the reason for the closure. > > * > > * Note: One method for attacking the security of the FCIP Link > > * formation process depends on keeping a TCP connect request open > > * without sending an FCIP Special Frame. Implementations should bear > > * this in mind in the handling of TCP connect requests > where the FCIP > > * Special Frame is not sent in a timely manner. > > > > Thanks. > > > > Ralph... > > > > Black_David@emc.com wrote: > > > > > Ralph, > > > > > > > Black_David@emc.com wrote [responses embedded]: > > > > > > > > > I think this is a workable approach. A few comments: > > > > > > > > > > - There are a dependencies among a number of components > > > > > on who supports what, some of which are under T11's > > > > > control. If it turns out that the T11 aspects of this > > > > > are not mandatory to implement, ... > > > > > > [... snip ...] > > > > > > > > I think multiple TCP > > > > > connections in a single FCIP session need to be disallowed > > > > > if this authentication cannot be performed by the > > > > > implementation (i.e., is not implemented) - putting in a > > > > > note to this effect regardless of what T11 does might be > > > > > a good idea to decouple FCIP from FC-BB-2 in this area. > > > > > > > > As currently worded, the FCIP Entity ALWAYS asks the FC Entity > > > > for authentication of a second to n-th connection and the > > > > FC Entity ALWAYS responds, yes or no. I fail to see how a > > > > note such as the one suggested would be viewed as anything > > > > more than advisory to FC-BB-2. The FCIP Entity has (in theory) > > > > no knowledge of how much or how little work the FC Entity > > > > does to generate its response to the request for connection > > > > authentication. > > > > > > What I had in mind was advice to implementers that if the FC > > > Entity does not check the nonce over the initial connection with > > > its peer FC entity, then the answer to the FCIP entity SHOULD > > > be "no". This could also be considered as advice to BB-2. > > > > > > > > - Any nonce must be validated ("yes, that's my connection") > > > > > at most once. If the FC Entity on the other end of the > > > > > first connection is capable of saying "yes" twice to the > > > > > same nonce, there's an obvious replay attack. > > > > > > > > I had sought to cut this type of attack off at the SF level > > > > (long before the FC Entity at the other end gets a nonce > > > > to validate) with the following words. > > > > > > > > }...} To further increase the difficulty of snooping > > > > }...} TCP connections, an FCIP Entity that receives > > > > }...} a duplicate nonce shall close the connection > > > > }...} on which that nonce was received immediately > > > > }...} without causing the SW_ILS to be sent. > > > > > > > > To me, this seems superior for a couple of reasons: > > > > > > > > o It places the requirement in FCIP, closer to the source > > > > of the problem. > > > > o It eliminates an unnecessary authentication transaction > > > > with the FC Entity at the other end. > > > > > > Ok, but also see the discussion below on the "who presents > > > the nonce first" race. > > > > > > > > - Some words will need to be added about a nasty race > > > > > condition in which the attacker opens up a connection up > > > > > to the point of sending the short frame, watches a real > > > > > connection get set up to the point that the attacker sees > > > > > the short frame on the real connection; the attacker > > > > > extracts and uses the nonce, and TCP tricks (e.g., corrupt > > > > > the TCP packet containing the nonce to cause a checksum > > > > > failure, or send a well-timed RST). The short answer to > > > > > dealing with this is "use IKE and also ESP encryption if > > > > > warranted" when this sort of attack is a concern. > > > > > > > > Would it not be better to include a broad caution along the > > > > lines of: > > > > > > > > Warning: The authentication mechanism described here is not > > > > designed to thwart sophisticated security threats. The IP > > > > security mechanisms described in section 9 should be enabled > > > > in environments where security threats are suspected. > > > > > > Both. The race is sufficiently related to the WWN short frame > > > that it should be specifically mentioned. There are other > > > authentication mechanisms that are not subject to this race. > > > > > > > > - I think it's necessary to authentication the first TCP > > > > > connection (up to FCAP or whatever) before sending the ILS > > > > > that would authenticate a subsequent one, but details beyond > > > > > that (e.g., can one send the SYN for the second TCP > connection > > > > > before the first connection authenticates) are > probably up to > > > > > implementations. > > > > > > > > I had hoped to have covered the case I think is being described > > > > above by the following language (note the words "previously > > > > authenticated"): > > > > > > > > }...} In situations where security > > > > }...} risks are possible, the FC Entity shall transmit > > > > }...} the information provided by the FCIP Entity via a new > > > > }...} SW_ILS on a previously authenticated TCP connection > > > > }...} (FCIP Data Engine) enabled for Class F frames. > > > > > > > > "Previously authenticated" may be vague, but it is intended to > > > > cover both authentication via FCAP and authentication against > > > > another F Class connection using this process. > > > > > > > > Consider that case where a long lived FCIP Link starts out > > > > with one F Class connection. Next, using the authentication > > > > process described in this proposal and two or more Class 2/3 > > > > connections are added to the FCIP Link. As time goes by the F > > > > Class connection becomes unreliable and the Entities at both > > > > ends decide to close it and switch one of the Class 2/3 > > > > connections to Class F service. > > > > > > > > The connection switched to F Class service has been duly > > > > authenticated, but not by FCAP. It seems perfectly reasonable > > > > that the switched F Class connection can serve to authenticate > > > > new connect requests. > > > > > > Yes, "previously authenticated" is a bit vague. This discussion > > > is fine, and adding the example from the discussion above would be > > > helpful. > > > > > > Thanks, > > > --David > > > > > > --------------------------------------------------- > > > David L. Black, Senior Technologist > > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > > > black_david@emc.com Cell: +1 (978) 394-7754 > > > --------------------------------------------------- > > > From owner-ips@ece.cmu.edu Thu Jan 10 00:06: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 AAA00373 for ; Thu, 10 Jan 2002 00:06:40 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0A4LTl06091 for ips-outgoing; Wed, 9 Jan 2002 23:21:29 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from homa.asicdesigners.com (sac-wan-d-203.sac.dsl.cerfnet.com [63.242.35.203]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g0A4LSj06086 for ; Wed, 9 Jan 2002 23:21:28 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: iSCSI: Markers Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Wed, 9 Jan 2002 20:21:26 -0800 Message-ID: Thread-Topic: iSCSI: Markers Thread-Index: AcGZGQD7z25dJNl0RLajxQhPi+XxLAAaCsxQ From: "Glenn Dasmalchi" To: "Stephen Bailey" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g0A4LSj06088 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit I agree with Steph's conclusion on this one. The PDU Containment Property of TUF is a good fit for high-bandwidth direct placement receive hardware. If COWS *with* TUF-style segmentation is deemed impractical, then I think it's better to have PDU containment in TCP segments (with random key/length headers) than fixed interval markers. I understood David's earlier posting about not allowing normative references to experimental drafts (i.e. TUF), but I don't understand how this precludes using the technique as the iSCSI framing mechanism. If we decided it was the right technique for iSCSI, couldn't we just lift the content and put it in the iSCSI draft? -Glenn > -----Original Message----- > From: Stephen Bailey [mailto:steph@cs.uchicago.edu] > Sent: Wednesday, January 09, 2002 5:34 AM > To: ips@ece.cmu.edu > Subject: Re: iSCSI: Markers > > > > As for COWS, it's clearly nasty. Even if you're doing CRC, > it adds a > > significant increment to the processing cost. > > Unfortunately, all the choices are nasty. Long time IETFers would > probably make the point that this is an indication we are trying to do > the wrong thing and should just use a message-based transport :^) > > That said, one position that many people thought was the least nasty > was key/length-based TUF (with TCP sender segmentation support), or > nothing at all (== full reassembly). A smaller number of `key' > participants felt that an intermediary framing solution for stock TCP > senders was necessary. > > We proposed COWS-based TUF to try to bring harmony to the spheres, but > I'm not hearing the pleasant resonance (piano tuning is an emperical > process, right?), so perhaps we didn't get it quite right. > > Absent any unification of sender segmentation-based and stock TCP > framing (perhaps 0-touch sends ARE too much to give up), I'm strongly > in the sender segmentation-based framing (TUF) or nothing at all camp. > > Steph > From owner-ips@ece.cmu.edu Thu Jan 10 02:30: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 CAA11158 for ; Thu, 10 Jan 2002 02:30:00 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0A6gBh11658 for ips-outgoing; Thu, 10 Jan 2002 01:42:11 -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 g0A6g9j11654 for ; Thu, 10 Jan 2002 01:42:09 -0500 (EST) Received: from somesh ([65.172.158.93]) by cleitus.hosting.pacbell.net id BAA11127; Thu, 10 Jan 2002 01:42:07 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Reply-To: From: "Somesh Gupta" To: Subject: RE: iSCSI: Markers Date: Wed, 9 Jan 2002 22:40:17 -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.00.2919.6700 Importance: Normal In-Reply-To: <200201091326.g09DQIx23505@chmls20.mediaone.net> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit COWS used in conjunction with "framing" allows for the "packetization" of TCP, and a lot of good things follow from that. COWS and framing allow complete processing of the segment as a single entity - one PDU, processed in a pipelined without recursion, and done. Markers enable no such capability. They actually make things worse by having to be inserted or removed as extra bytes in the stream. Markers and CRC interact very poorly since the markers are part of the data stream, but not part of the CRC. Markers can only be processed in the context of the connection state. COWS could actually help locate the state. There seem to be two main motivations to push markers 1. laptops and desktops using unchanged TCP/IP stacks and running iSCSI. a. when do we think customers will really deploy iSCSI at desktops/laptops without security and make their entire storage vulnerable? If of course, security is deployed, then COWS should be minor additional burden b. If we have lots of spare cycles, does it matter anyway c. even if the first generation does not have the capability, the second generation of iSCSI implementation may implement the TCP changes required for security - especially if it mandatory 2. decide something now and sooner rather than better. Given the substantial lack of evidence whether markers are useful at all, and the significant promise of COWS/ULP framing, I think it would be ill-advised to try to push this one. I think we should take this as part of our next phase. If we do want something now, I vote for COWS/ULP. Even if it is on the experimental track, we can always specify it as part of iSCSI. COWS/ULP really allows the cheaper and more widely applicable adapters that we would all like to see. Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Stephen Bailey > Sent: Wednesday, January 09, 2002 5:25 AM > To: ips@ece.cmu.edu > Subject: Re: iSCSI: Markers > > > > assuming iWARP is not an available option > > What John is referring to as iWarp is actually `TUF' (TCP ULP > Framing). iWarp is a putative RDMA on IP transports protocol, which > is not what we're talking about. > > All the TCP framing proposals we're discussing have: > > 1) an in-stream format > > To this, TUF adds: > > 2) a TCP sender segmentation behavior > > The in-stream formats so far are: > o fixed-interval markers (FIM) > o random key/length headers (TUF's FPDU) > o COWS header + marker knockout chain > > In addition to Julian's COWS proposal, Costa & I also did one: > > http://www.cs.uchicago.edu/~steph/draft-bailey-tsvwg-cows-00.txt > > It's substantially similar to Julian's, with a couple differences: > > o pointers are only forward > o payload length is 16-bit length (trivial to make it up to 2^30-1 tho) > o payload size is byte-granular > o marker is defined a priori (I like Julian's idea of being able > to exchange markers if desired---we'd add that) > > Our COWS was defined as an alternative to (replacement of) TUF's > current in-stream format. Compelling benefits of the COWS in-stream > format from our standpoint are: > > o the SAME in-stream format is works with or without TCP sender > segmentation support > o no chance of a false positive from key/length validation > > The first point is particularly important. COWS can be used to > validate the PDU contaiment property if the TCP sender is > TUF-compliant, and it can be used for marker-like (better, actually) > resynchronization if the TCP sender is stock. Before the COWS > proposal, we always had two different in-stream representations > (markers, & key/lengths) for different purposes. > > The primary disadvantage of the COWS in-stream format is: > > o prohibits 0-touch software senders > > I had suggested that if everybody liked COWS, we would update TUF to > use it, and even if TUF remains experimental, iSCSI could define the > same in-stream format for its framing (replacing markers). That way, > there would really be only ONE in-stream format in the universe, > though it might be redundantly defined in two places. > > For iSCSI, a single in-stream format that supports both modified and > stock sender approachs seems nice. Implementations can easily migrate > from stock to modified TCP senders (ask one of the authors of the TUF > draft if you don't understand why modified TCP sender segmentation is > good). > > For the rest of the world it would be nice (essential in my opinion) > if the same framing technique could be used for iSCSI and other > protocols (e.g. iWarp). System vendors that support iSCSI just might > want to support NAS too, which could mean DAFS (on iWarp). Chip > vendors CERTAINLY want to maximize return from their TOE investment > which means being able support various accelerated protocols with the > same hardware. Wouldn't it be stupid if we had a proliferation of > framing alternatives just because the world originally seemed flat? > > The tradeoff of 0-touch versus a single format clearly has powerful > arguments pulling either way. I'm personally ambivalent. Mostly, I > want to make sure everybody in the iSCSI community is sufficiently > informed about what's at stake. > > Steph > From owner-ips@ece.cmu.edu Thu Jan 10 04:55: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 EAA12357 for ; Thu, 10 Jan 2002 04:55:29 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0A9RVa17723 for ips-outgoing; Thu, 10 Jan 2002 04:27:31 -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 g0A9RQj17716 for ; Thu, 10 Jan 2002 04:27: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 EAA107120 for ; Thu, 10 Jan 2002 04:24:25 -0500 Received: from d03nm014.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 g0A9ROA99416 for ; Thu, 10 Jan 2002 02:27:24 -0700 X-Priority: 1 (High) Importance: Normal Subject: iSCSI Markers To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Thu, 10 Jan 2002 01:26:42 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 01/10/2002 02:27:24 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I stand corrected on the Name, of TUFs and not iWARP. The draft that will probably go experimental (TUFs) is a framing item that places PDUs at the beginning of TCP Segments (hence TCP Mods). We can not just take TUFs and add that to our iSCSI protocol since our charter prevents us from doing that. I see no relationship to COWS, except both have an 8 byte header. If you have TUFs, you do not need to have Word Stuffing. The problem with COWS is not is header it is the Word Stuffing and the Replacement Pointers. You have FIM or COWS, neither one is useful with TUFs, except that they have a similar header with COWS, not is hardly a reason to put up with the SCANNING and Stuffing of COWS Pointers in the Data. This is especially since depending on the development approach you may find the Pointers pointing the wrong way for either sending or receiving in some HW pipelining designs. And it is always a poorer approach then FIM in Software. I think folks want TUFs but we do not have that option now. And COWS does NOT bring that any closer any quicker. . . . 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 Thu Jan 10 04:55: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 EAA12376 for ; Thu, 10 Jan 2002 04:55:40 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0A973216979 for ips-outgoing; Thu, 10 Jan 2002 04:07:03 -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 g0A970j16962 for ; Thu, 10 Jan 2002 04:07:01 -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 EAA243912; Thu, 10 Jan 2002 04:04:00 -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 g0A96rg87358; Thu, 10 Jan 2002 02:06:58 -0700 Importance: Normal Subject: RE: iSCSI: Markers To: Cc: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Thu, 10 Jan 2002 01:06:10 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 01/10/2002 02:06:58 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Folks we can not add TUFs to our iSCSI protocol since it requires TCP/IP changes. Our draft says that we WILL NOT work on Modifications to internet transport protocols, Hence, bringing TUFs into our draft is not doable. I think I made the point about Desktops and laptops on my kick off note, they use NFS today and think things are fine. They will accept this in the future. (Right or Wrong). . . . 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 01/09/2002 10:40:17 PM Please respond to Sent by: owner-ips@ece.cmu.edu To: cc: Subject: RE: iSCSI: Markers COWS used in conjunction with "framing" allows for the "packetization" of TCP, and a lot of good things follow from that. COWS and framing allow complete processing of the segment as a single entity - one PDU, processed in a pipelined without recursion, and done. Markers enable no such capability. They actually make things worse by having to be inserted or removed as extra bytes in the stream. Markers and CRC interact very poorly since the markers are part of the data stream, but not part of the CRC. Markers can only be processed in the context of the connection state. COWS could actually help locate the state. There seem to be two main motivations to push markers 1. laptops and desktops using unchanged TCP/IP stacks and running iSCSI. a. when do we think customers will really deploy iSCSI at desktops/laptops without security and make their entire storage vulnerable? If of course, security is deployed, then COWS should be minor additional burden b. If we have lots of spare cycles, does it matter anyway c. even if the first generation does not have the capability, the second generation of iSCSI implementation may implement the TCP changes required for security - especially if it mandatory 2. decide something now and sooner rather than better. Given the substantial lack of evidence whether markers are useful at all, and the significant promise of COWS/ULP framing, I think it would be ill-advised to try to push this one. I think we should take this as part of our next phase. If we do want something now, I vote for COWS/ULP. Even if it is on the experimental track, we can always specify it as part of iSCSI. COWS/ULP really allows the cheaper and more widely applicable adapters that we would all like to see. Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Stephen Bailey > Sent: Wednesday, January 09, 2002 5:25 AM > To: ips@ece.cmu.edu > Subject: Re: iSCSI: Markers > > > > assuming iWARP is not an available option > > What John is referring to as iWarp is actually `TUF' (TCP ULP > Framing). iWarp is a putative RDMA on IP transports protocol, which > is not what we're talking about. > > All the TCP framing proposals we're discussing have: > > 1) an in-stream format > > To this, TUF adds: > > 2) a TCP sender segmentation behavior > > The in-stream formats so far are: > o fixed-interval markers (FIM) > o random key/length headers (TUF's FPDU) > o COWS header + marker knockout chain > > In addition to Julian's COWS proposal, Costa & I also did one: > > http://www.cs.uchicago.edu/~steph/draft-bailey-tsvwg-cows-00.txt > > It's substantially similar to Julian's, with a couple differences: > > o pointers are only forward > o payload length is 16-bit length (trivial to make it up to 2^30-1 tho) > o payload size is byte-granular > o marker is defined a priori (I like Julian's idea of being able > to exchange markers if desired---we'd add that) > > Our COWS was defined as an alternative to (replacement of) TUF's > current in-stream format. Compelling benefits of the COWS in-stream > format from our standpoint are: > > o the SAME in-stream format is works with or without TCP sender > segmentation support > o no chance of a false positive from key/length validation > > The first point is particularly important. COWS can be used to > validate the PDU contaiment property if the TCP sender is > TUF-compliant, and it can be used for marker-like (better, actually) > resynchronization if the TCP sender is stock. Before the COWS > proposal, we always had two different in-stream representations > (markers, & key/lengths) for different purposes. > > The primary disadvantage of the COWS in-stream format is: > > o prohibits 0-touch software senders > > I had suggested that if everybody liked COWS, we would update TUF to > use it, and even if TUF remains experimental, iSCSI could define the > same in-stream format for its framing (replacing markers). That way, > there would really be only ONE in-stream format in the universe, > though it might be redundantly defined in two places. > > For iSCSI, a single in-stream format that supports both modified and > stock sender approachs seems nice. Implementations can easily migrate > from stock to modified TCP senders (ask one of the authors of the TUF > draft if you don't understand why modified TCP sender segmentation is > good). > > For the rest of the world it would be nice (essential in my opinion) > if the same framing technique could be used for iSCSI and other > protocols (e.g. iWarp). System vendors that support iSCSI just might > want to support NAS too, which could mean DAFS (on iWarp). Chip > vendors CERTAINLY want to maximize return from their TOE investment > which means being able support various accelerated protocols with the > same hardware. Wouldn't it be stupid if we had a proliferation of > framing alternatives just because the world originally seemed flat? > > The tradeoff of 0-touch versus a single format clearly has powerful > arguments pulling either way. I'm personally ambivalent. Mostly, I > want to make sure everybody in the iSCSI community is sufficiently > informed about what's at stake. > > Steph > From owner-ips@ece.cmu.edu Thu Jan 10 12:11: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 MAA19410 for ; Thu, 10 Jan 2002 12:11:40 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0AGElp16599 for ips-outgoing; Thu, 10 Jan 2002 11:14:47 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lysimachus.hosting.pacbell.net (lysimachus.hosting.pacbell.net [216.100.98.17]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0AGEij16595 for ; Thu, 10 Jan 2002 11:14:45 -0500 (EST) Received: from gwendal.corp.silverbacksystems.com ([65.172.158.93]) by lysimachus.hosting.pacbell.net id LAA10081; Thu, 10 Jan 2002 11:11:05 -0500 (EST) [ConcentricHost SMTP Relay 1.7] Content-Type: text/plain; charset="iso-8859-1" From: Gwendal Grignou To: "Thomas McSweeney" Subject: Re: iSCSI : IscsiSessionStatsEntry MIB OBject contents Date: Thu, 10 Jan 2002 08:09:51 -0800 X-Mailer: KMail [version 1.2] Cc: ips@ece.cmu.edu References: In-Reply-To: MIME-Version: 1.0 Message-Id: <02011008095100.12881@gwendal.corp.silverbacksystems.com> Content-Transfer-Encoding: 8bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Thomas, I think the definition of MIBs fields should be more precise, so that all initiators and targets will store the same information, to allow useful comparison. My comments inline : > Login PDU and Login Response PDU are not counted in iscsiSsnRspPdus or > iscsiSsnCmdPdus because the session is not instantiated until full feature > phase (after Login Response). I don't see why we should not count them. Within the session object, you have connection objects, each of them with "iscsiConnectionAttributesEntry". One of the fields of this sequence is " iscsiCxnState", which can be "login",... So as soon as a connection is established at TCP level, the connection object (and the session object it belongs to) should be instantiated. > There are separate counters for Login > attempts - see the ...LoginStatsEntry definitions. Those counters do not count the PDUs exchanged between initiator and target, but store the result of each login attempts. > All other PDUs are > counted, including Data In and Data Out. I suppose we could discuss > whether Logout and Logout Response should be counted, since they have > separate counters in the MIB as well (see the ...LogoutStatsEntry > definitions). > As for the Data Octet counters, the easiest interpretation is that it > refers to all octets in all PDU Data Segments. I think the count will be > most useful if it counts only the bytes of data actually read from or > written to the SCSI device (e.g., it includes only the Data Segments of > Data Out and Data In PDUs). However, I suspect that the sum total of all > other PDU Data Segments will be so small compared to the Data Out and Data > In that it would not hurt to lump those in. Well, to have a clear definition would ensure the counters for a given session have the same value on both the target and the initiator. Gwendal. From owner-ips@ece.cmu.edu Thu Jan 10 12:14:08 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19477 for ; Thu, 10 Jan 2002 12:14:08 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0AGOCV17268 for ips-outgoing; Thu, 10 Jan 2002 11:24:12 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sandmail.sandburst.com (sandmail.sandburst.com [216.57.132.42]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0AGOBj17264 for ; Thu, 10 Jan 2002 11:24:11 -0500 (EST) To: ips@ece.cmu.edu Subject: Re: iSCSI: Markers In-Reply-To: Message from "Glenn Dasmalchi" of "Wed, 09 Jan 2002 20:21:26 PST." References: Date: Thu, 10 Jan 2002 11:23:49 -0500 From: Stephen Bailey Message-Id: <20020110162354.B835D4E99@sandmail.sandburst.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk > If we decided it was the right technique for iSCSI, couldn't we just > lift the content and put it in the iSCSI draft? From a standardization standpoint, it's like JohnH said. iSCSI is not chartered to do anything that modifies the transport. Even if it were (which it isn't) the `experimental stigma' of TUF would certainly spread to iSCSI if iSCSI ingested TUF in toto. The allure of COWS is that iSCSI CAN specify the in-stream format without saying anything about TCP segmentation---COWS in-stream format solves the same problem as markers. If iSCSI does that, it's a tiny step, for implementations that can take it, to add TUF-compliant TCP segmentation & PDU containment processing. What would be bad is if the `performance community' (RDMA, iSCSI & whomever else) decided that COWS is the best general solution to this problem, and iSCSI chose a variant of COWS that didn't work for other applications (current & future). Basically, the choices, as I see them are: o nothing, FIM, COWS for unmodified senders o key/length or COWS for TUF-compliant senders The key questions to make the choices come down to: 1) Is PDU containment `worth it'? 2) Is resynching in the absence of PDU containment `worth it'? 3) Is 0-touch send for software clients `worth it'? Most seem to strongly believe that PDU containment is worth it but there are some experienced, noteworthy objectors (e.g. Jim Williams). If you don't believe PDU containment is sufficiently beneficial, then you simply don't bother with TUF-compliant senders. I have no idea what `most' think for 2) & 3), but I can speak for myself. I don't think resynching in the absence of PDU containment is worth it. That implies that I'd take nothing over FIM. It also implies that I'd take nothing over COWS w/o a TUF sender, except that if the TUF sender approach uses COWS, having COWS in-stream is `free'. I'm undecided on whether 0-touch send for software clients is `worth it'. If yes, I'd take key/length for a TUF sender. If no, I'd take COWS. So the only free variable in my position is whether 0-touch software senders are worth it. I don't have the data (I'm sure you're wondering why that's stopping me on this point, and not the others :^) If yes, it's `nothing + key/length'. If no, it's `COWS + COWS'. Steph From owner-ips@ece.cmu.edu Thu Jan 10 12:14:30 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19494 for ; Thu, 10 Jan 2002 12:14:29 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0AGVlZ17719 for ips-outgoing; Thu, 10 Jan 2002 11:31:47 -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 g0AGVjj17714 for ; Thu, 10 Jan 2002 11:31:45 -0500 (EST) Received: from deneb.dev.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g0AGVa628570; Thu, 10 Jan 2002 11:31:36 -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 g0AGVWt06172; Thu, 10 Jan 2002 11:31:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15421.49636.699210.573299@pkoning.dev.equallogic.com> Date: Thu, 10 Jan 2002 11:31:32 -0500 (EST) From: Paul Koning To: hufferd@us.ibm.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI Markers References: 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 >>>>> "John" == John Hufferd writes: John> You have FIM or COWS, neither one is useful with TUFs, except John> that they have a similar header with COWS, not is hardly a John> reason to put up with the SCANNING and Stuffing of COWS John> Pointers in the Data. This is especially since depending on John> the development approach you may find the Pointers pointing the John> wrong way for either sending or receiving in some HW pipelining John> designs. And it is always a poorer approach then FIM in John> Software. Agreed. FIM is nasty, COWS is nastier. Both may require a memory to memory copy, but at least FIM doesn't require you to examine the data you're moving. Clearly, the real answer is a transport layer that isn't a byte stream transport. TP4 or SCTP, anyone? :-) paul From owner-ips@ece.cmu.edu Thu Jan 10 13:28: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 NAA20775 for ; Thu, 10 Jan 2002 13:27:59 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0AHUqv21292 for ips-outgoing; Thu, 10 Jan 2002 12:30:52 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from homa.asicdesigners.com (sac-wan-d-203.sac.dsl.cerfnet.com [63.242.35.203]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g0AHUoj21288 for ; Thu, 10 Jan 2002 12:30:51 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: iSCSI Markers X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Thu, 10 Jan 2002 09:30:49 -0800 Message-ID: Thread-Topic: iSCSI Markers Thread-Index: AcGZvy8bOurQKhHNSrajoDjTNhOJgwAOoUig From: "Glenn Dasmalchi" To: "John Hufferd" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g0AHUpj21289 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit > -----Original Message----- > From: John Hufferd [mailto:hufferd@us.ibm.com] > Sent: Thursday, January 10, 2002 1:27 AM > To: ips@ece.cmu.edu > Subject: iSCSI Markers > > I see no relationship to COWS, except both have an 8 byte > header. If you > have TUFs, you do not need to have Word Stuffing. The > problem with COWS is > not is header it is the Word Stuffing and the Replacement Pointers. > The random key marker approach in the TUF draft has a non-zero probability of generating a "false positive" in theory (requires resegmenting middle boxes + aliased data + exact length resegmentation, etc.). Personally I think the probability is so low as to not be a consideration, but a COWS approach using TUF-style segmentation does address the issue. The point about the iSCSI charter is interesting, do others feel that the segmentation requirements for TUF/PDU Alignment disqualify it from consideration for iSCSI? -Glenn From owner-ips@ece.cmu.edu Thu Jan 10 13:34: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 NAA20916 for ; Thu, 10 Jan 2002 13:34:35 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0AI5rc23509 for ips-outgoing; Thu, 10 Jan 2002 13:05:53 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0AI5pj23505 for ; Thu, 10 Jan 2002 13:05:51 -0500 (EST) 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 KAA05012; Thu, 10 Jan 2002 10:00:32 -0800 (PST) Message-ID: <3C3DD3BC.D066E4D8@cisco.com> Date: Thu, 10 Jan 2002 11:47:40 -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: Glenn Dasmalchi CC: John Hufferd , ips@ece.cmu.edu Subject: Re: iSCSI Markers References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Glenn- I agree that TUF is a better solution for iSCSI, and do not believe that either TUF or Markers are needed for this first version of the iSCSI protocol. I believe that the best solution so far for iSCSI framing is in TUF/PDU Alignment or to use another message protocol instead of TCP. Adding markers using either method is not usable by any other application than iSCSI, and adds some demands on implementations that can not make use of it anyway. Regardless of whether it is standard, TUF is not that hard to do, and it's what we should be doing. Without a more general solution like TUF, TCP will start running out of gas for other applications as well as iSCSI, and we will have to go look at other protocols instead when we get to 10G and beyond. I don't think that modifications to the usage of TCP are outside the scope of what iSCSI should influence. We clearly can't just do the work ourselves in a bubble, since that's not our charter. But we can certainly influence other high-bandwidth TCP users to help come up with good, general solutions. I don't think that the cost/performance problems that markers are trying to solve really exist today. We can deal with the performance issues at the expense of more memory on NIC cards, or by doing scatter-gather on storage devices and gateways. It just costs a little more. As the market for iSCSI stuff develops, and costs have to go down, we can address this by doing the right solution, which I do not believe involved markers. iSCSI is not the only protocol that is used to carry data on a network. NFS, CIFS, DAFS, FTP, HTTP, and others carry far more data than iSCSI. If we don't solve the problems for these as well, our NIC offload cards will eventually have to have "special" code for each one of these, which may end up being just as expensive than adding some memory. I personally think that there is no reason to mandate markers or framing of any kind in this iSCSI RFC. We are just not ready, and we already have enough things (security) that are mandated that will not be part of most implementations anyway. We are just not ready for the real solution yet. Those who wish to use markers for the time being should certainly do so, but we must not (oops, should have said that in caps :-) mandate their implementation and use. If markers stay in the draft in either form, they should remain optional. Just my opinions, Mark Glenn Dasmalchi wrote: > > > -----Original Message----- > > From: John Hufferd [mailto:hufferd@us.ibm.com] > > Sent: Thursday, January 10, 2002 1:27 AM > > To: ips@ece.cmu.edu > > Subject: iSCSI Markers > > > > I see no relationship to COWS, except both have an 8 byte > > header. If you > > have TUFs, you do not need to have Word Stuffing. The > > problem with COWS is > > not is header it is the Word Stuffing and the Replacement Pointers. > > > The random key marker approach in the TUF draft has a non-zero > probability of generating a "false positive" in theory (requires > resegmenting middle boxes + aliased data + exact length resegmentation, > etc.). Personally I think the probability is so low as to not be a > consideration, but a COWS approach using TUF-style segmentation does > address the issue. > > The point about the iSCSI charter is interesting, do others feel that > the segmentation requirements for TUF/PDU Alignment disqualify it from > consideration for iSCSI? > > -Glenn -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Thu Jan 10 14:06:12 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21607 for ; Thu, 10 Jan 2002 14:06:12 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0AIRae24968 for ips-outgoing; Thu, 10 Jan 2002 13:27:36 -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 g0AIRZj24963 for ; Thu, 10 Jan 2002 13:27:35 -0500 (EST) Received: from somesh ([65.172.158.93]) by cleitus.hosting.pacbell.net id NAA28959; Thu, 10 Jan 2002 13:27:30 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Reply-To: From: "Somesh Gupta" To: "John Hufferd" Cc: Subject: RE: iSCSI: Markers Date: Thu, 10 Jan 2002 10:25:40 -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.00.2919.6700 Importance: Normal In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I think the objections are to more to changing TCP wire protocol (i.e. header) than to the implementation. Also with NFS, there are two things. 1. There is some built-in containment in NAS which does provide some protection again "buggy" implementation/administration/ deliberate access to the wrong data. SANs as a rule require the clients to be much better behaved. 2. The security problems are recognized and being addressed in newer revs - also a sign that protocols can evolve. Would it be better to have everything in up-front - of course. But in this case, the evidence isn't there - and to make a choice just to accomodate - "software implementation but no rolling of the COWS in the copy or checksum loop, and which does not do CRC" and "in a hurry"?? Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > John Hufferd > Sent: Thursday, January 10, 2002 1:06 AM > To: somesh_gupta@silverbacksystems.com > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI: Markers > > > > Folks we can not add TUFs to our iSCSI protocol since it requires TCP/IP > changes. Our draft says that we WILL NOT work on Modifications > to internet > transport protocols, Hence, bringing TUFs into our draft is not doable. > > I think I made the point about Desktops and laptops on my kick off note, > they use NFS today and think things are fine. They will accept > this in the > future. (Right or Wrong). > > > > . > . > . > 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 > 01/09/2002 10:40:17 PM > > Please respond to > > Sent by: owner-ips@ece.cmu.edu > > > To: > cc: > Subject: RE: iSCSI: Markers > > > > COWS used in conjunction with "framing" allows for > the "packetization" of TCP, and a lot of good things follow > from that. > > COWS and framing allow complete processing of the segment > as a single entity - one PDU, processed in a pipelined > without recursion, and done. Markers enable no such > capability. They actually make things worse by having to > be inserted or removed as extra bytes in the stream. > > Markers and CRC interact very poorly since the markers > are part of the data stream, but not part of the CRC. > > Markers can only be processed in the context of the > connection state. COWS could actually help locate the > state. > > There seem to be two main motivations to push markers > > 1. laptops and desktops using unchanged TCP/IP stacks > and running iSCSI. > a. when do we think customers will really deploy iSCSI > at desktops/laptops without security and make their > entire storage vulnerable? If of course, security is > deployed, then COWS should be minor additional burden > b. If we have lots of spare cycles, does it matter anyway > c. even if the first generation does not have the capability, > the second generation of iSCSI implementation may implement > the TCP changes required for security - especially if it > mandatory > > 2. decide something now and sooner rather than better. Given > the substantial lack of evidence whether markers are useful > at all, and the significant promise of COWS/ULP framing, > I think it would be ill-advised to try to push this one. > > I think we should take this as part of our next phase. If > we do want something now, I vote for COWS/ULP. Even if it > is on the experimental track, we can always specify it as > part of iSCSI. > > COWS/ULP really allows the cheaper and more widely applicable > adapters that we would all like to see. > > Somesh > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Stephen Bailey > > Sent: Wednesday, January 09, 2002 5:25 AM > > To: ips@ece.cmu.edu > > Subject: Re: iSCSI: Markers > > > > > > > assuming iWARP is not an available option > > > > What John is referring to as iWarp is actually `TUF' (TCP ULP > > Framing). iWarp is a putative RDMA on IP transports protocol, which > > is not what we're talking about. > > > > All the TCP framing proposals we're discussing have: > > > > 1) an in-stream format > > > > To this, TUF adds: > > > > 2) a TCP sender segmentation behavior > > > > The in-stream formats so far are: > > o fixed-interval markers (FIM) > > o random key/length headers (TUF's FPDU) > > o COWS header + marker knockout chain > > > > In addition to Julian's COWS proposal, Costa & I also did one: > > > > http://www.cs.uchicago.edu/~steph/draft-bailey-tsvwg-cows-00.txt > > > > It's substantially similar to Julian's, with a couple differences: > > > > o pointers are only forward > > o payload length is 16-bit length (trivial to make it up to > 2^30-1 tho) > > o payload size is byte-granular > > o marker is defined a priori (I like Julian's idea of being able > > to exchange markers if desired---we'd add that) > > > > Our COWS was defined as an alternative to (replacement of) TUF's > > current in-stream format. Compelling benefits of the COWS in-stream > > format from our standpoint are: > > > > o the SAME in-stream format is works with or without TCP sender > > segmentation support > > o no chance of a false positive from key/length validation > > > > The first point is particularly important. COWS can be used to > > validate the PDU contaiment property if the TCP sender is > > TUF-compliant, and it can be used for marker-like (better, actually) > > resynchronization if the TCP sender is stock. Before the COWS > > proposal, we always had two different in-stream representations > > (markers, & key/lengths) for different purposes. > > > > The primary disadvantage of the COWS in-stream format is: > > > > o prohibits 0-touch software senders > > > > I had suggested that if everybody liked COWS, we would update TUF to > > use it, and even if TUF remains experimental, iSCSI could define the > > same in-stream format for its framing (replacing markers). That way, > > there would really be only ONE in-stream format in the universe, > > though it might be redundantly defined in two places. > > > > For iSCSI, a single in-stream format that supports both modified and > > stock sender approachs seems nice. Implementations can easily migrate > > from stock to modified TCP senders (ask one of the authors of the TUF > > draft if you don't understand why modified TCP sender segmentation is > > good). > > > > For the rest of the world it would be nice (essential in my opinion) > > if the same framing technique could be used for iSCSI and other > > protocols (e.g. iWarp). System vendors that support iSCSI just might > > want to support NAS too, which could mean DAFS (on iWarp). Chip > > vendors CERTAINLY want to maximize return from their TOE investment > > which means being able support various accelerated protocols with the > > same hardware. Wouldn't it be stupid if we had a proliferation of > > framing alternatives just because the world originally seemed flat? > > > > The tradeoff of 0-touch versus a single format clearly has powerful > > arguments pulling either way. I'm personally ambivalent. Mostly, I > > want to make sure everybody in the iSCSI community is sufficiently > > informed about what's at stake. > > > > Steph > > > > > > From owner-ips@ece.cmu.edu Thu Jan 10 14:11: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 OAA21702 for ; Thu, 10 Jan 2002 14:11:09 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0AIP1c24776 for ips-outgoing; Thu, 10 Jan 2002 13:25:01 -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 g0AIOxj24768 for ; Thu, 10 Jan 2002 13:24:59 -0500 (EST) Received: (cpmta 16385 invoked from network); 10 Jan 2002 10:24:52 -0800 Received: from 64.130.130.105 (HELO dougrmt) by smtp.telocity.com (209.228.32.218) with SMTP; 10 Jan 2002 10:24:52 -0800 X-Sent: 10 Jan 2002 18:24:52 GMT From: "Douglas Otis" To: "Ips" Subject: RE: iSCSI Markers Date: Thu, 10 Jan 2002 10:25:09 -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 In-Reply-To: <15421.49636.699210.573299@pkoning.dev.equallogic.com> Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Paul, I agree with you and John. Maintaining conformity as well network layering is important and advantages offered by the new transport easily outweigh concerns balanced against modification of TCP. No one needs to ask my preference. : ) Doug > >>>>> "John" == John Hufferd writes: > John> You have FIM or COWS, neither one is useful with TUFs, except > John> that they have a similar header with COWS, not is hardly a > John> reason to put up with the SCANNING and Stuffing of COWS > John> Pointers in the Data. This is especially since depending on > John> the development approach you may find the Pointers pointing the > John> wrong way for either sending or receiving in some HW pipelining > John> designs. And it is always a poorer approach then FIM in > John> Software. > > Agreed. FIM is nasty, COWS is nastier. Both may require a memory to > memory copy, but at least FIM doesn't require you to examine the data > you're moving. > > Clearly, the real answer is a transport layer that isn't a byte stream > transport. TP4 or SCTP, anyone? :-) > > paul > > From owner-ips@ece.cmu.edu Thu Jan 10 14:34: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 OAA22254 for ; Thu, 10 Jan 2002 14:34:54 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0AJMXF28550 for ips-outgoing; Thu, 10 Jan 2002 14:22:33 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sandmail.sandburst.com (sandmail.sandburst.com [216.57.132.42]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0AJMVj28545 for ; Thu, 10 Jan 2002 14:22:31 -0500 (EST) To: ips@ece.cmu.edu Subject: Re: iSCSI Markers In-Reply-To: Message from "Glenn Dasmalchi" of "Thu, 10 Jan 2002 09:30:49 PST." References: Date: Thu, 10 Jan 2002 14:22:24 -0500 From: Stephen Bailey Message-Id: <20020110192229.D4BED4EA5@sandmail.sandburst.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Glenn, > The point about the iSCSI charter is interesting, do others feel that > the segmentation requirements for TUF/PDU Alignment disqualify it from > consideration for iSCSI? Just to be pedantically clear, nothing stops the IPS WG from `considering' (the use of) solutions developed elsewhere (e.g. tsvwg). What IPS is prohibited from is specifying ITS OWN transport modifications. I have understood this to mean (David can probably correct me, and probably will :^) iSCSI could specify a way to negotiate the use of TUF, but can't say anything about MAY, or MUSTs of its use. An RFC can not normatively reference one lower on the track (experimental < proposed standard < draft standard < standard). Extending into the realm of complete guesswork, I imagine that even if iSCSI couldn't reference TUF AT ALL, it would probably be pretty easy to produce an IRFC (or another XRFC?) that defined the use of TUF with iSCSI. Certainly writing the draft would be easy, I'm less clear how it might progress to RFC status. Steph From owner-ips@ece.cmu.edu Thu Jan 10 14:34: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 OAA22265 for ; Thu, 10 Jan 2002 14:34:56 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0AInZ626318 for ips-outgoing; Thu, 10 Jan 2002 13:49:35 -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 g0AInXj26314 for ; Thu, 10 Jan 2002 13:49:33 -0500 (EST) Received: from somesh ([65.172.158.93]) by cleitus.hosting.pacbell.net id NAA06659; Thu, 10 Jan 2002 13:49:30 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Reply-To: From: "Somesh Gupta" To: "Stephen Bailey" , Subject: RE: iSCSI: Markers Date: Thu, 10 Jan 2002 10:47: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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <20020110162354.B835D4E99@sandmail.sandburst.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jim, What are the issues with "one PDU per TCP segment"? I think this would really enable simple, high performance Upper Layer protocol processing over TCP. Of course, you always have the issue that no matter what method is used, data can only be placed and not processed out of sequence (which implies that there is additional complexity if barrier lists and so on and having to do control processing at a faster rate when you do perform out of order processing). Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Stephen Bailey > Sent: Thursday, January 10, 2002 8:24 AM > To: ips@ece.cmu.edu > Subject: Re: iSCSI: Markers > > > > If we decided it was the right technique for iSCSI, couldn't we just > > lift the content and put it in the iSCSI draft? > > >From a standardization standpoint, it's like JohnH said. iSCSI is not > chartered to do anything that modifies the transport. Even if it were > (which it isn't) the `experimental stigma' of TUF would certainly > spread to iSCSI if iSCSI ingested TUF in toto. > > The allure of COWS is that iSCSI CAN specify the in-stream format > without saying anything about TCP segmentation---COWS in-stream format > solves the same problem as markers. If iSCSI does that, it's a tiny > step, for implementations that can take it, to add TUF-compliant TCP > segmentation & PDU containment processing. > > What would be bad is if the `performance community' (RDMA, iSCSI & > whomever else) decided that COWS is the best general solution to this > problem, and iSCSI chose a variant of COWS that didn't work for other > applications (current & future). > > Basically, the choices, as I see them are: > > o nothing, FIM, COWS for unmodified senders > o key/length or COWS for TUF-compliant senders > > The key questions to make the choices come down to: > > 1) Is PDU containment `worth it'? > 2) Is resynching in the absence of PDU containment `worth it'? > 3) Is 0-touch send for software clients `worth it'? > > Most seem to strongly believe that PDU containment is worth it but > there are some experienced, noteworthy objectors (e.g. Jim Williams). > If you don't believe PDU containment is sufficiently beneficial, then > you simply don't bother with TUF-compliant senders. > > I have no idea what `most' think for 2) & 3), but I can speak for > myself. > > I don't think resynching in the absence of PDU containment is worth > it. That implies that I'd take nothing over FIM. It also implies > that I'd take nothing over COWS w/o a TUF sender, except that if the > TUF sender approach uses COWS, having COWS in-stream is `free'. > > I'm undecided on whether 0-touch send for software clients is `worth > it'. If yes, I'd take key/length for a TUF sender. If no, > I'd take COWS. > > So the only free variable in my position is whether 0-touch software > senders are worth it. I don't have the data (I'm sure you're > wondering why that's stopping me on this point, and not the others :^) > If yes, it's `nothing + key/length'. If no, it's `COWS + COWS'. > > Steph > From owner-ips@ece.cmu.edu Thu Jan 10 15:22: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 PAA23213 for ; Thu, 10 Jan 2002 15:22:40 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0AJmjl00208 for ips-outgoing; Thu, 10 Jan 2002 14:48:45 -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 g0AJmij00204 for ; Thu, 10 Jan 2002 14:48: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 g0AJkXP07260; Thu, 10 Jan 2002 11:46:33 -0800 Message-Id: <200201101946.g0AJkXP07260@Gregorio.Stanford.EDU> To: somesh_gupta@silverbacksystems.com cc: "John Hufferd" , ips@ece.cmu.edu Subject: Re: iSCSI: Markers In-reply-to: Your message of "Thu, 10 Jan 2002 10:25:40 PST." Date: Thu, 10 Jan 2002 11:41:33 -0800 From: Jonathan Stone Sender: owner-ips@ece.cmu.edu Precedence: bulk In message , "Somesh Gupta" writes: >I think the objections are to more to changing TCP wire >protocol (i.e. header) than to the implementation. > >Also with NFS, there are two things. >1. There is some built-in containment in NAS which does >provide some protection again "buggy" implementation/administration/ >deliberate access to the wrong data. SANs as a rule require the >clients to be much better behaved. >2. The security problems are recognized and being addressed in >newer revs - also a sign that protocols can evolve. Would it >be better to have everything in up-front - of course. But in >this case, the evidence isn't there - and to make a choice >just to accomodate - "software implementation but no rolling >of the COWS in the copy or checksum loop, and which does not >do CRC" and "in a hurry"?? Somesh, Part of the message seems to've suffered packet drop. I can, and do, change my TCP implementation. The gotcha is that folding another operation into the existing loops in my TCP protocol-- whether it's COBS or COWS or a CRC -- *IS* changing my TCP implementation. Even if it doesn't change the on-the wire semantics, its still a change to my TCP. In fact, it's easier for me to change my TCP to make it guarantee to preserve any segment boundaries between iSCSI PDUs[*], than it is to fold iSCSI-PDU processing into TCP processing. [*] when sending/retransmitting, that is. If we could guarantee that, hardware-accelerated receiers could use a TCP header option to indicate start-of-frame in this segment, and be done with it. I'd even to go to bat with the transport-area representative, arguing that the ratio of iSCSI PDUs to expected drops is ``small enough'' that using that portion of the limited TCP option space for non-SACK usage was in fact a good trade-off. (My understanding is that it's not really necessary to mark *all* PDU boundaries, just to mark enough of them to permit a reassembly buffer significantly smaller than BW*RTT, which therefore doesn't require lots of external SRAM; while still allowing direct data placement.) I understand that door is well and truly closed, though. From owner-ips@ece.cmu.edu Thu Jan 10 15:25: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 PAA23252 for ; Thu, 10 Jan 2002 15:25:28 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0AJWh629201 for ips-outgoing; Thu, 10 Jan 2002 14:32:43 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0AJWfj29196 for ; Thu, 10 Jan 2002 14:32:41 -0500 (EST) 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 LAA09668; Thu, 10 Jan 2002 11:32:27 -0800 (PST) Message-ID: <3C3DE947.88A62F21@cisco.com> Date: Thu, 10 Jan 2002 13:19: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: Stephen Bailey CC: ips@ece.cmu.edu Subject: Re: iSCSI Markers References: <20020110192229.D4BED4EA5@sandmail.sandburst.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Steph- I think that your approach of writing a separate RFC would be the best way to document any framing method for iSCSI (including the use of markers). It's clean, separable, and doesn't get in the way of getting the protocol itself done, which seems to be the most important thing right now. Best of all, if one method doesn't work or is not adopted, it doesn't clutter the iSCSI specification for all time. -- Mark Stephen Bailey wrote: > > Glenn, > > > The point about the iSCSI charter is interesting, do others feel that > > the segmentation requirements for TUF/PDU Alignment disqualify it from > > consideration for iSCSI? > > Just to be pedantically clear, nothing stops the IPS WG from > `considering' (the use of) solutions developed elsewhere (e.g. tsvwg). > What IPS is prohibited from is specifying ITS OWN transport > modifications. > > I have understood this to mean (David can probably correct me, and > probably will :^) iSCSI could specify a way to negotiate the use of > TUF, but can't say anything about MAY, or MUSTs of its use. An RFC > can not normatively reference one lower on the track (experimental < > proposed standard < draft standard < standard). > > Extending into the realm of complete guesswork, I imagine that even if > iSCSI couldn't reference TUF AT ALL, it would probably be pretty easy > to produce an IRFC (or another XRFC?) that defined the use of TUF with > iSCSI. Certainly writing the draft would be easy, I'm less clear how > it might progress to RFC status. > > Steph -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Thu Jan 10 15:55: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 PAA23687 for ; Thu, 10 Jan 2002 15:55:26 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0AKdef03183 for ips-outgoing; Thu, 10 Jan 2002 15:39:40 -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 g0AKdcj03179 for ; Thu, 10 Jan 2002 15:39:39 -0500 (EST) Received: from somesh ([65.172.158.93]) by cleitus.hosting.pacbell.net id PAA28143; Thu, 10 Jan 2002 15:38:45 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Reply-To: From: "Somesh Gupta" To: "Jonathan Stone" Cc: "IPS" Subject: RE: iSCSI: Markers Date: Thu, 10 Jan 2002 12:36:55 -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.00.2919.6700 Importance: Normal In-Reply-To: <200201102016.g0AKG5P07517@Gregorio.Stanford.EDU> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Jonathan Stone [mailto:jonathan@DSG.Stanford.EDU] > Sent: Thursday, January 10, 2002 12:11 PM > To: somesh_gupta@silverbacksystems.com > Cc: Stephen Bailey; ips@ece.cmu.edu > Subject: Re: iSCSI: Markers > > > In message > , > "Somesh Gupta" writes: > > >Jim, > > > >What are the issues with "one PDU per TCP segment"? > > Mostly that what you're asking for is no longer TCP. > TCP does not preserve record, or packet, or push boundaries. Let us not be so religious about it. Everything must evolve. TCP has always evolved. To create cost-effective multi-gigabit adapters, I do think changes are needed to "packetize" TCP. Others are proposing changes to initial window size, ECN etc etc. > > TCP retransmissions can, and will, resend a maximal-MTU worth of > data from the point where a DUPACK triggers fast retramsit. > > That maximal segment contains the tail (perhaps all) of one iSCSI PDU, > plus as much as of the following PDU as fits inside the TCP segment. Ok. We do require change to the TCP implementation. I already gave you that. > Heck, if iSCSI can enqueue another PDU before the first one has gone > out the wire, then standard TCP semantics is to compact the second PDU > into the first one. In the reference BSD implemetnation, see > sbappend(). OK. Changes are needed to the implementation. Some OSes already avoid willy-nilly segmentation. > > SACK makes the picture more complicated. Retransmissions in the face > of PMTU and route/MTU changes make it even worse. But you get the idea. This is where the determinism of COWS addresses lets you handle such issues on the slow path. > > If iSCSI PDUs are bigger than TCP segments, then dropping segment > with a PDU boundary leaves the receiver unable to synchronize until it > receives the TCP retransission. That takes at least an RTT, > which takes us back to BW*RTT worth of buffering. There are many alternatives to avoid this one. > > Changing TCP, giving TCP senders the option of asking their sending > TCP to not coalesce segments across sender-marked boundaries, might > well be generally useful (c.f. the history behind PSH); but it's a > change to TCP. That's outside the IPS charter. It probably requires > an extension to the API to TCP as well, to mark the boundaries. Again, no protocol changes and interoperability with existing implementations is the goal. Even with markers, the receive TCP has to change significantly. > > From owner-ips@ece.cmu.edu Thu Jan 10 15:56: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 PAA23710 for ; Thu, 10 Jan 2002 15:56:50 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0AKF3001742 for ips-outgoing; Thu, 10 Jan 2002 15:15:03 -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 g0AKEvj01722 for ; Thu, 10 Jan 2002 15:14:57 -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 g0AKG5P07517; Thu, 10 Jan 2002 12:16:05 -0800 Message-Id: <200201102016.g0AKG5P07517@Gregorio.Stanford.EDU> To: somesh_gupta@silverbacksystems.com cc: "Stephen Bailey" , ips@ece.cmu.edu Subject: Re: iSCSI: Markers In-reply-to: Your message of "Thu, 10 Jan 2002 10:47:41 PST." Date: Thu, 10 Jan 2002 12:11:04 -0800 From: Jonathan Stone Sender: owner-ips@ece.cmu.edu Precedence: bulk In message , "Somesh Gupta" writes: >Jim, > >What are the issues with "one PDU per TCP segment"? Mostly that what you're asking for is no longer TCP. TCP does not preserve record, or packet, or push boundaries. TCP retransmissions can, and will, resend a maximal-MTU worth of data from the point where a DUPACK triggers fast retramsit. That maximal segment contains the tail (perhaps all) of one iSCSI PDU, plus as much as of the following PDU as fits inside the TCP segment. Heck, if iSCSI can enqueue another PDU before the first one has gone out the wire, then standard TCP semantics is to compact the second PDU into the first one. In the reference BSD implemetnation, see sbappend(). SACK makes the picture more complicated. Retransmissions in the face of PMTU and route/MTU changes make it even worse. But you get the idea. If iSCSI PDUs are bigger than TCP segments, then dropping segment with a PDU boundary leaves the receiver unable to synchronize until it receives the TCP retransission. That takes at least an RTT, which takes us back to BW*RTT worth of buffering. Changing TCP, giving TCP senders the option of asking their sending TCP to not coalesce segments across sender-marked boundaries, might well be generally useful (c.f. the history behind PSH); but it's a change to TCP. That's outside the IPS charter. It probably requires an extension to the API to TCP as well, to mark the boundaries. From owner-ips@ece.cmu.edu Thu Jan 10 15:58: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 PAA23757 for ; Thu, 10 Jan 2002 15:58:45 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0AKGYg01835 for ips-outgoing; Thu, 10 Jan 2002 15:16:34 -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 g0AKGWj01828 for ; Thu, 10 Jan 2002 15:16:32 -0500 (EST) Received: from somesh ([65.172.158.93]) by cleitus.hosting.pacbell.net id PAA06463; Thu, 10 Jan 2002 15:14:20 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Reply-To: From: "Somesh Gupta" To: "Jonathan Stone" Cc: "John Hufferd" , Subject: RE: iSCSI: Markers Date: Thu, 10 Jan 2002 12:12:30 -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.00.2919.6700 Importance: Normal In-Reply-To: <200201101946.g0AJkXP07260@Gregorio.Stanford.EDU> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Jonathan Stone [mailto:jonathan@DSG.Stanford.EDU] > Sent: Thursday, January 10, 2002 11:42 AM > To: somesh_gupta@silverbacksystems.com > Cc: John Hufferd; ips@ece.cmu.edu > Subject: Re: iSCSI: Markers > > > > In message > , > "Somesh Gupta" writes: > > >I think the objections are to more to changing TCP wire > >protocol (i.e. header) than to the implementation. > > > >Also with NFS, there are two things. > >1. There is some built-in containment in NAS which does > >provide some protection again "buggy" implementation/administration/ > >deliberate access to the wrong data. SANs as a rule require the > >clients to be much better behaved. > >2. The security problems are recognized and being addressed in > >newer revs - also a sign that protocols can evolve. Would it > >be better to have everything in up-front - of course. But in > >this case, the evidence isn't there - and to make a choice > >just to accomodate - "software implementation but no rolling > >of the COWS in the copy or checksum loop, and which does not > >do CRC" and "in a hurry"?? > > Somesh, > > Part of the message seems to've suffered packet drop. > > I can, and do, change my TCP implementation. The gotcha is that > folding another operation into the existing loops in my TCP protocol-- > whether it's COBS or COWS or a CRC -- *IS* changing my TCP > implementation. Even if it doesn't change the on-the wire semantics, > its still a change to my TCP. Yes and at least the IETF should not object to that part. John was referring to the fact that iSCSI charter states no changes to TCP (and by that I mean protocol). Even markers require changes to TCP on the receiver end, and fairly heavy at that. > > In fact, it's easier for me to change my TCP to make it guarantee to > preserve any segment boundaries between iSCSI PDUs[*], than it is to > fold iSCSI-PDU processing into TCP processing. By PDU processing do you imply doing the word stuffing processing? It should be something that can be rolled into the copy loop (if iSCSI is in user space and one of the applications that John referred to in the past) or into the checksum loop (if iSCSI is in the kernel space), or into the CRC loop. NOTE: If the data is touched once anyway, the cost of an additional touch is fairly minimal because everything is in the processor cache. The worst case is an accelerated NIC which does everything except COWS and CRC - the sender uses iSCSI, does not to do CRC, but does do COWS. This requires an extra touch. > > > [*] when sending/retransmitting, that is. > If we could guarantee that, hardware-accelerated receiers could use a > TCP header option to indicate start-of-frame in this segment, and be > done with it. I'd even to go to bat with the transport-area > representative, arguing that the ratio of iSCSI PDUs to expected drops > is ``small enough'' that using that portion of the limited TCP option > space for non-SACK usage was in fact a good trade-off. (My > understanding is that it's not really necessary to mark *all* PDU > boundaries, just to mark enough of them to permit a reassembly buffer > significantly smaller than BW*RTT, which therefore doesn't require > lots of external SRAM; while still allowing direct data placement.) > > I understand that door is well and truly closed, though. Actually as someone pointed out at the last IETF, the timestamp option wastes a couple of bytes(?). Seems like an opportunity without adding overhead. That is really the right way but people point at all sorts of misbehaving middle boxes. The advantage with COWS is that detection of alignment is deterministic. > > From owner-ips@ece.cmu.edu Thu Jan 10 16: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 QAA24421 for ; Thu, 10 Jan 2002 16:43:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0ALEUR05254 for ips-outgoing; Thu, 10 Jan 2002 16:14:30 -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 g0ALESj05245 for ; Thu, 10 Jan 2002 16:14:28 -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 g0ALFIP08030; Thu, 10 Jan 2002 13:15:18 -0800 Message-Id: <200201102115.g0ALFIP08030@Gregorio.Stanford.EDU> To: somesh_gupta@silverbacksystems.com cc: "IPS" Subject: Re: iSCSI: Markers In-reply-to: Your message of "Thu, 10 Jan 2002 12:36:55 PST." Date: Thu, 10 Jan 2002 13:10:17 -0800 From: Jonathan Stone Sender: owner-ips@ece.cmu.edu Precedence: bulk In message , "Somesh Gupta" writes: >> Mostly that what you're asking for is no longer TCP. >> TCP does not preserve record, or packet, or push boundaries. > > Let us not be so religious about it. Everything must evolve. Somesh, Nobody is being religious. You are asking for changes to RFC 1122, section 4.2. Perhaps TCP will need that in the fullness of...well, need it *now*, I guess, but I thought IPS was forbidden to go there. Or am I mistaken on that? > Ok. We do require change to the TCP implementation. I already gave > you that. If you want iSCSI receivers to rely on non-conforming assumptions about segmentation and upper-level boundaries, then that's a change to TCP (send policies, retransmit policies, and receiver-to-application policies about coalescing segments), which are not part of extant TCP implementations. The necessary changes fly in the face of the `MUST' requirements on RFC 1122, sec. 4.2, pp 82-83; and also require that the SHOULD in the `DISCUSSION' of filling become a `MUST NOT'. I dont see how anyone can claim that's not a change to TCP. [...] > Again, no protocol changes and interoperability with existing > implementations is the goal. Even with markers, the receive > TCP has to change significantly. It *is* a protocol change. Not a change to the on-the-wire format, true; its a change to the state machines which form user SEND requests into valid TCP segments, and in how received segments are passed up to the application. That's still a change to the protocol. I dont see any way for a software iSCSI implementation to conform with what you suggest, in general, without changing the innards of TCP in a way which (again in general) violates the Host Requirements RFC. Again, I'm not being doctrinaire about this. I'd use it myself, if I could. From owner-ips@ece.cmu.edu Thu Jan 10 16:46: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 QAA24464 for ; Thu, 10 Jan 2002 16:46:13 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0AKs8E03989 for ips-outgoing; Thu, 10 Jan 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 Gregorio.Stanford.EDU (Gregorio.Stanford.EDU [171.64.66.243]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0AKs6j03982 for ; Thu, 10 Jan 2002 15:54:06 -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 g0AKpGP07823; Thu, 10 Jan 2002 12:51:16 -0800 Message-Id: <200201102051.g0AKpGP07823@Gregorio.Stanford.EDU> To: somesh_gupta@silverbacksystems.com cc: "Jonathan Stone" , "John Hufferd" , ips@ece.cmu.edu Subject: Re: iSCSI: Markers In-reply-to: Your message of "Thu, 10 Jan 2002 12:12:30 PST." Date: Thu, 10 Jan 2002 12:46:16 -0800 From: Jonathan Stone Sender: owner-ips@ece.cmu.edu Precedence: bulk In message , "Somesh Gupta" writes: > By PDU processing do you imply > doing the word stuffing processing? Yes, that's part of it. > It should be something > that can be rolled into the copy loop (if iSCSI is in user space [...] This is still a change to the TCP _implementation_. Only the implementor of the TCP and the kernel/user boundary can do it, and it has to be tied, somehow, to the particular socket/fd/whatever is using not just TCP, but iSCSI-over-TCP. The issue I see here isn't IETF mandates: its that reasonable-quality software implementations require changes to code which may well be beyond the control (or even the access) of the iSCSI implementor. > NOTE: If the data is touched once anyway, the cost of an additional > touch is fairly minimal because everything is in the processor cache. No, it isn't, not always. I can think of at least three SIGCOM/TON papers, measuring data on top-end 1996 vintage machines, on which this assumption has been conclusively shown to be wrong. That price/performance point is still quite viable. Torsten Braun and Christoph Diot had one paper in SIGCOMM 95 and later in ToN; I dont recall the other one (my Stanford office papers are all packed). I can't speak to COWS. I have done a COBS implementation, and the byte-insertion meant that COBS dirtied every cache line; it turned out simpler and faster to just do another copy. [...] [header options] My understanding is that the limited option space, and the rather large demand on it which SACK can generate in wide-area links (transatlantic can regularly show 50% drop rate!), means our friendly transport representatives are reluctant to admit further use of TCP options. As I said, I'm willing to examine the numbers with the people I know. I'd be for it, myself. From owner-ips@ece.cmu.edu Thu Jan 10 16:49: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 QAA24540 for ; Thu, 10 Jan 2002 16:49:14 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0ALQVF06073 for ips-outgoing; Thu, 10 Jan 2002 16:26:31 -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 g0ALQSj06064 for ; Thu, 10 Jan 2002 16:26:28 -0500 (EST) Received: (cpmta 26112 invoked from network); 10 Jan 2002 13:26:22 -0800 Received: from 64.130.130.105 (HELO dougrmt) by smtp.telocity.com (209.228.32.214) with SMTP; 10 Jan 2002 13:26:22 -0800 X-Sent: 10 Jan 2002 21:26:22 GMT From: "Douglas Otis" To: "Ips" Subject: RE: iSCSI: Markers Date: Thu, 10 Jan 2002 13:26:40 -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 Importance: Normal In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Somesh, One view of evolution regarding TCP would be that it has already evolved into SCTP. There are many problems beyond framing being solved as a result. Doug > > In message > > , > > "Somesh Gupta" writes: > > > > >Jim, > > > > > >What are the issues with "one PDU per TCP segment"? > > > > Mostly that what you're asking for is no longer TCP. > > TCP does not preserve record, or packet, or push boundaries. > > Let us not be so religious about it. Everything must evolve. > TCP has always evolved. To create cost-effective multi-gigabit > adapters, I do think changes are needed to "packetize" TCP. > Others are proposing changes to initial window size, ECN > etc etc. > > > > > TCP retransmissions can, and will, resend a maximal-MTU worth of > > data from the point where a DUPACK triggers fast retramsit. > > > > That maximal segment contains the tail (perhaps all) of one iSCSI PDU, > > plus as much as of the following PDU as fits inside the TCP segment. > > Ok. We do require change to the TCP implementation. I already gave > you that. > > > Heck, if iSCSI can enqueue another PDU before the first one has gone > > out the wire, then standard TCP semantics is to compact the second PDU > > into the first one. In the reference BSD implemetnation, see > > sbappend(). > > OK. Changes are needed to the implementation. Some OSes already avoid > willy-nilly segmentation. > > > > > SACK makes the picture more complicated. Retransmissions in the face > > of PMTU and route/MTU changes make it even worse. But you get the idea. > > This is where the determinism of COWS addresses lets you handle > such issues on the slow path. > > > > If iSCSI PDUs are bigger than TCP segments, then dropping segment > > with a PDU boundary leaves the receiver unable to synchronize until it > > receives the TCP retransission. That takes at least an RTT, > > which takes us back to BW*RTT worth of buffering. > > There are many alternatives to avoid this one. > > > > Changing TCP, giving TCP senders the option of asking their sending > > TCP to not coalesce segments across sender-marked boundaries, might > > well be generally useful (c.f. the history behind PSH); but it's a > > change to TCP. That's outside the IPS charter. It probably requires > > an extension to the API to TCP as well, to mark the boundaries. > > Again, no protocol changes and interoperability with existing > implementations is the goal. Even with markers, the receive > TCP has to change significantly. From owner-ips@ece.cmu.edu Thu Jan 10 17:33: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 RAA25232 for ; Thu, 10 Jan 2002 17:33:24 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0AM8ZQ08469 for ips-outgoing; Thu, 10 Jan 2002 17:08:35 -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 g0AM8Xj08465 for ; Thu, 10 Jan 2002 17:08:33 -0500 (EST) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Jan 2002 17:11:09 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0293733C@CORPMX14> From: Black_David@emc.com To: rsnively@Brocade.COM, ips@ece.cmu.edu Subject: RE: FCIP: Short Frame Security Solution Proposal Date: Thu, 10 Jan 2002 16:55:53 -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, > In poking through the relevant text of our latest author's > draft (to be published early next week as an IETF draft), > I found the following text, which I would have imagined would > have addressed your concerns without any requirement > to document the particular example you have hypothesized. > > This one is part of the description of the authentication > procedure for creating additional connections. > > Warning: The authentication mechanism described here > and in FC-BB-2 [4] is not designed to thwart > sophisticated security threats. The IP security > mechanisms described in section 9 should be enabled > in environments where security threats are suspected. > > One of the reasons I would be reluctant to document the > special case you have described is that, given the same > kind of security threat you have described, there are probably > a number of other cases with equal exposure if you were to choose > to operate without turning on the appropriate IPSec > security features. Ralph pointed out that text to me a while ago. Here's some more text to consider, from the "Submitting Documents to the IESG" guidelines at http://www.ietf.org/ID-nits.html - Does your document have an adequate security considerations section? Some have said that the "Security Considerations" section of a document essentially helps hackers attack implementations. It may, but the fact is that they will do the analysis themselves anyway - not doing a threat analysis will not stop them from exploiting weaknesses in your design. But by pointing out design choices you have made which have security implications, or by documenting "when you implement this, you should make these choices that have security implications", you may help people build implementations that are more hacker-proof, and you may find something you can improve. Frankly, the IESG has so many documents come its way which have no thought for security in them it must return for the analysis, putting the analysis into the document will be helpful in getting it through. The use of the nonce is a design choice that has security implications, and I'm asking that those implications be described. A specific discussion of other threats to TCP, IP, and protocols that use them (e.g., address spoofing, TCP connection hijacking, RST attacks) is not needed beyond something like Ralph's text that notes their existence. FCIP did not invent TCP or IP, and hence can rely on other documents to describe security considerations inherent to those protocols. FCIP did invent the nonce, and hence needs to describe its security considerations. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Jan 10 17:38: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 RAA25335 for ; Thu, 10 Jan 2002 17:38:18 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0ALomX07476 for ips-outgoing; Thu, 10 Jan 2002 16:50:48 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from emulex.emulex.com (emulex.emulex.com [138.239.112.1]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0ALokj07470 for ; Thu, 10 Jan 2002 16:50:46 -0500 (EST) Received: from xbl.ad.emulex.com (xbl.ma.emulex.com [172.16.12.11]) by emulex.emulex.com (8.9.1a/8.9.1) with ESMTP id NAA15641 for ; Thu, 10 Jan 2002 13:50:52 -0800 (PST) Received: by xbl.ad.emulex.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Jan 2002 16:50:36 -0500 Message-ID: <3356669BBE90C448AD4645C843E2BF280A058B@xbl.ad.emulex.com> From: "Williams, Jim" To: ips@ece.cmu.edu Subject: RE: iSCSI: Markers Date: Thu, 10 Jan 2002 16:50:35 -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: Somesh Gupta [mailto:somesh_gupta@silverbacksystems.com] > Sent: Thursday, January 10, 2002 1:48 PM > To: Stephen Bailey; ips@ece.cmu.edu > Subject: RE: iSCSI: Markers > > > Jim, > > What are the issues with "one PDU per TCP segment"? I > think this would really enable simple, high performance > Upper Layer protocol processing over TCP. I have some doubts that the ability to place data out of order will actually result in a more cost effective NIC. Even without out of order placement, there may be some benefit to "one PDU per TCP segment", of course in this case there is no need for markers. In any case, the only thing I have objected to is making markers a requirement to use if other end requests it. I don't have a problem with making it an option (both ends agree) and see if it flies. > Of course, > you always have the issue that no matter what method > is used, data can only be placed and not processed > out of sequence (which implies that there is additional > complexity if barrier lists and so on and having to do > control processing at a faster rate when you do perform > out of order processing). > > Somesh From owner-ips@ece.cmu.edu Thu Jan 10 18:33: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 SAA26087 for ; Thu, 10 Jan 2002 18:33:40 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0AMUV509693 for ips-outgoing; Thu, 10 Jan 2002 17:30:31 -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 g0AMUTj09684 for ; Thu, 10 Jan 2002 17:30:29 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Jan 2002 17:30:23 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0293733D@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSCSI TUF/PDU alignment - Procedural matters Date: Thu, 10 Jan 2002 17:17:50 -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 With my WG Co-Chair hat firmly on, it's time to clear up a few questions about IETF procedures on this topic: > The point about the iSCSI charter is interesting, do others feel that > the segmentation requirements for TUF/PDU Alignment disqualify it from > consideration for iSCSI? If "consideration" means "detailed specification of TUF/PDU alignment in the iSCSI draft", then it is disqualified. A reference to the tsvwg draft on TUF/PDU alignment should be ok, but the strongest possible reference is "MAY", and the proposal below to move all material about iSCSI use of TUF/PDU alignment into a separate draft would be a better approach (hint). > Extending into the realm of complete guesswork, I imagine that even if > iSCSI couldn't reference TUF AT ALL, it would probably be pretty easy > to produce an IRFC (or another XRFC?) that defined the use of TUF with > iSCSI. Certainly writing the draft would be easy, I'm less clear how > it might progress to RFC status. Such a draft would have to use a normative reference to the TUF/PDU Alignment specification, and hence could only become an Experimental RFC. Writing such a draft with that goal in mind would be fine, and would provide a good home for any text keys/values that people want to use to negotiate TUF/PDU alignment for iSCSI. > If we could guarantee that, hardware-accelerated receivers could use a > TCP header option to indicate start-of-frame in this segment, and be > done with it. I'd even to go to bat with the transport-area > representative, arguing that the ratio of iSCSI PDUs to expected drops > is ``small enough'' that using that portion of the limited TCP option > space for non-SACK usage was in fact a good trade-off. That's a TSVWG topic, please take it up there rather than here on the IPS list. Responses to and questions about this email should be sent directly to me, please do not reply to the list. I'll post clarifications if they're important, but these sort of procedural discussions are not a good use of list bandwidth. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Jan 10 19:12:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26549 for ; Thu, 10 Jan 2002 19:12:34 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0ANMqh12411 for ips-outgoing; Thu, 10 Jan 2002 18:22:52 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0ANMnj12406 for ; Thu, 10 Jan 2002 18:22:49 -0500 (EST) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id PAA02595; Thu, 10 Jan 2002 15:22:33 -0800 (PST) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Jan 2002 15:22:32 -0800 Message-ID: From: Robert Snively To: "'Black_David@emc.com'" , Robert Snively , ips@ece.cmu.edu Subject: RE: FCIP: Short Frame Security Solution Proposal Date: Thu, 10 Jan 2002 15:22:32 -0800 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk My response below. > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Thursday, January 10, 2002 1:56 PM > To: rsnively@brocade.com; ips@ece.cmu.edu > Subject: RE: FCIP: Short Frame Security Solution Proposal > > > Bob, > > > In poking through the relevant text of our latest author's > > draft (to be published early next week as an IETF draft), > > I found the following text, which I would have imagined would > > have addressed your concerns without any requirement > > to document the particular example you have hypothesized. > > > > This one is part of the description of the authentication > > procedure for creating additional connections. > > > > Warning: The authentication mechanism described here > > and in FC-BB-2 [4] is not designed to thwart > > sophisticated security threats. The IP security > > mechanisms described in section 9 should be enabled > > in environments where security threats are suspected. > > > > One of the reasons I would be reluctant to document the > > special case you have described is that, given the same > > kind of security threat you have described, there are probably > > a number of other cases with equal exposure if you were to choose > > to operate without turning on the appropriate IPSec > > security features. > > Ralph pointed out that text to me a while ago. Here's some more > text to consider, from the "Submitting Documents to the IESG" > guidelines at http://www.ietf.org/ID-nits.html - > > Does your document have an adequate security considerations section? > Some have said that the "Security Considerations" section > of a document > essentially helps hackers attack implementations. It may, > but the fact > is that they will do the analysis themselves anyway - not > doing a threat > analysis will not stop them from exploiting weaknesses in > your design. > But by pointing out design choices you have made which have security > implications, or by documenting "when you implement this, you should > make these choices that have security implications", you > may help people > build implementations that are more hacker-proof, and you may find > something you can improve. Frankly, the IESG has so many > documents come > its way which have no thought for security in them it must > return for > the analysis, putting the analysis into the document will be helpful > in getting it through. > > The use of the nonce is a design choice that has security > implications, > and I'm asking that those implications be described. A specific > discussion of other threats to TCP, IP, and protocols that use them > (e.g., address spoofing, TCP connection hijacking, RST attacks) is > not needed beyond something like Ralph's text that notes > their existence. > FCIP did not invent TCP or IP, and hence can rely on other documents > to describe security considerations inherent to those protocols. > FCIP did invent the nonce, and hence needs to describe its security > considerations. David, That is why the nonce got the special treatment of this text (and related text in another section). However, I do not believe the particular scenario is interesting, since anyone who has the combination of resources and unauthorized access necessary to do that evil scenario can do some dozens of other related scenarios at least as evil. Some of them, especially those involving denial of service by flooding, can even be done on the first connection of a link. By providing the example, we may leave the mistaken impression that resolving the security issues of the particular scenario will successfully prevent all attacks. I think the straightforward warning that evil scenarios are possible in this particular environment should be sufficient to call security attention to that area. The simple solution (using IPSec) is offered to guarantee security for environments that can be secured using internet security functions. Of course there are lots of security problems outside the scope of IP, FCIP, and FC, but those are well understood, even though intractable. Bob From owner-ips@ece.cmu.edu Thu Jan 10 19:16: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 TAA26590 for ; Thu, 10 Jan 2002 19:16:58 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0ANOoS12527 for ips-outgoing; Thu, 10 Jan 2002 18:24:50 -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 g0ANOhj12520 for ; Thu, 10 Jan 2002 18:24:43 -0500 (EST) Received: from somesh ([65.172.158.93]) by cleitus.hosting.pacbell.net id SAA22802; Thu, 10 Jan 2002 18:24:37 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Reply-To: From: "Somesh Gupta" To: "Williams, Jim" , Subject: RE: iSCSI: Markers Date: Thu, 10 Jan 2002 15:22:48 -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.00.2919.6700 Importance: Normal In-Reply-To: <3356669BBE90C448AD4645C843E2BF280A058B@xbl.ad.emulex.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I agree that there is no rigorous system level analysis to back this up (no disrespect intended but none has been shared). On the surface it seems it should help. (One area where it should help is in latency reduction). 1. Assuming out of order segments happen due to packet loss (and yes routers have pretty much stopped reordering segments), it has an impact on the TCP send rate - you are really not going to go full speed anymore. 2. The memory requirement is always round trip delay * bandwidth. It is not a product of number of connections & the window size on each connection. Pathological cases can require more memory, but then we have chose TCP because we can recover from lost (or dropped in this case) packets. It is the memory access speed required which is really the problem. At 1 Gig or even multi-1G, it is not an issue today. 3. The processing of Upper Layer Protocol has to wait (at least theoretically) for the out of order segment to arrive. So when out of order segment arrives, we have a flood of protocol processing to take care of - previously received segments, and new segments that are arriving. Anyhow, it is an interesting concept and worth further exploration. Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Williams, Jim > Sent: Thursday, January 10, 2002 1:51 PM > To: ips@ece.cmu.edu > Subject: RE: iSCSI: Markers > > > > > > -----Original Message----- > > From: Somesh Gupta [mailto:somesh_gupta@silverbacksystems.com] > > Sent: Thursday, January 10, 2002 1:48 PM > > To: Stephen Bailey; ips@ece.cmu.edu > > Subject: RE: iSCSI: Markers > > > > > > Jim, > > > > What are the issues with "one PDU per TCP segment"? I > > think this would really enable simple, high performance > > Upper Layer protocol processing over TCP. > > I have some doubts that the ability to place data out > of order will actually result in a more cost effective > NIC. Even without out of order placement, there may > be some benefit to "one PDU per TCP segment", of course > in this case there is no need for markers. > > In any case, the only thing I have objected to is > making markers a requirement to use if other end > requests it. I don't have a problem with making it > an option (both ends agree) and see if it flies. > > > Of course, > > you always have the issue that no matter what method > > is used, data can only be placed and not processed > > out of sequence (which implies that there is additional > > complexity if barrier lists and so on and having to do > > control processing at a faster rate when you do perform > > out of order processing). > > > > Somesh > From owner-ips@ece.cmu.edu Thu Jan 10 22:03: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 WAA29244 for ; Thu, 10 Jan 2002 22:03:30 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0B2Lvk20921 for ips-outgoing; Thu, 10 Jan 2002 21:21:57 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0B2Luj20916 for ; Thu, 10 Jan 2002 21:21:56 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e34.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id VAA23550 for ; Thu, 10 Jan 2002 21:18:55 -0500 Received: from d03nm014.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 g0B2Kb3187566 for ; Thu, 10 Jan 2002 19:20:38 -0700 X-Priority: 1 (High) Importance: Normal Subject: iSCSI: Markers To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Thu, 10 Jan 2002 18:19:50 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 01/10/2002 07:20:38 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk OK, Folks, I have now talked to Steph, who authored TUF, which is currently on the road to Experimental Status, He has authored another version of TUF also, which uses a form of COWS. So that means that we have two different versions of TUF as well as 2 versions of COWS (which are independent of Framing), and then there is FIM. So let me list them and be sure we name them so that we are not in the middle of more confusion. 1. Fixed Interval Markers (FIM) Currently In the iSCSI Draft 2. Constant Overhead Word Stuffing (COWS) as drafted by Julian and sent in his note of 12/23/2001 Subject "iSCSI - Synch an Steering Appendix - Markers & COWS" 3. TCP Upper-layer-protocol Framing (TUF) as drafted by Stephen Bailey in http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-ulp-frame-01.txt 4. COWS Drafted By Stephen Bailey which can be used in both in stream and with Framing in http://www.cs.uchicago.edu/~steph/draft-bailey-tsvwg-cows-00.txt Now lets call Julian's proposal COWS with 2 way pointers (COWS2WP) Now lets call Steph's COWS with 1 way pointers (COWS1WP) When the type of COWS does not matter we can just call them COWS. Both COWS can be used in Framing. But to keep this discussion somewhat simpler lets call the Framing without any COWS as "Bare Framing", and Both of the other as "COWS Framing". Only when we need to talk about which type of COWS should we say "COWS2WP Framing" or "COWS1WP Framing". But for most conversation it should be just "COWS Framing". So we have FIM, COWS1WP, COWS2WP, Bare Framing, & COWS Framing (made up of COWS1WP Framing and COWS2WP Framing). Now we also need to understand that one of the main reasons expressed to make Framing go experimental, instead of Standards Track was that folks were worried that Bare Framing was based on probability, and that there was a very remote possibility that something could be done incorrectly. As a result of that Steph was considering, as part of the experimental work, seeing what the impact of his previous COWS Draft would be on the experimental work that was going to be done. He had no intention of bringing it up now, since he felt work/thought was still needed. As you know COWS came up anyhow (and in a different form). So what we have are statements from folks like me that had read Julian's Draft and the ietf-tsvwg version of Framing (Bare Framing), which did not see in those drafts the overlap. Clearly there is an overlap in the minds of Julian for COWS2WP and Steph for COWS1WP and how they might impact Framing. NET of Bare Framing vs COWS Framing: Bare Framing is based on probability and does not have to inspect each Word (SW or HW) COW requires Touching each Word, COWS Framing is guaranteed to always be correct. So the choices are: 1. FIM now, and Bare Framing later 2. FIM now, and COWS Framing later 3. COWS now, and Bare Framing later 4. COWS now, and COWS Framing Later 5. Nothing now, and some kind of Framing Later If we chose to do any of the "COWS now" options we would need to hold the debate on which form, but we should assume that which ever COWS we chose now is the COWS for later. Value Statements 1. FIM and Bare Framing: Means we never have the overhead of touching every word 2. FIM and COWS Framing: Means that touching is postponed until Framing, and perhaps Faster Desktops/Laptops or support even support in normal NICs. 3. COWS now and Bare Framing later: Has issues of toughing everything now, and then not useful later 4. COWS now and COWS Framing Later: Means always touch, but current approach is extensible into Framing 5.Nothing now, and some kind of Framing later: Means No current help, and no guarantee of help in the future, but some reasonable probability that some form of Framing will happen. So it is 1-5 upon which we should be taking a position. . . . 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 Fri Jan 11 00:01:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01811 for ; Fri, 11 Jan 2002 00:01:30 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0B4CS825851 for ips-outgoing; Thu, 10 Jan 2002 23:12:28 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar1ab.compuserve.com (siaar1ab.compuserve.com [149.174.40.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0B4CQj25846 for ; Thu, 10 Jan 2002 23:12:26 -0500 (EST) Received: (from mailgate@localhost) by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id XAA08669 for ips@ece.cmu.edu; Thu, 10 Jan 2002 23:12:20 -0500 (EST) Received: from compuserve.com (dal-tgn-tvm-vty8.as.wcom.net [206.175.227.8]) by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id XAA08648 for ; Thu, 10 Jan 2002 23:12:17 -0500 (EST) Message-ID: <3C3E6776.3DE48BB9@compuserve.com> Date: Thu, 10 Jan 2002 22:17:58 -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: Re: FCIP: Short Frame Security Solution Proposal References: <277DD60FB639D511AC0400B0D068B71E0293733C@CORPMX14> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Black_David@emc.com wrote: ...big snip... > Does your document have an adequate security > considerations section? ...bigger snip... Oh! So you want this in the Security Considerations section!!! That is a whole different kettle of fish. I need to talk to Venkat and see if he is agreeable, since I fear to tread in the security section without Venkat's able guidance. Stay tuned. Ralph... From owner-ips@ece.cmu.edu Fri Jan 11 00:42: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 AAA02368 for ; Fri, 11 Jan 2002 00:42:48 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0B4xwG28071 for ips-outgoing; Thu, 10 Jan 2002 23:59:58 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ns1.in-biz.net (ptil-196-150-hyd.primus-india.net [203.196.150.196] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0B4xqj28065 for ; Thu, 10 Jan 2002 23:59:53 -0500 (EST) Received: from yahoo.com ([203.196.150.219]) by ns1.in-biz.net (8.9.3/8.9.3) with ESMTP id KAA06942; Fri, 11 Jan 2002 10:28:59 +0530 Message-ID: <3C3E7297.9040901@yahoo.com> Date: Fri, 11 Jan 2002 10:35:27 +0530 From: Ajit Aryan Reply-To: digital_aryan@yahoo.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: John Hufferd CC: ips@ece.cmu.edu Subject: Re: iSCSI: Markers References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Of the five options mentioned should I say, the option 2 is the right kind of thing which provides the necessary flexibility and may be a easier way to implement or to adopt whenever needed. ANY COMMENTS?? Aryan John Hufferd wrote: > OK, Folks, I have now talked to Steph, who authored TUF, which is > currently on the road to Experimental Status, He has authored another > version of TUF also, which uses a form of COWS. So that means that we have > two different versions of TUF as well as 2 versions of COWS (which are > independent of Framing), and then there is FIM. So let me list them and be > sure we name them so that we are not in the middle of more confusion. > > 1. Fixed Interval Markers (FIM) Currently In the iSCSI Draft > 2. Constant Overhead Word Stuffing (COWS) as drafted by Julian and sent in > his note of 12/23/2001 Subject "iSCSI - Synch an Steering Appendix - > Markers & COWS" > 3. TCP Upper-layer-protocol Framing (TUF) as drafted by Stephen Bailey in > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-ulp-frame-01.txt > 4. COWS Drafted By Stephen Bailey which can be used in both in stream and > with Framing in > http://www.cs.uchicago.edu/~steph/draft-bailey-tsvwg-cows-00.txt > > Now lets call Julian's proposal COWS with 2 way pointers (COWS2WP) > Now lets call Steph's COWS with 1 way pointers (COWS1WP) > > When the type of COWS does not matter we can just call them COWS. > > Both COWS can be used in Framing. But to keep this discussion somewhat > simpler lets call the Framing without any COWS as "Bare Framing", and Both > of the other as "COWS Framing". Only when we need to talk about which type > of COWS should we say "COWS2WP Framing" or "COWS1WP Framing". But for most > conversation it should be just "COWS Framing". > > So we have FIM, COWS1WP, COWS2WP, Bare Framing, & COWS Framing (made up of > COWS1WP Framing and COWS2WP Framing). > > Now we also need to understand that one of the main reasons expressed to > make Framing go experimental, instead of Standards Track was that folks > were worried that Bare Framing was based on probability, and that there was > a very remote possibility that something could be done incorrectly. > > As a result of that Steph was considering, as part of the experimental > work, seeing what the impact of his previous COWS Draft would be on the > experimental work that was going to be done. He had no intention of > bringing it up now, since he felt work/thought was still needed. > > As you know COWS came up anyhow (and in a different form). > > So what we have are statements from folks like me that had read Julian's > Draft and the ietf-tsvwg version of Framing (Bare Framing), which did not > see in those drafts the overlap. Clearly there is an overlap in the minds > of Julian for COWS2WP and Steph for COWS1WP and how they might impact > Framing. > > NET of Bare Framing vs COWS Framing: > Bare Framing is based on probability and does not have to inspect each Word > (SW or HW) COW requires Touching each Word, > COWS Framing is guaranteed to always be correct. > > So the choices are: > 1. FIM now, and Bare Framing later > 2. FIM now, and COWS Framing later > 3. COWS now, and Bare Framing later > 4. COWS now, and COWS Framing Later > 5. Nothing now, and some kind of Framing Later > > If we chose to do any of the "COWS now" options we would need to hold the > debate on which form, but we should assume that which ever COWS we chose > now is the COWS for later. > > Value Statements > 1. FIM and Bare Framing: Means we never have the overhead of touching every > word > 2. FIM and COWS Framing: Means that touching is postponed until Framing, > and perhaps Faster Desktops/Laptops or support even support in normal NICs. > 3. COWS now and Bare Framing later: Has issues of toughing everything now, > and then not useful later > 4. COWS now and COWS Framing Later: Means always touch, but current > approach is extensible into Framing > 5.Nothing now, and some kind of Framing later: Means No current help, and > no guarantee of help in the future, but some reasonable probability that > some form of Framing will happen. > > So it is 1-5 upon which we should be taking a position. > . > . > . > 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 Fri Jan 11 06:16: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 GAA13092 for ; Fri, 11 Jan 2002 06:16:06 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0BA0lD09550 for ips-outgoing; Fri, 11 Jan 2002 05:00:47 -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 g0BA0gj09545 for ; Fri, 11 Jan 2002 05:00:42 -0500 (EST) Received: from nramamurpc (nramamur-pc.hcltech.com [192.168.100.98]) by mailnpd.hcltech.com (8.11.0/8.11.0) with SMTP id g0B9uow06558 for ; Fri, 11 Jan 2002 15:26:54 +0530 Message-ID: <00ff01c19a86$ede50930$6264a8c0@hcltech.com> From: "Nandakumar Ramamurthy" To: Subject: iSCSI: Connection termination conditions Date: Fri, 11 Jan 2002 15:31:21 +0530 Organization: HCL Technologies Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 Hi All, Section 2.2.6 specifies two conditions for connection termination : "Graceful connection shutdowns MUST only occur when there are no outstanding tasks that have allegiance to the connection and when the connection is not in full-feature phase." The above statement is ambiguous as to what a graceful connection shutdown is and the conditions in which this may occur. Can "graceful connection shutdown" be elaborated upon? My interpretation is that there could be 2 possible cases when graceful connection termination may occur. They are as follows: 1) A connection logout with no outstanding allegiant tasks is the first condition. In this case, the state of the connection is full feature. 2) The second case is when the connection is shutdown and the connection state is not in full feature phase i.e., in SecurityNegotiation or LoginOperationalNegotiation phase. Is that the correct interpretation? Thanks, Nandakumar Member Technical Staff HCL Technologies, Chennai, INDIA. http://san.hcltech.com From owner-ips@ece.cmu.edu Fri Jan 11 10:40: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 KAA18299 for ; Fri, 11 Jan 2002 10:40:01 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0BEpqP04281 for ips-outgoing; Fri, 11 Jan 2002 09:51:52 -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 g0BEpoj04275 for ; Fri, 11 Jan 2002 09:51:50 -0500 (EST) Received: from deneb.dev.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g0BEphH02358; Fri, 11 Jan 2002 09:51:43 -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 g0BEphc13133; Fri, 11 Jan 2002 09:51:43 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15422.64511.465923.312866@pkoning.dev.equallogic.com> Date: Fri, 11 Jan 2002 09:51:43 -0500 (EST) From: Paul Koning To: hufferd@us.ibm.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: Markers References: 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 Apart from taking a position on 1-5, we need to take a position on mandatory vs. optional to implement. I don't have strong views right now on which of 1-5 is best for those who want to cast their iSCSI protocol processing into silicon. But I do have views on what these things cost in software, so for any of options 1..4 I would object to a "mandatory to implement" requirement. paul From owner-ips@ece.cmu.edu Fri Jan 11 11:37: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 LAA20740 for ; Fri, 11 Jan 2002 11:37:57 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0BFgQ707548 for ips-outgoing; Fri, 11 Jan 2002 10:42:26 -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 g0BFgPj07542 for ; Fri, 11 Jan 2002 10:42:25 -0500 (EST) Received: from bursar.muttsnuts.com (193.120.246.22) by mail.san.yahoo.com (5.5.054.2) id 3C363D10000A4574 for ips@ece.cmu.edu; Fri, 11 Jan 2002 07:42:02 -0800 Message-Id: <5.1.0.14.2.20020111153339.033766d0@mail.muttsnuts.com> X-Sender: markemuttsnuts@mail.muttsnuts.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 11 Jan 2002 15:34:43 +0000 To: ips@ece.cmu.edu From: "Mark S. Edwards" Subject: Re: iSCSI: Markers In-Reply-To: <15422.64511.465923.312866@pkoning.dev.equallogic.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ips@ece.cmu.edu Precedence: bulk At 09:51 AM 1/11/2002 -0500, Paul Koning wrote: >Apart from taking a position on 1-5, we need to take a position on >mandatory vs. optional to implement. > >I don't have strong views right now on which of 1-5 is best for those >who want to cast their iSCSI protocol processing into silicon. But I >do have views on what these things cost in software, so for any of >options 1..4 I would object to a "mandatory to implement" requirement. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Ditto. Mark. From owner-ips@ece.cmu.edu Fri Jan 11 13:20: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 NAA24422 for ; Fri, 11 Jan 2002 13:20:41 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0BHVlm14342 for ips-outgoing; Fri, 11 Jan 2002 12:31:47 -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 g0BHVjj14338 for ; Fri, 11 Jan 2002 12:31:45 -0500 (EST) Received: from amirdesktop (dhcp62 [172.21.2.62]) by astutenetworks.com (8.11.6/8.11.2) with SMTP id g0BHT6i27327; Fri, 11 Jan 2002 09:29:06 -0800 From: "Amir Shalit" To: "Paul Koning" , Cc: Subject: RE: iSCSI: Markers Date: Fri, 11 Jan 2002 09:29: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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <15422.64511.465923.312866@pkoning.dev.equallogic.com> Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Any option that requires you to touch every byte is not Silicon friendly. In other words, only FIM and bare framing (TUF) are acceptable. Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Paul Koning Sent: Friday, January 11, 2002 6:52 AM To: hufferd@us.ibm.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: Markers Apart from taking a position on 1-5, we need to take a position on mandatory vs. optional to implement. I don't have strong views right now on which of 1-5 is best for those who want to cast their iSCSI protocol processing into silicon. But I do have views on what these things cost in software, so for any of options 1..4 I would object to a "mandatory to implement" requirement. paul From owner-ips@ece.cmu.edu Fri Jan 11 16:03: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 QAA29511 for ; Fri, 11 Jan 2002 16:03:45 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0BKOBU25310 for ips-outgoing; Fri, 11 Jan 2002 15:24:11 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from osmtp3.electric.net (osmtp1.electric.net [216.129.90.28]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0BKO9j25302 for ; Fri, 11 Jan 2002 15:24:09 -0500 (EST) Received: from [64.170.220.9] (helo=EGRodriguez) by osmtp3.electric.net with esmtp (Exim 3.22 #1) id 16P8DY-000Gka-04 for ips@ece.cmu.edu; Fri, 11 Jan 2002 12:24:04 -0800 Reply-To: From: "Elizabeth G. Rodriguez" To: Subject: IPS-ALL: Document submission cutoff date for interim meeting -- Jan 22 Date: Fri, 11 Jan 2002 14:21:38 -0600 Message-ID: <009901c19add$9f447c00$09dcaa40@EGRodriguez> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009A_01C19AAB.54AA0C00" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal 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_009A_01C19AAB.54AA0C00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, The document submission cutoff date for the interim meeting is Tuesday, Jan 22 at 5pm EST. Please have any documents to be discussed at the interim meeting in Huntington Beach Feb 6-8 posted to IETF by that time. Thank you, Elizabeth and David P.S. - Anyone wanting more information about the Interim meeting can find the announcement at http://www.ietf.org/IESG/IPS-Interim.txt ------=_NextPart_000_009A_01C19AAB.54AA0C00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

The document submission cutoff date for the interim = meeting is Tuesday, Jan 22 at 5pm EST.

 

Please have any documents to be discussed at the = interim meeting in Huntington Beach Feb 6-8 posted to IETF by = that time.

 

Thank you,

 

Elizabeth and David

 

P.S. – Anyone wanting more information about = the Interim meeting can find the announcement at

http://www.ietf.org/IES= G/IPS-Interim.txt

 

 

------=_NextPart_000_009A_01C19AAB.54AA0C00-- From owner-ips@ece.cmu.edu Fri Jan 11 16:10:28 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29727 for ; Fri, 11 Jan 2002 16:10:27 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0BKQdQ25442 for ips-outgoing; Fri, 11 Jan 2002 15:26:39 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from relay2.softcomca.com (relay.softcomca.com [168.144.1.68] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0BKQcj25438 for ; Fri, 11 Jan 2002 15:26:38 -0500 (EST) Received: from m2w035 ([168.144.108.35]) by relay2.softcomca.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 11 Jan 2002 15:26:44 -0500 X-Originating-IP: 64.170.220.19 X-URL: http://www.mail2web.com/ Subject: RE: Re: iSCSI: Markers From: "rakesh@qpackets.com" Date: Fri, 11 Jan 2002 15:26:51 -0500 To: "hufferd@us.ibm.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: 11 Jan 2002 20:26:44.0737 (UTC) FILETIME=[495D8F10:01C19ADE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by ece.cmu.edu id g0BKQcj25439 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit My two cents worth in response to John's comments. Before making any proposals and/or vote on choices we should be able to understand two things. 1) why do we need framing? 2) based on the application (iscsi hardware or software assist) which framing technique will make more sense? - Rakesh John Hufferd wrote: > OK, Folks, I have now talked to Steph, who authored TUF, which is > currently on the road to Experimental Status, He has authored another > version of TUF also, which uses a form of COWS. So that means that we have > two different versions of TUF as well as 2 versions of COWS (which are > independent of Framing), and then there is FIM. So let me list them and be > sure we name them so that we are not in the middle of more confusion. > > 1. Fixed Interval Markers (FIM) Currently In the iSCSI Draft > 2. Constant Overhead Word Stuffing (COWS) as drafted by Julian and sent in > his note of 12/23/2001 Subject "iSCSI - Synch an Steering Appendix - > Markers & COWS" > 3. TCP Upper-layer-protocol Framing (TUF) as drafted by Stephen Bailey in > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-ulp-frame-01.txt > 4. COWS Drafted By Stephen Bailey which can be used in both in stream and > with Framing in > http://www.cs.uchicago.edu/~steph/draft-bailey-tsvwg-cows-00.txt > > Now lets call Julian's proposal COWS with 2 way pointers (COWS2WP) > Now lets call Steph's COWS with 1 way pointers (COWS1WP) > > When the type of COWS does not matter we can just call them COWS. > > Both COWS can be used in Framing. But to keep this discussion somewhat > simpler lets call the Framing without any COWS as "Bare Framing", and Both > of the other as "COWS Framing". Only when we need to talk about which type > of COWS should we say "COWS2WP Framing" or "COWS1WP Framing". But for most > conversation it should be just "COWS Framing". > > So we have FIM, COWS1WP, COWS2WP, Bare Framing, & COWS Framing (made up of > COWS1WP Framing and COWS2WP Framing). > > Now we also need to understand that one of the main reasons expressed to > make Framing go experimental, instead of Standards Track was that folks > were worried that Bare Framing was based on probability, and that there was > a very remote possibility that something could be done incorrectly. > > As a result of that Steph was considering, as part of the experimental > work, seeing what the impact of his previous COWS Draft would be on the > experimental work that was going to be done. He had no intention of > bringing it up now, since he felt work/thought was still needed. > > As you know COWS came up anyhow (and in a different form). > > So what we have are statements from folks like me that had read Julian's > Draft and the ietf-tsvwg version of Framing (Bare Framing), which did not > see in those drafts the overlap. Clearly there is an overlap in the minds > of Julian for COWS2WP and Steph for COWS1WP and how they might impact > Framing. > > NET of Bare Framing vs COWS Framing: > Bare Framing is based on probability and does not have to inspect each Word > (SW or HW) COW requires Touching each Word, > COWS Framing is guaranteed to always be correct. > > So the choices are: > 1. FIM now, and Bare Framing later > 2. FIM now, and COWS Framing later > 3. COWS now, and Bare Framing later > 4. COWS now, and COWS Framing Later > 5. Nothing now, and some kind of Framing Later > > If we chose to do any of the "COWS now" options we would need to hold the > debate on which form, but we should assume that which ever COWS we chose > now is the COWS for later. > > Value Statements > 1. FIM and Bare Framing: Means we never have the overhead of touching every > word > 2. FIM and COWS Framing: Means that touching is postponed until Framing, > and perhaps Faster Desktops/Laptops or support even support in normal NICs. > 3. COWS now and Bare Framing later: Has issues of toughing everything now, > and then not useful later > 4. COWS now and COWS Framing Later: Means always touch, but current > approach is extensible into Framing > 5.Nothing now, and some kind of Framing later: Means No current help, and > no guarantee of help in the future, but some reasonable probability that > some form of Framing will happen. > > So it is 1-5 upon which we should be taking a position. > . > . > . > 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 > > -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . From owner-ips@ece.cmu.edu Fri Jan 11 16:12:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29762 for ; Fri, 11 Jan 2002 16:12:01 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0BKuXU27465 for ips-outgoing; Fri, 11 Jan 2002 15:56:33 -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 g0BKuVj27460 for ; Fri, 11 Jan 2002 15:56:31 -0500 (EST) Received: from alacritech.com (lambda.alacritech.com [10.1.1.32]) by smtp.alacritech.com (8.11.2/8.11.2) with ESMTP id g0BKmmU04377; Fri, 11 Jan 2002 12:48:48 -0800 Message-ID: <3C3F6179.5B5E7357@alacritech.com> Date: Fri, 11 Jan 2002 14:04:41 -0800 From: "Matt D. Robinson" Organization: Alacritech, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2smp i686) X-Accept-Language: en MIME-Version: 1.0 To: "Mark S. Edwards" CC: ips@ece.cmu.edu Subject: Re: iSCSI: Markers References: <5.1.0.14.2.20020111153339.033766d0@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 S. Edwards" wrote: > > At 09:51 AM 1/11/2002 -0500, Paul Koning wrote: > >Apart from taking a position on 1-5, we need to take a position on > >mandatory vs. optional to implement. > > > >I don't have strong views right now on which of 1-5 is best for those > >who want to cast their iSCSI protocol processing into silicon. But I > >do have views on what these things cost in software, so for any of > >options 1..4 I would object to a "mandatory to implement" requirement. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Ditto. > > Mark. I concur. --Matt From owner-ips@ece.cmu.edu Fri Jan 11 17:23:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01912 for ; Fri, 11 Jan 2002 17:23:07 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0BLYg229960 for ips-outgoing; Fri, 11 Jan 2002 16:34:42 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0BLYej29956 for ; Fri, 11 Jan 2002 16:34:40 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.99.140.22]) by e34.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA101430 for ; Fri, 11 Jan 2002 16:31:39 -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 g0BLYZn98748 for ; Fri, 11 Jan 2002 14:34:35 -0700 X-Priority: 1 (High) Importance: Normal Subject: iSCSI: Markers and Framing To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Fri, 11 Jan 2002 13:33:50 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 01/11/2002 02:34:35 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk In addition to the 5 options 1. FIM now, and Bare Framing later 2. FIM now, and COWS Framing later 3. COWS now, and Bare Framing later 4. COWS now, and COWS Framing Later 5. Nothing now, and some kind of Framing Later I have been asked to add a number six. as follows 6. FIM now, and some kind of Framing Later . . . 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 Fri Jan 11 20:24: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 UAA04178 for ; Fri, 11 Jan 2002 20:24:28 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0C0fNU10149 for ips-outgoing; Fri, 11 Jan 2002 19:41:23 -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 g0C0fMj10145 for ; Fri, 11 Jan 2002 19:41:22 -0500 (EST) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Jan 2002 19:43:59 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0293734F@CORPMX14> From: Black_David@emc.com To: jonathan@dsg.stanford.edu Cc: ips@ece.cmu.edu Subject: iSCSI TUF/PDU alignment - Procedural clarification Date: Fri, 11 Jan 2002 19:28: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 Jonathan Stone was quoted out of context in the original message I sent. With my apologies to Jonathan, here's the complete context followed by text reflecting the context: [Somesh Gupta] > >I think the objections are to more to changing TCP wire > >protocol (i.e. header) than to the implementation. [.. snip ..] [Jonathan Stone] > I can, and do, change my TCP implementation. The gotcha is that > folding another operation into the existing loops in my TCP protocol-- > whether it's COBS or COWS or a CRC -- *IS* changing my TCP > implementation. Even if it doesn't change the on-the wire semantics, > its still a change to my TCP. > > In fact, it's easier for me to change my TCP to make it guarantee to > preserve any segment boundaries between iSCSI PDUs[*], than it is to > fold iSCSI-PDU processing into TCP processing. > > > [*] when sending/retransmitting, that is. > If we could guarantee that, hardware-accelerated receiers could use a > TCP header option to indicate start-of-frame in this segment, and be > done with it. I'd even to go to bat with the transport-area > representative, arguing that the ratio of iSCSI PDUs to expected drops > is ``small enough'' that using that portion of the limited TCP option > space for non-SACK usage was in fact a good trade-off. (My > understanding is that it's not really necessary to mark *all* PDU > boundaries, just to mark enough of them to permit a reassembly buffer > significantly smaller than BW*RTT, which therefore doesn't require > lots of external SRAM; while still allowing direct data placement.) > > I understand that door is well and truly closed, though. [David Black] Indeed it is. In general, TCP header options and changes to TCP sending behavior are tsvwg topics, and further discussion of them should take place on the tsvwg list rather than here. 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 Jan 11 21:20: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 VAA04580 for ; Fri, 11 Jan 2002 21:20:52 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0C1pL113426 for ips-outgoing; Fri, 11 Jan 2002 20:51:21 -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 g0C1pJj13421 for ; Fri, 11 Jan 2002 20:51:19 -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 RAA03364; Fri, 11 Jan 2002 17:51:13 -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 RAA00504; Fri, 11 Jan 2002 17:35:01 -0800 (PST) Received: by aimexc07.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Jan 2002 17:51:12 -0800 Message-ID: From: "Mukund, Shridhar" To: "'John Hufferd'" , ips@ece.cmu.edu Cc: "Sperry, Todd" , "Munnangi, Siva" Subject: RE: iSCSI: Markers and Framing Date: Fri, 11 Jan 2002 17:51:12 -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, As an implementer of silicon solutions up to 10Gbps, my take is ... 1. Election # 6. FIM now and some kind of framing later. Comments: a. By framing I mean what ever method iWarp effort ends up with. (TUF as proposed today may not be it) b. I strongly recommend SHOULD implement FIM on the send side. Implication -> Senders that do not insert markers should be willing to accept up to RTT*BW data drops! Headers being "reasonably" out-of-order is OK. Of course, senders that do not insert markers but are willing to pay big $$$ to the SSP will get their buffer/BW allocation as usual and customary :-) c. I think that the proponents and beholders of FIM had good reasons. They still hold and are even more stronger. We have had FIM in the iSCSI spec since version 02. Major changes to the iSCSI draft, at this late date, should have significant technical reasons. 2. COBS is a good solution for the problem that Stuart and Mary originally set out to solve at Stanford. It's(COWS) use in the context of iSCSI is "misuse" at best, esp. given that the use of virgin TCP for transport is mandatory(for good reasons). Several of you have alluded to why COWS is nasty to implement ... I prefer not to get there. Markers on the other hand do bring in some "essential" complexity but they are reasonable to implement even at 10Gbps. We sure could brute-force COWS, but the point is why the additional "incidental" complexity. Do not read further, unless you are open to ... :-) -Shridhar Mukund --------------------------------------------------------------------------- CAUTION: MANDATORY to delete and OPTIONAL to read >> Wouldn't it be stupid if we had a proliferation of framing >> alternatives just because the "world originally seemed flat"? (My apology to Stephen Bailey for taking the quote out of context) A packetized HDLC stream(for which COBS was designed) has one whole space-time dimension lesser than a TCP stream. Relative to TCP stream, packetized HDLC stream is a flat world! As I see it, COBS is an alternative coding technique that makes delimiters explicit in an otherwise reference-less "sequence" or byte/word-stream. A reference-less sequence is assumed to have no ends or gradations. Yet the encoded sequence exposes 'handles' for synchronization. -> relatively synchronous after encoding. TCP stream on the other hand is a "time-sequence". It starts with a big-bang after which every byte in the sequence has an explicit time(sequence number) associated with it. -> It is absolutely synchronous even to begin with! The increase in entropy because of assuming a time-sequence to be a mere-sequence is probably :-) demonstrated by the following: In the Marker lingo : My second son was born in 99 and my first son in 94. Of course, 1900 AD is the marker here. In the COW's moo: My second son was born 20 blue moons after my first son. My first son ... I have no clue? Usage of COWS over TCP transport would be like loosing a needle in the hay stack, on purpose, and then devising a clever scheme to retrieve it. If you read on further, you may be wasting your time ... Are you certain that the world is round? If you read Stephen Hawkings or an article from Stanford in Scientific American 3 blue moons ago, there is scientific evidence of higher dimensions beyond the 4 space-time dimensions we perceive. In other words, round world might just be an illusion or a convenient definition of what we perceive! When I am using maps, flat world seems perfectly fine to me. Since a mere-sequence is a one dimensional space and a time-sequence like TCP stream is two-dimensional, COBS needs to work harder with packetized HDLC sequences. If COBS looks simpler than FIM, it is just an artifact your specific implementation. Q.E.D. -Merlin's apprentice From owner-ips@ece.cmu.edu Fri Jan 11 21:22: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 VAA04597 for ; Fri, 11 Jan 2002 21:22:41 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0C1fP212977 for ips-outgoing; Fri, 11 Jan 2002 20:41:25 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lightsand.com ([64.214.104.163]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0C0r2j10718 for ; Fri, 11 Jan 2002 19:53:03 -0500 (EST) Received: from andyhibmlaptop (dhcp093.lightsand.com [192.168.1.93]) by lightsand.com (8.9.3+Sun/8.9.1) with SMTP id QAA11613; Fri, 11 Jan 2002 16:52:53 -0800 (PST) From: "Andy Helland" To: "ips reflector" , "Bill Krieg" , "Andy Helland" , "Anil Rijhsinghani" , "Bob Snively" , "Craig Carlson" , "Dave Peterson" , "Don Fraser" , "Elizabeth Rodriguez" , "Gaby Hecht" , "Jim Nelson" , "Ken Hirata" , "Kha Sin Teow" , "Lawrence J. Lamers" , "Mike O'Donnell" , "Milan Merhar" , "Murali Rajagopal" , "Neil Wanamaker" , "Raj Bhagwat" , "Ralph Weber" , "Scott Kipp" , "Sriram Rupanagunta" , "Steve Wilson" , "Venkat Rangan" , "Vi Chau" , "Yaronl@Siliquent.Com" Subject: Minutes from FCIP concall 1/9/02 Date: Fri, 11 Jan 2002 16:56:31 -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) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Attendees Anil Rijhsinghani, Elizabeth Rodriguez, Larry Lamers, Ralph Weber, Neil Wanamaker, Murali Rajagopal, Jim Nelson, Milan Merhar, Kha Sin Teow, Bill Krieg, Dave Peterson, Don Fraser, Bob Snively, Raj Bhagwat, Venkat Rangan, Bret Ketchum, and Andy Helland (designated scribe) ---------------------------- Agenda agreed to as follows 1) Discussion on FCIP Requirements to FC-BB-2 2) Comment resolution - Bill - Murali - Neil 3) Other New Business 3) Next Call Host and Time --------------------------- FC-BB-2 issues for T11 Huntington Beach that involve FCIP Ralph will address BB-2 Requirements for Special Frame Security Proposal. Bret Ketchum will bring a "B_Port" proposal. -------------------------- Murali's comments Clarification needed for Section 4, Item 14: "This specification relies on both TCP and FC error recovery mechanisms to detect and recover from data loss and corruption within the IP Network." I think the intent of this item and what is written might have been different. Perhaps the following will mend this sentence: "On a given TCP Connection, this specification relies on TCP to detect and recover from data loss and corruption within the IP Network. This specification, also describes other mechanisms to detect data corruption causing loss of synchronization not detected by TCP." I am not clear why we need to mention the part about FC errory mechanisms in this context. Discussion regarding error recovery and the need (or lack of need) for FC based error recovery in FCIP. text amended to read: "14) This specification contains only limited error detection and recovery mechanisms and relies on both TCP and FC to handle data loss and corruption within the IP Network." -------------------------- Murali's comments Clarification on Section 4, Item 10: 10) Each FCIP Entity is statically or dynamically configured with a list of IP addresses and port numbers corresponding to participating FCIP Entities. If dynamic discovery of participating FCIP Entities is supported, the function SHALL be performed using the Service Location Protocol (SLPv2) [24]. It is outside the scope of this specification to describe any static configuration method for participating FCIP Entity discovery. Refer to section 8.1.4 for a detailed description of dynamic discovery of participating FCIP Entities using SLPv2. I am not sure what port numbers we are refering to in the above. Text amended to explicitly call out "TCP" port numbers -------------------------- Neil's comments 1. first sentence. FC is no longer limited to gigabit speeds. Suggest "...gigabit or multi-gigabit..." 3. last sentence. Rather than "..used by the FCIP protocol", perhaps "...used during FCIP connection establishment and authentication". 5.1 Last sentence. I'd argue that the objective is to transport data between E_Ports over an IP link. Creation and maintenance of FCIP links does not sound like a constructive activity. 5.3 second paragraph, last sentence. I don't believe that "loop primitive signals cannot be encapsulated for transmission over TCP.". Maybe we chose not to, and there are lots of good reasons not to do it, but cannot?? 5.6.1 last sentence on page 15. Change "Word 1 of the Protocol Specific Field" to "The first word of the Protocol Specific Field". Table 1 Note 1. Change to "...changes resulting from transmission errors..." 6. Replace the first sentence with "The FC entity SHALL implement the measurement of Fibre Channel frame transit time as described in section 4 of FC Frame Encapsulation [26]." The "setup" and "verification" components of the frame transit time function are not readily identifiable, nor is it clear what parts of [26] section 4 that are not required. 6. A note as to the reason for sending/accepting frames without timestamps might be useful here. Fig 9. The notation for word 3 is confusing. At first reading I took the fields to represent ranges rather than the contents of separate bytes. Even 3F for -Flags is somewhat unnatural (FC anyone???). 7. last paragraph. The paragraph reads as though the first list of contents, as well as the "other new connect information" comes from the connection request; perhaps rather than "for each new incoming TCP connection request received" say "when an FCIP special frame is received" Results from discussion: 1) add reference to higher than Gigabit per second rates 3) remove Section 3 (Terminology) definition of SF 5.1) Comment accepted. Text amended to reflect the real purpose is the transort data... 5.3) Not accepted. 5.6.1) Not accepted. Table 1, Note 1. Typo error. Comment accepted. 6) Issue #1. Accepted. Change SHALL to MUST. 6) Issue #2. Not accepted. 9) Ralph will get out his Dart Board and randomly add some obscure base notation (perhaps binary is best...). On a more realistic note, check out RFC 1483. 7) Add text "and subsequent special frame". Ralph will continue wordsmithing. ------------------------ Murali's comments. Item 10 is a good summary of the supported "Discovery methods". I was hoping for a brief summary about what information is learnt from such a discovery process. A proposed item that might follow item 10 could be: New 11) Before creating a TCP Connection to a peer FCIP Entity, the FCIP Entity shall statically or dynamically determine the IP address, expected FC Fabric Entity World Wide Name, TCP Connection Parameters, and Quality of Service Information. Or you could combine this with existing Item 10. One other point of clarification: Section 8.1.3 states that a discovering the need for a new TCP connection for the non-dynamic case. How is need made known? Comments accepted. ------------------------ Bill Krieg's comments. While reading through the draft I have the following observations to make: 1. In section 3 the definitions for "FCIP Data Engine" and "FCIP Link Endpoint" are nearly identical. I suggest that we clarify the "FCIP Link Endpoint" definition to state something like: FCIP Link Endpoint (FCIP_LEP) - The component of an FCIP Entity that contains one or more FCIP_DE's (see section 5.5). 2. In section 3 the definition of "Special Frame" could be extended to help identify its role. Suggested text to be added at the end of the definition is: ".....during the TCP connection setup phase (see section 7)." 3. just a nit ... I would suggest renaming section 4 to something like "FCIP Protocol Overview". "Protocol Summary" doesn't seem to clearly identify the section. 4. The wording on the left side of Fig. 6 in section 5.6 should be change from "Fibre Channel" to "FC Entity" if we want to maintain continuity with Fig. 5. 5. Section 7 Figure 10 and the following text should be updated to include class 4 (SOF?4) values. Comments accepted. ------------------------ Reference David Black email to IPS reflector (1/8/02 2:58 PM) Ralph will add annex to describe race condition. ------------------------ Discussion of "Author Lists growing in size" Vote taken by Authors. Unanimous consensus of FCIP authors that all current authors (as of FCIP r07c) have made substantial contributions to the FCIP RFC and should remain on list. Unanimous consensus that Bill Krieg (Lucent) should be added to author's list. (Welcome aboard, Bill!) ------------------------------ Ralph will release FCIP r07d on 1/10/02. Comments from authors MUST be received by Ralph NLT Friday 1/12/02 12:01 PM CST. -------------------------------- Next Concall will be Tuesday 1/15/02. 1:00 PM PST. Duration 1 hour. Primary Topic: Security (Venkat). Bill Krieg to make arrangements and take minutes. -Andy From owner-ips@ece.cmu.edu Fri Jan 11 21:24:49 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04616 for ; Fri, 11 Jan 2002 21:24:49 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0C1daj12903 for ips-outgoing; Fri, 11 Jan 2002 20:39:36 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0C1dYj12899 for ; Fri, 11 Jan 2002 20:39:34 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g0C1dV101179 for ; Fri, 11 Jan 2002 17:39:31 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 11 Jan 2002 17:39:16 -0800 Received: from [17.202.44.113] (chesh1.apple.com [17.202.44.113]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id g0C1dG627546; Fri, 11 Jan 2002 17:39:16 -0800 (PST) Message-Id: <200201120139.g0C1dG627546@scv3.apple.com> Subject: Re: iSCSI: Markers Date: Fri, 11 Jan 2002 17:39:17 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "John Hufferd" , Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ips@ece.cmu.edu Precedence: bulk I'm new to this list, so I should introduce myself. My name is Stuart Cheshire; I'm the author of Consistent Overhead Byte Stuffing (COBS), the framing technique from which COWS derives. I'm not working on any iSCSI product, but if COBS can contribute to iSCSI, then I'm happy to offer a little of my time, as much as I can spare, to help clarify what COWS does and does not do, to help people make an informed decision whether or not COWS is the right solution for iSCSI. ---- Assumption: A high-performance receiver is harder than a high-performance sender. This is because the sender is in control. It knows where the data is coming from in memory, and where it is going to on the network. The sending host knows and can control all aspects of the communication: what order iSCSI messages are delivered onto the wire, how big each one is, and at what time they are sent. If the sender wants to do some kind of housekeeping that prevents it from sending packets for a few milliseconds, then it has the option of doing that without terrible consequences. The receiver has a much harder time. It never knows what packet is going to arrive next, or how big it will be, or where it will be from, or where it will have to go to in memory. Packet loss/corruption/reordering makes things even more unpredictable. A receiver doesn't have the luxury of being able to not receive packets for a few milliseconds if it is busy with something else. For this reason, it makes sense to see what the sender can do to make the receiver's life a little easier. If the receiver could receive each TCP segment and process it in isolation, determining where to place it in memory solely from information within that TCP segment, without reference to data from other TCP segments (which may not have arrived yet), then it would be easier to make a high-performance receiver. What can we do to enable independent segment processing and idempotent direct data placement at the receiver? My first choice would be to add a couple of extra bits to the TCP header; a "start of message" bit and an "end of message" bit. The "start of message" bit indicates that the first byte of TCP data in the segment is also the first byte of an iSCSI message; the "end of message" bit indicates that the last byte of TCP data in the segment is also the last byte of an iSCSI message. When a receiver receives a TCP segment with both bits set, it knows with certainty that it has one (or more) complete iSCSI messages in the TCP segment and can immediately decode enough of the iSCSI message header(s) to determine where in memory to place the data. Unfortunately, adding extra bits to the TCP header is not viable. From a political point of view, trying to change the TCP on-the-wire protocol is a non-starter. From a practical point of view, there are too many routers and firewalls and similar devices that will throw away TCP packets with bits they don't understand. Given that out-of-band framing using header bits is not possible, the alternative is in-band framing using only information in the TCP data stream itself. If we can design our sender to normally send exactly one iSCSI message per TCP segment, and we have a way for our receiver to reliably verify that the received TCP segment contains exactly one iSCSI message, then the receiver can implement idempotent direct data placement for each TCP segment as it is received, without reference to state from previous TCP segments on that connection (which may not have arrived yet). The problem left to solve is how the receiver can reliably verify that the received TCP segment contains exactly one iSCSI message. It can do this by checking to see whether the TCP segment data begins with some special marker pattern, as long as it knows that this special marker pattern cannot appear anywhere within the body of valid iSCSI message data. This necessarily entails processing ("stuffing") the body of the iSCSI message to eliminate inadvertent occurrences of the special marker pattern before sending, and then reversing this transformation to restore the original data after reception. If the receiver finds that the segment does not begin with the special marker pattern, then it knows that the sender segmentation has not been maintained (or it is talking to an old TCP sender that doesn't support sender segmentation) and it has to fall back to treating the TCP data stream as a raw unstructured byte stream, with message boundaries indicated by occurrences of the the marker pattern. The important thing is that the receiver still works correctly, even though the performance will be lower. This prefer-sender-segmentation-but-verify approach is important. If the outgoing data is not processed to guarantee that the special marker pattern cannot occur, then malicious users might be able to subvert the protocol by putting contrived patterns in their data. Remember the days where you could make a user's modem hang up by sending them an email containing the text "+++ATH"? (Apologies to anyone reading this via modem who just had their telephone line hang up.) Another benefit of using in-band framing like this is that we can deploy it immediately using unmodified TCP stacks. In the future we can use enhanced sender TCP implementations that take steps to maintain segment boundaries, and smart receivers will get a performance boost from that, but it is a compatible upgrade that changes only the implementation, not the on-the-wire protocol. Of course, we don't get anything for free. If we want to receiver to be able to determine with 100% certainty that it has received a complete iSCSI message in one TCP segment, then the sender will have to do some work to enable that. This is the cost of COWS. It gives 100% framing certainty, but at the cost of checking the outgoing data for inadvertent occurrences of the special marker pattern, and eliminating them. There's no way for a sender to tell whether the outgoing data contains inadvertent occurrences of the special marker pattern if the sender is not willing to look at the data. On the plus side, the cost of COWS encoding is modest compared to some alternatives. COWS-encoding adds a little header but otherwise doesn't change the size of the outgoing data, ever. No matter how many occurrences of the framing marker pattern are found, the encoded output length is always exactly the same: the length of the input plus the length of the fixed-size framing header (typically two words). If the framing marker pattern is chosen to be something that is rare in normal (non-malicious) data, then in the common-case the encoding step will be a read-only operation: scan the data, determine that it contains no framing markers, set the COWS header to indicate that the data contains no framing markers, and send it. In contrast, when using Fixed Interval Markers, if a marker happens to fall in the middle of the data you are sending, then it creates a 'hole' in the middle of data that used to be contiguous, and the block of outgoing data changes size. On the receiving side, the 'hole' created by the marker has to be repaired in the process of transferring the data into memory. When using Fixed Interval Markers, when a receiver gets a TCP segment that contains no marker, it cannot reliably determine what it is supposed to do with that segment (where to put it in memory) without referring the state from the previous TCP segments of that connection. I don't believe that FIM can provide efficient idempotent direct data placement for inbound TCP segments, because you can't rely on any given received segment containing a marker via which the receiver can verify that the segment contains a complete iSCSI message. In summary: My first choice would be to modify the TCP protocol to support preservation of upper-level message boundaries. Given that this is not possible, I think COWS provdes a good alternative. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-ips@ece.cmu.edu Sat Jan 12 08:44: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 IAA20475 for ; Sat, 12 Jan 2002 08:44:20 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0CD1XA22304 for ips-outgoing; Sat, 12 Jan 2002 08:01:33 -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 g0CD1Vj22299 for ; Sat, 12 Jan 2002 08:01:32 -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 HAA153934; Sat, 12 Jan 2002 07:58:31 -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 g0CD1Un98666; Sat, 12 Jan 2002 06:01:30 -0700 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: Markers To: Stuart Cheshire Cc: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Sat, 12 Jan 2002 03:17:33 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 01/12/2002 06:01:29 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Stuart, thanks for the contribution. I found your views interesting, however, in the last part of your message, when you attempted to contrast it to FIM, you mixed a Framing discussion with a marker discussion. Here is what I mean: You made much of your arguments to address COWS as being part of a Framing (Forcing Segmentation alignment with PDUs). Many of us are already a fan of Framing, and understand that both the Key+length and COWS have an important debate to hold with lots of real world ASIC Vendor Input needed. But then you jumped to contrasting COWS with Framing vrs FIM. That has not been the focus of the discussion. I can not think of anyone that is suggesting FIM in place of any Framing approach. Framing is the goal, and honest debate on the Type, will be needed and be useful. The debate then occurs in two areas, what do we do until we have a Framing solution (Framing being out of the domain of iSCSI, so we must wait until one is accepted before we can point to it.), and what kind of a Framing solution should we wish, so that we can influence the Framing debate. Hence the Six Options. So some of your discussions on COWS, is completely valid for Framing, but is not quite as useful, without framing. When it comes to not having Framing (with Segmentation starts, etc) some will argue that COWS is much more complex, and much higher overhead. So again, thank you for your contribution, I just wanted to correct that slight misalignment at the end of your note. . . . 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 Stuart Cheshire on 01/11/2002 05:39:17 PM To: John Hufferd/San Jose/IBM@IBMUS, cc: Subject: Re: iSCSI: Markers I'm new to this list, so I should introduce myself. My name is Stuart Cheshire; I'm the author of Consistent Overhead Byte Stuffing (COBS), the framing technique from which COWS derives. I'm not working on any iSCSI product, but if COBS can contribute to iSCSI, then I'm happy to offer a little of my time, as much as I can spare, to help clarify what COWS does and does not do, to help people make an informed decision whether or not COWS is the right solution for iSCSI. ---- Assumption: A high-performance receiver is harder than a high-performance sender. This is because the sender is in control. It knows where the data is coming from in memory, and where it is going to on the network. The sending host knows and can control all aspects of the communication: what order iSCSI messages are delivered onto the wire, how big each one is, and at what time they are sent. If the sender wants to do some kind of housekeeping that prevents it from sending packets for a few milliseconds, then it has the option of doing that without terrible consequences. The receiver has a much harder time. It never knows what packet is going to arrive next, or how big it will be, or where it will be from, or where it will have to go to in memory. Packet loss/corruption/reordering makes things even more unpredictable. A receiver doesn't have the luxury of being able to not receive packets for a few milliseconds if it is busy with something else. For this reason, it makes sense to see what the sender can do to make the receiver's life a little easier. If the receiver could receive each TCP segment and process it in isolation, determining where to place it in memory solely from information within that TCP segment, without reference to data from other TCP segments (which may not have arrived yet), then it would be easier to make a high-performance receiver. What can we do to enable independent segment processing and idempotent direct data placement at the receiver? My first choice would be to add a couple of extra bits to the TCP header; a "start of message" bit and an "end of message" bit. The "start of message" bit indicates that the first byte of TCP data in the segment is also the first byte of an iSCSI message; the "end of message" bit indicates that the last byte of TCP data in the segment is also the last byte of an iSCSI message. When a receiver receives a TCP segment with both bits set, it knows with certainty that it has one (or more) complete iSCSI messages in the TCP segment and can immediately decode enough of the iSCSI message header(s) to determine where in memory to place the data. Unfortunately, adding extra bits to the TCP header is not viable. From a political point of view, trying to change the TCP on-the-wire protocol is a non-starter. From a practical point of view, there are too many routers and firewalls and similar devices that will throw away TCP packets with bits they don't understand. Given that out-of-band framing using header bits is not possible, the alternative is in-band framing using only information in the TCP data stream itself. If we can design our sender to normally send exactly one iSCSI message per TCP segment, and we have a way for our receiver to reliably verify that the received TCP segment contains exactly one iSCSI message, then the receiver can implement idempotent direct data placement for each TCP segment as it is received, without reference to state from previous TCP segments on that connection (which may not have arrived yet). The problem left to solve is how the receiver can reliably verify that the received TCP segment contains exactly one iSCSI message. It can do this by checking to see whether the TCP segment data begins with some special marker pattern, as long as it knows that this special marker pattern cannot appear anywhere within the body of valid iSCSI message data. This necessarily entails processing ("stuffing") the body of the iSCSI message to eliminate inadvertent occurrences of the special marker pattern before sending, and then reversing this transformation to restore the original data after reception. If the receiver finds that the segment does not begin with the special marker pattern, then it knows that the sender segmentation has not been maintained (or it is talking to an old TCP sender that doesn't support sender segmentation) and it has to fall back to treating the TCP data stream as a raw unstructured byte stream, with message boundaries indicated by occurrences of the the marker pattern. The important thing is that the receiver still works correctly, even though the performance will be lower. This prefer-sender-segmentation-but-verify approach is important. If the outgoing data is not processed to guarantee that the special marker pattern cannot occur, then malicious users might be able to subvert the protocol by putting contrived patterns in their data. Remember the days where you could make a user's modem hang up by sending them an email containing the text "+++ATH"? (Apologies to anyone reading this via modem who just had their telephone line hang up.) Another benefit of using in-band framing like this is that we can deploy it immediately using unmodified TCP stacks. In the future we can use enhanced sender TCP implementations that take steps to maintain segment boundaries, and smart receivers will get a performance boost from that, but it is a compatible upgrade that changes only the implementation, not the on-the-wire protocol. Of course, we don't get anything for free. If we want to receiver to be able to determine with 100% certainty that it has received a complete iSCSI message in one TCP segment, then the sender will have to do some work to enable that. This is the cost of COWS. It gives 100% framing certainty, but at the cost of checking the outgoing data for inadvertent occurrences of the special marker pattern, and eliminating them. There's no way for a sender to tell whether the outgoing data contains inadvertent occurrences of the special marker pattern if the sender is not willing to look at the data. On the plus side, the cost of COWS encoding is modest compared to some alternatives. COWS-encoding adds a little header but otherwise doesn't change the size of the outgoing data, ever. No matter how many occurrences of the framing marker pattern are found, the encoded output length is always exactly the same: the length of the input plus the length of the fixed-size framing header (typically two words). If the framing marker pattern is chosen to be something that is rare in normal (non-malicious) data, then in the common-case the encoding step will be a read-only operation: scan the data, determine that it contains no framing markers, set the COWS header to indicate that the data contains no framing markers, and send it. In contrast, when using Fixed Interval Markers, if a marker happens to fall in the middle of the data you are sending, then it creates a 'hole' in the middle of data that used to be contiguous, and the block of outgoing data changes size. On the receiving side, the 'hole' created by the marker has to be repaired in the process of transferring the data into memory. When using Fixed Interval Markers, when a receiver gets a TCP segment that contains no marker, it cannot reliably determine what it is supposed to do with that segment (where to put it in memory) without referring the state from the previous TCP segments of that connection. I don't believe that FIM can provide efficient idempotent direct data placement for inbound TCP segments, because you can't rely on any given received segment containing a marker via which the receiver can verify that the segment contains a complete iSCSI message. In summary: My first choice would be to modify the TCP protocol to support preservation of upper-level message boundaries. Given that this is not possible, I think COWS provdes a good alternative. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-ips@ece.cmu.edu Sat Jan 12 08:47: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 IAA20513 for ; Sat, 12 Jan 2002 08:47:25 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0CD1aI22311 for ips-outgoing; Sat, 12 Jan 2002 08:01:36 -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 g0CD1Yj22306 for ; Sat, 12 Jan 2002 08:01:35 -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 HAA164614; Sat, 12 Jan 2002 07:58:33 -0500 Received: from d03nm014.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 g0CD1WJ128200; Sat, 12 Jan 2002 06:01:32 -0700 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: Markers and Framing To: "Mukund, Shridhar" Cc: ips@ece.cmu.edu, "Sperry, Todd" , "Munnangi, Siva" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Sat, 12 Jan 2002 04:00:36 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 01/12/2002 06:01:31 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Shridhar, You input is both timely and amusing. A number of folks have wanted input from ASIC Designers that were focused on 1 and especially 10 Gig and I guess you clearly fall into that category. You bring up a few points, that I found useful: 1. That you like the FIM approach now, and that it is useful in your design until something REALLY better comes along. 2. That you would like "SHOULD Implement". And you did not push for the "MUST Implement". 3. That you, in effect, did not want to bet on the Final Framing since there will be perhaps lots of issues and solutions still to come with iWARP & RDMA, so don't worry about Framing now; there is lots of experimentation and debate that is going to occur, and who knows what will happen there. I think I did some interpretation on point 3 so if that was wrong please correct me. I think I could accept the "SHOULD Implement" statement. And perhaps that is better then the "MUST Implement" that we have been talking about, and to which a number of folks have objected. There have been several folks that seem to have reasons for not wanting "MUST Implement". This would give them an out if they felt that they have a just and valid reason in their product for not doing it. On the other hand "SHOULD" gives the customers enough other vendors that will support Markers, that if the customers care about it, they can easily obtain a Multi vendor solution which exploits it. I can accept a "SHOULD Implement on Send", but "Optional to use", for FIM. I also think the point you made about iWARP, was also valid. So I am starting to also lean towards the new Option 6, with SHOULD, instead of MUST. Comments from others? . . . 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 "Mukund, Shridhar" on 01/11/2002 05:51:12 PM To: John Hufferd/San Jose/IBM@IBMUS, ips@ece.cmu.edu cc: "Sperry, Todd" , "Munnangi, Siva" Subject: RE: iSCSI: Markers and Framing Dear Colleagues, As an implementer of silicon solutions up to 10Gbps, my take is ... 1. Election # 6. FIM now and some kind of framing later. Comments: a. By framing I mean what ever method iWarp effort ends up with. (TUF as proposed today may not be it) b. I strongly recommend SHOULD implement FIM on the send side. Implication -> Senders that do not insert markers should be willing to accept up to RTT*BW data drops! Headers being "reasonably" out-of-order is OK. Of course, senders that do not insert markers but are willing to pay big $$$ to the SSP will get their buffer/BW allocation as usual and customary :-) c. I think that the proponents and beholders of FIM had good reasons. They still hold and are even more stronger. We have had FIM in the iSCSI spec since version 02. Major changes to the iSCSI draft, at this late date, should have significant technical reasons. 2. COBS is a good solution for the problem that Stuart and Mary originally set out to solve at Stanford. It's(COWS) use in the context of iSCSI is "misuse" at best, esp. given that the use of virgin TCP for transport is mandatory(for good reasons). Several of you have alluded to why COWS is nasty to implement ... I prefer not to get there. Markers on the other hand do bring in some "essential" complexity but they are reasonable to implement even at 10Gbps. We sure could brute-force COWS, but the point is why the additional "incidental" complexity. Do not read further, unless you are open to ... :-) -Shridhar Mukund --------------------------------------------------------------------------- CAUTION: MANDATORY to delete and OPTIONAL to read >> Wouldn't it be stupid if we had a proliferation of framing >> alternatives just because the "world originally seemed flat"? (My apology to Stephen Bailey for taking the quote out of context) A packetized HDLC stream(for which COBS was designed) has one whole space-time dimension lesser than a TCP stream. Relative to TCP stream, packetized HDLC stream is a flat world! As I see it, COBS is an alternative coding technique that makes delimiters explicit in an otherwise reference-less "sequence" or byte/word-stream. A reference-less sequence is assumed to have no ends or gradations. Yet the encoded sequence exposes 'handles' for synchronization. -> relatively synchronous after encoding. TCP stream on the other hand is a "time-sequence". It starts with a big-bang after which every byte in the sequence has an explicit time(sequence number) associated with it. -> It is absolutely synchronous even to begin with! The increase in entropy because of assuming a time-sequence to be a mere-sequence is probably :-) demonstrated by the following: In the Marker lingo : My second son was born in 99 and my first son in 94. Of course, 1900 AD is the marker here. In the COW's moo: My second son was born 20 blue moons after my first son. My first son ... I have no clue? Usage of COWS over TCP transport would be like loosing a needle in the hay stack, on purpose, and then devising a clever scheme to retrieve it. If you read on further, you may be wasting your time ... Are you certain that the world is round? If you read Stephen Hawkings or an article from Stanford in Scientific American 3 blue moons ago, there is scientific evidence of higher dimensions beyond the 4 space-time dimensions we perceive. In other words, round world might just be an illusion or a convenient definition of what we perceive! When I am using maps, flat world seems perfectly fine to me. Since a mere-sequence is a one dimensional space and a time-sequence like TCP stream is two-dimensional, COBS needs to work harder with packetized HDLC sequences. If COBS looks simpler than FIM, it is just an artifact your specific implementation. Q.E.D. -Merlin's apprentice From owner-ips@ece.cmu.edu Sat Jan 12 18:49: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 SAA24856 for ; Sat, 12 Jan 2002 18:49:48 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0CMrVl16230 for ips-outgoing; Sat, 12 Jan 2002 17:53:31 -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 g0CMrSj16226 for ; Sat, 12 Jan 2002 17:53:29 -0500 (EST) Received: from somesh ([65.172.158.93]) by cleitus.hosting.pacbell.net id RAA08943; Sat, 12 Jan 2002 17:53:17 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Reply-To: From: "Somesh Gupta" To: "Stuart Cheshire" , "John Hufferd" , Subject: RE: iSCSI: Markers Date: Sat, 12 Jan 2002 14:51:32 -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.00.2919.6700 Importance: Normal In-Reply-To: <200201120139.g0C1dG627546@scv3.apple.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Stuart, Are there any IPR issues associated with COBS that you might want to share i.e. patents etc? Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Stuart Cheshire > Sent: Friday, January 11, 2002 5:39 PM > To: John Hufferd; ips@ece.cmu.edu > Subject: Re: iSCSI: Markers > > > I'm new to this list, so I should introduce myself. > > My name is Stuart Cheshire; I'm the author of Consistent Overhead Byte > Stuffing (COBS), the framing technique from which COWS derives. I'm not > working on any iSCSI product, but if COBS can contribute to iSCSI, then > I'm happy to offer a little of my time, as much as I can spare, to help > clarify what COWS does and does not do, to help people make an informed > decision whether or not COWS is the right solution for iSCSI. > > ---- > > Assumption: A high-performance receiver is harder than a high-performance > sender. > > This is because the sender is in control. It knows where the data is > coming from in memory, and where it is going to on the network. The > sending host knows and can control all aspects of the communication: what > order iSCSI messages are delivered onto the wire, how big each one is, > and at what time they are sent. If the sender wants to do some kind of > housekeeping that prevents it from sending packets for a few > milliseconds, then it has the option of doing that without terrible > consequences. > > The receiver has a much harder time. It never knows what packet is going > to arrive next, or how big it will be, or where it will be from, or where > it will have to go to in memory. Packet loss/corruption/reordering makes > things even more unpredictable. A receiver doesn't have the luxury of > being able to not receive packets for a few milliseconds if it is busy > with something else. > > For this reason, it makes sense to see what the sender can do to make the > receiver's life a little easier. If the receiver could receive each TCP > segment and process it in isolation, determining where to place it in > memory solely from information within that TCP segment, without reference > to data from other TCP segments (which may not have arrived yet), then it > would be easier to make a high-performance receiver. > > What can we do to enable independent segment processing and idempotent > direct data placement at the receiver? > > My first choice would be to add a couple of extra bits to the TCP header; > a "start of message" bit and an "end of message" bit. The "start of > message" bit indicates that the first byte of TCP data in the segment is > also the first byte of an iSCSI message; the "end of message" bit > indicates that the last byte of TCP data in the segment is also the last > byte of an iSCSI message. When a receiver receives a TCP segment with > both bits set, it knows with certainty that it has one (or more) complete > iSCSI messages in the TCP segment and can immediately decode enough of > the iSCSI message header(s) to determine where in memory to place the > data. > > Unfortunately, adding extra bits to the TCP header is not viable. From a > political point of view, trying to change the TCP on-the-wire protocol is > a non-starter. From a practical point of view, there are too many routers > and firewalls and similar devices that will throw away TCP packets with > bits they don't understand. > > Given that out-of-band framing using header bits is not possible, the > alternative is in-band framing using only information in the TCP data > stream itself. > > If we can design our sender to normally send exactly one iSCSI message > per TCP segment, and we have a way for our receiver to reliably verify > that the received TCP segment contains exactly one iSCSI message, then > the receiver can implement idempotent direct data placement for each TCP > segment as it is received, without reference to state from previous TCP > segments on that connection (which may not have arrived yet). > > The problem left to solve is how the receiver can reliably verify that > the received TCP segment contains exactly one iSCSI message. It can do > this by checking to see whether the TCP segment data begins with some > special marker pattern, as long as it knows that this special marker > pattern cannot appear anywhere within the body of valid iSCSI message > data. This necessarily entails processing ("stuffing") the body of the > iSCSI message to eliminate inadvertent occurrences of the special marker > pattern before sending, and then reversing this transformation to restore > the original data after reception. > > If the receiver finds that the segment does not begin with the special > marker pattern, then it knows that the sender segmentation has not been > maintained (or it is talking to an old TCP sender that doesn't support > sender segmentation) and it has to fall back to treating the TCP data > stream as a raw unstructured byte stream, with message boundaries > indicated by occurrences of the the marker pattern. The important thing > is that the receiver still works correctly, even though the performance > will be lower. > > This prefer-sender-segmentation-but-verify approach is important. If the > outgoing data is not processed to guarantee that the special marker > pattern cannot occur, then malicious users might be able to subvert the > protocol by putting contrived patterns in their data. Remember the days > where you could make a user's modem hang up by sending them an email > containing the text "+++ATH"? (Apologies to anyone reading this via modem > who just had their telephone line hang up.) > > Another benefit of using in-band framing like this is that we can deploy > it immediately using unmodified TCP stacks. In the future we can use > enhanced sender TCP implementations that take steps to maintain segment > boundaries, and smart receivers will get a performance boost from that, > but it is a compatible upgrade that changes only the implementation, not > the on-the-wire protocol. > > Of course, we don't get anything for free. If we want to receiver to be > able to determine with 100% certainty that it has received a complete > iSCSI message in one TCP segment, then the sender will have to do some > work to enable that. This is the cost of COWS. It gives 100% framing > certainty, but at the cost of checking the outgoing data for inadvertent > occurrences of the special marker pattern, and eliminating them. There's > no way for a sender to tell whether the outgoing data contains > inadvertent occurrences of the special marker pattern if the sender is > not willing to look at the data. > > On the plus side, the cost of COWS encoding is modest compared to some > alternatives. COWS-encoding adds a little header but otherwise doesn't > change the size of the outgoing data, ever. No matter how many > occurrences of the framing marker pattern are found, the encoded output > length is always exactly the same: the length of the input plus the > length of the fixed-size framing header (typically two words). If the > framing marker pattern is chosen to be something that is rare in normal > (non-malicious) data, then in the common-case the encoding step will be a > read-only operation: scan the data, determine that it contains no framing > markers, set the COWS header to indicate that the data contains no > framing markers, and send it. > > In contrast, when using Fixed Interval Markers, if a marker happens to > fall in the middle of the data you are sending, then it creates a 'hole' > in the middle of data that used to be contiguous, and the block of > outgoing data changes size. On the receiving side, the 'hole' created by > the marker has to be repaired in the process of transferring the data > into memory. When using Fixed Interval Markers, when a receiver gets a > TCP segment that contains no marker, it cannot reliably determine what it > is supposed to do with that segment (where to put it in memory) without > referring the state from the previous TCP segments of that connection. I > don't believe that FIM can provide efficient idempotent direct data > placement for inbound TCP segments, because you can't rely on any given > received segment containing a marker via which the receiver can verify > that the segment contains a complete iSCSI message. > > In summary: > > My first choice would be to modify the TCP protocol to support > preservation of upper-level message boundaries. > > Given that this is not possible, I think COWS provdes a good alternative. > > Stuart Cheshire > * Wizard Without Portfolio, Apple Computer > * Chairman, IETF ZEROCONF > * www.stuartcheshire.org > > > From owner-ips@ece.cmu.edu Sat Jan 12 18:51: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 SAA24874 for ; Sat, 12 Jan 2002 18:51:07 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0CN8Fq16800 for ips-outgoing; Sat, 12 Jan 2002 18:08:15 -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 g0CN8Ej16796 for ; Sat, 12 Jan 2002 18:08:14 -0500 (EST) Received: from somesh ([65.172.158.93]) by cleitus.hosting.pacbell.net id SAA21503; Sat, 12 Jan 2002 18:08:07 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Reply-To: From: "Somesh Gupta" To: "John Hufferd" , "Stuart Cheshire" Cc: Subject: RE: iSCSI: Markers Date: Sat, 12 Jan 2002 15:06: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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit It is important to realize that there is compatibility between COWS with TCP implementation changes and COWS without TCP implementation changes. Sender with COWS & TCP implementation changes works fine with a receiver with COWS but without TCP implementation changes. Sender with COWS & without TCP implementation changes works fine with a receiver with COWS and which is implemented to take advantage of but work with a sender that is not updated. Sender with COWS & TCP implementation changes works best with a receiver with COWS and takes advantage of alignment. What this says is that COWS preceding layer 5 header is a very solid migration path towards the most desirable objective of framing. There should be an iSCSI option to indicate whether the sender TCP has been changed to support framing or not. Over time as more and more sender TCP implementations can evolve to be framing compliant. Of course, all the issues that have been raised are still valid, and it is probably best to not mandate anything at this point. Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > John Hufferd > Sent: Saturday, January 12, 2002 3:18 AM > To: Stuart Cheshire > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: Markers > > > > Stuart, > thanks for the contribution. > > I found your views interesting, however, in the last part of your message, > when you attempted to contrast it to FIM, you mixed a Framing discussion > with a marker discussion. Here is what I mean: > > You made much of your arguments to address COWS as being part of a Framing > (Forcing Segmentation alignment with PDUs). Many of us are already a fan > of Framing, and understand that both the Key+length and COWS have an > important debate to hold with lots of real world ASIC Vendor Input needed. > > But then you jumped to contrasting COWS with Framing vrs FIM. > That has not > been the focus of the discussion. I can not think of anyone that is > suggesting FIM in place of any Framing approach. Framing is the goal, and > honest debate on the Type, will be needed and be useful. The debate then > occurs in two areas, what do we do until we have a Framing solution > (Framing being out of the domain of iSCSI, so we must wait until one is > accepted before we can point to it.), and what kind of a Framing solution > should we wish, so that we can influence the Framing debate. > Hence the Six > Options. > > So some of your discussions on COWS, is completely valid for Framing, but > is not quite as useful, without framing. When it comes to not having > Framing (with Segmentation starts, etc) some will argue that COWS is much > more complex, and much higher overhead. > > So again, thank you for your contribution, I just wanted to correct that > slight misalignment at the end of your note. > > . > . > . > 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 > > > Stuart Cheshire on 01/11/2002 05:39:17 PM > > To: John Hufferd/San Jose/IBM@IBMUS, > cc: > Subject: Re: iSCSI: Markers > > > > I'm new to this list, so I should introduce myself. > > My name is Stuart Cheshire; I'm the author of Consistent Overhead Byte > Stuffing (COBS), the framing technique from which COWS derives. I'm not > working on any iSCSI product, but if COBS can contribute to iSCSI, then > I'm happy to offer a little of my time, as much as I can spare, to help > clarify what COWS does and does not do, to help people make an informed > decision whether or not COWS is the right solution for iSCSI. > > ---- > > Assumption: A high-performance receiver is harder than a high-performance > sender. > > This is because the sender is in control. It knows where the data is > coming from in memory, and where it is going to on the network. The > sending host knows and can control all aspects of the communication: what > order iSCSI messages are delivered onto the wire, how big each one is, > and at what time they are sent. If the sender wants to do some kind of > housekeeping that prevents it from sending packets for a few > milliseconds, then it has the option of doing that without terrible > consequences. > > The receiver has a much harder time. It never knows what packet is going > to arrive next, or how big it will be, or where it will be from, or where > it will have to go to in memory. Packet loss/corruption/reordering makes > things even more unpredictable. A receiver doesn't have the luxury of > being able to not receive packets for a few milliseconds if it is busy > with something else. > > For this reason, it makes sense to see what the sender can do to make the > receiver's life a little easier. If the receiver could receive each TCP > segment and process it in isolation, determining where to place it in > memory solely from information within that TCP segment, without reference > to data from other TCP segments (which may not have arrived yet), then it > would be easier to make a high-performance receiver. > > What can we do to enable independent segment processing and idempotent > direct data placement at the receiver? > > My first choice would be to add a couple of extra bits to the TCP header; > a "start of message" bit and an "end of message" bit. The "start of > message" bit indicates that the first byte of TCP data in the segment is > also the first byte of an iSCSI message; the "end of message" bit > indicates that the last byte of TCP data in the segment is also the last > byte of an iSCSI message. When a receiver receives a TCP segment with > both bits set, it knows with certainty that it has one (or more) complete > iSCSI messages in the TCP segment and can immediately decode enough of > the iSCSI message header(s) to determine where in memory to place the > data. > > Unfortunately, adding extra bits to the TCP header is not viable. From a > political point of view, trying to change the TCP on-the-wire protocol is > a non-starter. From a practical point of view, there are too many routers > and firewalls and similar devices that will throw away TCP packets with > bits they don't understand. > > Given that out-of-band framing using header bits is not possible, the > alternative is in-band framing using only information in the TCP data > stream itself. > > If we can design our sender to normally send exactly one iSCSI message > per TCP segment, and we have a way for our receiver to reliably verify > that the received TCP segment contains exactly one iSCSI message, then > the receiver can implement idempotent direct data placement for each TCP > segment as it is received, without reference to state from previous TCP > segments on that connection (which may not have arrived yet). > > The problem left to solve is how the receiver can reliably verify that > the received TCP segment contains exactly one iSCSI message. It can do > this by checking to see whether the TCP segment data begins with some > special marker pattern, as long as it knows that this special marker > pattern cannot appear anywhere within the body of valid iSCSI message > data. This necessarily entails processing ("stuffing") the body of the > iSCSI message to eliminate inadvertent occurrences of the special marker > pattern before sending, and then reversing this transformation to restore > the original data after reception. > > If the receiver finds that the segment does not begin with the special > marker pattern, then it knows that the sender segmentation has not been > maintained (or it is talking to an old TCP sender that doesn't support > sender segmentation) and it has to fall back to treating the TCP data > stream as a raw unstructured byte stream, with message boundaries > indicated by occurrences of the the marker pattern. The important thing > is that the receiver still works correctly, even though the performance > will be lower. > > This prefer-sender-segmentation-but-verify approach is important. If the > outgoing data is not processed to guarantee that the special marker > pattern cannot occur, then malicious users might be able to subvert the > protocol by putting contrived patterns in their data. Remember the days > where you could make a user's modem hang up by sending them an email > containing the text "+++ATH"? (Apologies to anyone reading this via modem > who just had their telephone line hang up.) > > Another benefit of using in-band framing like this is that we can deploy > it immediately using unmodified TCP stacks. In the future we can use > enhanced sender TCP implementations that take steps to maintain segment > boundaries, and smart receivers will get a performance boost from that, > but it is a compatible upgrade that changes only the implementation, not > the on-the-wire protocol. > > Of course, we don't get anything for free. If we want to receiver to be > able to determine with 100% certainty that it has received a complete > iSCSI message in one TCP segment, then the sender will have to do some > work to enable that. This is the cost of COWS. It gives 100% framing > certainty, but at the cost of checking the outgoing data for inadvertent > occurrences of the special marker pattern, and eliminating them. There's > no way for a sender to tell whether the outgoing data contains > inadvertent occurrences of the special marker pattern if the sender is > not willing to look at the data. > > On the plus side, the cost of COWS encoding is modest compared to some > alternatives. COWS-encoding adds a little header but otherwise doesn't > change the size of the outgoing data, ever. No matter how many > occurrences of the framing marker pattern are found, the encoded output > length is always exactly the same: the length of the input plus the > length of the fixed-size framing header (typically two words). If the > framing marker pattern is chosen to be something that is rare in normal > (non-malicious) data, then in the common-case the encoding step will be a > read-only operation: scan the data, determine that it contains no framing > markers, set the COWS header to indicate that the data contains no > framing markers, and send it. > > In contrast, when using Fixed Interval Markers, if a marker happens to > fall in the middle of the data you are sending, then it creates a 'hole' > in the middle of data that used to be contiguous, and the block of > outgoing data changes size. On the receiving side, the 'hole' created by > the marker has to be repaired in the process of transferring the data > into memory. When using Fixed Interval Markers, when a receiver gets a > TCP segment that contains no marker, it cannot reliably determine what it > is supposed to do with that segment (where to put it in memory) without > referring the state from the previous TCP segments of that connection. I > don't believe that FIM can provide efficient idempotent direct data > placement for inbound TCP segments, because you can't rely on any given > received segment containing a marker via which the receiver can verify > that the segment contains a complete iSCSI message. > > In summary: > > My first choice would be to modify the TCP protocol to support > preservation of upper-level message boundaries. > > Given that this is not possible, I think COWS provdes a good alternative. > > Stuart Cheshire > * Wizard Without Portfolio, Apple Computer > * Chairman, IETF ZEROCONF > * www.stuartcheshire.org > > > > > > From owner-ips@ece.cmu.edu Sun Jan 13 02:02: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 CAA03183 for ; Sun, 13 Jan 2002 02:02:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0D6GMf03881 for ips-outgoing; Sun, 13 Jan 2002 01:16:22 -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 g0D6GKj03876 for ; Sun, 13 Jan 2002 01:16:20 -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 HAA04302 for ; Sun, 13 Jan 2002 07:16:13 +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 g0D6H4C178306 for ; Sun, 13 Jan 2002 07:17:04 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: Markers X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sun, 13 Jan 2002 08:17:08 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 13/01/2002 08:17:12, Serialize complete at 13/01/2002 08:17:12 Content-Type: multipart/alternative; boundary="=_alternative 00216899C2256B40_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00216899C2256B40_= Content-Type: text/plain; charset="us-ascii" Very good point. That is what we had in mind when we suggested COWS. Julo "Somesh Gupta" Sent by: owner-ips@ece.cmu.edu 13-01-02 01:06 Please respond to somesh_gupta To: John Hufferd/San Jose/IBM@IBMUS, "Stuart Cheshire" cc: Subject: RE: iSCSI: Markers It is important to realize that there is compatibility between COWS with TCP implementation changes and COWS without TCP implementation changes. Sender with COWS & TCP implementation changes works fine with a receiver with COWS but without TCP implementation changes. Sender with COWS & without TCP implementation changes works fine with a receiver with COWS and which is implemented to take advantage of but work with a sender that is not updated. Sender with COWS & TCP implementation changes works best with a receiver with COWS and takes advantage of alignment. What this says is that COWS preceding layer 5 header is a very solid migration path towards the most desirable objective of framing. There should be an iSCSI option to indicate whether the sender TCP has been changed to support framing or not. Over time as more and more sender TCP implementations can evolve to be framing compliant. Of course, all the issues that have been raised are still valid, and it is probably best to not mandate anything at this point. Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > John Hufferd > Sent: Saturday, January 12, 2002 3:18 AM > To: Stuart Cheshire > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: Markers > > > > Stuart, > thanks for the contribution. > > I found your views interesting, however, in the last part of your message, > when you attempted to contrast it to FIM, you mixed a Framing discussion > with a marker discussion. Here is what I mean: > > You made much of your arguments to address COWS as being part of a Framing > (Forcing Segmentation alignment with PDUs). Many of us are already a fan > of Framing, and understand that both the Key+length and COWS have an > important debate to hold with lots of real world ASIC Vendor Input needed. > > But then you jumped to contrasting COWS with Framing vrs FIM. > That has not > been the focus of the discussion. I can not think of anyone that is > suggesting FIM in place of any Framing approach. Framing is the goal, and > honest debate on the Type, will be needed and be useful. The debate then > occurs in two areas, what do we do until we have a Framing solution > (Framing being out of the domain of iSCSI, so we must wait until one is > accepted before we can point to it.), and what kind of a Framing solution > should we wish, so that we can influence the Framing debate. > Hence the Six > Options. > > So some of your discussions on COWS, is completely valid for Framing, but > is not quite as useful, without framing. When it comes to not having > Framing (with Segmentation starts, etc) some will argue that COWS is much > more complex, and much higher overhead. > > So again, thank you for your contribution, I just wanted to correct that > slight misalignment at the end of your note. > > . > . > . > 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 > > > Stuart Cheshire on 01/11/2002 05:39:17 PM > > To: John Hufferd/San Jose/IBM@IBMUS, > cc: > Subject: Re: iSCSI: Markers > > > > I'm new to this list, so I should introduce myself. > > My name is Stuart Cheshire; I'm the author of Consistent Overhead Byte > Stuffing (COBS), the framing technique from which COWS derives. I'm not > working on any iSCSI product, but if COBS can contribute to iSCSI, then > I'm happy to offer a little of my time, as much as I can spare, to help > clarify what COWS does and does not do, to help people make an informed > decision whether or not COWS is the right solution for iSCSI. > > ---- > > Assumption: A high-performance receiver is harder than a high-performance > sender. > > This is because the sender is in control. It knows where the data is > coming from in memory, and where it is going to on the network. The > sending host knows and can control all aspects of the communication: what > order iSCSI messages are delivered onto the wire, how big each one is, > and at what time they are sent. If the sender wants to do some kind of > housekeeping that prevents it from sending packets for a few > milliseconds, then it has the option of doing that without terrible > consequences. > > The receiver has a much harder time. It never knows what packet is going > to arrive next, or how big it will be, or where it will be from, or where > it will have to go to in memory. Packet loss/corruption/reordering makes > things even more unpredictable. A receiver doesn't have the luxury of > being able to not receive packets for a few milliseconds if it is busy > with something else. > > For this reason, it makes sense to see what the sender can do to make the > receiver's life a little easier. If the receiver could receive each TCP > segment and process it in isolation, determining where to place it in > memory solely from information within that TCP segment, without reference > to data from other TCP segments (which may not have arrived yet), then it > would be easier to make a high-performance receiver. > > What can we do to enable independent segment processing and idempotent > direct data placement at the receiver? > > My first choice would be to add a couple of extra bits to the TCP header; > a "start of message" bit and an "end of message" bit. The "start of > message" bit indicates that the first byte of TCP data in the segment is > also the first byte of an iSCSI message; the "end of message" bit > indicates that the last byte of TCP data in the segment is also the last > byte of an iSCSI message. When a receiver receives a TCP segment with > both bits set, it knows with certainty that it has one (or more) complete > iSCSI messages in the TCP segment and can immediately decode enough of > the iSCSI message header(s) to determine where in memory to place the > data. > > Unfortunately, adding extra bits to the TCP header is not viable. From a > political point of view, trying to change the TCP on-the-wire protocol is > a non-starter. From a practical point of view, there are too many routers > and firewalls and similar devices that will throw away TCP packets with > bits they don't understand. > > Given that out-of-band framing using header bits is not possible, the > alternative is in-band framing using only information in the TCP data > stream itself. > > If we can design our sender to normally send exactly one iSCSI message > per TCP segment, and we have a way for our receiver to reliably verify > that the received TCP segment contains exactly one iSCSI message, then > the receiver can implement idempotent direct data placement for each TCP > segment as it is received, without reference to state from previous TCP > segments on that connection (which may not have arrived yet). > > The problem left to solve is how the receiver can reliably verify that > the received TCP segment contains exactly one iSCSI message. It can do > this by checking to see whether the TCP segment data begins with some > special marker pattern, as long as it knows that this special marker > pattern cannot appear anywhere within the body of valid iSCSI message > data. This necessarily entails processing ("stuffing") the body of the > iSCSI message to eliminate inadvertent occurrences of the special marker > pattern before sending, and then reversing this transformation to restore > the original data after reception. > > If the receiver finds that the segment does not begin with the special > marker pattern, then it knows that the sender segmentation has not been > maintained (or it is talking to an old TCP sender that doesn't support > sender segmentation) and it has to fall back to treating the TCP data > stream as a raw unstructured byte stream, with message boundaries > indicated by occurrences of the the marker pattern. The important thing > is that the receiver still works correctly, even though the performance > will be lower. > > This prefer-sender-segmentation-but-verify approach is important. If the > outgoing data is not processed to guarantee that the special marker > pattern cannot occur, then malicious users might be able to subvert the > protocol by putting contrived patterns in their data. Remember the days > where you could make a user's modem hang up by sending them an email > containing the text "+++ATH"? (Apologies to anyone reading this via modem > who just had their telephone line hang up.) > > Another benefit of using in-band framing like this is that we can deploy > it immediately using unmodified TCP stacks. In the future we can use > enhanced sender TCP implementations that take steps to maintain segment > boundaries, and smart receivers will get a performance boost from that, > but it is a compatible upgrade that changes only the implementation, not > the on-the-wire protocol. > > Of course, we don't get anything for free. If we want to receiver to be > able to determine with 100% certainty that it has received a complete > iSCSI message in one TCP segment, then the sender will have to do some > work to enable that. This is the cost of COWS. It gives 100% framing > certainty, but at the cost of checking the outgoing data for inadvertent > occurrences of the special marker pattern, and eliminating them. There's > no way for a sender to tell whether the outgoing data contains > inadvertent occurrences of the special marker pattern if the sender is > not willing to look at the data. > > On the plus side, the cost of COWS encoding is modest compared to some > alternatives. COWS-encoding adds a little header but otherwise doesn't > change the size of the outgoing data, ever. No matter how many > occurrences of the framing marker pattern are found, the encoded output > length is always exactly the same: the length of the input plus the > length of the fixed-size framing header (typically two words). If the > framing marker pattern is chosen to be something that is rare in normal > (non-malicious) data, then in the common-case the encoding step will be a > read-only operation: scan the data, determine that it contains no framing > markers, set the COWS header to indicate that the data contains no > framing markers, and send it. > > In contrast, when using Fixed Interval Markers, if a marker happens to > fall in the middle of the data you are sending, then it creates a 'hole' > in the middle of data that used to be contiguous, and the block of > outgoing data changes size. On the receiving side, the 'hole' created by > the marker has to be repaired in the process of transferring the data > into memory. When using Fixed Interval Markers, when a receiver gets a > TCP segment that contains no marker, it cannot reliably determine what it > is supposed to do with that segment (where to put it in memory) without > referring the state from the previous TCP segments of that connection. I > don't believe that FIM can provide efficient idempotent direct data > placement for inbound TCP segments, because you can't rely on any given > received segment containing a marker via which the receiver can verify > that the segment contains a complete iSCSI message. > > In summary: > > My first choice would be to modify the TCP protocol to support > preservation of upper-level message boundaries. > > Given that this is not possible, I think COWS provdes a good alternative. > > Stuart Cheshire > * Wizard Without Portfolio, Apple Computer > * Chairman, IETF ZEROCONF > * www.stuartcheshire.org > > > > > > --=_alternative 00216899C2256B40_= Content-Type: text/html; charset="us-ascii"
Very good point. That is what we had in mind when we suggested COWS.

Julo


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

13-01-02 01:06
Please respond to somesh_gupta

       
        To:        John Hufferd/San Jose/IBM@IBMUS, "Stuart Cheshire" <cheshire@apple.com>
        cc:        <ips@ece.cmu.edu>
        Subject:        RE: iSCSI: Markers

       


It is important to realize that there is compatibility between
COWS with TCP implementation changes and COWS without TCP
implementation changes.

Sender with COWS & TCP implementation changes works fine
with a receiver with COWS but without TCP implementation
changes.

Sender with COWS & without TCP implementation changes works
fine with a receiver with COWS and which is implemented
to take advantage of but work with a sender that is not
updated.

Sender with COWS & TCP implementation changes works best
with a receiver with COWS and takes advantage of alignment.

What this says is that COWS preceding layer 5 header is
a very solid migration path towards the most desirable
objective of framing. There should be an iSCSI option to
indicate whether the sender TCP has been changed to
support framing or not. Over time as more and more sender
TCP implementations can evolve to be framing compliant.

Of course, all the issues that have been raised are
still valid, and it is probably best to not mandate
anything at this point.

Somesh


> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> John Hufferd
> Sent: Saturday, January 12, 2002 3:18 AM
> To: Stuart Cheshire
> Cc: ips@ece.cmu.edu
> Subject: Re: iSCSI: Markers
>
>
>
> Stuart,
> thanks for the contribution.
>
> I found your views interesting, however, in the last part of your message,
> when you attempted to contrast it to FIM, you mixed a Framing discussion
> with a marker discussion.  Here is what I mean:
>
> You made much of your arguments to address COWS as being part of a Framing
> (Forcing Segmentation alignment with PDUs).  Many of us are already a fan
> of Framing, and understand that both the Key+length and COWS have an
> important debate to hold with lots of real world ASIC Vendor Input needed.
>
> But then you jumped to contrasting COWS with Framing vrs FIM.
> That has not
> been the focus of the discussion.  I can not think of anyone that is
> suggesting FIM in place of any Framing approach.  Framing is the goal, and
> honest debate on the Type, will be needed and be useful.  The debate then
> occurs in two areas, what do we do until we have a Framing solution
> (Framing being out of the domain of iSCSI, so we must wait until one is
> accepted before we can point to it.), and what kind of a Framing solution
> should we wish, so that we can influence the Framing debate.
> Hence the Six
> Options.
>
> So some of your discussions on COWS, is completely valid for Framing, but
> is not quite as useful, without framing. When it comes to not having
> Framing (with Segmentation starts, etc) some will argue that COWS is much
> more complex, and much higher overhead.
>
> So again, thank you for your contribution, I just wanted to correct that
> slight misalignment at the end of your note.
>
> .
> .
> .
> 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
>
>
> Stuart Cheshire <cheshire@apple.com> on 01/11/2002 05:39:17 PM
>
> To:    John Hufferd/San Jose/IBM@IBMUS, <ips@ece.cmu.edu>
> cc:
> Subject:    Re: iSCSI: Markers
>
>
>
> I'm new to this list, so I should introduce myself.
>
> My name is Stuart Cheshire; I'm the author of Consistent Overhead Byte
> Stuffing (COBS), the framing technique from which COWS derives. I'm not
> working on any iSCSI product, but if COBS can contribute to iSCSI, then
> I'm happy to offer a little of my time, as much as I can spare, to help
> clarify what COWS does and does not do, to help people make an informed
> decision whether or not COWS is the right solution for iSCSI.
>
> ----
>
> Assumption: A high-performance receiver is harder than a high-performance
> sender.
>
> This is because the sender is in control. It knows where the data is
> coming from in memory, and where it is going to on the network. The
> sending host knows and can control all aspects of the communication: what
> order iSCSI messages are delivered onto the wire, how big each one is,
> and at what time they are sent. If the sender wants to do some kind of
> housekeeping that prevents it from sending packets for a few
> milliseconds, then it has the option of doing that without terrible
> consequences.
>
> The receiver has a much harder time. It never knows what packet is going
> to arrive next, or how big it will be, or where it will be from, or where
> it will have to go to in memory. Packet loss/corruption/reordering makes
> things even more unpredictable. A receiver doesn't have the luxury of
> being able to not receive packets for a few milliseconds if it is busy
> with something else.
>
> For this reason, it makes sense to see what the sender can do to make the
> receiver's life a little easier. If the receiver could receive each TCP
> segment and process it in isolation, determining where to place it in
> memory solely from information within that TCP segment, without reference
> to data from other TCP segments (which may not have arrived yet), then it
> would be easier to make a high-performance receiver.
>
> What can we do to enable independent segment processing and idempotent
> direct data placement at the receiver?
>
> My first choice would be to add a couple of extra bits to the TCP header;
> a "start of message" bit and an "end of message" bit. The "start of
> message" bit indicates that the first byte of TCP data in the segment is
> also the first byte of an iSCSI message; the "end of message" bit
> indicates that the last byte of TCP data in the segment is also the last
> byte of an iSCSI message. When a receiver receives a TCP segment with
> both bits set, it knows with certainty that it has one (or more) complete
> iSCSI messages in the TCP segment and can immediately decode enough of
> the iSCSI message header(s) to determine where in memory to place the
> data.
>
> Unfortunately, adding extra bits to the TCP header is not viable. From a
> political point of view, trying to change the TCP on-the-wire protocol is
> a non-starter. From a practical point of view, there are too many routers
> and firewalls and similar devices that will throw away TCP packets with
> bits they don't understand.
>
> Given that out-of-band framing using header bits is not possible, the
> alternative is in-band framing using only information in the TCP data
> stream itself.
>
> If we can design our sender to normally send exactly one iSCSI message
> per TCP segment, and we have a way for our receiver to reliably verify
> that the received TCP segment contains exactly one iSCSI message, then
> the receiver can implement idempotent direct data placement for each TCP
> segment as it is received, without reference to state from previous TCP
> segments on that connection (which may not have arrived yet).
>
> The problem left to solve is how the receiver can reliably verify that
> the received TCP segment contains exactly one iSCSI message. It can do
> this by checking to see whether the TCP segment data begins with some
> special marker pattern, as long as it knows that this special marker
> pattern cannot appear anywhere within the body of valid iSCSI message
> data. This necessarily entails processing ("stuffing") the body of the
> iSCSI message to eliminate inadvertent occurrences of the special marker
> pattern before sending, and then reversing this transformation to restore
> the original data after reception.
>
> If the receiver finds that the segment does not begin with the special
> marker pattern, then it knows that the sender segmentation has not been
> maintained (or it is talking to an old TCP sender that doesn't support
> sender segmentation) and it has to fall back to treating the TCP data
> stream as a raw unstructured byte stream, with message boundaries
> indicated by occurrences of the the marker pattern. The important thing
> is that the receiver still works correctly, even though the performance
> will be lower.
>
> This prefer-sender-segmentation-but-verify approach is important. If the
> outgoing data is not processed to guarantee that the special marker
> pattern cannot occur, then malicious users might be able to subvert the
> protocol by putting contrived patterns in their data. Remember the days
> where you could make a user's modem hang up by sending them an email
> containing the text "+++ATH"? (Apologies to anyone reading this via modem
> who just had their telephone line hang up.)
>
> Another benefit of using in-band framing like this is that we can deploy
> it immediately using unmodified TCP stacks. In the future we can use
> enhanced sender TCP implementations that take steps to maintain segment
> boundaries, and smart receivers will get a performance boost from that,
> but it is a compatible upgrade that changes only the implementation, not
> the on-the-wire protocol.
>
> Of course, we don't get anything for free. If we want to receiver to be
> able to determine with 100% certainty that it has received a complete
> iSCSI message in one TCP segment, then the sender will have to do some
> work to enable that. This is the cost of COWS. It gives 100% framing
> certainty, but at the cost of checking the outgoing data for inadvertent
> occurrences of the special marker pattern, and eliminating them. There's
> no way for a sender to tell whether the outgoing data contains
> inadvertent occurrences of the special marker pattern if the sender is
> not willing to look at the data.
>
> On the plus side, the cost of COWS encoding is modest compared to some
> alternatives. COWS-encoding adds a little header but otherwise doesn't
> change the size of the outgoing data, ever. No matter how many
> occurrences of the framing marker pattern are found, the encoded output
> length is always exactly the same: the length of the input plus the
> length of the fixed-size framing header (typically two words). If the
> framing marker pattern is chosen to be something that is rare in normal
> (non-malicious) data, then in the common-case the encoding step will be a
> read-only operation: scan the data, determine that it contains no framing
> markers, set the COWS header to indicate that the data contains no
> framing markers, and send it.
>
> In contrast, when using Fixed Interval Markers, if a marker happens to
> fall in the middle of the data you are sending, then it creates a 'hole'
> in the middle of data that used to be contiguous, and the block of
> outgoing data changes size. On the receiving side, the 'hole' created by
> the marker has to be repaired in the process of transferring the data
> into memory. When using Fixed Interval Markers, when a receiver gets a
> TCP segment that contains no marker, it cannot reliably determine what it
> is supposed to do with that segment (where to put it in memory) without
> referring the state from the previous TCP segments of that connection. I
> don't believe that FIM can provide efficient idempotent direct data
> placement for inbound TCP segments, because you can't rely on any given
> received segment containing a marker via which the receiver can verify
> that the segment contains a complete iSCSI message.
>
> In summary:
>
> My first choice would be to modify the TCP protocol to support
> preservation of upper-level message boundaries.
>
> Given that this is not possible, I think COWS provdes a good alternative.
>
> Stuart Cheshire <cheshire@apple.com>
>  * Wizard Without Portfolio, Apple Computer
>  * Chairman, IETF ZEROCONF
>  * www.stuartcheshire.org
>
>
>
>
>
>

--=_alternative 00216899C2256B40_=-- From owner-ips@ece.cmu.edu Sun Jan 13 15:46: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 PAA15048 for ; Sun, 13 Jan 2002 15:46:49 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0DK5SH15906 for ips-outgoing; Sun, 13 Jan 2002 15:05:28 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0DK5Qj15901 for ; Sun, 13 Jan 2002 15:05:26 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g0DK5N111942 for ; Sun, 13 Jan 2002 12:05:23 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Sun, 13 Jan 2002 12:05:07 -0800 Received: from [206.111.147.149] (vpn-gh-1048.apple.com [17.254.140.23]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id g0DK56w16868; Sun, 13 Jan 2002 12:05:06 -0800 (PST) Message-Id: <200201132005.g0DK56w16868@scv2.apple.com> Subject: RE: iSCSI: Markers Date: Sun, 13 Jan 2002 12:05:06 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: , "John Hufferd" , Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ips@ece.cmu.edu Precedence: bulk >Stuart, > >Are there any IPR issues associated with COBS that you might >want to share i.e. patents etc? > >Somesh COBS was published first at SIGCOMM in September 1997. My PhD dissertation, published 1998 and formally registered with the United States Library of Congress Copyright Register in January 1999, describes extensions including using word lengths other than eight bits, eliminating framing marker values other than zero, eliminating multiple framing marker values simultaneously, etc. I have not filed any patent on any aspect of COBS/COWS, and my prior publications should ensure that no one else can file a defensible patent on any aspect of COBS/COWS. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-ips@ece.cmu.edu Sun Jan 13 15:47: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 PAA15059 for ; Sun, 13 Jan 2002 15:47:26 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0DJmZM15183 for ips-outgoing; Sun, 13 Jan 2002 14:48: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-h013.c003.snv.cp.net [209.228.32.227]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g0DJmXj15178 for ; Sun, 13 Jan 2002 14:48:33 -0500 (EST) Received: (cpmta 11338 invoked from network); 13 Jan 2002 11:48:26 -0800 Received: from 64.130.130.105 (HELO dougrmt) by smtp.telocity.com (209.228.32.227) with SMTP; 13 Jan 2002 11:48:26 -0800 X-Sent: 13 Jan 2002 19:48:26 GMT From: "Douglas Otis" To: Subject: RE: iSCSI: Markers Date: Sun, 13 Jan 2002 11:48:53 -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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julo, Topics related to negotiating TCP implementation, framing of ULP Data Units, mandated path MTU compliance by the ULP, employing packet filtering below the transport, modification of TCP retry algorithms, as related to this animal, clearly goes well beyond IPS. There is already a means for implementing framing within an IP transport, so persuade a larger group, not this one, they should modify their stacks to implement TCP as desired by storage applications, and to ignore the ongoing work of the IETF transport WG. Doug Very good point. That is what we had in mind when we suggested COWS. Julo "Somesh Gupta" Sent by: owner-ips@ece.cmu.edu 13-01-02 01:06 Please respond to somesh_gupta To: John Hufferd/San Jose/IBM@IBMUS, "Stuart Cheshire" cc: Subject: RE: iSCSI: Markers It is important to realize that there is compatibility between COWS with TCP implementation changes and COWS without TCP implementation changes. Sender with COWS & TCP implementation changes works fine with a receiver with COWS but without TCP implementation changes. Sender with COWS & without TCP implementation changes works fine with a receiver with COWS and which is implemented to take advantage of but work with a sender that is not updated. Sender with COWS & TCP implementation changes works best with a receiver with COWS and takes advantage of alignment. What this says is that COWS preceding layer 5 header is a very solid migration path towards the most desirable objective of framing. There should be an iSCSI option to indicate whether the sender TCP has been changed to support framing or not. Over time as more and more sender TCP implementations can evolve to be framing compliant. Of course, all the issues that have been raised are still valid, and it is probably best to not mandate anything at this point. Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > John Hufferd > Sent: Saturday, January 12, 2002 3:18 AM > To: Stuart Cheshire > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: Markers > > > > Stuart, > thanks for the contribution. > > I found your views interesting, however, in the last part of your message, > when you attempted to contrast it to FIM, you mixed a Framing discussion > with a marker discussion. Here is what I mean: > > You made much of your arguments to address COWS as being part of a Framing > (Forcing Segmentation alignment with PDUs). Many of us are already a fan > of Framing, and understand that both the Key+length and COWS have an > important debate to hold with lots of real world ASIC Vendor Input needed. > > But then you jumped to contrasting COWS with Framing vrs FIM. > That has not > been the focus of the discussion. I can not think of anyone that is > suggesting FIM in place of any Framing approach. Framing is the goal, and > honest debate on the Type, will be needed and be useful. The debate then > occurs in two areas, what do we do until we have a Framing solution > (Framing being out of the domain of iSCSI, so we must wait until one is > accepted before we can point to it.), and what kind of a Framing solution > should we wish, so that we can influence the Framing debate. > Hence the Six > Options. > > So some of your discussions on COWS, is completely valid for Framing, but > is not quite as useful, without framing. When it comes to not having > Framing (with Segmentation starts, etc) some will argue that COWS is much > more complex, and much higher overhead. > > So again, thank you for your contribution, I just wanted to correct that > slight misalignment at the end of your note. > > . > . > . > 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 > > > Stuart Cheshire on 01/11/2002 05:39:17 PM > > To: John Hufferd/San Jose/IBM@IBMUS, > cc: > Subject: Re: iSCSI: Markers > > > > I'm new to this list, so I should introduce myself. > > My name is Stuart Cheshire; I'm the author of Consistent Overhead Byte > Stuffing (COBS), the framing technique from which COWS derives. I'm not > working on any iSCSI product, but if COBS can contribute to iSCSI, then > I'm happy to offer a little of my time, as much as I can spare, to help > clarify what COWS does and does not do, to help people make an informed > decision whether or not COWS is the right solution for iSCSI. > > ---- > > Assumption: A high-performance receiver is harder than a high-performance > sender. > > This is because the sender is in control. It knows where the data is > coming from in memory, and where it is going to on the network. The > sending host knows and can control all aspects of the communication: what > order iSCSI messages are delivered onto the wire, how big each one is, > and at what time they are sent. If the sender wants to do some kind of > housekeeping that prevents it from sending packets for a few > milliseconds, then it has the option of doing that without terrible > consequences. > > The receiver has a much harder time. It never knows what packet is going > to arrive next, or how big it will be, or where it will be from, or where > it will have to go to in memory. Packet loss/corruption/reordering makes > things even more unpredictable. A receiver doesn't have the luxury of > being able to not receive packets for a few milliseconds if it is busy > with something else. > > For this reason, it makes sense to see what the sender can do to make the > receiver's life a little easier. If the receiver could receive each TCP > segment and process it in isolation, determining where to place it in > memory solely from information within that TCP segment, without reference > to data from other TCP segments (which may not have arrived yet), then it > would be easier to make a high-performance receiver. > > What can we do to enable independent segment processing and idempotent > direct data placement at the receiver? > > My first choice would be to add a couple of extra bits to the TCP header; > a "start of message" bit and an "end of message" bit. The "start of > message" bit indicates that the first byte of TCP data in the segment is > also the first byte of an iSCSI message; the "end of message" bit > indicates that the last byte of TCP data in the segment is also the last > byte of an iSCSI message. When a receiver receives a TCP segment with > both bits set, it knows with certainty that it has one (or more) complete > iSCSI messages in the TCP segment and can immediately decode enough of > the iSCSI message header(s) to determine where in memory to place the > data. > > Unfortunately, adding extra bits to the TCP header is not viable. From a > political point of view, trying to change the TCP on-the-wire protocol is > a non-starter. From a practical point of view, there are too many routers > and firewalls and similar devices that will throw away TCP packets with > bits they don't understand. > > Given that out-of-band framing using header bits is not possible, the > alternative is in-band framing using only information in the TCP data > stream itself. > > If we can design our sender to normally send exactly one iSCSI message > per TCP segment, and we have a way for our receiver to reliably verify > that the received TCP segment contains exactly one iSCSI message, then > the receiver can implement idempotent direct data placement for each TCP > segment as it is received, without reference to state from previous TCP > segments on that connection (which may not have arrived yet). > > The problem left to solve is how the receiver can reliably verify that > the received TCP segment contains exactly one iSCSI message. It can do > this by checking to see whether the TCP segment data begins with some > special marker pattern, as long as it knows that this special marker > pattern cannot appear anywhere within the body of valid iSCSI message > data. This necessarily entails processing ("stuffing") the body of the > iSCSI message to eliminate inadvertent occurrences of the special marker > pattern before sending, and then reversing this transformation to restore > the original data after reception. > > If the receiver finds that the segment does not begin with the special > marker pattern, then it knows that the sender segmentation has not been > maintained (or it is talking to an old TCP sender that doesn't support > sender segmentation) and it has to fall back to treating the TCP data > stream as a raw unstructured byte stream, with message boundaries > indicated by occurrences of the the marker pattern. The important thing > is that the receiver still works correctly, even though the performance > will be lower. > > This prefer-sender-segmentation-but-verify approach is important. If the > outgoing data is not processed to guarantee that the special marker > pattern cannot occur, then malicious users might be able to subvert the > protocol by putting contrived patterns in their data. Remember the days > where you could make a user's modem hang up by sending them an email > containing the text "+++ATH"? (Apologies to anyone reading this via modem > who just had their telephone line hang up.) > > Another benefit of using in-band framing like this is that we can deploy > it immediately using unmodified TCP stacks. In the future we can use > enhanced sender TCP implementations that take steps to maintain segment > boundaries, and smart receivers will get a performance boost from that, > but it is a compatible upgrade that changes only the implementation, not > the on-the-wire protocol. > > Of course, we don't get anything for free. If we want to receiver to be > able to determine with 100% certainty that it has received a complete > iSCSI message in one TCP segment, then the sender will have to do some > work to enable that. This is the cost of COWS. It gives 100% framing > certainty, but at the cost of checking the outgoing data for inadvertent > occurrences of the special marker pattern, and eliminating them. There's > no way for a sender to tell whether the outgoing data contains > inadvertent occurrences of the special marker pattern if the sender is > not willing to look at the data. > > On the plus side, the cost of COWS encoding is modest compared to some > alternatives. COWS-encoding adds a little header but otherwise doesn't > change the size of the outgoing data, ever. No matter how many > occurrences of the framing marker pattern are found, the encoded output > length is always exactly the same: the length of the input plus the > length of the fixed-size framing header (typically two words). If the > framing marker pattern is chosen to be something that is rare in normal > (non-malicious) data, then in the common-case the encoding step will be a > read-only operation: scan the data, determine that it contains no framing > markers, set the COWS header to indicate that the data contains no > framing markers, and send it. > > In contrast, when using Fixed Interval Markers, if a marker happens to > fall in the middle of the data you are sending, then it creates a 'hole' > in the middle of data that used to be contiguous, and the block of > outgoing data changes size. On the receiving side, the 'hole' created by > the marker has to be repaired in the process of transferring the data > into memory. When using Fixed Interval Markers, when a receiver gets a > TCP segment that contains no marker, it cannot reliably determine what it > is supposed to do with that segment (where to put it in memory) without > referring the state from the previous TCP segments of that connection. I > don't believe that FIM can provide efficient idempotent direct data > placement for inbound TCP segments, because you can't rely on any given > received segment containing a marker via which the receiver can verify > that the segment contains a complete iSCSI message. > > In summary: > > My first choice would be to modify the TCP protocol to support > preservation of upper-level message boundaries. > > Given that this is not possible, I think COWS provdes a good alternative. > > Stuart Cheshire > * Wizard Without Portfolio, Apple Computer > * Chairman, IETF ZEROCONF > * www.stuartcheshire.org > > > > > > From owner-ips@ece.cmu.edu Sun Jan 13 19:46: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 TAA16296 for ; Sun, 13 Jan 2002 19:46:45 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0E034F25897 for ips-outgoing; Sun, 13 Jan 2002 19:03:04 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from over.ny.us.ibm.com (over.ny.us.ibm.com [32.97.182.111]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0E031j25892 for ; Sun, 13 Jan 2002 19:03:01 -0500 (EST) Received: from e31.co.us.ibm.com (e31.esmtp.ibm.com [9.14.4.129]) by admin.ny.us.ibm.com. (8.9.3/8.9.3) with ESMTP id QAA55160 for ; Thu, 10 Jan 2002 16:07:09 -0500 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 QAA239410 for ; Thu, 10 Jan 2002 16:05:49 -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 g0AL8lY22714 for ; Thu, 10 Jan 2002 14:08:47 -0700 X-Priority: 1 (High) Importance: Normal Subject: iSCSI: Markers To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Thu, 10 Jan 2002 13:08:04 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 01/10/2002 02:08:47 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk OK, Folks, I have now talked to Steph, who authored TUF, which is currently on the road to Experimental Status, He has authored another version of TUF also, which uses a form of COWS. So that means that we have two different versions of TUF as well as 2 versions of COWS (which are independent of Framing), and then there is FIM. So let me list them and be sure we name them so that we are not in the middle of more confusion. 1. Fixed Interval Markers (FIM) Currently In the iSCSI Draft 2. Constant Overhead Word Stuffing (COWS) as drafted by Julian and sent in his note of 12/23/2001 Subject "iSCSI - Synch an Steering Appendix - Markers & COWS" 3. TCP Upper-layer-protocol Framing (TUF) as drafted by Stephen Bailey in http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-ulp-frame-01.txt 4. COWS Drafted By Stephen Bailey which can be used in both in stream and with Framing in http://www.cs.uchicago.edu/~steph/draft-bailey-tsvwg-cows-00.txt Now lets call Julian's proposal COWS with 2 way pointers (COWS2WP) Now lets call Steph's COWS with 1 way pointers (COWS1WP) When the type of COWS does not matter we can just call them COWS. Both COWS can be used in Framing. But to keep this discussion somewhat simpler lets call the Framing without any COWS as "Bare Framing", and Both of the other as "COWS Framing". Only when we need to talk about which type of COWS should we say "COWS2WP Framing" or "COWS1WP Framing". But for most conversation it should be just "COWS Framing". So we have FIM, COWS1WP, COWS2WP, Bare Framing, & COWS Framing (made up of COWS1WP Framing and COWS2WP Framing). Now we also need to understand that one of the main reasons expressed to make Framing go experimental, instead of Standards Track was that folks were worried that Bare Framing was based on probability, and that there was a very remote possibility that something could be done incorrectly. As a result of that Steph was considering, as part of the experimental work, seeing what the impact of his previous COWS Draft would be on the experimental work that was going to be done. He had no intention of bringing it up now, since he felt work/thought was still needed. As you know COWS came up anyhow (and in a different form). So what we have are statements from folks like me that had read Julian's Draft and the ietf-tsvwg version of Framing (Bare Framing), which did not see in those drafts the overlap. Clearly there is an overlap in the minds of Julian for COWS2WP and Steph for COWS1WP and how they might impact Framing. NET of Bare Framing vs COWS Framing: Bare Framing is based on probability and does not have to inspect each Word (SW or HW) COW requires Touching each Word, COWS Framing is guaranteed to always be correct. So the choices are: 1. FIM now, and Bare Framing later 2. FIM now, and COWS Framing later 3. COWS now, and Bare Framing later 4. COWS now, and COWS Framing Later 5. Nothing now, and some kind of Framing Later If we chose to do any of the "COWS now" options we would need to hold the debate on which form, but we should assume that which ever COWS we chose now is the COWS for later. Value Statements 1. FIM and Bare Framing: Means we never have the overhead of touching every word 2. FIM and COWS Framing: Means that touching is postponed until Framing, and perhaps Faster Desktops/Laptops or support even support in normal NICs. 3. COWS now and Bare Framing later: Has issues of toughing everything now, and then not useful later 4. COWS now and COWS Framing Later: Means always touch, but current approach is extensible into Framing 5.Nothing now, and some kind of Framing later: Means No current help, and no guarantee of help in the future, but some reasonable probability that some form of Framing will happen. So it is 1-5 upon which we should be taking a position. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Mon Jan 14 11:14:17 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05418 for ; Mon, 14 Jan 2002 11:14:17 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0EFpC714776 for ips-outgoing; Mon, 14 Jan 2002 10:51:12 -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.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0EFpAj14771 for ; Mon, 14 Jan 2002 10:51:10 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jan 2002 10:45:59 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0293735B@CORPMX14> From: Black_David@emc.com To: Shridhar_Mukund@adaptec.com, ips@ece.cmu.edu Subject: RE: iSCSI: Markers and Framing Date: Mon, 14 Jan 2002 10:37:57 -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 A couple of comments on this: > b. I strongly recommend SHOULD implement FIM on the send side. > Implication -> Senders that do not insert markers should be > willing to accept up to RTT*BW data drops! Headers being > "reasonably" out-of-order is OK. Of course, senders that do not > insert markers but are willing to pay big $$$ to the SSP will > get their buffer/BW allocation as usual and customary :-) I think the Implication is too strong, as it goes against the following SHOULD from RFC 1122 (which modifies RFC 793): 4.2.2.20 Event Processing: RFC-793 Section 3.9 While it is not strictly required, a TCP SHOULD be capable of queueing out-of-order TCP segments. A drop causes the segments up to the retransmission of the drop to be out-of-order. This does not preclude "SHOULD implement FIM", but the above Implication is overdone in my view as it appears to condone drops of all out-of-order segments. > c. I think that the proponents and beholders of FIM had > good reasons. They still hold and are even more stronger. We > have had FIM in the iSCSI spec since version 02. Major changes > to the iSCSI draft, at this late date, should have significant > technical reasons. I just want to remind everyone that there can be "significant technical reasons" to change things at this juncture. One example is the change made to SCSI Task Management (e.g., Abort Task Set) in Salt Lake City. The balance in the above text between "changes ... at this late date" and "significant technical reasons" is a good way to think about this sort of issue. 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 Jan 14 11:14: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 LAA05495 for ; Mon, 14 Jan 2002 11:14:46 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0EFC2k12195 for ips-outgoing; Mon, 14 Jan 2002 10:12:02 -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 g0EFC1j12190 for ; Mon, 14 Jan 2002 10:12:01 -0500 (EST) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jan 2002 10:14:12 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937358@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: FCIP Author count Date: Mon, 14 Jan 2002 09:58: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 > Discussion of "Author Lists growing in size" > > Vote taken by Authors. Unanimous consensus of FCIP authors that all current > authors (as of FCIP r07c) have made substantial contributions to the FCIP > RFC and should remain on list. Unanimous consensus that Bill Krieg (Lucent) > should be added to author's list. (Welcome aboard, Bill!) That's unfortunate. The word from one of the ADs is: Q: How serious is the IESG about Bob Braden's request at the SLC plenary to reduce author count? A: Serious enough - I (AD) doubt that a doc with 20 authors ` will go anywhere. I suggest that the FCIP authors rethink this issue. 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 Jan 14 11:21: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 LAA05633 for ; Mon, 14 Jan 2002 11:21:22 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0EFaLS13800 for ips-outgoing; Mon, 14 Jan 2002 10:36:21 -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 g0EFaJj13793 for ; Mon, 14 Jan 2002 10:36:19 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jan 2002 10:36:13 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0293735A@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: RFC Editor changes Date: Mon, 14 Jan 2002 10:23:24 -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 More information about author count and separation of normative vs. non-normative references (among a few other topics) can be found at: http://www.rfc-editor.org/policy.html Anyone responsible for the actual text of a draft should read this, please. 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 Jan 14 13:19:26 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10838 for ; Mon, 14 Jan 2002 13:19:26 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0EHReU22142 for ips-outgoing; Mon, 14 Jan 2002 12:27: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 g0EFdBj13970 for ; Mon, 14 Jan 2002 10:39:11 -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 KAA04370; Mon, 14 Jan 2002 10:39:07 -0500 (EST) Message-Id: <200201141539.KAA04370@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-07.txt Date: Mon, 14 Jan 2002 10:39:07 -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) : K. Gibbons et al. Filename : draft-ietf-ips-isns-07.txt Pages : 84 Date : 11-Jan-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-07.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-07.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-07.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: <20020111152253.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-isns-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-isns-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020111152253.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Mon Jan 14 13:26: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 NAA11122 for ; Mon, 14 Jan 2002 13:26:03 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0EI1PL24589 for ips-outgoing; Mon, 14 Jan 2002 13:01:25 -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 g0EI1Nj24584 for ; Mon, 14 Jan 2002 13:01:23 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel11.hp.com (Postfix) with ESMTP id 43381E00369 for ; Mon, 14 Jan 2002 10:01:14 -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 KAA21780 for ; Mon, 14 Jan 2002 10:02:49 -0800 (PST) Message-Id: <200201141802.KAA21780@core.rose.hp.com> Date: Mon, 14 Jan 2002 10:14: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@ece.cmu.edu Subject: Re: iSCSI: Connection termination conditions References: <00ff01c19a86$ede50930$6264a8c0@hcltech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Nandakumar, As the preceding sentence indicates, the "graceful connection shutdown" being referred to is the TCP connection termination. All the text is saying is that the an intentional and graceful transport connection termination must also be "graceful" wrt iSCSI. The first sentence in this section requires rewording for rev10, and I suggest ignoring it for now. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Nandakumar Ramamurthy wrote: > > Hi All, > > Section 2.2.6 specifies two conditions for connection termination : > > "Graceful connection shutdowns MUST only occur when there are no > outstanding tasks that have allegiance to the connection and when the > connection is not in full-feature phase." > > The above statement is ambiguous as to what a graceful connection > shutdown is and the conditions in which this may occur. Can "graceful > connection shutdown" be elaborated upon? > > My interpretation is that there could be 2 possible cases when graceful > connection termination may occur. They are as follows: > > 1) A connection logout with no outstanding allegiant tasks is the first > condition. > In this case, the state of the connection is full feature. > > 2) The second case is when the connection is shutdown and the connection > state is not in full feature phase i.e., in SecurityNegotiation or > LoginOperationalNegotiation > phase. > > Is that the correct interpretation? > > Thanks, > Nandakumar > Member Technical Staff > HCL Technologies, Chennai, INDIA. > http://san.hcltech.com From owner-ips@ece.cmu.edu Mon Jan 14 16:27: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 QAA20174 for ; Mon, 14 Jan 2002 16:27:16 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0EKhSL06542 for ips-outgoing; Mon, 14 Jan 2002 15:43:28 -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 g0EKhPj06527 for ; Mon, 14 Jan 2002 15:43:25 -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 PAA31934 for ; Mon, 14 Jan 2002 15:40:22 -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 g0EKhC7104662 for ; Mon, 14 Jan 2002 13:43:12 -0700 X-Priority: 1 (High) Importance: Normal Subject: iSCSI Markers and Framing, a recomendation To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Mon, 14 Jan 2002 12:37:20 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 01/14/2002 01:43:10 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Now that I have punished you all with the notes defining what is Framing and COWS. I will lobby for one. Here again are the choices 1. FIM now, and Bare Framing later 2. FIM now, and COWS Framing later 3. COWS now, and Bare Framing later 4. COWS now, and COWS Framing Later 5. Nothing now, and some kind of Framing Later 6. FIM now, and some kind of Framing Later Two arguments one for FIM now and one for Bare Framing later: Let me start with "Framing Later": The more I have seen of the work going on defining RDMA/iWARP, and the work that is going into the Framing Experimental Status, the more I believe, we can NOT now know how this will work out. Let me give you an example. The only significant concern, with Bare Framing, is the case of a false positive indicator only when the network has re-segmented the TCP Segment. The Bare Framing protocol has a 48-bit Random number and a 16 bit length field to detect this. I believe this has a lower probability of false positives then passing an undetected error through the 16 bit TCP/IP XOR Checksum, and possibly even the 32-bit CRC. So the Experimental work was started to prove that this was not an issue. Now, even though Bare Framing is the easiest to implement, and probably statically just fine (at least in my opinion), some folks are attempting to come up with a fool proof approach, which probably causes more implementation costs. (You can bet that will be a major shoot out.) No one yet has been able to do the needed math to prove that Bare Framing is a problem or not a problem (volunteers anyone?). But sooner or later some one will do that. There is even a chance that another word could be added to the Random Number to make it even stronger. In the mean time we have two Different COWS proposals, and no one knows if something now unknown will bleed over from the RDMA work. We simply do not know how the Framing will work out. iSCSI choosing a Marking approach to match one of the perceived Framing approaches, will not cause that approach to happen, and it is probably going to cause turf wars, and other non productive interactions. Therefore, I have come to the conclusion that Markers and Framing are disjoint issues. Further, we have no control over the direction of framing. Now my arguments for "FIM now": FIM is the lowest overhead Marker approach we have been able to come up with. I think we need something that can easily be placed into SW ( In this context I am talking about SW that does not "OWN" the Host TCP/IP stack.). As I have stated before, FIM is simple to implement and can greatly help some HW. It needs to be Sent only if requested, and not other wise. It has been in the spec for some time, is therefore well understood and I think it has been scrubbed my a number of different vendors. Some of which have told me that they have either placed it in their product or are working on that. This is NOT to say that we can not change it, but that because of its longevity in the spec, has undergone a lot of study. And we should have important reasons not to do FIM (such as if it doesn't work). Now, Jonathan Stone, has stated that "transatlantic can regularly show 50% drop rate". I would like the vendors to have some approach to enable a reasonable solution, to this and other long haul requirements, which keeps the Adapter cost as low as possible. Also, that would mean that it can NOT wait until 10 Gig. Now to the issue of MUST or SHOULD implement. I have been persuaded that "SHOULD implement on Send" but optional to use, would be a more acceptable position, since vendors with good and just reasons would not have to implement it, yet the customer could find solutions if they needed them. Therefore, based on the above reasoning, I am recommending: Choice 6, with "SHOULD implement on Send". That is, Leave FIM in the Spec, and add an enabling statement about "SHOULD implement on Send if requested by the receiving side". . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Mon Jan 14 23:24: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 XAA03778 for ; Mon, 14 Jan 2002 23:24:58 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0F3O4Q29533 for ips-outgoing; Mon, 14 Jan 2002 22:24: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-h016.c003.snv.cp.net [209.228.32.230]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g0F3O2j29527 for ; Mon, 14 Jan 2002 22:24:02 -0500 (EST) Received: (cpmta 1932 invoked from network); 14 Jan 2002 19:23:52 -0800 Received: from 64.130.130.105 (HELO dougrmt) by smtp.telocity.com (209.228.32.230) with SMTP; 14 Jan 2002 19:23:52 -0800 X-Sent: 15 Jan 2002 03:23:52 GMT From: "Douglas Otis" To: Subject: RE: iSCSI Markers and Framing, a recomendation Date: Mon, 14 Jan 2002 19:24:23 -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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit John, One other possible consideration would be to use a framing transport that also solves: - Blind or Flood Attacks - Single State Fast Recovery Multi-Homing - Non-Blocking Service Level Resolution - Improved Data Integrity with Framing and Alignment - Standardized Path Management - TLV Bundling for Differential Path MTUs - Unordered Delivery - Payload Identification These features are extremely important for any mission critical application. The AAA WG already recommends this new transport for authentication, authorization, and accounting services. IPS should review current RSERPOOL efforts for Association aggregation as well. A transatlantic link with a 50% loss rate is not of any concern with respect to bandwidth or system overhead. This would represent almost no traffic and would be best handled by a non-modified TCP implementation. One consideration not in this debate would be to exclude modifications to TCP and not incorporate these extensions by means of experimental techniques and instead consider improvements found by a sanctioned transport. This would go a long way in restoring trust. A random number could be a string of 20 hex bytes or all zeros and the header found by resegmentation may have a high likelihood of presenting that value. In other words, not all random numbers offer significant protection. Once the wrong header is used, there is no recovery possible even if such an error is later uncovered, as the intent is to de-encapsulate data below the transport and place it directly into user buffers. Techniques specific to iSCSI are not likely to find support in the future as features not possible by these patch methods will force iSCSI to remain inferior to ongoing work. Should you wish to find a technique that will be used by a broad range of applications, then a search for this technique should not be conducted within this workgroup, as this is clearly not its charter nor its expertise. Your choice of Should use Fixed Interval Markers is perhaps innocuous, but as this represents changing TCP to make use of this feature; would not this recommendation of Should be a bit too strong? Doug > Now that I have punished you all with the notes defining what is Framing > and COWS. I will lobby for one. > > Here again are the choices > > 1. FIM now, and Bare Framing later > 2. FIM now, and COWS Framing later > 3. COWS now, and Bare Framing later > 4. COWS now, and COWS Framing Later > 5. Nothing now, and some kind of Framing Later > 6. FIM now, and some kind of Framing Later > > Two arguments one for FIM now and one for Bare Framing later: > > Let me start with "Framing Later": > > The more I have seen of the work going on defining RDMA/iWARP, > and the work > that is going into the Framing Experimental Status, the more I believe, we > can NOT now know how this will work out. Let me give you an example. The > only significant concern, with Bare Framing, is the case of a false > positive indicator only when the network has re-segmented the TCP Segment. > The Bare Framing protocol has a 48-bit Random number and a 16 bit length > field to detect this. I believe this has a lower probability of false > positives then passing an undetected error through the 16 bit TCP/IP XOR > Checksum, and possibly even the 32-bit CRC. So the Experimental work was > started to prove that this was not an issue. Now, even though > Bare Framing > is the easiest to implement, and probably statically just fine > (at least in > my opinion), some folks are attempting to come up with a fool proof > approach, which probably causes more implementation costs. (You can bet > that will be a major shoot out.) No one yet has been able to do > the needed > math to prove that Bare Framing is a problem or not a problem (volunteers > anyone?). But sooner or later some one will do that. There is even a > chance that another word could be added to the Random Number to make it > even stronger. In the mean time we have two Different COWS proposals, > and no one knows if something now unknown will bleed over from the RDMA > work. > > We simply do not know how the Framing will work out. > > iSCSI choosing a Marking approach to match one of the perceived Framing > approaches, will not cause that approach to happen, and it is probably > going to cause turf wars, and other non productive interactions. > > Therefore, I have come to the conclusion that Markers and Framing are > disjoint issues. Further, we have no control over the direction of > framing. > > Now my arguments for "FIM now": > > FIM is the lowest overhead Marker approach we have been able to come up > with. I think we need something that can easily be placed into SW ( In > this context I am talking about SW that does not "OWN" the Host TCP/IP > stack.). As I have stated before, FIM is simple to implement and can > greatly help some HW. It needs to be Sent only if requested, and not > other wise. It has been in the spec for some time, is therefore well > understood and I think it has been scrubbed my a number of different > vendors. Some of which have told me that they have either placed it in > their product or are working on that. This is NOT to say that we can not > change it, but that because of its longevity in the spec, has undergone a > lot of study. And we should have important reasons not to do FIM (such as > if it doesn't work). > Now, Jonathan Stone, has stated that "transatlantic can regularly show 50% > drop rate". I would like the vendors to have some approach to enable a > reasonable solution, to this and other long haul requirements, which keeps > the Adapter cost as low as possible. Also, that would mean that > it can NOT > wait until 10 Gig. > > Now to the issue of MUST or SHOULD implement. > > I have been persuaded that "SHOULD implement on Send" but optional to use, > would be a more acceptable position, since vendors with good and just > reasons would not have to implement it, yet the customer could find > solutions if they needed them. > > Therefore, based on the above reasoning, I am recommending: > > Choice 6, with "SHOULD implement on Send". That is, > > Leave FIM in the Spec, and add an enabling statement about "SHOULD > implement on Send if requested by the receiving side". > > > . > . > . > 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 Jan 15 07:33: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 HAA20011 for ; Tue, 15 Jan 2002 07:33:05 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0FBOnh01456 for ips-outgoing; Tue, 15 Jan 2002 06:24:49 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from webmail.iei.com.tw (c65.h202052108.is.net.tw [202.52.108.65]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0FBOkj01452 for ; Tue, 15 Jan 2002 06:24:46 -0500 (EST) Received: from nike ([172.16.14.227]) by webmail.iei.com.tw (Lotus Domino Release 5.0.8) with SMTP id 2002011516283710:2711 ; Tue, 15 Jan 2002 16:28:37 +0800 Message-ID: <006c01c19d9e$a0e60fb0$e30e10ac@hq.iei> From: "Nike Chen" To: Subject: Differences between iSCSI Router (ex. CISCO RN5420) and iSCSI Switch (ex. SANRAD Switch 3000) Date: Tue, 15 Jan 2002 16:28:34 +0800 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MIMETrack: Itemize by SMTP Server on webmail/iei2(Release 5.0.8 |June 18, 2001) at 2002/01/15 04:28:37 PM, Serialize by Router on webmail/iei2(Release 5.0.8 |June 18, 2001) at 2002/01/15 07:23:32 PM, Serialize complete at 2002/01/15 07:23:32 PM Content-Type: multipart/alternative; boundary="----=_NextPart_000_0069_01C19DE1.AD2FADB0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0069_01C19DE1.AD2FADB0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Hi All: Would anybody tell me the function differences between iSCSI Router and = Switch,=20 or just like performance difference in Layer 3 switch and Router? When it say it is a iSCSI switch, what level do it operate, level 2, 3 = or 4? When it say it is a iSCSI Router, what level do it operate, or just a = protocol converting gateway? Is there any definition for iSCSI Router or iSCSI switch? Thanks, Nike ------=_NextPart_000_0069_01C19DE1.AD2FADB0 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Hi All:
 
Would anybody tell me the function = differences=20 between iSCSI Router and Switch,
or just like=20 performance difference in Layer 3 switch and Router?
When it say it is a iSCSI = switch, what level do it=20 operate, level 2, 3 or 4?
When it say it is a iSCSI = Router, what level do it=20 operate, or just a protocol
converting = gateway?
Is there any = definition for iSCSI Router or=20 iSCSI switch?
 
Thanks,
Nike
 
 
 
------=_NextPart_000_0069_01C19DE1.AD2FADB0-- From owner-ips@ece.cmu.edu Tue Jan 15 09: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 JAA24454 for ; Tue, 15 Jan 2002 09:27:36 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0FDd7507257 for ips-outgoing; Tue, 15 Jan 2002 08:39:07 -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 g0FDd2j07250 for ; Tue, 15 Jan 2002 08:39:02 -0500 (EST) Received: from nramamurpc (nramamur-pc.hcltech.com [192.168.100.98]) by mailnpd.hcltech.com (8.11.0/8.11.0) with SMTP id g0FDXxw01817; Tue, 15 Jan 2002 19:04:01 +0530 Message-ID: <02a301c19dc9$fb96b5b0$6264a8c0@hcltech.com> From: "Nandakumar Ramamurthy" To: , References: <00ff01c19a86$ede50930$6264a8c0@hcltech.com> <200201141802.KAA21780@core.rose.hp.com> Subject: Re: iSCSI: Connection termination conditions Date: Tue, 15 Jan 2002 19:08:54 +0530 Organization: HCL Technologies Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 Hi Mallikarjun, Agreed that there exists a distinction between a TCP connection and an iSCSI connection. IMHO, an iSCSI logout should precede sending TCP FINs. Section 2.2.6 must offer a clearer explanation in this regard. As the section is entitled "iSCSI Connection Termination", there should be more focus on termination of an iSCSI connection. A separate section entitled "TCP Connection Termination" could probably speak about TCP related intricacies. My understanding of iSCSI connection termination is : An intentional and graceful iSCSI connection termination MUST occur only through the iSCSI logout process ( either implicit or explicit ). This is not clear from section 2.2.6. ( Are the 2 situations specified in my earlier mail valid? ) Section 3.13.5 states : "If the Status Class is not 0, the initiator and target MUST close the TCP connection." Does this constitute a graceful TCP connection termination? What are the other interpretations for a "graceful" iSCSI connection termination? Can "graceful" connection termination happen when it is not in full-feature phase? How? Please describe the related mechanism. Thanks, Nandakumar Member Technical Staff HCL Technologies, Chennai, INDIA. http://san.hcltech.com ----- Original Message ----- From: "Mallikarjun C." To: Sent: Monday, January 14, 2002 11:44 PM Subject: Re: iSCSI: Connection termination conditions > Nandakumar, > > As the preceding sentence indicates, the "graceful connection > shutdown" being referred to is the TCP connection termination. > > All the text is saying is that the an intentional and graceful > transport connection termination must also be "graceful" wrt iSCSI. > The first sentence in this section requires rewording for rev10, > and I suggest ignoring it for now. > > Thanks. > -- > Mallikarjun > > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > > Nandakumar Ramamurthy wrote: > > > > Hi All, > > > > Section 2.2.6 specifies two conditions for connection termination : > > > > "Graceful connection shutdowns MUST only occur when there are no > > outstanding tasks that have allegiance to the connection and when the > > connection is not in full-feature phase." > > > > The above statement is ambiguous as to what a graceful connection > > shutdown is and the conditions in which this may occur. Can "graceful > > connection shutdown" be elaborated upon? > > > > My interpretation is that there could be 2 possible cases when graceful > > connection termination may occur. They are as follows: > > > > 1) A connection logout with no outstanding allegiant tasks is the first > > condition. > > In this case, the state of the connection is full feature. > > > > 2) The second case is when the connection is shutdown and the connection > > state is not in full feature phase i.e., in SecurityNegotiation or > > LoginOperationalNegotiation > > phase. > > > > Is that the correct interpretation? > > > > Thanks, > > Nandakumar > > Member Technical Staff > > HCL Technologies, Chennai, INDIA. > > http://san.hcltech.com > From owner-ips@ece.cmu.edu Tue Jan 15 10:09: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 KAA28150 for ; Tue, 15 Jan 2002 10:09:15 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0FEJDV09453 for ips-outgoing; Tue, 15 Jan 2002 09:19:13 -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 g0FBPxj01499 for ; Tue, 15 Jan 2002 06:25:59 -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 GAA17554; Tue, 15 Jan 2002 06:25:57 -0500 (EST) Message-Id: <200201151125.GAA17554@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-00.txt Date: Tue, 15 Jan 2002 06:25:56 -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-00.txt Pages : 36 Date : 14-Jan-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-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-ietf-ips-scsi-mib-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-ietf-ips-scsi-mib-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: <20020114174815.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-scsi-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-scsi-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020114174815.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Tue Jan 15 11:14:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00831 for ; Tue, 15 Jan 2002 11:14:18 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0FFVj414260 for ips-outgoing; Tue, 15 Jan 2002 10:31:45 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0FFVij14255 for ; Tue, 15 Jan 2002 10:31:44 -0500 (EST) 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 HAA29582 for ; Tue, 15 Jan 2002 07:31:36 -0800 (PST) Message-ID: <3C444848.E3B4ABF7@cisco.com> Date: Tue, 15 Jan 2002 09:18:32 -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 CC: ips@ece.cmu.edu Subject: Re: I-D ACTION:draft-ietf-ips-scsi-mib-00.txt References: <200201151125.GAA17554@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit This draft was produced using Word, which left a lot of space in the left margin, and did not put in the page feeds. I have a version available with adjusted margins and page feeds (I did not change anything else) on my ftp site at: ftp://ftpeng.cisco.com/mbakke/ips/scsi-mib/draft-ietf-ips-scsi-mib-00-reformat.txt in case it's useful to anyone. BTW, the UML is also available on the same site as: ftp://ftpeng.cisco.com/mbakke/ips/scsi-mib/Visio-scsi-uml-model-00d.pdf -- Mark Internet-Drafts@ietf.org wrote: > > 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-00.txt > Pages : 36 > Date : 14-Jan-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-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-ietf-ips-scsi-mib-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-ietf-ips-scsi-mib-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. > > ---------------------------------------------------------------------------------------------------- > Content-Type: text/plain > Content-ID: <20020114174815.I-D@ietf.org> -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Jan 15 11:14: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 LAA00862 for ; Tue, 15 Jan 2002 11:14:29 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0FF6i312747 for ips-outgoing; Tue, 15 Jan 2002 10:06:44 -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 g0FF6gj12741 for ; Tue, 15 Jan 2002 10:06:42 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jan 2002 10:06:36 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0293736E@CORPMX14> From: Black_David@emc.com To: dotis@sanlight.net, ips@ece.cmu.edu Subject: RE: iSCSI Markers and Framing, a recomendation Date: Tue, 15 Jan 2002 09:53: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 With my WG chair hat on, Doug's email raises a number of issues that need to be dealt with: (1) SCTP should be substituted for TCP in iSCSI. Doug and anyone else is welcome to write a draft on the use of SCTP for iSCSI, but the long-standing rough consensus of this WG is to use TCP, and hence substitution of SCTP for TCP in the main iSCSI draft is not in the cards. (2) The random number approach used in the TCP ULP framing draft may result in false detection of a frame boundary. That topic is covered in the tsvwg draft - see Section 5.2.1 of draft-ietf-tsvwg-tcp-ulp-frame-01.txt. It's germane to mention here, e.g., in support of: (3) iSCSI should not reference the TCP ULP framing draft in any fashion. That's a reasonable input to the discussion. As I've said before, I think specifying use of TCP ULP framing with iSCSI in a separate experimental ips draft that can make a normative reference to the tsvwg draft would be preferable to continuing to describe this in the main iSCSI draft. (4) iSCSI should not specify any framing technique, including FIM, and should not use "SHOULD" for the requirement level. Also reasonable input to the discussion. Let me take the opportunity to remind folks to look to RFC 2119 for the definition of "SHOULD", as that definition differs from what one may find in an ordinary dictionary. 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: Douglas Otis [mailto:dotis@sanlight.net] > Sent: Monday, January 14, 2002 10:24 PM > To: ips@ece.cmu.edu > Subject: RE: iSCSI Markers and Framing, a recomendation > > > John, > > One other possible consideration would be to use a framing > transport that > also solves: > - Blind or Flood Attacks > - Single State Fast Recovery Multi-Homing > - Non-Blocking Service Level Resolution > - Improved Data Integrity with Framing and Alignment > - Standardized Path Management > - TLV Bundling for Differential Path MTUs > - Unordered Delivery > - Payload Identification > > These features are extremely important for any mission > critical application. > > The AAA WG already recommends this new transport for authentication, > authorization, and accounting services. > IPS should review current RSERPOOL efforts for Association > aggregation as > well. > > A transatlantic link with a 50% loss rate is not of any > concern with respect > to bandwidth or system overhead. This would represent almost > no traffic and > would be best handled by a non-modified TCP implementation. > > One consideration not in this debate would be to exclude > modifications to > TCP and not incorporate these extensions by means of > experimental techniques > and instead consider improvements found by a sanctioned > transport. This > would go a long way in restoring trust. > > A random number could be a string of 20 hex bytes or all zeros and the > header found by resegmentation may have a high likelihood of > presenting that > value. In other words, not all random numbers offer > significant protection. > Once the wrong header is used, there is no recovery possible > even if such an > error is later uncovered, as the intent is to de-encapsulate > data below the > transport and place it directly into user buffers. > > Techniques specific to iSCSI are not likely to find support > in the future as > features not possible by these patch methods will force iSCSI > to remain > inferior to ongoing work. Should you wish to find a > technique that will be > used by a broad range of applications, then a search for this > technique > should not be conducted within this workgroup, as this is > clearly not its > charter nor its expertise. Your choice of Should use Fixed > Interval Markers > is perhaps innocuous, but as this represents changing TCP to > make use of > this feature; would not this recommendation of Should be a > bit too strong? > > Doug > > > > Now that I have punished you all with the notes defining > what is Framing > > and COWS. I will lobby for one. > > > > Here again are the choices > > > > 1. FIM now, and Bare Framing later > > 2. FIM now, and COWS Framing later > > 3. COWS now, and Bare Framing later > > 4. COWS now, and COWS Framing Later > > 5. Nothing now, and some kind of Framing Later > > 6. FIM now, and some kind of Framing Later > > > > Two arguments one for FIM now and one for Bare Framing later: > > > > Let me start with "Framing Later": > > > > The more I have seen of the work going on defining RDMA/iWARP, > > and the work > > that is going into the Framing Experimental Status, the > more I believe, we > > can NOT now know how this will work out. Let me give you > an example. The > > only significant concern, with Bare Framing, is the case of a false > > positive indicator only when the network has re-segmented > the TCP Segment. > > The Bare Framing protocol has a 48-bit Random number and a > 16 bit length > > field to detect this. I believe this has a lower > probability of false > > positives then passing an undetected error through the 16 > bit TCP/IP XOR > > Checksum, and possibly even the 32-bit CRC. So the > Experimental work was > > started to prove that this was not an issue. Now, even though > > Bare Framing > > is the easiest to implement, and probably statically just fine > > (at least in > > my opinion), some folks are attempting to come up with a fool proof > > approach, which probably causes more implementation costs. > (You can bet > > that will be a major shoot out.) No one yet has been able to do > > the needed > > math to prove that Bare Framing is a problem or not a > problem (volunteers > > anyone?). But sooner or later some one will do that. > There is even a > > chance that another word could be added to the Random > Number to make it > > even stronger. In the mean time we have two Different > COWS proposals, > > and no one knows if something now unknown will bleed over > from the RDMA > > work. > > > > We simply do not know how the Framing will work out. > > > > iSCSI choosing a Marking approach to match one of the > perceived Framing > > approaches, will not cause that approach to happen, and it > is probably > > going to cause turf wars, and other non productive interactions. > > > > Therefore, I have come to the conclusion that Markers and > Framing are > > disjoint issues. Further, we have no control over the direction of > > framing. > > > > Now my arguments for "FIM now": > > > > FIM is the lowest overhead Marker approach we have been > able to come up > > with. I think we need something that can easily be placed > into SW ( In > > this context I am talking about SW that does not "OWN" the > Host TCP/IP > > stack.). As I have stated before, FIM is simple to > implement and can > > greatly help some HW. It needs to be Sent only if > requested, and not > > other wise. It has been in the spec for some time, is > therefore well > > understood and I think it has been scrubbed my a number of > different > > vendors. Some of which have told me that they have either > placed it in > > their product or are working on that. This is NOT to say > that we can not > > change it, but that because of its longevity in the spec, > has undergone a > > lot of study. And we should have important reasons not to > do FIM (such as > > if it doesn't work). > > Now, Jonathan Stone, has stated that "transatlantic can > regularly show 50% > > drop rate". I would like the vendors to have some > approach to enable a > > reasonable solution, to this and other long haul > requirements, which keeps > > the Adapter cost as low as possible. Also, that would mean that > > it can NOT > > wait until 10 Gig. > > > > Now to the issue of MUST or SHOULD implement. > > > > I have been persuaded that "SHOULD implement on Send" but > optional to use, > > would be a more acceptable position, since vendors with > good and just > > reasons would not have to implement it, yet the customer could find > > solutions if they needed them. > > > > Therefore, based on the above reasoning, I am recommending: > > > > Choice 6, with "SHOULD implement on Send". That is, > > > > Leave FIM in the Spec, and add an enabling statement about "SHOULD > > implement on Send if requested by the receiving side". > > > > > > . > > . > > . > > 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 Jan 15 12:29: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 MAA06205 for ; Tue, 15 Jan 2002 12:29:04 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0FGEVd17647 for ips-outgoing; Tue, 15 Jan 2002 11:14:31 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0FGESj17637 for ; Tue, 15 Jan 2002 11:14:29 -0500 (EST) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id IAA12956; Tue, 15 Jan 2002 08:13:46 -0800 (PST) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jan 2002 08:13:45 -0800 Message-ID: <176B85B0D4E0D411BA5200508B692E0A049DBC92@hq-ex-1.brocade.com> From: Camden Ford To: "'Nike Chen'" , ips@ece.cmu.edu Subject: RE: Differences between iSCSI Router (ex. CISCO RN5420) and iSCSI Switch (ex. SANRAD Switch 3000) Date: Tue, 15 Jan 2002 08:13:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19DDF.9B75EFF0" 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_01C19DDF.9B75EFF0 Content-Type: text/plain; charset="big5" Nike, Please be careful about the difference between technical capabilities and Marketing fluff. Cisco's iSCSI Router is simply a bridge between FC and iSCSI. It performs protocol conversion for SCSI commands encapsulated in iSCSI on TCP and SCSI commands encapsulated in FC. This product also provides simplistic mapping between iSCSI devices and FC domains. I am not familiar with the SANRAD switch, but I suspect that provides very similar capabilities. If you were to compare either of these products to our notion of Switching and Routing in the IP/Ethernet world, these are neither Switches or Routers....but simple Bridges, much like the early Ethernet Bridges. iSCSI switches are simple Ethernet Switches or any other switch that can switch or route TCP/IP. Because iSCSI utilizes TCP/IP, the iSCSI protocol rides as a byte stream on top of TCP. Therefore, most switches are unaware that the packets that they are switching or routing are actually iSCSI. They simply appear as another TCP byte stream. So if you think in terms of Layer X switching, a simple Layer 2 switch is a switch based in a transports like EThernet, a Layer 3 switch is a simple version of a router with IP forwarding inmplemented in HW. A Layer 4 switch can prioritize traffic based on TCP connections. In order to provide intelligence in a switch that recognizes iSCSI, it would be somewhere in Layer 5-7 depending on what you filter on. I would imaging that in order for any product to be a Storage Router, there would have to be the notion of Global Addressing of storage elements....something which does not exist today. Technically, FC switching is based on logical addressing, and not physical addresses, so it is most similar to Layer 3 switching in IP/EThernet....which some might call a router. Camden ford -----Original Message----- From: Nike Chen [mailto:nikechen@ksts.seed.net.tw] Sent: Tuesday, January 15, 2002 12:29 AM To: ips@ece.cmu.edu Subject: Differences between iSCSI Router (ex. CISCO RN5420) and iSCSI Switch (ex. SANRAD Switch 3000) Hi All: Would anybody tell me the function differences between iSCSI Router and Switch, or just like performance difference in Layer 3 switch and Router? When it say it is a iSCSI switch, what level do it operate, level 2, 3 or 4? When it say it is a iSCSI Router, what level do it operate, or just a protocol converting gateway? Is there any definition for iSCSI Router or iSCSI switch? Thanks, Nike ------_=_NextPart_001_01C19DDF.9B75EFF0 Content-Type: text/html; charset="big5"
Nike,
 
Please be careful about the difference between technical capabilities and Marketing fluff.  Cisco's iSCSI Router is simply a  bridge between FC and iSCSI.  It performs protocol conversion for SCSI commands encapsulated in iSCSI on TCP and SCSI commands encapsulated in FC.  This product also provides simplistic mapping between iSCSI devices and FC domains.
 
I am not familiar with the SANRAD switch, but I suspect that provides very similar capabilities.
 
If you were to compare either of these products to our notion of Switching and Routing in the IP/Ethernet world, these are neither Switches or Routers....but simple Bridges, much like the early Ethernet Bridges.
 
iSCSI switches are simple Ethernet Switches or any other switch that can switch or route TCP/IP.  Because iSCSI utilizes TCP/IP, the iSCSI protocol rides as a byte stream on top of TCP.  Therefore, most switches are unaware that the packets that they are switching or routing are actually iSCSI.  They simply appear as another TCP byte stream.  So if you think in terms of Layer X switching, a simple Layer 2 switch is a switch based in a transports like EThernet, a Layer 3 switch is a simple version of a router with IP forwarding inmplemented in HW.  A Layer 4 switch can prioritize traffic based on TCP connections.  In order to provide intelligence in a switch that recognizes iSCSI, it would be somewhere in Layer 5-7 depending on what you filter on.
 
I would imaging that in order for any product to be a Storage Router, there would have to be the notion of Global Addressing of storage elements....something which does not exist today.
 
Technically, FC switching is based on logical addressing, and not physical addresses, so it is most similar to Layer 3 switching in IP/EThernet....which some might call a router.
 
Camden ford
-----Original Message-----
From: Nike Chen [mailto:nikechen@ksts.seed.net.tw]
Sent: Tuesday, January 15, 2002 12:29 AM
To: ips@ece.cmu.edu
Subject: Differences between iSCSI Router (ex. CISCO RN5420) and iSCSI Switch (ex. SANRAD Switch 3000)

Hi All:
 
Would anybody tell me the function differences between iSCSI Router and Switch,
or just like performance difference in Layer 3 switch and Router?
When it say it is a iSCSI switch, what level do it operate, level 2, 3 or 4?
When it say it is a iSCSI Router, what level do it operate, or just a protocol
converting gateway?
Is there any definition for iSCSI Router or iSCSI switch?
 
Thanks,
Nike
 
 
 
------_=_NextPart_001_01C19DDF.9B75EFF0-- From owner-ips@ece.cmu.edu Tue Jan 15 12:29: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 MAA06227 for ; Tue, 15 Jan 2002 12:29:10 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0FGlmD20280 for ips-outgoing; Tue, 15 Jan 2002 11:47:48 -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 g0FGlkj20275 for ; Tue, 15 Jan 2002 11:47:46 -0500 (EST) Received: (cpmta 595 invoked from network); 15 Jan 2002 08:47:38 -0800 Received: from 64.130.130.105 (HELO dougrmt) by smtp.telocity.com (209.228.32.229) with SMTP; 15 Jan 2002 08:47:38 -0800 X-Sent: 15 Jan 2002 16:47:38 GMT From: "Douglas Otis" To: Subject: RE: iSCSI Markers and Framing, a recomendation Date: Tue, 15 Jan 2002 08:48:11 -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) In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0293736E@CORPMX14> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, I felt continued discussion on changing a TCP implementation was indication of dissatisfaction by the WG. Use of a sanctioned transport should be preferable over deciding how to alter TCP. Even minor points such as increased SACK size is sure to place protocols sensitive to bandwidth in an inferior status if restricted to just TCP in my view. Thank you for the clarification and I am sorry for the disruption. Doug > With my WG chair hat on, Doug's email raises a number of > issues that need to be dealt with: > > (1) SCTP should be substituted for TCP in iSCSI. > > Doug and anyone else is welcome to write a draft on the > use of SCTP for iSCSI, but the long-standing rough consensus > of this WG is to use TCP, and hence substitution of SCTP > for TCP in the main iSCSI draft is not in the cards. > > (2) The random number approach used in the TCP > ULP framing draft may result in false > detection of a frame boundary. > > That topic is covered in the tsvwg draft - see Section 5.2.1 > of draft-ietf-tsvwg-tcp-ulp-frame-01.txt. It's germane to > mention here, e.g., in support of: > > (3) iSCSI should not reference the TCP ULP framing > draft in any fashion. > > That's a reasonable input to the discussion. As I've said > before, I think specifying use of TCP ULP framing with > iSCSI in a separate experimental ips draft that can make > a normative reference to the tsvwg draft would be preferable > to continuing to describe this in the main iSCSI draft. > > (4) iSCSI should not specify any framing technique, > including FIM, and should not use "SHOULD" for > the requirement level. > > Also reasonable input to the discussion. Let me take the > opportunity to remind folks to look to RFC 2119 for the > definition of "SHOULD", as that definition differs from > what one may find in an ordinary dictionary. > > 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: Douglas Otis [mailto:dotis@sanlight.net] > > Sent: Monday, January 14, 2002 10:24 PM > > To: ips@ece.cmu.edu > > Subject: RE: iSCSI Markers and Framing, a recomendation > > > > > > John, > > > > One other possible consideration would be to use a framing > > transport that > > also solves: > > - Blind or Flood Attacks > > - Single State Fast Recovery Multi-Homing > > - Non-Blocking Service Level Resolution > > - Improved Data Integrity with Framing and Alignment > > - Standardized Path Management > > - TLV Bundling for Differential Path MTUs > > - Unordered Delivery > > - Payload Identification > > > > These features are extremely important for any mission > > critical application. > > > > The AAA WG already recommends this new transport for authentication, > > authorization, and accounting services. > > IPS should review current RSERPOOL efforts for Association > > aggregation as > > well. > > > > A transatlantic link with a 50% loss rate is not of any > > concern with respect > > to bandwidth or system overhead. This would represent almost > > no traffic and > > would be best handled by a non-modified TCP implementation. > > > > One consideration not in this debate would be to exclude > > modifications to > > TCP and not incorporate these extensions by means of > > experimental techniques > > and instead consider improvements found by a sanctioned > > transport. This > > would go a long way in restoring trust. > > > > A random number could be a string of 20 hex bytes or all zeros and the > > header found by resegmentation may have a high likelihood of > > presenting that > > value. In other words, not all random numbers offer > > significant protection. > > Once the wrong header is used, there is no recovery possible > > even if such an > > error is later uncovered, as the intent is to de-encapsulate > > data below the > > transport and place it directly into user buffers. > > > > Techniques specific to iSCSI are not likely to find support > > in the future as > > features not possible by these patch methods will force iSCSI > > to remain > > inferior to ongoing work. Should you wish to find a > > technique that will be > > used by a broad range of applications, then a search for this > > technique > > should not be conducted within this workgroup, as this is > > clearly not its > > charter nor its expertise. Your choice of Should use Fixed > > Interval Markers > > is perhaps innocuous, but as this represents changing TCP to > > make use of > > this feature; would not this recommendation of Should be a > > bit too strong? > > > > Doug > > > > > > > Now that I have punished you all with the notes defining > > what is Framing > > > and COWS. I will lobby for one. > > > > > > Here again are the choices > > > > > > 1. FIM now, and Bare Framing later > > > 2. FIM now, and COWS Framing later > > > 3. COWS now, and Bare Framing later > > > 4. COWS now, and COWS Framing Later > > > 5. Nothing now, and some kind of Framing Later > > > 6. FIM now, and some kind of Framing Later > > > > > > Two arguments one for FIM now and one for Bare Framing later: > > > > > > Let me start with "Framing Later": > > > > > > The more I have seen of the work going on defining RDMA/iWARP, > > > and the work > > > that is going into the Framing Experimental Status, the > > more I believe, we > > > can NOT now know how this will work out. Let me give you > > an example. The > > > only significant concern, with Bare Framing, is the case of a false > > > positive indicator only when the network has re-segmented > > the TCP Segment. > > > The Bare Framing protocol has a 48-bit Random number and a > > 16 bit length > > > field to detect this. I believe this has a lower > > probability of false > > > positives then passing an undetected error through the 16 > > bit TCP/IP XOR > > > Checksum, and possibly even the 32-bit CRC. So the > > Experimental work was > > > started to prove that this was not an issue. Now, even though > > > Bare Framing > > > is the easiest to implement, and probably statically just fine > > > (at least in > > > my opinion), some folks are attempting to come up with a fool proof > > > approach, which probably causes more implementation costs. > > (You can bet > > > that will be a major shoot out.) No one yet has been able to do > > > the needed > > > math to prove that Bare Framing is a problem or not a > > problem (volunteers > > > anyone?). But sooner or later some one will do that. > > There is even a > > > chance that another word could be added to the Random > > Number to make it > > > even stronger. In the mean time we have two Different > > COWS proposals, > > > and no one knows if something now unknown will bleed over > > from the RDMA > > > work. > > > > > > We simply do not know how the Framing will work out. > > > > > > iSCSI choosing a Marking approach to match one of the > > perceived Framing > > > approaches, will not cause that approach to happen, and it > > is probably > > > going to cause turf wars, and other non productive interactions. > > > > > > Therefore, I have come to the conclusion that Markers and > > Framing are > > > disjoint issues. Further, we have no control over the direction of > > > framing. > > > > > > Now my arguments for "FIM now": > > > > > > FIM is the lowest overhead Marker approach we have been > > able to come up > > > with. I think we need something that can easily be placed > > into SW ( In > > > this context I am talking about SW that does not "OWN" the > > Host TCP/IP > > > stack.). As I have stated before, FIM is simple to > > implement and can > > > greatly help some HW. It needs to be Sent only if > > requested, and not > > > other wise. It has been in the spec for some time, is > > therefore well > > > understood and I think it has been scrubbed my a number of > > different > > > vendors. Some of which have told me that they have either > > placed it in > > > their product or are working on that. This is NOT to say > > that we can not > > > change it, but that because of its longevity in the spec, > > has undergone a > > > lot of study. And we should have important reasons not to > > do FIM (such as > > > if it doesn't work). > > > Now, Jonathan Stone, has stated that "transatlantic can > > regularly show 50% > > > drop rate". I would like the vendors to have some > > approach to enable a > > > reasonable solution, to this and other long haul > > requirements, which keeps > > > the Adapter cost as low as possible. Also, that would mean that > > > it can NOT > > > wait until 10 Gig. > > > > > > Now to the issue of MUST or SHOULD implement. > > > > > > I have been persuaded that "SHOULD implement on Send" but > > optional to use, > > > would be a more acceptable position, since vendors with > > good and just > > > reasons would not have to implement it, yet the customer could find > > > solutions if they needed them. > > > > > > Therefore, based on the above reasoning, I am recommending: > > > > > > Choice 6, with "SHOULD implement on Send". That is, > > > > > > Leave FIM in the Spec, and add an enabling statement about "SHOULD > > > implement on Send if requested by the receiving side". > > > > > > > > > . > > > . > > > . > > > 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 Jan 15 13:53: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 NAA09444 for ; Tue, 15 Jan 2002 13:53:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0FI0lM25500 for ips-outgoing; Tue, 15 Jan 2002 13:00:47 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0FI0jj25494 for ; Tue, 15 Jan 2002 13:00:45 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel8.hp.com (Postfix) with ESMTP id A2636E001E8 for ; Tue, 15 Jan 2002 13:00:39 -0500 (EST) Received: from swathi (pal1nai160063.nsr.hp.com [15.244.160.63]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id KAA16879 for ; Tue, 15 Jan 2002 10:02:14 -0800 (PST) Message-ID: <003f01c19dee$898cfc20$3fa0f40f@rose.hp.com> From: "Mallikarjun C." To: References: <00ff01c19a86$ede50930$6264a8c0@hcltech.com> <200201141802.KAA21780@core.rose.hp.com> <02a301c19dc9$fb96b5b0$6264a8c0@hcltech.com> Subject: Re: iSCSI: Connection termination conditions Date: Tue, 15 Jan 2002 09:59:57 -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 Nandakumar, There appears to be some confusion about what is implied by graceful connection termination. Transport protocol (TCP for now) defines what a graceful transport connection shutdown is. In section 2.2.5, iSCSI is only attempting to spell out *when* it should be used, so that the iSCSI activity also comes to a stop gracefully. >an iSCSI logout should precede sending > TCP FINs *If* the connection is logged in - yes. As far as I can tell, 2.2.6 says it clearly. The case in 3.13.5 you refer is when the connection is not yet logged in! Keep in mind that an iSCSI connection is nothing but a transport connection used to carry out iSCSI activity - as defined by section 7. Based on the state of the "iSCSI activity", a Logout may or may not always be required. The state transitions chapter could be of some help in understanding how transport and iSCSI activities are intertwined during the life of an iSCSI connection. Hope that clears it up. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ----- Original Message ----- From: "Nandakumar Ramamurthy" To: ; Sent: Tuesday, January 15, 2002 5:38 AM Subject: Re: iSCSI: Connection termination conditions > Hi Mallikarjun, > > Agreed that there exists a distinction between a TCP connection > and an iSCSI connection. IMHO, an iSCSI logout should precede sending > TCP FINs. Section 2.2.6 must offer a clearer explanation in this regard. > > As the section is entitled "iSCSI Connection Termination", there should be > more > focus on termination of an iSCSI connection. A separate section > entitled "TCP Connection Termination" could probably speak about TCP related > intricacies. > > My understanding of iSCSI connection termination is : > > An intentional and graceful iSCSI connection termination MUST occur > only through the iSCSI logout process ( either implicit or explicit ). > This is not clear from section 2.2.6. > ( Are the 2 situations specified in my earlier mail valid? ) > > Section 3.13.5 states : > "If the Status Class is not 0, the initiator and target MUST close the TCP > connection." > Does this constitute a graceful TCP connection termination? > > What are the other interpretations for a "graceful" iSCSI connection > termination? > > Can "graceful" connection termination happen when it is not in full-feature > phase? How? > Please describe the related mechanism. > > Thanks, > Nandakumar > Member Technical Staff > HCL Technologies, Chennai, INDIA. > http://san.hcltech.com > > > ----- Original Message ----- > From: "Mallikarjun C." > To: > Sent: Monday, January 14, 2002 11:44 PM > Subject: Re: iSCSI: Connection termination conditions > > > > Nandakumar, > > > > As the preceding sentence indicates, the "graceful connection > > shutdown" being referred to is the TCP connection termination. > > > > All the text is saying is that the an intentional and graceful > > transport connection termination must also be "graceful" wrt iSCSI. > > The first sentence in this section requires rewording for rev10, > > and I suggest ignoring it for now. > > > > Thanks. > > -- > > Mallikarjun > > > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > MS 5668 Hewlett-Packard, Roseville. > > cbm@rose.hp.com > > > > > > Nandakumar Ramamurthy wrote: > > > > > > Hi All, > > > > > > Section 2.2.6 specifies two conditions for connection termination : > > > > > > "Graceful connection shutdowns MUST only occur when there are no > > > outstanding tasks that have allegiance to the connection and when the > > > connection is not in full-feature phase." > > > > > > The above statement is ambiguous as to what a graceful connection > > > shutdown is and the conditions in which this may occur. Can "graceful > > > connection shutdown" be elaborated upon? > > > > > > My interpretation is that there could be 2 possible cases when graceful > > > connection termination may occur. They are as follows: > > > > > > 1) A connection logout with no outstanding allegiant tasks is the first > > > condition. > > > In this case, the state of the connection is full feature. > > > > > > 2) The second case is when the connection is shutdown and the connection > > > state is not in full feature phase i.e., in SecurityNegotiation or > > > LoginOperationalNegotiation > > > phase. > > > > > > Is that the correct interpretation? > > > > > > Thanks, > > > Nandakumar > > > Member Technical Staff > > > HCL Technologies, Chennai, INDIA. > > > http://san.hcltech.com > > > > From owner-ips@ece.cmu.edu Tue Jan 15 14:31:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10747 for ; Tue, 15 Jan 2002 14:31:44 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0FIZ2s27824 for ips-outgoing; Tue, 15 Jan 2002 13:35:02 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mms1.broadcom.com (mms1.broadcom.com [63.70.210.58]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g0FIZ0j27820 for ; Tue, 15 Jan 2002 13:35:00 -0500 (EST) Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom MMS-1 SMTP Relay (MMS v4.7)); Tue, 15 Jan 2002 10:34:42 -0800 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from mail-sj1-1.sj.broadcom.com (mail-sj1-1.sj.broadcom.com [10.16.128.231]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id KAA13446; Tue, 15 Jan 2002 10:34:57 -0800 (PST) Received: from PCSJCGNAVEEN (dhcpe2-sj3-097 [10.21.66.97]) by mail-sj1-1.sj.broadcom.com (8.8.8/8.8.8/MS01) with SMTP id KAA22543; Tue, 15 Jan 2002 10:34:58 -0800 (PST) From: "Naveen Nimmu" To: "Camden Ford" , "'Nike Chen'" , ips@ece.cmu.edu Subject: RE: Differences between iSCSI Router (ex. CISCO RN5420) and iSCSI Switch (ex. SANRAD Switch 3000) Date: Tue, 15 Jan 2002 10:34:48 -0800 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <176B85B0D4E0D411BA5200508B692E0A049DBC92@hq-ex-1.brocade.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-WSS-ID: 105AA9C8525941-01-01 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C19DB0.418C4040" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C19DB0.418C4040 X-MIME-Autoconverted: from 8bit to quoted-printable by mon-irva-11.broadcom.com id KAA13446 Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: quoted-printable [snip] If you were to compare either of these products to our notion of Switchin= g and Routing in the IP/Ethernet world, these are neither Switches or Routers....but simple Bridges, much like the early Ethernet Bridges. Camden, Given that iSCSI is defined above TCP it falls in layer 5 . FCP on FC also does a similar function. From the networking protocol perspective It may be better to call the =A1=A5cisco Storage router=A1=A6 a SCSI gatewa= y than a simple bridge. Naveen nimmu iSCSI switches are simple Ethernet Switches or any other switch that can switch or route TCP/IP. Because iSCSI utilizes TCP/IP, the iSCSI protoco= l rides as a byte stream on top of TCP. Therefore, most switches are unawa= re that the packets that they are switching or routing are actually iSCSI. They simply appear as another TCP byte stream. So if you think in terms = of Layer X switching, a simple Layer 2 switch is a switch based in a transpo= rts like EThernet, a Layer 3 switch is a simple version of a router with IP forwarding inmplemented in HW. A Layer 4 switch can prioritize traffic based on TCP connections. In order to provide intelligence in a switch t= hat recognizes iSCSI, it would be somewhere in Layer 5-7 depending on what yo= u filter on. I would imaging that in order for any product to be a Storage Router, the= re would have to be the notion of Global Addressing of storage elements....something which does not exist today. Technically, FC switching is based on logical addressing, and not physica= l addresses, so it is most similar to Layer 3 switching in IP/EThernet....which some might call a router. Camden ford -----Original Message----- From: Nike Chen [mailto:nikechen@ksts.seed.net.tw] Sent: Tuesday, January 15, 2002 12:29 AM To: ips@ece.cmu.edu Subject: Differences between iSCSI Router (ex. CISCO RN5420) and iSCSI Switch (ex. SANRAD Switch 3000) Hi All: Would anybody tell me the function differences between iSCSI Router and Switch, or just like performance difference in Layer 3 switch and Router? When it say it is a iSCSI switch, what level do it operate, level 2, 3 or= 4? When it say it is a iSCSI Router, what level do it operate, or just a protocol converting gateway? Is there any definition for iSCSI Router or iSCSI switch? Thanks, Nike ------=_NextPart_000_0008_01C19DB0.418C4040 Content-Type: text/html; charset=big5 Content-Transfer-Encoding: quoted-printable

 

 

 [snip]<= /p>

If you were to compare either of = these products to our notion of Switching and Routing in the IP/Ethernet = world, these are neither Switches or Routers....but simple Bridges, much like the = early Ethernet Bridges.

 

Ca= mden,

  Given that iSCSI  is defined above TCP it falls = in layer 5 . FCP on FC also does a similar function. From the networking protocol perspective It may be better to call the =A1=A5cisco  Storage router=A1=A6 a SCSI gateway than a simple = bridge.

 

Na= veen nimmu

 

 <= /p>

iSCSI switches are simple Ethernet Switches or any other switch that can switch or route TCP/IP.  = Because iSCSI utilizes TCP/IP, the iSCSI protocol rides as a byte stream on top = of TCP.  Therefore, most switches are unaware that the packets that = they are switching or routing are actually iSCSI.  They simply appear as = another TCP byte stream.  So if you think in terms of Layer X switching, a = simple Layer 2 switch is a switch based in a transports like EThernet, a Layer = 3 switch is a simple version of a router with IP forwarding inmplemented = in HW.  A Layer 4 switch can prioritize traffic based on TCP connections.  In order to provide intelligence in a switch that = recognizes iSCSI, it would be somewhere in Layer 5-7 depending on what you filter = on.<= /p>

 <= /p>

I would imaging that in order for = any product to be a Storage Router, there would have to be the notion of = Global Addressing of storage elements....something which does not exist = today.<= /p>

 <= /p>

Technically, FC switching is based = on logical addressing, and not physical addresses, so it is most similar to = Layer 3 switching in IP/EThernet....which some might call a = router.<= /p>

 <= /p>

Camden ford<= /p>

-----Original Message-----
From: Nike Chen [mailto:nikechen@ksts.seed.net.tw]
Sent: Tuesday, January = 15, 2002 12:29 AM
To: ips@ece.cmu.edu
Subject: Differences = between iSCSI Router (ex. CISCO RN5420) and iSCSI Switch (ex. SANRAD Switch = 3000)

Hi All:<= /p>

 <= /p>

Would anybody tell me the = function differences between iSCSI Router and Switch, <= /p>

or just like performance = difference in Layer 3 switch and Router?<= /p>

When it say it is a iSCSI = switch, what level do it operate, level 2, 3 or 4?<= /p>

When it say it is a iSCSI = Router, what level do it operate, or just a protocol<= /p>

converting = gateway?<= /p>

Is there any = definition for iSCSI Router or iSCSI switch?<= /p>

 <= /p>

Thanks,<= /p>

Nike<= /p>

 <= /p>

 <= /p>

 <= /p>

------=_NextPart_000_0008_01C19DB0.418C4040-- From owner-ips@ece.cmu.edu Tue Jan 15 19:06: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 TAA16845 for ; Tue, 15 Jan 2002 19:06:17 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0FNAxa17963 for ips-outgoing; Tue, 15 Jan 2002 18:10:59 -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 g0FNAtj17952 for ; Tue, 15 Jan 2002 18:10:55 -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 PAA06593 for ; Tue, 15 Jan 2002 15:10:41 -0800 (PST) Received: from aimexc02.corp.adaptec.com (aimexc02.corp.adaptec.com [162.62.62.40]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id OAA05989 for ; Tue, 15 Jan 2002 14:54:23 -0800 (PST) Received: from adaptec.com (ws10-20-142-76.corp.adaptec.com [10.20.142.76]) by aimexc02.corp.adaptec.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CSD0FCS9; Tue, 15 Jan 2002 15:10:41 -0800 Message-ID: <3C44B6FF.3F0C12E7@adaptec.com> Date: Tue, 15 Jan 2002 15:10:55 -0800 From: Tow Wang X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: iSCSI: NopIn in ping mode can contain data? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello everybody. 1) When a target sends out a NopIn as a ping, is it allowed to contain a data segment? 2) If yes, a) why would anyone send data along? b) must the initiator echo back the data? I haven't found a clear answer in draft 9. Thanks for any clarifications. -- Tow Wang Adaptec Software Engineer From owner-ips@ece.cmu.edu Wed Jan 16 09:49: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 JAA09540 for ; Wed, 16 Jan 2002 09:49:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0GDt9q10849 for ips-outgoing; Wed, 16 Jan 2002 08:55: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 (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0GDt4j10837 for ; Wed, 16 Jan 2002 08:55:04 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jan 2002 08:54:57 -0500 Message-ID: <25369470B6F0D41194820002B328BDD22023F8@ATLOPS> From: Eddy Quicksall To: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" , "'Dave Francheski'" , ips@ece.cmu.edu Subject: RE: iSCSI Text Request Date: Wed, 16 Jan 2002 08:54:56 -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 A "protocol error" is only represented by a Reject and the login phase only allows Login PDU's (see 2.2.3). So, I use a Login Response with status = 0200 (Initiator Error). There should probably be more status's defined. For example, Section 5.1 (Login Phase Start) says: the target may reply with a Login Response indicating that it is unwilling to accept the connection without SecurityNegotiation and terminate the connection. But the table in 3.13 (Login Response) does not give a status for explicitly that. So, I give 0201 (Authentication Failure). Comments? Eddy -----Original Message----- From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) [mailto:matthew_burbridge@hp.com] Sent: Friday, December 14, 2001 3:12 AM To: 'Dave Francheski'; ips@ece.cmu.edu Subject: RE: iSCSI Text Request Dave, You are correct: only Login Requests and Login Responses are allowed during the login phase. Until FFP, any other PDU is protocol? error. The use of Text PDUs were removed when we revised the login procedure as there were no benefits for using different PDUs (i.e. Text PDUs). Matthew Burbridge Senior Development Engineer NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com -----Original Message----- -----Original Message----- From: Dave Francheski [mailto:davef@seven-systems.com] Sent: Thursday, December 13, 2001 7:23 PM To: ips@ece.cmu.edu Subject: iSCSI Text Request Before full feature phase is entered, is it valid for an initiator to send a Text Request PDU for parameter negotiation purposes? In other words, are only Login Request PDUs and Login Response PDUs allowed during the login phase? I believe iSCSI draft 9 only permits Login Request/Response PDUs during the login phase, but we've noticed that some initiators violate this restriction. Regards, David Francheski Seven Systems Technologies 575 Menlo Drive Suite 2 Rocklin CA 916-577-1281 davef@seven-systems.com From owner-ips@ece.cmu.edu Wed Jan 16 12: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 MAA15730 for ; Wed, 16 Jan 2002 12:54:40 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0GGZ8421049 for ips-outgoing; Wed, 16 Jan 2002 11:35:08 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from host32.cedant.com (host32.cedant.com [209.239.32.20]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0GGZ6j21044 for ; Wed, 16 Jan 2002 11:35:06 -0500 (EST) Received: from sahara (178.sanjose-05-10rs16rt.ca.dial-access.att.net [12.81.6.178]) by host32.cedant.com (8.10.2/8.10.2) with ESMTP id g0GGYYE01618; Wed, 16 Jan 2002 11:34:34 -0500 Message-ID: <200201160849430169.19C0CD23@opulentsystems.com> In-Reply-To: References: X-Mailer: Calypso Version 3.30.00.00 (4) Date: Wed, 16 Jan 2002 08:49:43 -0800 Reply-To: sganguly@opulentsystems.com From: "Sukanta Ganguly" To: "Naveen Nimmu" , "Camden Ford" , "'Nike Chen'" , "IPS" Subject: RE: Differences between iSCSI Router (ex. CISCO RN5420) and iSCSI Switch (ex. SANRAD Switch 3000) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====_101119978341=_" Sender: owner-ips@ece.cmu.edu Precedence: bulk --=====_101119978341=_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Camden, I would like to add a point here that there is the World Wide Name (WWN)= convention that is responsible for a unique identification of a storage= device. SG *********** REPLY SEPARATOR *********** On 1/15/2002 at 10:34 AM Naveen Nimmu wrote: [snip] If you were to compare either of these products to our notion of Switching= and Routing in the IP/Ethernet world, these are neither Switches or= Routers....but simple Bridges, much like the early Ethernet Bridges. Camden, Given that iSCSI is defined above TCP it falls in layer 5 . FCP on FC= also does a similar function. From the networking protocol perspective It= may be better to call the =A1=A5cisco Storage router=A1=A6 a SCSI gateway= than a simple bridge. Naveen nimmu iSCSI switches are simple Ethernet Switches or any other switch that can= switch or route TCP/IP. Because iSCSI utilizes TCP/IP, the iSCSI protocol= rides as a byte stream on top of TCP. Therefore, most switches are= unaware that the packets that they are switching or routing are actually= iSCSI. They simply appear as another TCP byte stream. So if you think in= terms of Layer X switching, a simple Layer 2 switch is a switch based in a= transports like EThernet, a Layer 3 switch is a simple version of a router= with IP forwarding inmplemented in HW. A Layer 4 switch can prioritize= traffic based on TCP connections. In order to provide intelligence in a= switch that recognizes iSCSI, it would be somewhere in Layer 5-7 depending= on what you filter on. I would imaging that in order for any product to be a Storage Router, there= would have to be the notion of Global Addressing of storage= elements....something which does not exist today. Technically, FC switching is based on logical addressing, and not physical= addresses, so it is most similar to Layer 3 switching in= IP/EThernet....which some might call a router. Camden ford -----Original Message----- From: Nike Chen [mailto:nikechen@ksts.seed.net.tw] Sent: Tuesday, January 15, 2002 12:29 AM To: ips@ece.cmu.edu Subject: Differences between iSCSI Router (ex. CISCO RN5420) and iSCSI= Switch (ex. SANRAD Switch 3000) Hi All: Would anybody tell me the function differences between iSCSI Router and= Switch, or just like performance difference in Layer 3 switch and Router? When it say it is a iSCSI switch, what level do it operate, level 2, 3 or= 4? When it say it is a iSCSI Router, what level do it operate, or just a= protocol converting gateway? Is there any definition for iSCSI Router or iSCSI switch? Thanks, Nike --=====_101119978341=_ Content-Type: text/html; charset="us-ascii"
Camden,
   I would like to add a point here that there is the World Wide Name (WWN) convention that is responsible for a unique identification of a storage device.
  
SG

*********** REPLY SEPARATOR ***********

On 1/15/2002 at 10:34 AM Naveen Nimmu wrote:

 

 

 [snip]

If you were to compare either of these products to our notion of Switching and Routing in the IP/Ethernet world, these are neither Switches or Routers....but simple Bridges, much like the early Ethernet Bridges.

 

Camden,

  Given that iSCSI  is defined above TCP it falls in layer 5 . FCP on FC also does a similar function. From the networking protocol perspective It may be better to call the ¡¥cisco  Storage router¡¦ a SCSI gateway than a simple bridge.

 

Naveen nimmu

 

 

iSCSI switches are simple Ethernet Switches or any other switch that can switch or route TCP/IP.  Because iSCSI utilizes TCP/IP, the iSCSI protocol rides as a byte stream on top of TCP.  Therefore, most switches are unaware that the packets that they are switching or routing are actually iSCSI.  They simply appear as another TCP byte stream.  So if you think in terms of Layer X switching, a simple Layer 2 switch is a switch based in a transports like EThernet, a Layer 3 switch is a simple version of a router with IP forwarding inmplemented in HW.  A Layer 4 switch can prioritize traffic based on TCP connections.  In order to provide intelligence in a switch that recognizes iSCSI, it would be somewhere in Layer 5-7 depending on what you filter on.

 

I would imaging that in order for any product to be a Storage Router, there would have to be the notion of Global Addressing of storage elements....something which does not exist today.

 

Technically, FC switching is based on logical addressing, and not physical addresses, so it is most similar to Layer 3 switching in IP/EThernet....which some might call a router.

 

Camden ford

-----Original Message-----
From: Nike Chen [mailto:nikechen@ksts.seed.net.tw]
Sent: Tuesday, January 15, 2002 12:29 AM
To: ips@ece.cmu.edu
Subject: Differences between iSCSI Router (ex. CISCO RN5420) and iSCSI Switch (ex. SANRAD Switch 3000)

Hi All:

 

Would anybody tell me the function differences between iSCSI Router and Switch,

or just like performance difference in Layer 3 switch and Router?

When it say it is a iSCSI switch, what level do it operate, level 2, 3 or 4?

When it say it is a iSCSI Router, what level do it operate, or just a protocol

converting gateway?

Is there any definition for iSCSI Router or iSCSI switch?

 

Thanks,

Nike

 

 

 

--=====_101119978341=_-- From owner-ips@ece.cmu.edu Wed Jan 16 13:01: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 NAA15996 for ; Wed, 16 Jan 2002 13:01:32 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0GGKXo19897 for ips-outgoing; Wed, 16 Jan 2002 11:20:33 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0GGKTj19891 for ; Wed, 16 Jan 2002 11:20:29 -0500 (EST) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id IAA17300; Wed, 16 Jan 2002 08:16:09 -0800 (PST) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jan 2002 08:16:08 -0800 Message-ID: From: Robert Snively To: "'Black_David@emc.com'" , ips@ece.cmu.edu Subject: RE: RFC Editor changes Date: Wed, 16 Jan 2002 08:16:07 -0800 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk David, What is the e-mail forum in which these policies are discussed? Bob > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Monday, January 14, 2002 7:23 AM > To: ips@ece.cmu.edu > Subject: RFC Editor changes > > > More information about author count and separation of > normative vs. non-normative references (among a few > other topics) can be found at: > > http://www.rfc-editor.org/policy.html > > Anyone responsible for the actual text of a draft should > read this, please. > > 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 Jan 16 19:05: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 TAA24056 for ; Wed, 16 Jan 2002 19:05:11 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0GN2Rf21839 for ips-outgoing; Wed, 16 Jan 2002 18:02:27 -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 g0GN2Oj21809 for ; Wed, 16 Jan 2002 18:02:24 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel9.hp.com (Postfix) with ESMTP id CF4ADE0025A for ; Wed, 16 Jan 2002 18:02:18 -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 PAA07104 for ; Wed, 16 Jan 2002 15:03:54 -0800 (PST) Message-Id: <200201162303.PAA07104@core.rose.hp.com> Date: Wed, 16 Jan 2002 15:16:03 -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: iSCSI: new state diagram slides posted 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 new iSCSI state diagram slides at: http://storage-arch.hp.com/iscsi_states_rev10.pdf or, also at: http://www.haifa.il.ibm.com/satran/ips/iscsi_states_rev10.pdf These contain the following changes - - Addition of T18 to both initiator and target standard connection state diagrams - to take care of the "session close" case. - Wording changes in other places to take care of the "session close" case properly. - Addition of a new target session state Q5 (IN_CONTINUE), since the previous Q2 state was overloaded. As defined in rev09, on receiving a login_failed event in state Q2, the resolution of choice between transitions N8 and N9 requires additional "state" not defined in the state diagram. The current change remedies that. - Other minor wording fixes. The updated content in these diagrams will be published as part of rev10. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com From owner-ips@ece.cmu.edu Wed Jan 16 21:22: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 VAA25755 for ; Wed, 16 Jan 2002 21:22:45 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0H1J5I28941 for ips-outgoing; Wed, 16 Jan 2002 20:19:05 -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 g0H1J0j28935 for ; Wed, 16 Jan 2002 20:19:04 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel11.hp.com (Postfix) with ESMTP id DDFC6E002FB for ; Wed, 16 Jan 2002 17:18:54 -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 RAA07570 for ; Wed, 16 Jan 2002 17:20:30 -0800 (PST) Message-Id: <200201170120.RAA07570@core.rose.hp.com> Date: Wed, 16 Jan 2002 17:32:39 -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: iSCSI: wider scope for a Reject reason code Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit All: I propose to change the current Reject reason code 0x09 to cover the following class of errors. These errors would then be able to be labeled with the Reject reason "Invalid PDU field". "invalid values of task-specific fields (as in buffer offset, tag, LUN qualifying a TTT etc.)" Only one of these "task-specific" fields - TTT - is currently covered under reason code 0x09 today. So this change would widen the scope of this reason code to cover others that currently are not covered anywhere else. If I don't hear any objections, this would be incorporated into the rev10 text. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com From owner-ips@ece.cmu.edu Thu Jan 17 03:14: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 DAA09982 for ; Thu, 17 Jan 2002 03:14:09 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0H7Eru15593 for ips-outgoing; Thu, 17 Jan 2002 02:14:53 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from webmail.iei.com.tw (c65.h202052108.is.net.tw [202.52.108.65]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0H7Emj15583 for ; Thu, 17 Jan 2002 02:14:48 -0500 (EST) Received: from nike ([172.16.14.227]) by webmail.iei.com.tw (Lotus Domino Release 5.0.8) with SMTP id 2002011715132434:2709 ; Thu, 17 Jan 2002 15:13:24 +0800 Message-ID: <000a01c19f26$73c50570$e30e10ac@hq.iei> From: "Nike Chen" To: Subject: UNH iSCSI Initiator install: /proc/scsi/iscsi_initiator/X Operation not permitted Date: Thu, 17 Jan 2002 15:13:24 +0800 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MIMETrack: Itemize by SMTP Server on webmail/iei2(Release 5.0.8 |June 18, 2001) at 2002/01/17 03:13:24 PM, Serialize by Router on webmail/iei2(Release 5.0.8 |June 18, 2001) at 2002/01/17 03:13:32 PM, Serialize complete at 2002/01/17 03:13:32 PM Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C19F69.81BEEB80" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C19F69.81BEEB80 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Hi All: After I build the UNH iSCSI linux project v6.09 successfully, I run the following command: 1. insmod iscsi_initiator.o 2. iscsi_config up ip=3D*** port=3D4000 and iscsi_config response the follwoing message: /proc/scsi/iscsi_initiator/0 Operation not permitted But I do see the exact file in /proc/scsi/iscsi_initaiator, and I was loggin as root. Does anyone tell me where may be went wrong, and how to check? Thanks. Nike ------=_NextPart_000_0007_01C19F69.81BEEB80 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Hi All:
 
After I build the UNH = iSCSI linux project v6.09=20 successfully,
I run the following = command:
 
1. insmod = iscsi_initiator.o
2. iscsi_config up = ip=3D*** port=3D4000
 
and iscsi_config response = the follwoing=20 message:
 
/proc/scsi/iscsi_initiator/0 Operation not=20 permitted
 
But I do see the = exact file in=20 /proc/scsi/iscsi_initaiator,
and I was loggin as = root.
 
Does anyone tell me where = may be went wrong, and how=20 to check?
 
Thanks.
Nike
------=_NextPart_000_0007_01C19F69.81BEEB80-- From owner-ips@ece.cmu.edu Thu Jan 17 06:11: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 GAA11710 for ; Thu, 17 Jan 2002 06:11:56 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0HAAsG22511 for ips-outgoing; Thu, 17 Jan 2002 05:10: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 g0HAAmj22500; Thu, 17 Jan 2002 05:10:48 -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 LAA83468; Thu, 17 Jan 2002 11:10:40 +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 g0HABWm28490; Thu, 17 Jan 2002 11:11:33 +0100 Subject: RE: iSCSI Text Request To: Eddy Quicksall Cc: "'Dave Francheski'" , ips@ece.cmu.edu, "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" , owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Thu, 17 Jan 2002 09:45:33 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 17/01/2002 12:11:44 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy, We did not think that it is worth having a variety of statuses for different errors. After a (relatively long) debate we reduced them to the current list. It could have been shorter (as in the old Unix ?). In any case your choices are the ones we had in mind too. Regards, Julo Eddy Quicksall , "'Dave Francheski'" Sent by: , ips@ece.cmu.edu owner-ips@ece.cmu. cc: edu Subject: RE: iSCSI Text Request 16-01-02 15:54 A "protocol error" is only represented by a Reject and the login phase only allows Login PDU's (see 2.2.3). So, I use a Login Response with status = 0200 (Initiator Error). There should probably be more status's defined. For example, Section 5.1 (Login Phase Start) says: the target may reply with a Login Response indicating that it is unwilling to accept the connection without SecurityNegotiation and terminate the connection. But the table in 3.13 (Login Response) does not give a status for explicitly that. So, I give 0201 (Authentication Failure). Comments? Eddy -----Original Message----- From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) [mailto:matthew_burbridge@hp.com] Sent: Friday, December 14, 2001 3:12 AM To: 'Dave Francheski'; ips@ece.cmu.edu Subject: RE: iSCSI Text Request Dave, You are correct: only Login Requests and Login Responses are allowed during the login phase. Until FFP, any other PDU is protocol? error. The use of Text PDUs were removed when we revised the login procedure as there were no benefits for using different PDUs (i.e. Text PDUs). Matthew Burbridge Senior Development Engineer NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com -----Original Message----- -----Original Message----- From: Dave Francheski [mailto:davef@seven-systems.com] Sent: Thursday, December 13, 2001 7:23 PM To: ips@ece.cmu.edu Subject: iSCSI Text Request Before full feature phase is entered, is it valid for an initiator to send a Text Request PDU for parameter negotiation purposes? In other words, are only Login Request PDUs and Login Response PDUs allowed during the login phase? I believe iSCSI draft 9 only permits Login Request/Response PDUs during the login phase, but we've noticed that some initiators violate this restriction. Regards, David Francheski Seven Systems Technologies 575 Menlo Drive Suite 2 Rocklin CA 916-577-1281 davef@seven-systems.com From owner-ips@ece.cmu.edu Thu Jan 17 10:43: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 KAA19267 for ; Thu, 17 Jan 2002 10:43:41 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0HEgBk16545 for ips-outgoing; Thu, 17 Jan 2002 09:42:11 -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 g0HEg6j16533 for ; Thu, 17 Jan 2002 09:42:07 -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 g0HEbmw19828 for ; Thu, 17 Jan 2002 20:07:48 +0530 Message-ID: <3C46E30A.AD380A5E@npd.hcltech.com> Date: Thu, 17 Jan 2002 20:13:22 +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: iSCSI:regarding connection shutdown Content-Type: multipart/alternative; boundary="------------CC97F1AA93FE1C3FE1C7263E" Sender: owner-ips@ece.cmu.edu Precedence: bulk --------------CC97F1AA93FE1C3FE1C7263E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, Section 1.2.6 of the iscsi draft 07 says : "Graceful connection shutdowns MUST only occur when there are no outstanding tasks that have allegiance to the connection or when the connection is not in full-feature phase." But section 2.2.6 of the iscsi draft 08 and 09 say : "Graceful connection shutdowns MUST only occur when there are no outstanding tasks that have allegiance to the connection and when the connection is not in full-feature phase." The sentence mentioned in draft 07 sounds clear as it talks about the two possibilities of graceful connection shutdown. But the same sentence in draft 08 and 09 suggests a different meaning because of 'and'. Is there any reason why this has been changed to 'and' ? I'm asking this because this change has not been recorded in the change log. Please clarify . Regards, Sastry -- Subrahmanya Sastry K V Member Technical Staff HCLTech, Chennai, INDIA http://san.hcltech.com --------------CC97F1AA93FE1C3FE1C7263E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all,

 Section 1.2.6 of the iscsi draft 07 says :
"Graceful connection shutdowns MUST only occur when there are no outstanding tasks that have allegiance to the connection or when the connection is not in full-feature phase."

But section 2.2.6 of the iscsi draft 08 and 09 say :
"Graceful connection shutdowns MUST only occur when there are no outstanding tasks that have allegiance to the connection and when the connection is not in full-feature phase."

The sentence mentioned in draft 07 sounds clear as it talks about the two possibilities of graceful connection shutdown.
But the same sentence in draft 08 and 09 suggests a different meaning because of 'and'. Is there any reason why this has been changed to 'and' ?

I'm asking this because this change has not been recorded in the change log. Please clarify .

Regards,
Sastry

-- 
Subrahmanya Sastry K V
Member Technical Staff
HCLTech, Chennai, INDIA
http://san.hcltech.com
  --------------CC97F1AA93FE1C3FE1C7263E-- From owner-ips@ece.cmu.edu Thu Jan 17 11:19: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 LAA20555 for ; Thu, 17 Jan 2002 11:19:08 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0HFMYY19621 for ips-outgoing; Thu, 17 Jan 2002 10:22:34 -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 g0HFMXj19617 for ; Thu, 17 Jan 2002 10:22:33 -0500 (EST) Received: from ahganemw2k (dhcp-161-44-68-125.cisco.com [161.44.68.125]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id KAA23912 for ; Thu, 17 Jan 2002 10:22:27 -0500 (EST) From: "Ayman Ghanem" To: Subject: iSCSI: PDU size and FirstBurstSize Date: Thu, 17 Jan 2002 09:21: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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit 1- In draft-09, section 2.2.2.1 near the end: "The target MUST NOT transmit a MaxCmdSN that is less than the last ExpCmdSN." This should be: "The target MUST NOT transmit a MaxCmdSN that is less than the last ExpCmdSN - 1." to be consistent with the previous paragraph. 2- section 2.2.5 (sixth paragraph): "An initiator may send unsolicited data as immediate up to the negotiated maximum PDU size or in a separate PDU sequence (up to the mode page limit). All subsequent data MUST be solicited." Can the PDU size be negotiated to a value larger than FirstBurstSize? The definition of MaxRecvPDULength does not limit that, and the definition of FirstBurstSize includes immediate data, which implies FBS larger than PDU size. If PDU size is larger than FBS, then the definition of FBS is not consistent with the above paragraph. -Ayman From owner-ips@ece.cmu.edu Thu Jan 17 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 PAA07034 for ; Thu, 17 Jan 2002 15:10:59 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0HJ5SO06552 for ips-outgoing; Thu, 17 Jan 2002 14:05:28 -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 g0HJ5Qj06548 for ; Thu, 17 Jan 2002 14:05:27 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel12.hp.com (Postfix) with ESMTP id D245DE00239 for ; Thu, 17 Jan 2002 11:05:20 -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 LAA25500 for ; Thu, 17 Jan 2002 11:06:56 -0800 (PST) Message-Id: <200201171906.LAA25500@core.rose.hp.com> Date: Thu, 17 Jan 2002 11:19:06 -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:regarding connection shutdown References: <3C46E30A.AD380A5E@npd.hcltech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sastry, Thanks for the close review. As I mentioned in an earlier response to Nandakumar on this subject, the "graceful connection shutdown" is referring to a graceful TCP connection shutdown. With that said, the usage of "and" in the quoted sentence was meant to underline the point that a connection shutdown must be initiated only after the Logout dialogue is cleanly complete - a mere `no active tasks` is not sufficient to drop the connection - since iSCSI connection and session structures would hang around (until timeout, waiting for session continuation) if a clean logout is not done. This was sought to be actively discouraged. On thinking more about it, I think perhaps this sentence says more than is necessary. It's completely legitimate for initiators to Logout("close") a connection to implicitly abort all active tasks. If one merely ensures that the connection is *not* in the FFP to start a TCP connection close, that is completely adequate (since the active tasks if any, were automatically taken care of in the Logout process). So, I would actually suggest wording like - "A graceful connection shutdown MUST be initiated only when the connection is not in full-feature phase." We already have wording there that takes care of outstanding tasks -"Connection termination with outstanding commands may require recovery actions." Also, I noticed that the section doesn't consistently use "termination" - we need to address that aspect as well. Please comment if something isn't clear. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Subrahmanya Sastry K V wrote: > > Hi all, > > Section 1.2.6 of the iscsi draft 07 says : > "Graceful connection shutdowns MUST only occur when there are no > outstanding tasks that have allegiance to the connection or when the > connection is not in full-feature phase." > > But section 2.2.6 of the iscsi draft 08 and 09 say : > "Graceful connection shutdowns MUST only occur when there are no > outstanding tasks that have allegiance to the connection and when the > connection is not in full-feature phase." > > The sentence mentioned in draft 07 sounds clear as it talks about the > two possibilities of graceful connection shutdown. > But the same sentence in draft 08 and 09 suggests a different meaning > because of 'and'. Is there any reason why this has been changed to > 'and' ? > > I'm asking this because this change has not been recorded in the > change log. Please clarify . > > Regards, > Sastry > > -- > Subrahmanya Sastry K V > Member Technical Staff > HCLTech, Chennai, INDIA > http://san.hcltech.com > From owner-ips@ece.cmu.edu Thu Jan 17 18:25: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 SAA15410 for ; Thu, 17 Jan 2002 18:25:42 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0HMbwu27860 for ips-outgoing; Thu, 17 Jan 2002 17:37:58 -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 g0HMbvj27855 for ; Thu, 17 Jan 2002 17:37:57 -0500 (EST) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Jan 2002 17:40:35 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937387@CORPMX14> From: Black_David@emc.com To: rsnively@Brocade.COM, ips@ece.cmu.edu Subject: RE: RFC Editor changes Date: Thu, 17 Jan 2002 17:24:58 -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, > What is the e-mail forum in which these policies are > discussed? The IETF Discussion List, ietf@ietf.org, see: http://www.ietf.org/maillist.html The RFC Editor announced these changes at: http://www.rfc-editor.org/news.html although that's not one of the places that IETF folks are generally expected to monitor on an ongoing basis. Please note that these policy changes do have the approval of the IESG. Thanks, --David > -----Original Message----- > From: Robert Snively [mailto:rsnively@brocade.com] > Sent: Wednesday, January 16, 2002 11:16 AM > To: 'Black_David@emc.com'; ips@ece.cmu.edu > Subject: RE: RFC Editor changes > > > David, > > What is the e-mail forum in which these policies are > discussed? > > Bob > > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > Sent: Monday, January 14, 2002 7:23 AM > > To: ips@ece.cmu.edu > > Subject: RFC Editor changes > > > > > > More information about author count and separation of > > normative vs. non-normative references (among a few > > other topics) can be found at: > > > > http://www.rfc-editor.org/policy.html > > > > Anyone responsible for the actual text of a draft should > > read this, please. > > > > 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 Jan 18 00:02: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 AAA22741 for ; Fri, 18 Jan 2002 00:02:34 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0I44GF18224 for ips-outgoing; Thu, 17 Jan 2002 23:04:16 -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 g0I44Cj18212 for ; Thu, 17 Jan 2002 23:04:13 -0500 (EST) Received: from npd.hcltech.com (tskariah-pc.hcltech.com [192.168.100.72]) by mailnpd.hcltech.com (8.11.0/8.11.0) with ESMTP id g0I3www01561; Fri, 18 Jan 2002 09:29:02 +0530 Message-ID: <3C479EDC.D6B21B5D@npd.hcltech.com> Date: Fri, 18 Jan 2002 09:34:44 +0530 From: Thanu Skariah X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Nike Chen CC: ips@ece.cmu.edu Subject: Re: UNH iSCSI Initiator install: /proc/scsi/iscsi_initiator/X Operation not permitted References: <000a01c19f26$73c50570$e30e10ac@hq.iei> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, We met with similar error messages in earlier versions when installing them, some time back. This was solved then by giving the hostname and the ip address of the target machine in /etc/hosts file of the initiator machine. Let me know if that helped. Thanks, Thanu > Nike Chen wrote: >Hi All: > > After I build the UNH iSCSI linux project v6.09 successfully, > I run the following command: > > 1. insmod iscsi_initiator.o > 2. iscsi_config up ip=*** port=4000 > > and iscsi_config response the follwoing message: > > /proc/scsi/iscsi_initiator/0 Operation not permitted > > But I do see the exact file in /proc/scsi/iscsi_initaiator, > and I was loggin as root. > > Does anyone tell me where may be went wrong, and how to check? > > Thanks. > Nike -- Thanu Skariah Member Technical Staff Hcl Technologies , Chennai. http://www.san.hcltech.com From owner-ips@ece.cmu.edu Fri Jan 18 13:23: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 NAA22136 for ; Fri, 18 Jan 2002 13:23:30 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0IHiaO08383 for ips-outgoing; Fri, 18 Jan 2002 12:44:36 -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 g0IHiVj08374 for ; Fri, 18 Jan 2002 12:44:32 -0500 (EST) Received: from russian.wrs.com (russian [147.11.45.28]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA22370 for ; Fri, 18 Jan 2002 09:43:06 -0800 (PST) From: andy currid Received: (from andy@localhost) by russian.wrs.com (8.9.1/8.9.0) id JAA28821 for ips@ece.cmu.edu; Fri, 18 Jan 2002 09:44:19 -0800 (PST) Message-Id: <200201181744.JAA28821@russian.wrs.com> Subject: iSCSI: TargetAlias in SendTargets reply? To: ips@ece.cmu.edu Date: Fri, 18 Jan 2002 09:44:14 -0800 (PST) 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 Folks I think it would be useful to permit iSCSI targets to optionally return the TargetAlias text key in their replies to a SendTargets text request used in a discovery session. As currently defined in draft 9, the target records sent in response to a SendTargets request may only include the text keys TargetName and TargetAddress. It seems to me that TargetAlias is potentially at its most useful during discovery sessions, when a human operator may be involved. I suggest we permit TargetAlias to be optionally returned by a target in its response to SendTargets. Comments? Andy -- Andy Currid andy@windriver.com Server Products Group http://www.windriver.com Wind River Networks Phone : (1) 510 749 2191 500 Wind River Way, Alameda, CA 94501 Fax : (1) 510 749 2560 From owner-ips@ece.cmu.edu Fri Jan 18 13:36: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 NAA22605 for ; Fri, 18 Jan 2002 13:36:46 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0IHXIt07623 for ips-outgoing; Fri, 18 Jan 2002 12:33:18 -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 g0IHXGj07617 for ; Fri, 18 Jan 2002 12:33:16 -0500 (EST) Received: from ahganemw2k (dhcp-161-44-68-125.cisco.com [161.44.68.125]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id MAA03066 for ; Fri, 18 Jan 2002 12:33:10 -0500 (EST) From: "Ayman Ghanem" To: Subject: iSCSI: Rejecting immediate commands Date: Fri, 18 Jan 2002 11:32: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.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, In draft-09 section 2.2.2.1, 6th paragraph: ".......................... Immediate commands can be rejected by the iSCSI target due to lack of resources. An iSCSI target MUST be able to handle at least one immediate task management command and one immediate non-task-management iSCSI request per connection at any time." If the target MUST handle two immediate commands per connection, and with number of connections possibly negotiated to a large value , this can add up to significant resources the session has to have. Since the command sequence numbering is session wide, I would think the limit should be per session, not per connection. -Ayman From owner-ips@ece.cmu.edu Fri Jan 18 15:41: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 PAA26193 for ; Fri, 18 Jan 2002 15:41:01 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0IJWY015946 for ips-outgoing; Fri, 18 Jan 2002 14:32:34 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lightsand.com ([64.214.104.163]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0IJWWj15938 for ; Fri, 18 Jan 2002 14:32:32 -0500 (EST) Received: from MURALIRLAPTOP ([192.168.2.60]) by lightsand.com (8.9.3+Sun/8.9.1) with SMTP id LAA18938 for ; Fri, 18 Jan 2002 11:32:18 -0800 (PST) From: "Murali Rajagopal" To: Subject: FCIP: authors Teleconf call minutes - 1/15/2002 Date: Fri, 18 Jan 2002 11:32:07 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Minutes taken by Bill Krieg, Lucent Technologies ------------------------------------------------------- Attendees: Ralph Weber, Elizabeth Rodriguez, Neil Wanamaker, Murali Rajagopal, Don Fraser, Dave Peterson, Bob Snively, Venkat Rangan, K. Hirata, Andy Helland, and Bill Krieg (designated scribe) Agenda: 1. Security 2. FCIP Authors list 3. Other FCIP Author's list discussion: > Some discussion about D. Black's recent email concerning the number of authors identified in a document. > Elizabeth R. - will discuss this issue with the IETF Area Director to better understand IETF's position. Security: > Reviewed Bill's section 9 clarification comments 1. Section 9.3.2 - Page 37, 3rd paragraph from the top, 2nd sentence ... I'm not sure what the "active SA entires" implies here? Where do we discuss in-active or dormant SA entries? Is there an dormant SAD? Comment accepted ... new wording: "When a TCP Connection is established between two FCIP_DEs, two unidirectional SA's are created for that connection and each SA is identified in the form of a Security Parameter Index (SPI). One SA is associated with the incoming traffic flow and the other SA is associated with the outgoing traffic flow. The FCIP_DE's at each end of the TCP Connection MUST maintain the SPI's for both its incoming and outgoing FCIP Encapsulated Frames." 2. Section 9.3.3 - Page 37, 1st paragraph clarification request Comment accepted: Revise the text from "... key becomes compromised." in the 2nd sentence to "... key may become compromised." 3. Section 9.3.3 - Page 38, 3rd line from top clarification request Comment accepted & modified - no change to original comment but the last paragraph in Section 9.3.3 will be changed to: "When a new SPI is created for the outgoing direction, the sending side SHALL begin using it for all new FCIP Encapsulated Frames. Frames that are either in-flight, or resent due to TCP retransmissions etc. MAY use either the new SPI or the one being replaced." 4. Section 9.3.3 - Page 38, last paragraph clarification request Comment rejected 5. Section 9.4.1 - Page 38, 1st paragraph clarification request Comment accepted and modified Text changed from the "FCIP_LEP" reference to an "FCIP Entity". 6. Section 9.4.1 - Page 38, 2nd paragraph clarification request\ Comment rejected 7. Section 9.4.2 - Page 38, 2nd paragraph clarification request Comment rejected 8. Section 9.4.2 - Page 38, 3rd paragraph clarification request Comment accepted as is > Bill to send clarification comments for sections 5, 7, & 8. > All agreeded to accept Venkat's SF description (item #8 section 9.1) in the draft 2. Bob Snively's Duplicate nonce concern...based on Bob's earlier email >Bob S/Ralph W. lead the discussion and they indicated that this is but one type of security threat and the draft includes wording that clearly states that IPSec should be used in these situations. > Discussion suggested adding some words to the FC-BB-2 draft to address this security issue. FC-BB-2 could address this as a security policy issues. Draft status > Elizabeth R. - Rev 8 to IETF office by Tuesday (2 week before meeting starts). Next Authors call - Wed 1/23/2002 4-6pm EST > Anil R. (McData). Murali will check with Anil. From owner-ips@ece.cmu.edu Sat Jan 19 11:28: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 LAA20218 for ; Sat, 19 Jan 2002 11:28:19 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0JFMdC01641 for ips-outgoing; Sat, 19 Jan 2002 10:22:39 -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 g0JFMbj01636 for ; Sat, 19 Jan 2002 10:22:37 -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 QAA144392 for ; Sat, 19 Jan 2002 16:22: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 g0JFNOv139714 for ; Sat, 19 Jan 2002 16:23:30 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: NopIn in ping mode can contain data? X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 19 Jan 2002 17:23:27 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 19/01/2002 17:23:37, Serialize complete at 19/01/2002 17:23:37 Content-Type: multipart/alternative; boundary="=_alternative 00536C0EC2256B46_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00536C0EC2256B46_= Content-Type: text/plain; charset="us-ascii" No data - will indicate this in 10 - Julo Tow Wang Sent by: owner-ips@ece.cmu.edu 16-01-02 01:10 To: ips@ece.cmu.edu cc: Subject: iSCSI: NopIn in ping mode can contain data? Hello everybody. 1) When a target sends out a NopIn as a ping, is it allowed to contain a data segment? 2) If yes, a) why would anyone send data along? b) must the initiator echo back the data? I haven't found a clear answer in draft 9. Thanks for any clarifications. -- Tow Wang Adaptec Software Engineer --=_alternative 00536C0EC2256B46_= Content-Type: text/html; charset="us-ascii"
No  data - will indicate this in 10 - Julo


Tow Wang <Tow_Wang@adaptec.com>
Sent by: owner-ips@ece.cmu.edu

16-01-02 01:10

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI: NopIn in ping mode can contain data?

       


Hello everybody.

1) When a target sends out a NopIn as a ping, is it allowed to contain a
data segment?
2) If yes,
   a) why would anyone send data along?
   b) must the initiator echo back the data?

I haven't found a clear answer in draft 9. Thanks for any
clarifications.
--
Tow Wang
Adaptec Software Engineer

--=_alternative 00536C0EC2256B46_=-- From owner-ips@ece.cmu.edu Sun Jan 20 01:19: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 BAA28943 for ; Sun, 20 Jan 2002 01:19:58 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0K5XWn15597 for ips-outgoing; Sun, 20 Jan 2002 00:33:32 -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 g0K5XUj15591 for ; Sun, 20 Jan 2002 00:33:30 -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 GAA17328 for ; Sun, 20 Jan 2002 06:33:24 +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 g0K5YJv220752 for ; Sun, 20 Jan 2002 06:34:24 +0100 Subject: Re: iSCSI: Rejecting immediate commands To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Sat, 19 Jan 2002 17:27:58 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 20/01/2002 07:34:32 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Ayman, The reason for requirement is to be able to handle task management commands and logout on every connection. It all adds up to the resources you allocate per connection. Task Abort must be given on the same connection as the aborting task. Julo "Ayman Ghanem" .com> cc: Sent by: Subject: iSCSI: Rejecting immediate commands owner-ips@ece. cmu.edu 18-01-02 19:32 Julian, In draft-09 section 2.2.2.1, 6th paragraph: ".......................... Immediate commands can be rejected by the iSCSI target due to lack of resources. An iSCSI target MUST be able to handle at least one immediate task management command and one immediate non-task-management iSCSI request per connection at any time." If the target MUST handle two immediate commands per connection, and with number of connections possibly negotiated to a large value , this can add up to significant resources the session has to have. Since the command sequence numbering is session wide, I would think the limit should be per session, not per connection. -Ayman From owner-ips@ece.cmu.edu Sun Jan 20 12:17: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 MAA13571 for ; Sun, 20 Jan 2002 12:17:19 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0KGalv28192 for ips-outgoing; Sun, 20 Jan 2002 11:36:47 -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 g0KGaij28185 for ; Sun, 20 Jan 2002 11:36: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 RAA32138 for ; Sun, 20 Jan 2002 17:36:33 +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 g0KGbWB92498 for ; Sun, 20 Jan 2002 17:37:32 +0100 To: ips@ece.cmu.edu Importance: High MIME-Version: 1.0 Subject: draft 10 on my site X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sun, 20 Jan 2002 18:37:41 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 20/01/2002 18:37:43, Serialize complete at 20/01/2002 18:37:43 Content-Type: multipart/alternative; boundary="=_alternative 005A4E63C2256B47_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005A4E63C2256B47_= Content-Type: text/plain; charset="us-ascii" Dear colleagues, You may want to look at: http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iSCSI-10.pdf for the new draft. The site has also a text version but one that is quite badly formatted. I will try to fix that and offer you a pdf version with change bars - however I am not sure I will be able to do it before the January 22 deadline (I am leaving the office for a couple of day and will have only limited on-line time - yes it happens to me too... :-)). The garbled version of the text will go out to the drafts archive if I can't do any better by tomorrow. Julo --=_alternative 005A4E63C2256B47_= Content-Type: text/html; charset="us-ascii"
Dear colleagues,

You may want to look at:

http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iSCSI-10.pdf

for the new draft.

The site has also a text version but one that is quite badly formatted.
I will try to fix that and offer you a pdf version with change bars - however I am not sure
I will be able to do it before the January 22 deadline (I am leaving the office for a couple
of day and will have only limited on-line time - yes it happens to me too... :-)).

The garbled version of the text will go out to the drafts archive if I can't do any better by tomorrow.

Julo

--=_alternative 005A4E63C2256B47_=-- From owner-ips@ece.cmu.edu Mon Jan 21 01: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 BAA23419 for ; Mon, 21 Jan 2002 01:43:31 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0L5pPq11630 for ips-outgoing; Mon, 21 Jan 2002 00:51:25 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f183.law10.hotmail.com [64.4.15.183]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0L5pLj11617 for ; Mon, 21 Jan 2002 00:51:21 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 20 Jan 2002 21:51:15 -0800 Received: from 62.0.67.47 by lw10fd.law10.hotmail.msn.com with HTTP; Mon, 21 Jan 2002 05:51:15 GMT X-Originating-IP: [62.0.67.47] Reply-To: Julian_Satran@il.ibm.com From: "Julian Satran" To: internet-drafts@ietf.org, ips@ece.cmu.edu Cc: Julian_Satran@il.ibm.com Subject: draft submission Date: Mon, 21 Jan 2002 07:51:15 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Jan 2002 05:51:15.0639 (UTC) FILETIME=[A3B6CC70:01C1A23F] Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi, On behalf of a group of authors and as part of the IP Storage working group I am submitting a new version of the draft: draft-ietf-ips-iSCSI-10.txt that completely replaces: draft-ietf-ips-iSCSI-09.txt I am also submitting a pdf version for readers convenience. The two versions can be found at: http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iSCSI-10.txt and http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iSCSI-10.pdf Julo _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From owner-ips@ece.cmu.edu Mon Jan 21 07:36: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 HAA07193 for ; Mon, 21 Jan 2002 07:36:24 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0LBtnx11721 for ips-outgoing; Mon, 21 Jan 2002 06:55:49 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar1aa.compuserve.com (siaar1aa.compuserve.com [149.174.40.9]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0LBtkj11710 for ; Mon, 21 Jan 2002 06:55:46 -0500 (EST) Received: (from mailgate@localhost) by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id GAA09353 for ips@ece.cmu.edu; Mon, 21 Jan 2002 06:55:41 -0500 (EST) Received: from compuserve.com (dal-tgn-tkm-vty2.as.wcom.net [216.192.225.2]) by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id GAA09202 for ; Mon, 21 Jan 2002 06:55:32 -0500 (EST) Message-ID: <3C4C02E0.3D5FE9C6@compuserve.com> Date: Mon, 21 Jan 2002 06:00:32 -0600 From: Ralph Weber Reply-To: roweber@acm.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win98; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IPS Reflector Subject: FCIP rev 08 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-08.pdf, and draft-ietf-ips-fcovertcpip-08.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-004v6.pdf and ftp://ftp.t11.org/t11/member/incoming/02-004v6.pdf In a day or two they will move to: ftp://ftp.t11.org/t11/pub/fc/bb-2/02-004v6.pdf and ftp://ftp.t11.org/t11/pub/fc/bb-2/02-004v6.txt If you cannot find them one place try the other. The PDF version contains change bars from FCIP 07. FCIP rev 8 contains the following major changes (from rev 7): o Addition of authentication for SF frames received on the 2-nd to n-th TCP Connections in an FCIP Link. o Remove the ability to send the SF at any time other than as the first bytes on a new TCP Connection. o Remove the ability to merge FCIP_LEPs. o Update security section to match latest IPS WG draft. o Addition of Class 4 SOF codes. o Addition of TCP Connection closure reporting requirements so that the FC Entity is made aware of every significant TCP Connection closure. o Move Ch bit in pFlags. o Add IANA assigned FCIP well known port number and IANA Considerations annex. o Add "FCIP Usage of Addresses and Identifiers" annex. o Other changes agreed in Salt Lake. Work remaining to do: o Further corrections to the Special Frame security based on review of the rev 8 draft Enjoy. Ralph... From owner-ips@ece.cmu.edu Mon Jan 21 07:40:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07318 for ; Mon, 21 Jan 2002 07:40:24 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0LC2VG12061 for ips-outgoing; Mon, 21 Jan 2002 07:02:31 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar1aa.compuserve.com (siaar1aa.compuserve.com [149.174.40.9]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0LC2Tj12057 for ; Mon, 21 Jan 2002 07:02:29 -0500 (EST) Received: (from mailgate@localhost) by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id HAA11061 for ips@ece.cmu.edu; Mon, 21 Jan 2002 07:02:24 -0500 (EST) Received: from compuserve.com (dal-tgn-tkm-vty2.as.wcom.net [216.192.225.2]) by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id HAA11024 for ; Mon, 21 Jan 2002 07:02:22 -0500 (EST) Message-ID: <3C4C047B.F76DB575@compuserve.com> Date: Mon, 21 Jan 2002 06:07:23 -0600 From: Ralph Weber Reply-To: roweber@acm.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win98; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IPS Reflector Subject: FCIP: Special Frame FC-BB-2 Security Proposal Available Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The proposal covering the FC-BB-2 half of the Special Frame (SF) authentication protocol described previously on this reflector for FCIP is available as: ftp://ftp.t11.org/t11/member/incoming/02-020v0.pdf In a day or two it will be moved to: ftp://ftp.t11.org/t11/pub/fc/bb-2/02-020v0.pdf If you cannot find it in one place try the other. Since this half of the protocol must be defined in T11 standards, this proposal is informational only to the IPS WG. However, comments and requests for changes made on this reflector will be considered. I believe that the results of the T11 deliberations will be available for reporting at the Huntington Beach interim meeting. FYI Ralph... From owner-ips@ece.cmu.edu Mon Jan 21 11:50: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 LAA16435 for ; Mon, 21 Jan 2002 11:50:54 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0LFSKE27315 for ips-outgoing; Mon, 21 Jan 2002 10:28:20 -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 g0LFSJj27311 for ; Mon, 21 Jan 2002 10:28:19 -0500 (EST) Received: from london ([10.95.10.3]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id HAA06743; Mon, 21 Jan 2002 07:26:50 -0800 (PST) From: "Rod Harrison" To: "Julian Satran" , Subject: RE: iSCSI: NopIn in ping mode can contain data? Date: Mon, 21 Jan 2002 15:31: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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, What's the reason behind preventing the target sending ping data? I would have thought it would be just as much use for a target as it is for an initiator. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Saturday, January 19, 2002 3:23 PM To: ips@ece.cmu.edu Subject: Re: iSCSI: NopIn in ping mode can contain data? No data - will indicate this in 10 - Julo Tow Wang Sent by: owner-ips@ece.cmu.edu 16-01-02 01:10 To: ips@ece.cmu.edu cc: Subject: iSCSI: NopIn in ping mode can contain data? Hello everybody. 1) When a target sends out a NopIn as a ping, is it allowed to contain a data segment? 2) If yes, a) why would anyone send data along? b) must the initiator echo back the data? I haven't found a clear answer in draft 9. Thanks for any clarifications. -- Tow Wang Adaptec Software Engineer From owner-ips@ece.cmu.edu Mon Jan 21 12:20: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 MAA17462 for ; Mon, 21 Jan 2002 12:20:09 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0LGPhI01849 for ips-outgoing; Mon, 21 Jan 2002 11:25:43 -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 g0LGPVj01832 for ; Mon, 21 Jan 2002 11:25:33 -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 g0LGI5w10619; Mon, 21 Jan 2002 21:48:10 +0530 Message-ID: <3C4C3F22.36863B92@npd.hcltech.com> Date: Mon, 21 Jan 2002 21:47:38 +0530 From: Sajay Selvaraj X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sganguly@opulentsystems.com CC: Naveen Nimmu , Camden Ford , "'Nike Chen'" , IPS Subject: iSCSI: WWName mapping to iSCSI names (Was Re: Differences between iSCSI Router ..) References: <200201160849430169.19C0CD23@opulentsystems.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sukanta, I suppose you are referring to an FC node. I remember an old thread on 'a standard way of representing/mapping WWNames in iSCSI' ? This was with special reference to iSCSI-FC address mapping. Any new ideas on a standard way to do this ? Regards, Sajay Camden, I would like to add a point here that there is the World Wide Name (WWN) convention that is responsible for a unique identification of a storage device. SG *********** REPLY SEPARATOR *********** On 1/15/2002 at 10:34 AM Naveen Nimmu wrote: [snip] -- http://san.hcltech.com From owner-ips@ece.cmu.edu Mon Jan 21 13:03: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 NAA18877 for ; Mon, 21 Jan 2002 13:03:02 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0LHGhW05916 for ips-outgoing; Mon, 21 Jan 2002 12:16:43 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0LHGej05906 for ; Mon, 21 Jan 2002 12:16:40 -0500 (EST) 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 JAA05786 for ; Mon, 21 Jan 2002 09:16:28 -0800 (PST) Message-ID: <3C4C49CC.E512C1B1@cisco.com> Date: Mon, 21 Jan 2002 11:03: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: Draft submission String Profile for iSCSI Names Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I've just submitted the draft on string profiling for iSCSI names as draft-ietf-ips-iscsi-stringprep-00.txt. Until it turns up as an internet-draft, it is available at: ftp://ftpeng.cisco.com/mbakke/ips/iscsi/draft-ietf-ips-iscsi-string-prep-00.txt This draft covers the mapping process by which internationalized UTF-8 iSCSI names can be "normalized" (converted to the equivalent of lower-case, and having illegal characters removed) before being used by the iSCSI protocol. Note that from the iSCSI protocol's point of view, iSCSI names are assumed to have been normalized before being sent or received by iSCSI or any of its discovery or management protocols; the draft mainly serves as a method for checking and converting user input into iSCSI names for those implementations that wish to do so. This document should not be read without first reading the iSCSI naming & discovery draft. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Mon Jan 21 14:29:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21212 for ; Mon, 21 Jan 2002 14:29:59 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0LILp911834 for ips-outgoing; Mon, 21 Jan 2002 13:21:51 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web12503.mail.yahoo.com (web12503.mail.yahoo.com [216.136.173.195]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g0LIC7j11133 for ; Mon, 21 Jan 2002 13:12:08 -0500 (EST) Message-ID: <20020121181207.62617.qmail@web12503.mail.yahoo.com> Received: from [66.122.195.194] by web12503.mail.yahoo.com via HTTP; Mon, 21 Jan 2002 10:12:07 PST Date: Mon, 21 Jan 2002 10:12:07 -0800 (PST) From: Sukanta ganguly Subject: Re: iSCSI: WWName mapping to iSCSI names (Was Re: Differences between iSCSI Router ..) To: Sajay Selvaraj , sganguly@opulentsystems.com Cc: Naveen Nimmu , Camden Ford , "'Nike Chen'" , IPS In-Reply-To: <3C4C3F22.36863B92@npd.hcltech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I don't have one now, but am working on defining one. All I was trying to state in my reply to the Camden was the WWN does exist and can be leveraged for the unique identification. SG --- Sajay Selvaraj wrote: > Sukanta, > > I suppose you are referring to an FC node. I > remember an old thread on 'a standard > way of representing/mapping WWNames in iSCSI' ? This > was with special reference to > iSCSI-FC address mapping. Any new ideas on a > standard way to do this ? > > Regards, > Sajay > > Camden, > I would like to add a point here that there is > the World Wide Name (WWN) convention that is > responsible for a unique identification of a storage > device. > > SG > > *********** REPLY SEPARATOR *********** > > On 1/15/2002 at 10:34 AM Naveen Nimmu wrote: > > [snip] > > -- > http://san.hcltech.com > __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From owner-ips@ece.cmu.edu Mon Jan 21 19:15: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 TAA28728 for ; Mon, 21 Jan 2002 19:15:24 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0LNQgf05394 for ips-outgoing; Mon, 21 Jan 2002 18:26:42 -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 g0LNQej05388 for ; Mon, 21 Jan 2002 18:26:40 -0500 (EST) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Jan 2002 15:26:04 -0800 Message-ID: From: Joshua Tseng To: "'Sukanta ganguly'" , Sajay Selvaraj , sganguly@opulentsystems.com Cc: Naveen Nimmu , Camden Ford , "'Nike Chen'" , IPS Subject: RE: iSCSI: WWName mapping to iSCSI names (Was Re: Differences bet ween iSCSI Router ..) Date: Mon, 21 Jan 2002 15:25:56 -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 All, iSNS can store a WWN to iSCSI name mapping. This is reflected in the latest iSNS -07 draft, where a "proxy WWNN" is stored as an attribute of an iSCSI device. Josh > -----Original Message----- > From: Sukanta ganguly [mailto:sganguly@yahoo.com] > Sent: Monday, January 21, 2002 10:12 AM > To: Sajay Selvaraj; sganguly@opulentsystems.com > Cc: Naveen Nimmu; Camden Ford; 'Nike Chen'; IPS > Subject: Re: iSCSI: WWName mapping to iSCSI names (Was Re: Differences > between iSCSI Router ..) > > > I don't have one now, but am working on defining one. > All I was trying to state in my reply to the Camden > was the WWN does exist and can be leveraged for the > unique identification. > > > SG > --- Sajay Selvaraj wrote: > > Sukanta, > > > > I suppose you are referring to an FC node. I > > remember an old thread on 'a standard > > way of representing/mapping WWNames in iSCSI' ? This > > was with special reference to > > iSCSI-FC address mapping. Any new ideas on a > > standard way to do this ? > > > > Regards, > > Sajay > > > > Camden, > > I would like to add a point here that there is > > the World Wide Name (WWN) convention that is > > responsible for a unique identification of a storage > > device. > > > > SG > > > > *********** REPLY SEPARATOR *********** > > > > On 1/15/2002 at 10:34 AM Naveen Nimmu wrote: > > > > [snip] > > > > -- > > http://san.hcltech.com > > > > > __________________________________________________ > Do You Yahoo!? > Send FREE video emails in Yahoo! Mail! > http://promo.yahoo.com/videomail/ > From owner-ips@ece.cmu.edu Tue Jan 22 00:24: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 AAA04053 for ; Tue, 22 Jan 2002 00:24:51 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0M4g8a24566 for ips-outgoing; Mon, 21 Jan 2002 23:42:08 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web12505.mail.yahoo.com (web12505.mail.yahoo.com [216.136.173.197]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g0LNlnj06733 for ; Mon, 21 Jan 2002 18:47:49 -0500 (EST) Message-ID: <20020121234748.82097.qmail@web12505.mail.yahoo.com> Received: from [66.122.195.194] by web12505.mail.yahoo.com via HTTP; Mon, 21 Jan 2002 15:47:48 PST Date: Mon, 21 Jan 2002 15:47:48 -0800 (PST) From: Sukanta ganguly Subject: RE: iSCSI: WWName mapping to iSCSI names (Was Re: Differences bet ween iSCSI Router ..) To: Joshua Tseng , Sajay Selvaraj , sganguly@opulentsystems.com Cc: Naveen Nimmu , Camden Ford , "'Nike Chen'" , IPS In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Perfect. Then the unique name resolution issue can be tackled. It will require the iSCSI router to locate the iSNS server. I need to read the latest iSNS draft. Thanks for the info Josh. SG --- Joshua Tseng wrote: > All, > > iSNS can store a WWN to iSCSI name mapping. This is > reflected > in the latest iSNS -07 draft, where a "proxy WWNN" > is stored > as an attribute of an iSCSI device. > > Josh > > > -----Original Message----- > > From: Sukanta ganguly [mailto:sganguly@yahoo.com] > > Sent: Monday, January 21, 2002 10:12 AM > > To: Sajay Selvaraj; sganguly@opulentsystems.com > > Cc: Naveen Nimmu; Camden Ford; 'Nike Chen'; IPS > > Subject: Re: iSCSI: WWName mapping to iSCSI names > (Was Re: Differences > > between iSCSI Router ..) > > > > > > I don't have one now, but am working on defining > one. > > All I was trying to state in my reply to the > Camden > > was the WWN does exist and can be leveraged for > the > > unique identification. > > > > > > SG > > --- Sajay Selvaraj > wrote: > > > Sukanta, > > > > > > I suppose you are referring to an FC node. I > > > remember an old thread on 'a standard > > > way of representing/mapping WWNames in iSCSI' ? > This > > > was with special reference to > > > iSCSI-FC address mapping. Any new ideas on a > > > standard way to do this ? > > > > > > Regards, > > > Sajay > > > > > > Camden, > > > I would like to add a point here that there > is > > > the World Wide Name (WWN) convention that is > > > responsible for a unique identification of a > storage > > > device. > > > > > > SG > > > > > > *********** REPLY SEPARATOR *********** > > > > > > On 1/15/2002 at 10:34 AM Naveen Nimmu wrote: > > > > > > [snip] > > > > > > -- > > > http://san.hcltech.com > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Send FREE video emails in Yahoo! Mail! > > http://promo.yahoo.com/videomail/ > > __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From owner-ips@ece.cmu.edu Tue Jan 22 03:21: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 DAA13667 for ; Tue, 22 Jan 2002 03:21:24 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0M7bFi04442 for ips-outgoing; Tue, 22 Jan 2002 02:37:15 -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 g0M7bDj04438 for ; Tue, 22 Jan 2002 02:37: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 IAA72510; Tue, 22 Jan 2002 08:37: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 g0M7c5I50316; Tue, 22 Jan 2002 08:38:05 +0100 To: "Rod Harrison" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: NopIn in ping mode can contain data? X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 22 Jan 2002 09:38:15 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 22/01/2002 09:38:17, Serialize complete at 22/01/2002 09:38:17 Content-Type: multipart/alternative; boundary="=_alternative 0078AEC8C2256B48_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0078AEC8C2256B48_= Content-Type: text/plain; charset="us-ascii" Rod, Initiators are usually build under the assumption that they are "in control" - e.g., no unsolicited data. Having them prepare for unsolicited data without good cause does not seem a good idea. Julo "Rod Harrison" 21-01-02 17:31 To: Julian Satran/Haifa/IBM@IBMIL, cc: Subject: RE: iSCSI: NopIn in ping mode can contain data? Julian, What's the reason behind preventing the target sending ping data? I would have thought it would be just as much use for a target as it is for an initiator. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Saturday, January 19, 2002 3:23 PM To: ips@ece.cmu.edu Subject: Re: iSCSI: NopIn in ping mode can contain data? No data - will indicate this in 10 - Julo Tow Wang Sent by: owner-ips@ece.cmu.edu 16-01-02 01:10 To: ips@ece.cmu.edu cc: Subject: iSCSI: NopIn in ping mode can contain data? Hello everybody. 1) When a target sends out a NopIn as a ping, is it allowed to contain a data segment? 2) If yes, a) why would anyone send data along? b) must the initiator echo back the data? I haven't found a clear answer in draft 9. Thanks for any clarifications. -- Tow Wang Adaptec Software Engineer --=_alternative 0078AEC8C2256B48_= Content-Type: text/html; charset="us-ascii"
Rod,

Initiators are usually build under the assumption that they are "in control" - e.g., no unsolicited data.
Having them prepare for unsolicited data without good cause does not seem a good idea.

Julo


"Rod Harrison" <rod.harrison@windriver.com>

21-01-02 17:31

       
        To:        Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>
        cc:        
        Subject:        RE: iSCSI: NopIn in ping mode can contain data?

       


Julian,

                What's the reason behind preventing the target sending ping data? I
would have thought it would be just as much use for a target as it is
for an initiator.

                - Rod

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Julian Satran
Sent: Saturday, January 19, 2002 3:23 PM
To: ips@ece.cmu.edu
Subject: Re: iSCSI: NopIn in ping mode can contain data?



No  data - will indicate this in 10 - Julo


Tow Wang <Tow_Wang@adaptec.com>
Sent by: owner-ips@ece.cmu.edu
16-01-02 01:10

       To:        ips@ece.cmu.edu
       cc:
       Subject:        iSCSI: NopIn in ping mode can contain data?




Hello everybody.

1) When a target sends out a NopIn as a ping, is it allowed to contain
a
data segment?
2) If yes,
  a) why would anyone send data along?
  b) must the initiator echo back the data?

I haven't found a clear answer in draft 9. Thanks for any
clarifications.
--
Tow Wang
Adaptec Software Engineer

--=_alternative 0078AEC8C2256B48_=-- From owner-ips@ece.cmu.edu Tue Jan 22 05:03: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 FAA14820 for ; Tue, 22 Jan 2002 05:03:19 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0M9HO809926 for ips-outgoing; Tue, 22 Jan 2002 04:17:24 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ns1.in-biz.net (IDENT:root@ptil-196-150-hyd.primus-india.net [203.196.150.196] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0M9HKj09920 for ; Tue, 22 Jan 2002 04:17:21 -0500 (EST) Received: from yahoo.com ([203.196.150.219]) by ns1.in-biz.net (8.9.3/8.9.3) with ESMTP id OAA00884; Tue, 22 Jan 2002 14:46:41 +0530 Message-ID: <3C4D2F8B.8060009@yahoo.com> Date: Tue, 22 Jan 2002 14:53:23 +0530 From: Ajit Aryan Reply-To: digital_aryan@yahoo.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Julian Satran CC: ips@ece.cmu.edu Subject: Re: iSCSI: NopIn in ping mode can contain data? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julo, By this we should be able to say one thing, NOPIn in ping mode can contain data. What every care has to be taken about the data. Now, what should be the solicited data? In sense, the data which the initiator could use for tuning, negotiation etc...?? Aryan Julian Satran wrote: > > Rod, > > Initiators are usually build under the assumption that they are "in > control" - e.g., no unsolicited data. > Having them prepare for unsolicited data without good cause does not > seem a good idea. > > Julo > > > "Rod Harrison" > > 21-01-02 17:31 > > > To: Julian Satran/Haifa/IBM@IBMIL, > cc: > Subject: RE: iSCSI: NopIn in ping mode can contain data? > > > > > > Julian, > > What's the reason behind preventing the target sending > ping data? I > would have thought it would be just as much use for a target as it is > for an initiator. > > - Rod > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Saturday, January 19, 2002 3:23 PM > To: ips@ece.cmu.edu > Subject: Re: iSCSI: NopIn in ping mode can contain data? > > > > No data - will indicate this in 10 - Julo > > > Tow Wang > Sent by: owner-ips@ece.cmu.edu > 16-01-02 01:10 > > To: ips@ece.cmu.edu > cc: > Subject: iSCSI: NopIn in ping mode can contain data? > > > > > Hello everybody. > > 1) When a target sends out a NopIn as a ping, is it allowed to contain > a > data segment? > 2) If yes, > a) why would anyone send data along? > b) must the initiator echo back the data? > > I haven't found a clear answer in draft 9. Thanks for any > clarifications. > -- > Tow Wang > Adaptec Software Engineer > > > From owner-ips@ece.cmu.edu Tue Jan 22 08:58:08 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18289 for ; Tue, 22 Jan 2002 08:58:08 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0MDFLF03681 for ips-outgoing; Tue, 22 Jan 2002 08:15:21 -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 g0MDFKj03677 for ; Tue, 22 Jan 2002 08:15:20 -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 IAA94806 for ; Tue, 22 Jan 2002 08:12:15 -0500 Received: from d03nm041.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 g0MDFH748034 for ; Tue, 22 Jan 2002 06:15:17 -0700 Subject: iSCSI: changelog ver8 to ver9 To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Prasenjit Sarkar" Date: Tue, 22 Jan 2002 05:15:10 -0800 X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.8 |June 18, 2001) at 01/22/2002 05:15:17 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk The units for FirstBurstSize, MaxBurstSize, etc has been changed from 512 bytes to bytes and has not been reflected in the changelog. Prasenjit Prasenjit Sarkar Research Staff Member IBM Almaden Research San Jose From owner-ips@ece.cmu.edu Tue Jan 22 12:40: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 MAA01856 for ; Tue, 22 Jan 2002 12:40:52 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0MGoEK20682 for ips-outgoing; Tue, 22 Jan 2002 11:50:14 -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 g0MCujj02689 for ; Tue, 22 Jan 2002 07:57:00 -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 HAA16673; Tue, 22 Jan 2002 07:56:42 -0500 (EST) Message-Id: <200201221256.HAA16673@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-fcovertcpip-08.txt,.pdf Date: Tue, 22 Jan 2002 07:56:42 -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 : Fibre Channel Over TCP/IP (FCIP) Author(s) : M. Rajagopal, R. Bhagwat et al. Filename : draft-ietf-ips-fcovertcpip-08.txt,.pdf Pages : 56 Date : 21-Jan-02 Fibre Channel Over TCP/IP (FCIP) describes mechanisms that allow the interconnection of islands of Fibre Channel storage area networks over IP-based networks to form a unified storage area network in a single Fibre Channel fabric. FCIP relies on IP-based network services to provide the connectivity between the storage area network islands over local area networks, metropolitan area networks, or wide area networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcovertcpip-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-fcovertcpip-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-fcovertcpip-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: <20020121082139.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-fcovertcpip-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-fcovertcpip-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020121082139.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Tue Jan 22 12:52: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 MAA02214 for ; Tue, 22 Jan 2002 12:52:50 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0MGoAY20669 for ips-outgoing; Tue, 22 Jan 2002 11:50:10 -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 g0MCuoj02694 for ; Tue, 22 Jan 2002 07:56:50 -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 HAA16689; Tue, 22 Jan 2002 07:56:47 -0500 (EST) Message-Id: <200201221256.HAA16689@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-iscsi-10.txt,.pdf Date: Tue, 22 Jan 2002 07:56:47 -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 : iSCSI Author(s) : J. Satran et al. Filename : draft-ietf-ips-iscsi-10.txt,.pdf Pages : Date : 21-Jan-02 The Small Computer Systems Interface (SCSI) is a popular family of protocols for communicating with I/O devices, especially storage devices. This memo describes a trans- port protocol for SCSI that operates on top of TCP. The iSCSI protocol aims to be fully compliant with the requirements laid out in the SCSI Architecture Model - 2 [SAM2] document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-10.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-10.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: <20020121082153.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020121082153.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Tue Jan 22 16:50:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12048 for ; Tue, 22 Jan 2002 16:50:15 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0MKphx11325 for ips-outgoing; Tue, 22 Jan 2002 15:51:43 -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 g0MKpej11320 for ; Tue, 22 Jan 2002 15:51:41 -0500 (EST) Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id MAA21627; Tue, 22 Jan 2002 12:50:55 -0800 (PST) From: Keith McCloghrie Message-Id: <200201222050.MAA21627@cisco.com> Subject: Submission of draft-ietf-ips-fcmgmt-mib-00.txt To: internet-drafts@ietf.org (Internet Drafts Submissions) Date: Tue, 22 Jan 2002 12:50:55 -0800 (PST) Cc: Black_David@emc.com, ElizabethRodriguez@ieee.org, ips@ece.cmu.edu, kzm@cisco.com (Keith McCloghrie) 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, Please find the text stored at ftp://ftpeng.cisco.com/ftp/kzm/pub/draft-ietf-ips-fcmgmt-mib-00.txt for submission as an Internet-Draft of the IPS Working Group. Thanks, Keith. From owner-ips@ece.cmu.edu Tue Jan 22 17:27: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 RAA13260 for ; Tue, 22 Jan 2002 17:27:08 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0MLbHS15609 for ips-outgoing; Tue, 22 Jan 2002 16:37:17 -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 g0MLbFj15604 for ; Tue, 22 Jan 2002 16:37:15 -0500 (EST) Received: from [64.170.220.9] (helo=EGRodriguez) by osmtp1.electric.net with esmtp (Exim 3.22 #1) id 16T8bM-000AzA-04 for ips@ece.cmu.edu; Tue, 22 Jan 2002 13:37:10 -0800 From: "Elizabeth G. Rodriguez" To: Subject: Multiple listings now on Internet Draft Announcements Date: Tue, 22 Jan 2002 15:34:32 -0600 Message-ID: <007501c1a38c$97d4f730$09dcaa40@EGRodriguez> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0076_01C1A35A.4D3A8730" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 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_0076_01C1A35A.4D3A8730 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, When viewing internet draft announcements, if multiple formats of the document are submitted, it is now being noted on the announcement. Look at the filename line - will list draft-xxx.txt, .pdf to indicate both txt and pdf formats available. Unfortunately, you will still need to make some effort to retrieve the appropriate draft. In general, you can copy the url to the txt draft and replace .txt with .pdf. Still no way to see if multiple versions of the draft is available on the charter page, but we will have to work on that next. Thanks, Elizabeth ------=_NextPart_000_0076_01C1A35A.4D3A8730 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

When viewing internet draft announcements, if = multiple formats of the document are submitted, it is now being noted on the announcement.

Look at the filename line – will list = draft-xxx.txt, .pdf

to indicate both txt and pdf formats = available.

 

Unfortunately, you will still need to make some = effort to retrieve the appropriate draft.

In general, you can copy the url to the txt draft and replace .txt with .pdf.

 

Still no way to see if multiple versions of the draft = is available on the charter page, but we will have to work on that = next.

 

Thanks,

 

Elizabeth

------=_NextPart_000_0076_01C1A35A.4D3A8730-- From owner-ips@ece.cmu.edu Tue Jan 22 17:29: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 RAA13296 for ; Tue, 22 Jan 2002 17:29:28 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0MLY2g15307 for ips-outgoing; Tue, 22 Jan 2002 16:34:02 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0MLY0j15302 for ; Tue, 22 Jan 2002 16:34:00 -0500 (EST) 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 NAA20155 for ; Tue, 22 Jan 2002 13:33:44 -0800 (PST) Message-ID: <3C4DD795.AA38DEF@cisco.com> Date: Tue, 22 Jan 2002 15:20:21 -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: Authorization Model for the iSCSI MIB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit One of the open items for the iSCSI MIB was to be able to display and configure information about the various authorization schemes available in the iSCSI protocol. An iSCSI target can allow access to an iSCSI initiator based on several things: - iSCSI initiator name - iSCSI initiator address - SRP or CHAP username - Kerberos - Public key certificates The iSCSI MIB team has developed a UML model of the additions to the iSCSI MIB that will support these things. This model defines a "user" (meaning a host, cluster, application, whatever counts as the "user" of iSCSI) identity, which is composed of initiator names, address ranges, credentials (user names), and accepted certificates. The model allows the user identity to consist of a reasonable set of these attributes, without getting too complicated and dragging us into the policy swamp. Instead of including initiator names in the current access list entries, we would add a RowPointer attribute that would point to the user identity that the target would accept. This way, user identities do not live under targets, and can be used by more than one target. This model is best understood by way of examples, which are included. Page 1 of the drawing is the current iSCSI MIB. Page 2 includes the iscsiInstance and iscsiTarget objects from the iSCSI MIB, with the remainder of the objects added for this authorization model. As usual, the last page includes a key for those who have not been exposed to the slightly simplified version of UML that we are using. The best way to look at this model (on page 2) is: 1. Read the use case on the lower left. 2. Look at the UML. 3. Read the solution to the use case on the lower right. 4. Look at the UML again. Note that specific attributes to handle SRP, public keys, and Kerberos have not yet been fully defined; we wanted to make sure the model was structurally sound first. This model will serve in place of an internet-draft with the MIB changes for the interim meeting, since at this point, the discussion of the model is more important than the discussion of the individual MIB attributes. The model (pdf) is available at: ftp://ftpeng.cisco.com/mbakke/ips/iscsi-mib/Visio-ietf-iscsi-uml-model-03-access.pdf The next steps are to look at whether the same model, or a generalization thereof, can or should be used to configure an iSCSI initiator, and how far to take this model in terms of allowing configuration via SNMP. Enjoy, -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Jan 22 21:53: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 VAA18919 for ; Tue, 22 Jan 2002 21:53:31 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0N214u04713 for ips-outgoing; Tue, 22 Jan 2002 21:01: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 g0N212j04703 for ; Tue, 22 Jan 2002 21:01: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 07C1B99E for ; Tue, 22 Jan 2002 19:01:02 -0700 (MST) Received: from acropora.rose.agilent.com (acropora.rose.agilent.com [130.30.179.5]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id A12BD1A5 for ; Tue, 22 Jan 2002 19:01:01 -0700 (MST) Received: (from dbs@localhost) by acropora.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) id RAA04596 for ips@ece.cmu.edu; Tue, 22 Jan 2002 17:59:42 -0800 (PST) From: Dave Sheehy Message-Id: <200201230159.RAA04596@acropora.rose.agilent.com> Subject: RE: iSCSI: Markers and Framing To: ips@ece.cmu.edu (IETF IP SAN Reflector) Date: Tue, 22 Jan 2002 17:59:41 PST X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk > > A couple of comments on this: > > > b. I strongly recommend SHOULD implement FIM on the send side. > > Implication -> Senders that do not insert markers should be > > willing to accept up to RTT*BW data drops! Headers being > > "reasonably" out-of-order is OK. Of course, senders that do not > > insert markers but are willing to pay big $$$ to the SSP will > > get their buffer/BW allocation as usual and customary :-) > > I think the Implication is too strong, as it goes against the following > SHOULD from RFC 1122 (which modifies RFC 793): > > 4.2.2.20 Event Processing: RFC-793 Section 3.9 > > While it is not strictly required, a TCP SHOULD be capable > of queueing out-of-order TCP segments. > > A drop causes the segments up to the retransmission of the drop to > be out-of-order. This does not preclude "SHOULD implement FIM", but > the above Implication is overdone in my view as it appears to condone > drops of all out-of-order segments. It is not overdone. It is the reality of the situation for a one touch NIC. If an implementation does not want to implement some form of framing that is the consequence it must be willing to pay for that choice. Dave Sheehy From owner-ips@ece.cmu.edu Wed Jan 23 01:05: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 BAA22972 for ; Wed, 23 Jan 2002 01:05:20 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0N5Jf116079 for ips-outgoing; Wed, 23 Jan 2002 00:19: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-h015.c003.snv.cp.net [209.228.32.229]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g0N5Jdj16074 for ; Wed, 23 Jan 2002 00:19:39 -0500 (EST) Received: (cpmta 21206 invoked from network); 22 Jan 2002 21:19:32 -0800 Received: from 64.130.130.105 (HELO dougrmt) by smtp.telocity.com (209.228.32.229) with SMTP; 22 Jan 2002 21:19:32 -0800 X-Sent: 23 Jan 2002 05:19:32 GMT From: "Douglas Otis" To: "IETF IP SAN Reflector" Subject: RE: iSCSI: Markers and Framing Date: Tue, 22 Jan 2002 21:20:32 -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: <200201230159.RAA04596@acropora.rose.agilent.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Dave, The iSCSI draft includes use of Fixed Interval Markers- "Different schemes can be used to recover synchronization. One of these schemes is detailed in Appendix A. - Sync and Steering with Fixed Interval Markers -. To make these schemes work, iSCSI implementations have to make sure that the appropriate protocol layers are provided with enough information to implement a synchronization and/or data steering mechanism." As you are suggesting there is a significant consequence in TCP behavior if not adhering to this iSCSI recommendation that mandates a process below the transport layer for de-encapsulation of iSCSI related structures, the impact of this requirement should be reviewed within the appropriate workgroup. Until then, Fixed Interval Markers should not be included within the iSCSI documentation as this behavior is a change to TCP as you have indicated. Doug > > A couple of comments on this: > > > > > b. I strongly recommend SHOULD implement FIM on the send side. > > > Implication -> Senders that do not insert markers should be > > > willing to accept up to RTT*BW data drops! Headers being > > > "reasonably" out-of-order is OK. Of course, senders that do not > > > insert markers but are willing to pay big $$$ to the SSP will > > > get their buffer/BW allocation as usual and customary :-) > > > > I think the Implication is too strong, as it goes against the following > > SHOULD from RFC 1122 (which modifies RFC 793): > > > > 4.2.2.20 Event Processing: RFC-793 Section 3.9 > > > > While it is not strictly required, a TCP SHOULD be capable > > of queueing out-of-order TCP segments. > > > > A drop causes the segments up to the retransmission of the drop to > > be out-of-order. This does not preclude "SHOULD implement FIM", but > > the above Implication is overdone in my view as it appears to condone > > drops of all out-of-order segments. > > It is not overdone. It is the reality of the situation for a one > touch NIC. > If an implementation does not want to implement some form of framing > that is the consequence it must be willing to pay for that choice. > > Dave Sheehy > > From owner-ips@ece.cmu.edu Wed Jan 23 07:46: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 HAA06457 for ; Wed, 23 Jan 2002 07:46:15 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0NBlDS16836 for ips-outgoing; Wed, 23 Jan 2002 06:47: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 g0NBlBj16832 for ; Wed, 23 Jan 2002 06:47: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 MAA82336 for ; Wed, 23 Jan 2002 12:47: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 g0NBlmW141762 for ; Wed, 23 Jan 2002 12:48:04 +0100 Subject: Re: iSCSI: changelog ver8 to ver9 To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Tue, 22 Jan 2002 18:34:24 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 23/01/2002 13:48:15 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Prasenjit, Should I read your statement as a question - i.e., with a why preceding it? They where many other editorial changes that are not reflected in the log - they have no major significance and the change bars in the pdf file reflect them. The new units are clearly stated everywhere. Julo Prasenjit Sarkar/Almaden To: ips@ece.cmu.edu /IBM@IBMUS cc: Sent by: Subject: iSCSI: changelog ver8 to ver9 owner-ips@ece. cmu.edu 22-01-02 15:15 The units for FirstBurstSize, MaxBurstSize, etc has been changed from 512 bytes to bytes and has not been reflected in the changelog. Prasenjit Prasenjit Sarkar Research Staff Member IBM Almaden Research San Jose From owner-ips@ece.cmu.edu Wed Jan 23 09:53: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 JAA10848 for ; Wed, 23 Jan 2002 09:53:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0NE0Te24040 for ips-outgoing; Wed, 23 Jan 2002 09:00:29 -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 g0NE0Pj24033 for ; Wed, 23 Jan 2002 09:00:26 -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 g0NDxwJ15766; Wed, 23 Jan 2002 08:59:58 -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 g0NDxvc01545; Wed, 23 Jan 2002 08:59:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15438.49629.898000.327569@gargle.gargle.HOWL> Date: Wed, 23 Jan 2002 08:59:57 -0500 From: Paul Koning To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: changelog ver8 to ver9 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 22 January 2002) by Julian Satran: > Prasenjit, > > Should I read your statement as a question - i.e., with a why preceding it? > They where many other editorial changes that are not reflected in the log - > they have no major > significance and the change bars in the pdf file reflect them. > The new units are clearly stated everywhere. But a change in units is not an editorial change. Editorial changes are changes that affect the way things are described but not the way the implementations are coded. A change in units is a message encoding change and requires changes to implementations. paul From owner-ips@ece.cmu.edu Wed Jan 23 11:49: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 LAA15945 for ; Wed, 23 Jan 2002 11:49:29 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0NFqtn03367 for ips-outgoing; Wed, 23 Jan 2002 10:52:55 -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 g0NENxj25713 for ; Wed, 23 Jan 2002 09:23:59 -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 JAA09631; Wed, 23 Jan 2002 09:23:57 -0500 (EST) Message-Id: <200201231423.JAA09631@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-iscsi-name-disc-04.txt Date: Wed, 23 Jan 2002 09:23:56 -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 : iSCSI Naming and Discovery Author(s) : M. Bakke et al. Filename : draft-ietf-ips-iscsi-name-disc-04.txt Pages : 22 Date : 22-Jan-02 This document describes iSCSI [7] naming and discovery details. This document complements the iSCSI Protocol draft. Flexibility is the key guiding principle behind this document. That is, an effort has been made to satisfy the needs of both small isolated environments, as well as large environments requiring secure/scalable solutions A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-name-disc-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-name-disc-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-name-disc-04.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: <20020122153254.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-name-disc-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-name-disc-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020122153254.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Wed Jan 23 11:52: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 LAA16121 for ; Wed, 23 Jan 2002 11:52:54 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0NFr0O03386 for ips-outgoing; Wed, 23 Jan 2002 10:53:00 -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 g0NEOlj25765 for ; Wed, 23 Jan 2002 09:24:47 -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 JAA09778; Wed, 23 Jan 2002 09:24:44 -0500 (EST) Message-Id: <200201231424.JAA09778@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-grant-iscsi-eui64node-00.txt Date: Wed, 23 Jan 2002 09:24:44 -0500 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : iSCSI EUI64-based Node Naming Author(s) : R. Grant, T. Sperry Filename : draft-grant-iscsi-eui64node-00.txt Pages : Date : 22-Jan-02 This document proposes a new method of identifying iSCSI Nodes beyond the iSCSI name. The new method uses a 64-bit field to be compatible with technologies using 64-bit identifiers such as EUI-64. These technologies include Fibre Channel and Infiniband, but may also extend to storage features such as failover, LUN-level masking or storage asset management. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-grant-iscsi-eui64node-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-grant-iscsi-eui64node-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-grant-iscsi-eui64node-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: <20020122153432.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-grant-iscsi-eui64node-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-grant-iscsi-eui64node-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020122153432.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Wed Jan 23 15:17: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 PAA23585 for ; Wed, 23 Jan 2002 15:17:22 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0NIluu18706 for ips-outgoing; Wed, 23 Jan 2002 13:47:56 -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 g0NIlrj18695 for ; Wed, 23 Jan 2002 13:47:53 -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 KAA01512 for ; Wed, 23 Jan 2002 10:47:42 -0800 (PST) Received: from aimexc02.corp.adaptec.com (aimexc02.corp.adaptec.com [162.62.62.40]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id KAA03059 for ; Wed, 23 Jan 2002 10:31:10 -0800 (PST) Received: from adaptec.com (ws10-20-142-76.corp.adaptec.com [10.20.142.76]) by aimexc02.corp.adaptec.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DPT39TPM; Wed, 23 Jan 2002 10:46:42 -0800 Message-ID: <3C4F055D.D968AF9B@adaptec.com> Date: Wed, 23 Jan 2002 10:47:57 -0800 From: Tow Wang X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI: NopIn in ping mode can contain data? References: <3C4D2F8B.8060009@yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello. For negotiation you'd use login and text commands; we have said before that targets can offer text key=value pairs out of their own initiative. I don't see your reasoning here, and can't understand your second sentence. Tow Ajit Aryan wrote: > Julo, > By this we should be able to say one thing, NOPIn in ping mode can > contain data. What every care has to be taken about the data. Now, what > should be the solicited data? In sense, the data which the initiator > could use for tuning, negotiation etc...?? > > Aryan > > Julian Satran wrote: > > > > > Rod, > > > > Initiators are usually build under the assumption that they are "in > > control" - e.g., no unsolicited data. > > Having them prepare for unsolicited data without good cause does not > > seem a good idea. > > > > Julo > > > > > > "Rod Harrison" > > > > 21-01-02 17:31 > > > > > > To: Julian Satran/Haifa/IBM@IBMIL, > > cc: > > Subject: RE: iSCSI: NopIn in ping mode can contain data? > > > > > > > > > > > > Julian, > > > > What's the reason behind preventing the target sending > > ping data? I > > would have thought it would be just as much use for a target as it is > > for an initiator. > > > > - Rod > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Julian Satran > > Sent: Saturday, January 19, 2002 3:23 PM > > To: ips@ece.cmu.edu > > Subject: Re: iSCSI: NopIn in ping mode can contain data? > > > > > > > > No data - will indicate this in 10 - Julo > > > > > > Tow Wang > > Sent by: owner-ips@ece.cmu.edu > > 16-01-02 01:10 > > > > To: ips@ece.cmu.edu > > cc: > > Subject: iSCSI: NopIn in ping mode can contain data? > > > > > > > > > > Hello everybody. > > > > 1) When a target sends out a NopIn as a ping, is it allowed to contain > > a > > data segment? > > 2) If yes, > > a) why would anyone send data along? > > b) must the initiator echo back the data? > > > > I haven't found a clear answer in draft 9. Thanks for any > > clarifications. > > -- > > Tow Wang > > Adaptec Software Engineer > > > > > > -- Tow Wang Adaptec Software Engineer Telephone: 408 957 4838 Mail stop 46 800 869 8883 x4838 691 South Milpitas Boulevard Fax: 530 686 8023 Milpitas, California 95035 E-mail: Tow_Wang@adaptec.com From owner-ips@ece.cmu.edu Wed Jan 23 16: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 QAA26381 for ; Wed, 23 Jan 2002 16:32:38 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0NKQ4A26955 for ips-outgoing; Wed, 23 Jan 2002 15:26:04 -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 g0NKQ0j26950 for ; Wed, 23 Jan 2002 15:26:02 -0500 (EST) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id 3BA762618; Wed, 23 Jan 2002 14:25:55 -0600 (CST) Received: from cceexg13.americas.cpqcorp.net (cceexg13.americas.cpqcorp.net [16.110.250.119]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 276BB24A5; Wed, 23 Jan 2002 14:25:55 -0600 (CST) Received: from cceexc18.americas.cpqcorp.net ([16.110.250.64]) by cceexg13.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 23 Jan 2002 14:25:54 -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: NopIn in ping mode can contain data? Date: Wed, 23 Jan 2002 14:25:54 -0600 Message-ID: <31891B757C09184BBFEC5275F85D5595104E19@cceexc18.americas.cpqcorp.net> Thread-Topic: iSCSI: NopIn in ping mode can contain data? Thread-Index: AcGjJgdJqvmXeih3SpqIc6/0Ev1LCwBIPoiA From: "Martin, Nick" To: Cc: X-OriginalArrivalTime: 23 Jan 2002 20:25:54.0831 (UTC) FILETIME=[289381F0:01C1A44C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g0NKQ2j26952 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Aryan, I believe you are reading too much into "data". A [NOP-Out or] NOP-In may contain a payload called "ping data", the format of which is not specified. That payload, if present is not iSCSI Data-IN "data" nor Text Response "data". If this NOP-In is a response to a NOP-Out then it is a copy (a.k.a. an echo) of the payload contained in the NOP-Out which solicited this response. This was intended as a way for an Initiator to verify that packets of a certain length can currently be successfully transmitted over this connection. The question being asked is whether a Target, which may send a NOP-In that is not a response to a NOP-Out, should be allowed to include a payload to be echoed by the Initiator. This would allow the Target to similarly test the connection with various packet lengths. The answer, now clarified in draft 10 is no, the Target may not send a NOP-In containing "ping data" except in response to a NOP-Out containing "ping data". Thanks, Nick Ajit Aryan wrote: > > > Julo, > By this we should be able to say one thing, NOPIn in ping mode can > contain data. What every care has to be taken about the data. > Now, what > should be the solicited data? In sense, the data which the initiator > could use for tuning, negotiation etc...?? > > Aryan > > Julian Satran wrote: > > > > > Rod, > > > > Initiators are usually build under the assumption that they are "in > > control" - e.g., no unsolicited data. > > Having them prepare for unsolicited data without good cause > does not > > seem a good idea. > > > > Julo > > > > > > "Rod Harrison" > > > > 21-01-02 17:31 > > > > > > To: Julian Satran/Haifa/IBM@IBMIL, > > cc: > > Subject: RE: iSCSI: NopIn in ping mode can > contain data? > > > > > > > > > > > > Julian, > > > > What's the reason behind preventing the > target sending > > ping data? I > > would have thought it would be just as much use for a > target as it is > > for an initiator. > > > > - Rod > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Julian Satran > > Sent: Saturday, January 19, 2002 3:23 PM > > To: ips@ece.cmu.edu > > Subject: Re: iSCSI: NopIn in ping mode can contain data? > > > > > > > > No data - will indicate this in 10 - Julo > > > > > > Tow Wang > > Sent by: owner-ips@ece.cmu.edu > > 16-01-02 01:10 > > > > To: ips@ece.cmu.edu > > cc: > > Subject: iSCSI: NopIn in ping mode can contain data? > > > > > > > > > > Hello everybody. > > > > 1) When a target sends out a NopIn as a ping, is it allowed > to contain > > a > > data segment? > > 2) If yes, > > a) why would anyone send data along? > > b) must the initiator echo back the data? > > > > I haven't found a clear answer in draft 9. Thanks for any > > clarifications. > > -- > > Tow Wang > > Adaptec Software Engineer > > > > > > > > > From owner-ips@ece.cmu.edu Wed Jan 23 16:43: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 QAA27024 for ; Wed, 23 Jan 2002 16:43:06 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0NLN0x01956 for ips-outgoing; Wed, 23 Jan 2002 16:23: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 g0NLMvj01942 for ; Wed, 23 Jan 2002 16:22:57 -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 g0NLMmJ17893 for ; Wed, 23 Jan 2002 16:22:48 -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 g0NLMlq20820 for ; Wed, 23 Jan 2002 16:22:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15439.10663.813000.360531@gargle.gargle.HOWL> Date: Wed, 23 Jan 2002 16:22:47 -0500 From: Paul Koning To: ips@ece.cmu.edu Subject: Error in ips-security-07 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 Page 12 of the security draft says: If an IKE implementation receives a Phase 1 Delete message for a Phase 1 Security Association bound to one or more sessions, then it SHOULD delete the associated IKE Phase 2 security associations. This directly contradicts the rules in RFC 2408 and 2409. For example, consider the description of PFS in section 8 of RFC 2409. In that discussion, the Phase 1 SA is deleted when the Phase 2 exchange is complete. The text in the security draft is based on a mistaken assumption. In fact, sessions are not bound to Phase 2 SAs in the first place -- only to Phase 2 SAs. Phase 2 SAs are not dependent on a particular Phase 1 SA, and in particular the deletion of the Phase 1 SA that was used to do a Quick Mode exchange has no effect on the Phase 2 SAs established by (completed) QM exchanges on that SA. The paragraph I quoted should be deleted. paul From owner-ips@ece.cmu.edu Wed Jan 23 16:45: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 QAA27145 for ; Wed, 23 Jan 2002 16:45:36 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0NL3uU00272 for ips-outgoing; Wed, 23 Jan 2002 16:03:56 -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 g0NL3tj00268 for ; Wed, 23 Jan 2002 16:03:55 -0500 (EST) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jan 2002 13:03:19 -0800 Message-ID: From: Charles Monia To: "Ips (E-mail)" Cc: "Franco Travostino (E-mail)" , "David Black (E-mail)" , "Elizabeth Rodriguez (E-mail)" Subject: iFCP Revision 8 Released Date: Wed, 23 Jan 2002 13:03: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 Colleagues: iFCP revision 8 was submitted to the IETF archive on 1/22/2002. Pending its availability, a copy of the text or PDF (with markups visible) can also be obtained from the T11 archive at the URLs listed below. iFCP Revision 8: ftp://ftp.t11.org/t11/member/incoming/02-023v0.txt ftp://ftp.t11.org/t11/member/incoming/02-023v0.pdf Release notes: ftp://ftp.t11.org/t11/member/incoming/02-028v0.txt ftp://ftp.t11.org/t11/member/incoming/02-028v0.pdf. After 1/24, the files will be available from: Spec: ftp://ftp.t11.org/t11/docs/02-023v0.txt ftp://ftp.t11.org/t11/docs/02-023v0.pdf Release notes: ftp://ftp.t11.org/t11/docs/02-028v0.txt ftp://ftp.t11.org/t11/docs/02-028v0.pdf. The following information is extracted from the release notes. ==================================================== These notes describe the changes incorporated in revision 8 of iFCP, including the disposition of review comments received from David Black via the IPS reflector on 11/13/01. The comments are taken verbatim from that posting, with edits where needed to fit the format of these notes. 2. New or Modified Material 2.1 Security a) Aligned the security section with version 7 of the IPS security draft. b) Added new certificate text (incorporating feedback from the ips security reflector). c) Added new text on transport mode requirements and RFC 2401 compliance. 2.2 Liveness Test Mechanism Added a liveness message (LTEST) to periodically test the state of the iFCP session from the encapsulation interface at the transmitting gateway to the de-encapsulation interface at the receiving gateway. The intent of this feature is to provide a connectivity probe for sessions, such as an iFCP broadcast session, which may be dormant for long periods of time. The heartbeat is also useful for dealing with stateful intermediate boxes, such as NAPTs or firewalls, which may delete dormant TCP/IP connections. 2.3 iFCP Fabric Types Reorganized the explanation of address translation and address transparent modes around the concept of bounded and unbounded iFCP fabric types as the basis for internetworking a collection of gateways. ........... ====================================================== 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 Jan 23 21:06: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 VAA01244 for ; Wed, 23 Jan 2002 21:06:23 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0O16jj17847 for ips-outgoing; Wed, 23 Jan 2002 20:06:45 -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 g0O16gj17840 for ; Wed, 23 Jan 2002 20:06:42 -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 g0O0AHJ18413; Wed, 23 Jan 2002 19:10:17 -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 g0O0AG327955; Wed, 23 Jan 2002 19:10:17 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15439.20713.264000.849122@gargle.gargle.HOWL> Date: Wed, 23 Jan 2002 19:10:17 -0500 From: Paul Koning To: marjorie_krueger@hp.com, ips@ece.cmu.edu Subject: RE: Error in ips-security-07 References: <6BD67FFB937FD411A04F00D0B74FE87805CCF356@xrose06.rose.hp.com> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 23 January 2002) by KRUEGER,MARJORIE (HP-Roseville,ex1): > Was this a typo?: > > > The text in the security draft is based on a mistaken assumption. In > > fact, sessions are not bound to Phase 2 SAs in the first place -- only > > to Phase 2 SAs. > ^^^^^^^ > Did you mean Phase 1 SAs? Otherwise this sentence doesn't make sense? Oops, yes, that's a typo, but not that way around. Here's what I meant: The text in the security draft is based on a mistaken assumption. In fact, sessions are not bound to Phase 1 SAs in the first place -- only to Phase 2 SAs. paul From owner-ips@ece.cmu.edu Thu Jan 24 01:55: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 BAA08181 for ; Thu, 24 Jan 2002 01:55:18 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0O5pi604127 for ips-outgoing; Thu, 24 Jan 2002 00:51:44 -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 g0O5pgj04123 for ; Thu, 24 Jan 2002 00:51:42 -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 GAA71448 for ; Thu, 24 Jan 2002 06:51: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 g0O5qan52688 for ; Thu, 24 Jan 2002 06:52:36 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: changelog ver8 to ver9 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 24 Jan 2002 07:52:45 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 24/01/2002 07:52:49, Serialize complete at 24/01/2002 07:52:49 Content-Type: multipart/alternative; boundary="=_alternative 001F61E4C2256B4B_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001F61E4C2256B4B_= Content-Type: text/plain; charset="us-ascii" We can debate for ever if 3m are equivalent or not to 0.003km. If a nuit change breaks your implementation you certainly have to look closer at it. I won't comment anymore on this noise. Julo Paul Koning 23-01-02 15:59 To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI: changelog ver8 to ver9 Excerpt of message (sent 22 January 2002) by Julian Satran: > Prasenjit, > > Should I read your statement as a question - i.e., with a why preceding it? > They where many other editorial changes that are not reflected in the log - > they have no major > significance and the change bars in the pdf file reflect them. > The new units are clearly stated everywhere. But a change in units is not an editorial change. Editorial changes are changes that affect the way things are described but not the way the implementations are coded. A change in units is a message encoding change and requires changes to implementations. paul --=_alternative 001F61E4C2256B4B_= Content-Type: text/html; charset="us-ascii"
We can debate for ever if 3m are equivalent or not to 0.003km.
If a nuit change breaks your implementation you certainly have to look closer at it.
I won't comment anymore on this noise.

Julo


Paul Koning <ni1d@arrl.net>

23-01-02 15:59

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        Re: iSCSI: changelog ver8 to ver9

       


Excerpt of message (sent 22 January 2002) by Julian Satran:
> Prasenjit,
>
> Should I read your statement as a question - i.e., with a why preceding it?
> They where many other editorial changes that are not reflected in the log -
> they have no major
> significance and the change bars in the pdf file reflect them.
> The new units are clearly stated everywhere.

But a change in units is not an editorial change.  Editorial changes
are changes that affect the way things are described but not the way
the implementations are coded.  A change in units is a message
encoding change and requires changes to implementations.

                 paul

--=_alternative 001F61E4C2256B4B_=-- From owner-ips@ece.cmu.edu Thu Jan 24 03:17: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 DAA17442 for ; Thu, 24 Jan 2002 03:17:28 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0O7U8v09166 for ips-outgoing; Thu, 24 Jan 2002 02:30:08 -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 g0O7U7j09160 for ; Thu, 24 Jan 2002 02:30:07 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jan 2002 02:25:08 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029373CC@CORPMX14> From: Black_David@emc.com To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI: changelog ver8 to ver9 Date: Thu, 24 Jan 2002 02:16:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A4A7.17538DD0" 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_01C1A4A7.17538DD0 Content-Type: text/plain; charset="iso-8859-1" Julian, Paul is right because the units aren't sent in the message - in your example if the meaning of 3 changes from 3 meters to 3 kilometers, the implementation has to be revised to send 0.003 instead of 3. This is a small change, but it is a change (not just editorial). Please add this to the change log for the next version. 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: Thursday, January 24, 2002 12:53 AM To: ips@ece.cmu.edu Subject: Re: iSCSI: changelog ver8 to ver9 We can debate for ever if 3m are equivalent or not to 0.003km. If a nuit change breaks your implementation you certainly have to look closer at it. I won't comment anymore on this noise. Julo Paul Koning 23-01-02 15:59 To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI: changelog ver8 to ver9 Excerpt of message (sent 22 January 2002) by Julian Satran: > Prasenjit, > > Should I read your statement as a question - i.e., with a why preceding it? > They where many other editorial changes that are not reflected in the log - > they have no major > significance and the change bars in the pdf file reflect them. > The new units are clearly stated everywhere. But a change in units is not an editorial change. Editorial changes are changes that affect the way things are described but not the way the implementations are coded. A change in units is a message encoding change and requires changes to implementations. paul ------_=_NextPart_001_01C1A4A7.17538DD0 Content-Type: text/html; charset="iso-8859-1"
Julian,
 
Paul is right because the units aren't sent in the message -
in your example if the meaning of 3 changes from 3 meters to
3 kilometers, the implementation has to be revised to send
0.003 instead of 3.  This is a small change, but it is a change
(not just editorial).  Please add this to the change log for
the next version.
 
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: Thursday, January 24, 2002 12:53 AM
To: ips@ece.cmu.edu
Subject: Re: iSCSI: changelog ver8 to ver9


We can debate for ever if 3m are equivalent or not to 0.003km.
If a nuit change breaks your implementation you certainly have to look closer at it.
I won't comment anymore on this noise.

Julo


Paul Koning <ni1d@arrl.net>

23-01-02 15:59

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        Re: iSCSI: changelog ver8 to ver9

       


Excerpt of message (sent 22 January 2002) by Julian Satran:
> Prasenjit,
>
> Should I read your statement as a question - i.e., with a why preceding it?
> They where many other editorial changes that are not reflected in the log -
> they have no major
> significance and the change bars in the pdf file reflect them.
> The new units are clearly stated everywhere.

But a change in units is not an editorial change.  Editorial changes
are changes that affect the way things are described but not the way
the implementations are coded.  A change in units is a message
encoding change and requires changes to implementations.

                 paul



------_=_NextPart_001_01C1A4A7.17538DD0-- From owner-ips@ece.cmu.edu Thu Jan 24 03:17: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 DAA17455 for ; Thu, 24 Jan 2002 03:17:31 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0O7MpL08786 for ips-outgoing; Thu, 24 Jan 2002 02:22:51 -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 g0O7Moj08781 for ; Thu, 24 Jan 2002 02:22:50 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jan 2002 02:17:50 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029373CB@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSCSI: Framing Steps Date: Thu, 24 Jan 2002 02:09:32 -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 want to attempt to make some steps towards resolving the framing issues. In reviewing the recent discussions on framing, I have a couple of conclusions: (1) I do not believe that WG consensus (rough or otherwise) can be obtained for a "MUST implement" requirement for any form of framing. (2) The COWS mechanism has a lot of potential, but its newness, the multiple versions that have been mentioned, and the desire for some sort of alignment with new work on DDP/RDMA suggest that COWS is premature to specify as part of iSCSI. I suggest that these conclusions form the basis for further ips WG consideration of framing. Please think carefully before objecting to these conclusions on the list (I'm happy to respond to private questions/expressions of concern). If the framing issue cannot be driven to closure in the next few weeks, I will be forced to conclude that the entire topic is experimental, and hence needs to be removed from the iSCSI specification and handled in separate drafts intended to become experimental RFCs. Thanks, --David p.s. A desire to build NICs that never behave in accordance with an important SHOULD in RFC 1122 (out-of-order segments SHOULD be queued) does not strike me as a good reason for changing the first conclusion above. --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Jan 24 04:44: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 EAA18470 for ; Thu, 24 Jan 2002 04:44:17 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0O8tUQ13484 for ips-outgoing; Thu, 24 Jan 2002 03:55:30 -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 g0O8tSj13480 for ; Thu, 24 Jan 2002 03:55:28 -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 DAA08930 for ; Thu, 24 Jan 2002 03:52:24 -0500 Received: from d03nm014.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 g0O8tRI64810 for ; Thu, 24 Jan 2002 01:55:27 -0700 X-Priority: 1 (High) Importance: Normal Subject: iSCSI:eui64node To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Thu, 24 Jan 2002 00:54:35 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 01/24/2002 01:55:26 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk This came up at the last, IETF meeting, and most folks disagreed with it. But I think it was useful to get it put into a draft form where we could respond completely. The Draft seems to confuse the NODE name with a physical HBA ID. And it is not obvious that there is a complete understanding of Multiple Connections per Session as they apply across HBAs (Portals). I think you were trying to make sure that the WWNN was unique across the different Gateways, but since it includes a eui that has a vendor ID, you must be worried about Gateways from the same vendor. (which I also do not see as a problem which others should worry about). In any event I did not fully understand the problem, and the solution was even less clear. Anyway somehow you are trying to make iSCSI node name be a name of an adapter, and we took many pains to absolutely avoid that. I also did not understand in your negotiation examples. What you are asking for is iSCSI Initiators to have a 64bit name on top of the 48 bit ISID and the long REAL node name that can be 255 Bytes long. Just so some gateway does not coordinate with its partner Gateway. That means that either ALL HBAs and iSCSI Device Drivers must deal with this total name, just in case there is a non coordinating Gateway in the middle some where. This does not seem like a good idea to me. . . . 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 Thu Jan 24 11:59:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27248 for ; Thu, 24 Jan 2002 11:59:37 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0OGQLC21502 for ips-outgoing; Thu, 24 Jan 2002 11:26:21 -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 g0OFEVj15549 for ; Thu, 24 Jan 2002 10:14:31 -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 KAA23227; Thu, 24 Jan 2002 10:14:27 -0500 (EST) Message-Id: <200201241514.KAA23227@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-ifcp-08.txt Date: Thu, 24 Jan 2002 10:14:26 -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 : iFCP - A Protocol for Internet Fibre Channel Storage Networking Author(s) : C. Monia et al. Filename : draft-ietf-ips-ifcp-08.txt Pages : 98 Date : 23-Jan-02 This document specifies an architecture and gateway-to-gateway protocol for the implementation of Fibre Channel fabric functionality on a network in which TCP/IP switching and routing elements replace Fibre Channel components. The protocol enables the attachment of Fibre Channel devices to an IP network by supporting the fabric services required by such devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-ifcp-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-ifcp-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-ifcp-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: <20020123143122.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-ifcp-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-ifcp-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020123143122.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Thu Jan 24 12:09: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 MAA27685 for ; Thu, 24 Jan 2002 12:09:01 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0OGQ7e21468 for ips-outgoing; Thu, 24 Jan 2002 11:26:07 -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 g0OFEHj15508 for ; Thu, 24 Jan 2002 10:14:18 -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 KAA23161; Thu, 24 Jan 2002 10:14:14 -0500 (EST) Message-Id: <200201241514.KAA23161@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-fcmgmt-mib-00.txt Date: Thu, 24 Jan 2002 10:14:13 -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 : Fibre Channel Management MIB Author(s) : K. McCloghrie Filename : draft-ietf-ips-fcmgmt-mib-00.txt Pages : 64 Date : 23-Jan-02 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for informantion related to Fibre Channel. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcmgmt-mib-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-ietf-ips-fcmgmt-mib-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-ietf-ips-fcmgmt-mib-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: <20020123143057.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-fcmgmt-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-fcmgmt-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020123143057.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Thu Jan 24 12:16: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 MAA28162 for ; Thu, 24 Jan 2002 12:16:47 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0OFU8816924 for ips-outgoing; Thu, 24 Jan 2002 10:30:08 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0OFU6j16920 for ; Thu, 24 Jan 2002 10:30:06 -0500 (EST) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.28 2002/01/02 21:40:45 root Exp $) with ESMTP id g0OFTZb26409 for ; Thu, 24 Jan 2002 15:29:35 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.11 2001/11/09 23:28:01 root Exp $) with SMTP id g0OFTTi21327 for ; Thu, 24 Jan 2002 15:29:29 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002012407292524302 ; Thu, 24 Jan 2002 07:29:25 -0800 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jan 2002 07:29:54 -0800 Message-ID: <25282B06EFB8D31198BF00508B66D4FA1501ED@fmsmsx114.fm.intel.com> From: "Shah, Hemal" To: "'Black_David@emc.com'" , ips@ece.cmu.edu Subject: RE: iSCSI: Framing Steps Date: Thu, 24 Jan 2002 07:29:52 -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 David, I agree with your conclusions. I would like to add something related to framing. Framing by itself solves only part of the problem from the perspective of sync and steering. I am not going to summarize pro/cons of each framing proposal here as they have been summarized in the previously posted emails. I would add though that all different forms of framing proposals put some sort of aritificial limitation on max. iSCSI PDU size - TUF requires an iSCSI PDU to be contained within Framing PDU - FIM & COWS require iSCSI PDU reassembly buffer in case of a packet loss (Thus, amount of buffering on NIC/HBA dictates max. iSCSI PDU size) In addition to framing, you definitely need some sort of steering mechanism that completely eliminates reassembly buffers on NIC and does not put any artificial limitation on Max. iSCSI PDU size. If this steering layer is generic (DDP/RDMA), then the NIC/HBA now has wider applicability. In my opinion, until sync and steering layers related issues are resolved, framing/DDP/RDMA are premature at this point to be included in iSCSI 1.0 draft. Hemal -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Thursday, January 24, 2002 1:10 AM To: ips@ece.cmu.edu Subject: iSCSI: Framing Steps I want to attempt to make some steps towards resolving the framing issues. In reviewing the recent discussions on framing, I have a couple of conclusions: (1) I do not believe that WG consensus (rough or otherwise) can be obtained for a "MUST implement" requirement for any form of framing. (2) The COWS mechanism has a lot of potential, but its newness, the multiple versions that have been mentioned, and the desire for some sort of alignment with new work on DDP/RDMA suggest that COWS is premature to specify as part of iSCSI. I suggest that these conclusions form the basis for further ips WG consideration of framing. Please think carefully before objecting to these conclusions on the list (I'm happy to respond to private questions/expressions of concern). If the framing issue cannot be driven to closure in the next few weeks, I will be forced to conclude that the entire topic is experimental, and hence needs to be removed from the iSCSI specification and handled in separate drafts intended to become experimental RFCs. Thanks, --David p.s. A desire to build NICs that never behave in accordance with an important SHOULD in RFC 1122 (out-of-order segments SHOULD be queued) does not strike me as a good reason for changing the first conclusion above. --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Jan 24 12:30: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 MAA28583 for ; Thu, 24 Jan 2002 12:30:46 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0OGQFp21488 for ips-outgoing; Thu, 24 Jan 2002 11:26:15 -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 g0OFEPj15533 for ; Thu, 24 Jan 2002 10:14:26 -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 KAA23205; Thu, 24 Jan 2002 10:14:22 -0500 (EST) Message-Id: <200201241514.KAA23205@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-iscsi-string-prep-00.txt Date: Thu, 24 Jan 2002 10:14:21 -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 : String Profile for iSCSI Names Author(s) : M. Bakke Filename : draft-ietf-ips-iscsi-string-prep-00.txt Pages : 50 Date : 23-Jan-02 The iSCSI protocol provides a way for hosts to access SCSI devices over an IP network. The iSCSI end-points, called initiators and targets, each have a globally-unique name that must be transcribable, as well as easily compared. This document describes how to prepare internationlized iSCSI names to increase the likelihood that name input and comparison work in ways that make sense for typical users throughout the world. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-string-prep-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-ietf-ips-iscsi-string-prep-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-ietf-ips-iscsi-string-prep-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: <20020123143111.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-string-prep-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-string-prep-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020123143111.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Thu Jan 24 12:37: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 MAA28785 for ; Thu, 24 Jan 2002 12:37:57 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0OGQCe21480 for ips-outgoing; Thu, 24 Jan 2002 11:26:12 -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 g0OFEDj15493 for ; Thu, 24 Jan 2002 10:14:23 -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 KAA23141; Thu, 24 Jan 2002 10:14:09 -0500 (EST) Message-Id: <200201241514.KAA23141@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-fcip-mib-01.txt Date: Thu, 24 Jan 2002 10:14:08 -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 FCIP Author(s) : S. Akkala et al. Filename : draft-ietf-ips-fcip-mib-01.txt Pages : Date : 23-Jan-02 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing a FCIP device, as defined in [FCIP]. This MIB is defined such that it can be viewed as an extension to the existing FC Management Framework Integration MIB, as specified in [FCMGMT]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-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-fcip-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-fcip-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: <20020123143047.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-fcip-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-fcip-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020123143047.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Thu Jan 24 13:56: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 NAA02162 for ; Thu, 24 Jan 2002 13:56:18 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0OHTtj26690 for ips-outgoing; Thu, 24 Jan 2002 12:29:55 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f220.law12.hotmail.com [64.4.19.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0O0SWj15373 for ; Wed, 23 Jan 2002 19:28:37 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 23 Jan 2002 16:28:26 -0800 Received: from 168.103.93.57 by lw12fd.law12.hotmail.msn.com with HTTP; Thu, 24 Jan 2002 00:28:26 GMT X-Originating-IP: [168.103.93.57] From: "Deen Jiee" To: ips@ece.cmu.edu Subject: unsubscribe Date: Wed, 23 Jan 2002 16:28:26 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 24 Jan 2002 00:28:26.0965 (UTC) FILETIME=[0A52F050:01C1A46E] Sender: owner-ips@ece.cmu.edu Precedence: bulk unsubscribe _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From owner-ips@ece.cmu.edu Thu Jan 24 14: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 OAA02296 for ; Thu, 24 Jan 2002 14:00:06 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0OHqkm28463 for ips-outgoing; Thu, 24 Jan 2002 12:52:46 -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 g0OHqhj28455 for ; Thu, 24 Jan 2002 12:52:43 -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 SAA106784 for ; Thu, 24 Jan 2002 18:52:37 +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 g0OHrYn152560 for ; Thu, 24 Jan 2002 18:53:37 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: NopIn in ping mode can contain data? X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 24 Jan 2002 19:53:42 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 24/01/2002 19:53:49, Serialize complete at 24/01/2002 19:53:49 Content-Type: multipart/alternative; boundary="=_alternative 0029679DC2256B4B_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0029679DC2256B4B_= Content-Type: text/plain; charset="us-ascii" Within an exchane - everytthing an initiator sees is sollicited and expected. Julo ----- Forwarded by Julian Satran/Haifa/IBM on 24-01-02 09:31 ----- Tow Wang Sent by: owner-ips@ece.cmu.edu 23-01-02 20:47 To: ips@ece.cmu.edu cc: Subject: Re: iSCSI: NopIn in ping mode can contain data? Hello. For negotiation you'd use login and text commands; we have said before that targets can offer text key=value pairs out of their own initiative. I don't see your reasoning here, and can't understand your second sentence. Tow Ajit Aryan wrote: > Julo, > By this we should be able to say one thing, NOPIn in ping mode can > contain data. What every care has to be taken about the data. Now, what > should be the solicited data? In sense, the data which the initiator > could use for tuning, negotiation etc...?? > > Aryan > > Julian Satran wrote: > > > > > Rod, > > > > Initiators are usually build under the assumption that they are "in > > control" - e.g., no unsolicited data. > > Having them prepare for unsolicited data without good cause does not > > seem a good idea. > > > > Julo > > > > > > "Rod Harrison" > > > > 21-01-02 17:31 > > > > > > To: Julian Satran/Haifa/IBM@IBMIL, > > cc: > > Subject: RE: iSCSI: NopIn in ping mode can contain data? > > > > > > > > > > > > Julian, > > > > What's the reason behind preventing the target sending > > ping data? I > > would have thought it would be just as much use for a target as it is > > for an initiator. > > > > - Rod > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Julian Satran > > Sent: Saturday, January 19, 2002 3:23 PM > > To: ips@ece.cmu.edu > > Subject: Re: iSCSI: NopIn in ping mode can contain data? > > > > > > > > No data - will indicate this in 10 - Julo > > > > > > Tow Wang > > Sent by: owner-ips@ece.cmu.edu > > 16-01-02 01:10 > > > > To: ips@ece.cmu.edu > > cc: > > Subject: iSCSI: NopIn in ping mode can contain data? > > > > > > > > > > Hello everybody. > > > > 1) When a target sends out a NopIn as a ping, is it allowed to contain > > a > > data segment? > > 2) If yes, > > a) why would anyone send data along? > > b) must the initiator echo back the data? > > > > I haven't found a clear answer in draft 9. Thanks for any > > clarifications. > > -- > > Tow Wang > > Adaptec Software Engineer > > > > > > -- Tow Wang Adaptec Software Engineer Telephone: 408 957 4838 Mail stop 46 800 869 8883 x4838 691 South Milpitas Boulevard Fax: 530 686 8023 Milpitas, California 95035 E-mail: Tow_Wang@adaptec.com --=_alternative 0029679DC2256B4B_= Content-Type: text/html; charset="us-ascii"
Within an exchane - everytthing an initiator sees is sollicited and expected. Julo
----- Forwarded by Julian Satran/Haifa/IBM on 24-01-02 09:31 -----
Tow Wang <Tow_Wang@adaptec.com>
Sent by: owner-ips@ece.cmu.edu

23-01-02 20:47

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        Re: iSCSI: NopIn in ping mode can contain data?

       


Hello.

For negotiation you'd use login and text commands; we have said before that
targets can offer text key=value pairs out of their own initiative.

I don't see your reasoning here, and can't understand your second sentence.

Tow

Ajit Aryan wrote:

> Julo,
> By this we should be able to say one thing, NOPIn in ping mode can
> contain data. What every care has to be taken about the data. Now, what
> should be the solicited data? In sense, the data which the initiator
> could use for tuning, negotiation etc...??
>
> Aryan
>
> Julian Satran wrote:
>
> >
> > Rod,
> >
> > Initiators are usually build under the assumption that they are "in
> > control" - e.g., no unsolicited data.
> > Having them prepare for unsolicited data without good cause does not
> > seem a good idea.
> >
> > Julo
> >
> >
> > "Rod Harrison" <rod.harrison@windriver.com>
> >
> > 21-01-02 17:31
> >
> >
> >         To:        Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>
> >         cc:
> >         Subject:        RE: iSCSI: NopIn in ping mode can contain data?
> >
> >
> >
> >
> >
> > Julian,
> >
> >                 What's the reason behind preventing the target sending
> > ping data? I
> > would have thought it would be just as much use for a target as it is
> > for an initiator.
> >
> >                 - Rod
> >
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > Julian Satran
> > Sent: Saturday, January 19, 2002 3:23 PM
> > To: ips@ece.cmu.edu
> > Subject: Re: iSCSI: NopIn in ping mode can contain data?
> >
> >
> >
> > No  data - will indicate this in 10 - Julo
> >
> >
> > Tow Wang <Tow_Wang@adaptec.com>
> > Sent by: owner-ips@ece.cmu.edu
> > 16-01-02 01:10
> >
> >        To:        ips@ece.cmu.edu
> >        cc:
> >        Subject:        iSCSI: NopIn in ping mode can contain data?
> >
> >
> >
> >
> > Hello everybody.
> >
> > 1) When a target sends out a NopIn as a ping, is it allowed to contain
> > a
> > data segment?
> > 2) If yes,
> >   a) why would anyone send data along?
> >   b) must the initiator echo back the data?
> >
> > I haven't found a clear answer in draft 9. Thanks for any
> > clarifications.
> > --
> > Tow Wang
> > Adaptec Software Engineer
> >
> >
> >

--
Tow Wang
Adaptec Software Engineer       Telephone: 408 957 4838
Mail stop 46                               800 869 8883 x4838
691 South Milpitas Boulevard    Fax:       530 686 8023
Milpitas, California 95035      E-mail:    Tow_Wang@adaptec.com

--=_alternative 0029679DC2256B4B_=-- From owner-ips@ece.cmu.edu Thu Jan 24 18:28: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 SAA09656 for ; Thu, 24 Jan 2002 18:28:20 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0OMDTB21127 for ips-outgoing; Thu, 24 Jan 2002 17:13:29 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from fw.hel.fi.ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0OMDQj21122 for ; Thu, 24 Jan 2002 17:13:27 -0500 (EST) Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.27) with SMTP id g0OMDLf00760 for ; Fri, 25 Jan 2002 00:13:21 +0200 (EET) Received: (qmail 21522 invoked from network); 24 Jan 2002 22:13:20 -0000 Received: from unknown (HELO sshb3qf0i5anf6) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 24 Jan 2002 22:13:20 -0000 Message-ID: <010301c1a524$54cfba30$65c2210a@sshb3qf0i5anf6> Reply-To: "Jussi Kukkonen" From: "Jussi Kukkonen" To: Cc: "Vaishali Deshpande" Subject: iSCSI + IPsec ? Date: Thu, 24 Jan 2002 14:13: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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit We (SSH Communications) are following the developements of IP storage industry closely. Our interest is delivering security components that go with storage protocol implementations. Are there any IP storage industry forums where vendors would already be testing with integrated iSCSI + IPsec stacks? Jussi Kukkonen Technical Product Manager (IPsec OEM Toolkit) SSH Communications Security www.ssh.com From owner-ips@ece.cmu.edu Thu Jan 24 18:34:25 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09839 for ; Thu, 24 Jan 2002 18:34:24 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0OMXiM22725 for ips-outgoing; Thu, 24 Jan 2002 17:33: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 g0OMXgj22720 for ; Thu, 24 Jan 2002 17:33:42 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jan 2002 17:33:41 -0500 Message-ID: <25369470B6F0D41194820002B328BDD2202522@ATLOPS> From: Eddy Quicksall To: "julian_satran@il. ibm. com (E-mail)" , "ips@ece. cmu. edu (E-mail)" Subject: iSCSI: keys allowed during security stage Date: Thu, 24 Jan 2002 17:33:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A527.2ADFEB70" 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_01C1A527.2ADFEB70 Content-Type: text/plain; charset="iso-8859-1" Julian, What would you think about putting a list of keys that are allowed during security stage in Section 11? The reason I ask this is because currently you have to read through each key to figure that out. I think the only keys allowed during security stage are: SessionType InitiatorName TargetName AuthMethod And all keys listed under AuthMethod along with all of their associated keys. If you don't want to list them, can you please confirm that I am correct above (e.g., HeaderDigest is not allowed in security stage)? Eddy ------_=_NextPart_001_01C1A527.2ADFEB70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Julian,

 

=

What would you think about putting a list of keys that are allowed during = security stage in Section 11? The reason I ask this is because currently you = have to read through each key to figure that = out.

 

=

I think the only keys allowed during security stage = are:

 

=

SessionType=

InitiatorName

TargetName<= /font>

AuthMethod<= /font>

And all keys listed under AuthMethod along with all of their associated = keys.

 

=

If you don’t want to list them, can you please confirm that I am = correct above (e.g., HeaderDigest is not allowed in security = stage)?

 

=

Eddy=

------_=_NextPart_001_01C1A527.2ADFEB70-- From owner-ips@ece.cmu.edu Thu Jan 24 20:12: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 UAA11139 for ; Thu, 24 Jan 2002 20:12:26 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0P0Ahk29097 for ips-outgoing; Thu, 24 Jan 2002 19:10:43 -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 g0P0AZj29086 for ; Thu, 24 Jan 2002 19:10:40 -0500 (EST) Received: from amirdesktop (dhcp62 [172.21.2.62]) by astutenetworks.com (8.11.6/8.11.2) with SMTP id g0P0AP609402 for ; Thu, 24 Jan 2002 16:10:25 -0800 From: "Amir Shalit" To: "ips@ece. cmu. edu \(E-mail\)" Subject: SCSI Format/Copy CDB support Date: Thu, 24 Jan 2002 16:10:23 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0062_01C1A4F1.A0BAB9F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <25369470B6F0D41194820002B328BDD2202522@ATLOPS> Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0062_01C1A4F1.A0BAB9F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I see a few problems in implementing the format/copy commands over iSCSI 1) CmdSN may wrap between command and response (assuming multiple LUNs) 2) iSCSI keepalive NOPs may be required to keep the connection open during format ------=_NextPart_000_0062_01C1A4F1.A0BAB9F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I see=20 a few problems in implementing the format/copy commands over=20 iSCSI
 
1)=20 CmdSN may wrap between command and response (assuming multiple=20 LUNs)
 
2)=20 iSCSI keepalive NOPs may be required to keep the connection open during = format=20  
 
------=_NextPart_000_0062_01C1A4F1.A0BAB9F0-- From owner-ips@ece.cmu.edu Thu Jan 24 20:26:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11319 for ; Thu, 24 Jan 2002 20:26:31 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0P0jE801202 for ips-outgoing; Thu, 24 Jan 2002 19:45:14 -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 g0P0jDj01198 for ; Thu, 24 Jan 2002 19:45:13 -0500 (EST) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jan 2002 16:44:33 -0800 Received: from ece.cmu.edu ([128.2.136.200]) by ariel.nishansystems.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZG036DF3; Wed, 23 Jan 2002 13:35:40 -0800 Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0NL3uU00272 for ips-outgoing; Wed, 23 Jan 2002 16:03:56 -0500 (EST) 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 g0NL3tj00268 for ; Wed, 23 Jan 2002 16:03:55 -0500 (EST) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jan 2002 13:03:19 -0800 Message-ID: From: Charles Monia To: "Ips (E-mail)" Cc: "Franco Travostino (E-mail)" , "David Black (E-mail)" , "Elizabeth Rodriguez (E-mail)" Subject: iFCP Revision 9 Date: Thu, 24 Jan 2002 16:44:33 -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 Colleagues: This note announces the submission of iFCP revision 9 to the IETF archive. This version corrects editorial errors in revision 8, some of which are terminology changes that were not properly reflected throughout the document. Since this version is otherwise technically complete, it was felt that a revision to eliminate inconsistent, incorrect or obsolete terms was essential. Pending the announcement of availability from the IETF archive, this revision can be obtained from: ftp://ftp.t11.org/t11/member/incoming/02-023v1.txt ftp://ftp.t11.org/t11/member/incoming/02-023v1.pdf -- version with markups visible The release notes are archived at: ftp://ftp.t11.org/t11/docs/02-028v0.txt ftp://ftp.t11.org/t11/docs/02-028v0.pdf. After 1/25, iFCP will be available from: ftp://ftp.t11.org/t11/docs/02-023v1.txt ftp://ftp.t11.org/t11/docs/02-023v1.pdf 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 Fri Jan 25 01:58: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 BAA17867 for ; Fri, 25 Jan 2002 01:58:00 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0P68Cb20987 for ips-outgoing; Fri, 25 Jan 2002 01:08: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 g0P68Aj20981 for ; Fri, 25 Jan 2002 01:08:10 -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 HAA08292; Fri, 25 Jan 2002 07:08:03 +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 g0P68sL133060; Fri, 25 Jan 2002 07:09:04 +0100 Subject: Re: Login Command Clarification To: "Fischer, Michael" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Fri, 25 Jan 2002 07:43:25 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 25/01/2002 08:09:17 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Michael, Both min and max are in flux (the 1.0 release will probably have 1 (or 10?). They where meant for the initiator parties to indicate the range it supports and the target select (probably the highest). However if an initiator gives out a range and the target selects a number that is not the highest - it may do so (like when it wants to expose a new and unstable version only to those initiators that do not support an older version). Julo "Fischer, Michael" cc: Subject: Login Command Clarification 24-01-02 22:40 Julian, I have a question about Version-Max and Version-Min in the Login Request PDU. The way I understand it is that Spec Max Min <= .6 1 1 .6, .8 2 <= 2 >= .9 3 <= 3 But I have had discussions with others that indicate that Version-Max should still be 1 since the spec does not specify it. Their argument is that the version information is specified in the version-min section of the spec only. Please clarify. Thank you, Michael Fischer michael_fischer@adaptec.com From owner-ips@ece.cmu.edu Fri Jan 25 04:02: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 EAA27360 for ; Fri, 25 Jan 2002 04:02:29 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0P89It27267 for ips-outgoing; Fri, 25 Jan 2002 03:09:18 -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 g0P89Fj27262 for ; Fri, 25 Jan 2002 03:09:16 -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 g0P85Yc15707 for ; Fri, 25 Jan 2002 00:05:34 -0800 (PST) Received: from vxindia.veritas.com(revati.vxindia.veritas.com[202.41.69.12]) (9947 bytes) by megami.veritas.com via sendmail with P:esmtp/R:smart_host/T:smtp (sender: ) id for ; Fri, 25 Jan 2002 00:09:09 -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 NAA15444 for ; Fri, 25 Jan 2002 13:38:34 +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 NAA15385 for ; Fri, 25 Jan 2002 13:46:38 -0530 (GMT) Message-ID: <002501c1a578$0530fe40$3b50d40a@vxindia.veritas.com> From: "Rahul Bhagwat" To: Subject: Fw: Session state and Text Sequence Date: Fri, 25 Jan 2002 13:42:23 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01C1A5A6.1E9526D0" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C1A5A6.1E9526D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, In the v10 specification, I think there is a problem in explanation of = connection state transition T6 for target which reads "target: Timed out waiting for an iSCSI Login, or=20 transport disconnect indication was received, or=20 transport reset was received, or an internal event=20 indicating a transport timeout was received, or an=20 internal event of sending a Logout response (suc- cess) on another connection for a close the ses- sion Logout command was received. In all these=20 cases, the connection is to be closed." The part of the statement "on another connection for a close the session Logout command was received" does not seem correct. T6 change happens only when target is in S3 (XPT_UP) state. In this state, the connection cannot belong to any session and must not be closed. In a specific case, if there was only one initiator and one session, (which means that the connection was actually intended for the session being logged out) the connection can probably get closed due to login timeout at target side or initiator explicitly closing it. Please let me know if this is correct. Regards, Rahul ----- Original Message -----=20 From: Rahul Bhagwat=20 To: ips@ece.cmu.edu=20 Sent: Wednesday, December 05, 2001 2:53 PM Subject: Session state and Text Sequence Hi, I have two questions here 1. The description for Q2 state for Session says "at least one = connection" "is XPT_UP" A connection goes in XPT_UP state means that only the TCP connection is established and no login PDU is received. =20 In this state, it is not possible for a connection to belong to any = session as such (It is possible only after receiving the first login PDU = which means the connection goes into IN_LOGIN state. So the description for Q2 state should be "at least one connection = is=20 IN_LOGIN"=20 2. The specification says that it is possible to split a key value pair = across multiple Text PDUs. Consider a case where only one key value pair is to be sent by the = initiator. How should the target respond to it ? Is the following valid = request-response sequence in that case I -> T Text Request with partial key=3Dvalue pair F=3D0 T -> I Text Response empty F=3D1 I -> T Text Request with remaining key=3Dvalue pair F=3D1 T -> I Text Response for the key=3Dvalue pair F=3D1. Regards, Rahul ------=_NextPart_000_0022_01C1A5A6.1E9526D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
In the v10 specification, I think there = is a=20 problem in explanation of connection state
transition T6 for target which = reads
"target: Timed out waiting for an iSCSI = Login,=20 or 
          &= nbsp;=20 transport disconnect indication was received,=20 or 
          &= nbsp;=20 transport reset was received, or an internal=20 event 
         &nbs= p; =20 indicating a transport timeout was received, or=20 an 
          &= nbsp;=20 internal event of sending a Logout response=20 (suc-
           = cess) on=20 another connection for a  close the=20 ses-
           = sion =20 Logout command was received. In all=20 these 
         &nbs= p;=20 cases, the connection is to be closed."
 
The part of the statement "on another = connection=20 for a close the
session Logout command was received" = does not seem=20 correct.
 
T6 change happens only when target is = in S3=20 (XPT_UP) state.
In this state, the connection cannot = belong to any=20 session and
must not be closed.
In a specific case, if there was only = one initiator=20 and one session,
(which means that the connection was = actually=20 intended for the
session being logged out) the = connection can=20 probably get closed
due to login timeout at target side or initiator explicitly closing it.
 
Please let me know if this is = correct.
 
Regards,
Rahul
 
 
----- Original Message -----=20
From: Rahul = Bhagwat=20
Sent: Wednesday, December 05, 2001 2:53 PM
Subject: Session state and Text Sequence

Hi,
 
I have two questions here
 
1. The description for Q2 state for = Session says=20 "at least one connection"
    "is = XPT_UP"
 
    A connection goes in = XPT_UP=20 state means that only the TCP connection
    is established and = no login PDU=20 is received.
   
    In this state, it is = not=20 possible for a connection to belong to any session
    as such (It is = possible only=20 after receiving the first login PDU which means
    the connection = goes into=20 IN_LOGIN state.
 
    So the description = for Q2 state=20 should be "at least one connection is
    IN_LOGIN" =
 
 
2. The specification says that it is = possible to=20 split a key value pair across
    multiple Text = PDUs.
 
    Consider a case = where only one=20 key value pair is to be sent by the initiator.
    How should the = target respond to=20 it ? Is the following valid request-response
    sequence in that=20 case
 
    I  -> = T  Text=20 Request with partial key=3Dvalue pair F=3D0
    T -> = I   Text=20 Response empty F=3D1
    I  -> = T  Text=20 Request with remaining key=3Dvalue pair F=3D1
    T -> = I   Text=20 Response for the key=3Dvalue pair F=3D1.
 
Regards,
Rahul
------=_NextPart_000_0022_01C1A5A6.1E9526D0-- From owner-ips@ece.cmu.edu Fri Jan 25 04:37: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 EAA27730 for ; Fri, 25 Jan 2002 04:37:58 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0P8nMd29343 for ips-outgoing; Fri, 25 Jan 2002 03:49:22 -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 g0P8nKj29335; Fri, 25 Jan 2002 03:49:20 -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 JAA17676; Fri, 25 Jan 2002 09:49:03 +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 g0P8nx0129364; Fri, 25 Jan 2002 09:50:05 +0100 To: "Jussi Kukkonen" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu, "Vaishali Deshpande" MIME-Version: 1.0 Subject: Re: iSCSI + IPsec ? X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 25 Jan 2002 10:50:04 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 25/01/2002 10:50:17, Serialize complete at 25/01/2002 10:50:17 Content-Type: multipart/alternative; boundary="=_alternative 002FF392C2256B4C_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 002FF392C2256B4C_= Content-Type: text/plain; charset="us-ascii" You may want to try the upcoming plugfest at the University of NewHampshire. Julo "Jussi Kukkonen" Sent by: owner-ips@ece.cmu.edu 25-01-02 00:13 Please respond to "Jussi Kukkonen" To: cc: "Vaishali Deshpande" Subject: iSCSI + IPsec ? We (SSH Communications) are following the developements of IP storage industry closely. Our interest is delivering security components that go with storage protocol implementations. Are there any IP storage industry forums where vendors would already be testing with integrated iSCSI + IPsec stacks? Jussi Kukkonen Technical Product Manager (IPsec OEM Toolkit) SSH Communications Security www.ssh.com --=_alternative 002FF392C2256B4C_= Content-Type: text/html; charset="us-ascii"
You may want to try the upcoming plugfest at the University of NewHampshire. Julo


"Jussi Kukkonen" <kukkonen@ssh.com>
Sent by: owner-ips@ece.cmu.edu

25-01-02 00:13
Please respond to "Jussi Kukkonen"

       
        To:        <ips@ece.cmu.edu>
        cc:        "Vaishali Deshpande" <vdeshpande@ssh.com>
        Subject:        iSCSI + IPsec ?

       


We (SSH Communications) are following the developements of
IP storage industry closely. Our interest is delivering security
components that go with storage protocol implementations.

Are there any IP storage industry forums where vendors would
already be testing with integrated iSCSI + IPsec stacks?


Jussi Kukkonen
Technical Product Manager (IPsec OEM Toolkit)
SSH Communications Security
www.ssh.com

--=_alternative 002FF392C2256B4C_=-- From owner-ips@ece.cmu.edu Fri Jan 25 04:41: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 EAA27798 for ; Fri, 25 Jan 2002 04:41:18 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0P8nGf29318 for ips-outgoing; Fri, 25 Jan 2002 03:49:16 -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 g0P8nEj29313 for ; Fri, 25 Jan 2002 03:49:14 -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 JAA134904; Fri, 25 Jan 2002 09:49: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 g0P8o00161824; Fri, 25 Jan 2002 09:50:11 +0100 To: Eddy Quicksall Cc: "ips@ece. cmu. edu (E-mail)" MIME-Version: 1.0 Subject: Re: iSCSI: keys allowed during security stage X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 25 Jan 2002 10:50:06 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 25/01/2002 10:50:21, Serialize complete at 25/01/2002 10:50:21 Content-Type: multipart/alternative; boundary="=_alternative 00306276C2256B4C_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00306276C2256B4C_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable you are correct - I will consider the list. Julo Eddy Quicksall 25-01-02 00:33 =20 To: Julian Satran/Haifa/IBM@IBMIL, "ips@ece. cmu. edu (E-mail)"= =20 cc:=20 Subject: iSCSI: keys allowed during security stage =20 Julian, =20 What would you think about putting a list of keys that are allowed during=20 security stage in Section 11? The reason I ask this is because currently=20 you have to read through each key to figure that out. =20 I think the only keys allowed during security stage are: =20 SessionType InitiatorName TargetName AuthMethod And all keys listed under AuthMethod along with all of their associated=20 keys. =20 If you don't want to list them, can you please confirm that I am correct=20 above (e.g., HeaderDigest is not allowed in security stage)? =20 Eddy --=_alternative 00306276C2256B4C_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
you are correct - I will consider th= e list. Julo


Eddy Quicksall <Eddy=5FQuicksa= ll@ivivity.com>

25-01-02 00:33

       
        To: &nbs= p;      Julian Satran/Haifa/IBM@IBMIL, "ips@ece. cmu. e= du (E-mail)" <ips@ece.cmu.edu>
        cc: &nbs= p;      
        Subject:=        iSCSI: keys allowed during security stage

       


Julian,

 

What would you think about putting a list = of keys that are allowed during security stage in Section 11? The reason I = ask this is because currently you have to read through each key to figure t= hat out.

 

I think the only keys allowed during secur= ity stage are:

 

SessionType

InitiatorName

TargetName

AuthMethod

And all keys listed under AuthMethod along= with all of their associated keys.

 

If you don't want to list them, can you pl= ease confirm that I am correct above (e.g., HeaderDigest is not allowed in = security stage)?

 

Eddy

--=_alternative 00306276C2256B4C_=-- From owner-ips@ece.cmu.edu Fri Jan 25 04:44: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 EAA27883 for ; Fri, 25 Jan 2002 04:44:40 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0P9MMI01110 for ips-outgoing; Fri, 25 Jan 2002 04:22:22 -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 g0P9MGj01100; Fri, 25 Jan 2002 04:22:16 -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 KAA25508; Fri, 25 Jan 2002 10:20:35 +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 g0P9L5L39518; Fri, 25 Jan 2002 10:21:17 +0100 To: "Amir Shalit" Cc: "ips@ece. cmu. edu \(E-mail\)" , owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: SCSI Format/Copy CDB support X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 25 Jan 2002 11:21:14 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 25/01/2002 11:21:30, Serialize complete at 25/01/2002 11:21:30 Content-Type: multipart/alternative; boundary="=_alternative 003325ABC2256B4C_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 003325ABC2256B4C_= Content-Type: text/plain; charset="us-ascii" Amir, The draft says in several places that CmdSN is not important after the task gets to SCSI. On 2 yes you might be right but that is purely an implementation issue. Format commands do not time-out at SCSI level and iSCSI has no cause to e "nervous" - nothing is expected. Julo "Amir Shalit" Sent by: owner-ips@ece.cmu.edu 25-01-02 02:10 To: "ips@ece. cmu. edu \(E-mail\)" cc: Subject: SCSI Format/Copy CDB support I see a few problems in implementing the format/copy commands over iSCSI 1) CmdSN may wrap between command and response (assuming multiple LUNs) 2) iSCSI keepalive NOPs may be required to keep the connection open during format --=_alternative 003325ABC2256B4C_= Content-Type: text/html; charset="us-ascii"
Amir,

The draft says in several places that CmdSN is not important after the task gets to SCSI.
On 2 yes you might be right but that is purely an implementation issue. Format commands do not time-out
at SCSI level and iSCSI has no cause to e "nervous" - nothing is expected.


Julo




"Amir Shalit" <amir@astutenetworks.com>
Sent by: owner-ips@ece.cmu.edu

25-01-02 02:10

       
        To:        "ips@ece. cmu. edu \(E-mail\)" <ips@ece.cmu.edu>
        cc:        
        Subject:        SCSI Format/Copy CDB support

       


I see a few problems in implementing the format/copy commands over iSCSI
 
1) CmdSN may wrap between command and response (assuming multiple LUNs)
 
2) iSCSI keepalive NOPs may be required to keep the connection open during format  
 

--=_alternative 003325ABC2256B4C_=-- From owner-ips@ece.cmu.edu Fri Jan 25 07:23: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 HAA00183 for ; Fri, 25 Jan 2002 07:23:08 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0PBD5w17597 for ips-outgoing; Fri, 25 Jan 2002 06:13:05 -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 g0PBD3j17592 for ; Fri, 25 Jan 2002 06:13:04 -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 MAA27966 for ; Fri, 25 Jan 2002 12:12:56 +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 g0PBDsL166976 for ; Fri, 25 Jan 2002 12:13:57 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: keys allowed during security stage X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 25 Jan 2002 13:14:04 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 25/01/2002 13:14:10, Serialize complete at 25/01/2002 13:14:10 Content-Type: multipart/alternative; boundary="=_alternative 003D393AC2256B4C_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 003D393AC2256B4C_= Content-Type: text/plain; charset="us-ascii" You are right - they are allowed too. Julo "Robert D. Russell" 25-01-02 12:06 To: Julian Satran/Haifa/IBM@IBMIL cc: Eddy Quicksall , "ips@ece. cmu. edu (E-mail)" Subject: Re: iSCSI: keys allowed during security stage Julian: I thought InitiatorAlias and TargetAlias were also allowed during security negotiation. Is this incorrect? There doesn't seem to be any reason to disallow them, and they could be used to provide extra information in the case of a negotiation failure that could be helpful. Bob Russell On Fri, 25 Jan 2002, Julian Satran wrote: > you are correct - I will consider the list. Julo > > > > > Eddy Quicksall > 25-01-02 00:33 > > > To: Julian Satran/Haifa/IBM@IBMIL, "ips@ece. cmu. edu (E-mail)" > > cc: > Subject: iSCSI: keys allowed during security stage > > > > Julian, > > What would you think about putting a list of keys that are allowed during > security stage in Section 11? The reason I ask this is because currently > you have to read through each key to figure that out. > > I think the only keys allowed during security stage are: > > SessionType > InitiatorName > TargetName > AuthMethod > And all keys listed under AuthMethod along with all of their associated > keys. > > If you don't want to list them, can you please confirm that I am correct > above (e.g., HeaderDigest is not allowed in security stage)? > > Eddy > > --=_alternative 003D393AC2256B4C_= Content-Type: text/html; charset="us-ascii"

You are right - they are allowed too.  Julo


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

25-01-02 12:06

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        Eddy Quicksall <Eddy_Quicksall@ivivity.com>, "ips@ece. cmu. edu (E-mail)" <ips@ece.cmu.edu>
        Subject:        Re: iSCSI: keys allowed during security stage

       


Julian:

I thought InitiatorAlias and TargetAlias were also allowed
during security negotiation.  Is this incorrect?
There doesn't seem to be any reason to disallow them,
and they could be used to provide extra information in
the case of a negotiation failure that could be helpful.

Bob Russell


On Fri, 25 Jan 2002, Julian Satran wrote:

> you are correct - I will consider the list. Julo
>
>
>
>
> Eddy Quicksall <Eddy_Quicksall@ivivity.com>
> 25-01-02 00:33
>
>
>         To:     Julian Satran/Haifa/IBM@IBMIL, "ips@ece. cmu. edu (E-mail)"
> <ips@ece.cmu.edu>
>         cc:
>         Subject:        iSCSI: keys allowed during security stage
>
>
>
> Julian,
>
> What would you think about putting a list of keys that are allowed during
> security stage in Section 11? The reason I ask this is because currently
> you have to read through each key to figure that out.
>
> I think the only keys allowed during security stage are:
>
> SessionType
> InitiatorName
> TargetName
> AuthMethod
> And all keys listed under AuthMethod along with all of their associated
> keys.
>
> If you don't want to list them, can you please confirm that I am correct
> above (e.g., HeaderDigest is not allowed in security stage)?
>
> Eddy
>
>



--=_alternative 003D393AC2256B4C_=-- From owner-ips@ece.cmu.edu Fri Jan 25 10: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 KAA05719 for ; Fri, 25 Jan 2002 10:57:32 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0PFHHc02786 for ips-outgoing; Fri, 25 Jan 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 mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0PFHFj02781 for ; Fri, 25 Jan 2002 10:17:15 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jan 2002 10:17:15 -0500 Message-ID: <25369470B6F0D41194820002B328BDD220253C@ATLOPS> From: Eddy Quicksall To: "ips@ece. cmu. edu (E-mail)" Subject: iSCSI: invalid key value Date: Fri, 25 Jan 2002 10:17:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A5B3.5CF05D70" 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_01C1A5B3.5CF05D70 Content-Type: text/plain; charset="iso-8859-1" If a key has a value that is not valid, do you know how I respond? For example, DataDigest=#$C32C,none. The valid values are CRC32C,none. If I say DataDigest=NotUnderstood, wouldn't that mean the key was not understood? If I say DataDigest=Reject, that would mean I don't support the key for the current initiator. If I say DataDigest=Irrelevant, that would mean the digest is not relevant for the current negotiation. If I say DataDigest=none, that would mean I don't support CRC32C when in reality I do. It could be that, since there is no digest in login, the 1st two letters got changed. If I treat it as a protocol error and send a response with status == 0200 or 0201, then the initiator does not know why. Eddy ------_=_NextPart_001_01C1A5B3.5CF05D70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

If a key has a value that is not valid, do you know how I = respond?

 

For example, DataDigest=3D#$C32C,none. The valid values are = CRC32C,none.

 

If I say DataDigest=3DNotUnderstood, wouldn't that mean the key was not = understood?

 

If I say DataDigest=3DReject, that would mean I don't support the key for = the current initiator.

 

If I say DataDigest=3DIrrelevant, that would mean the digest is not = relevant for the current negotiation.

 

=

If I say DataDigest=3Dnone, that would mean I don’t support CRC32C = when in reality I do. It could be that, since there is no digest in login, the = 1st two letters got changed.

 

=

If I treat it as a protocol error and send a response with status =3D=3D = 0200 or 0201, then the initiator does not know = why.

 

Eddy=

 

=
------_=_NextPart_001_01C1A5B3.5CF05D70-- From owner-ips@ece.cmu.edu Fri Jan 25 11:00: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 LAA05828 for ; Fri, 25 Jan 2002 11:00:18 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0PF8vE01941 for ips-outgoing; Fri, 25 Jan 2002 10:08:57 -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 g0PF8tj01936 for ; Fri, 25 Jan 2002 10:08:55 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jan 2002 10:08:54 -0500 Message-ID: <25369470B6F0D41194820002B328BDD220253B@ATLOPS> From: Eddy Quicksall To: "ips@ece. cmu. edu (E-mail)" Cc: "julian_satran@il. ibm. com (E-mail)" Subject: iSCSI: not offering a key Date: Fri, 25 Jan 2002 10:08:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A5B2.33E71AF0" 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_01C1A5B2.33E71AF0 Content-Type: text/plain; charset="iso-8859-1" The spec says: Not offering a key for negotiation is not equivalent to offering the current (or default) value. Does anyone know why? Eddy ------_=_NextPart_001_01C1A5B2.33E71AF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The = spec says:

 

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

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

 

Does anyone know = why?

 

Eddy

 

=
------_=_NextPart_001_01C1A5B2.33E71AF0-- From owner-ips@ece.cmu.edu Fri Jan 25 11:01: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 LAA05901 for ; Fri, 25 Jan 2002 11:01:36 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0PFHZP02802 for ips-outgoing; Fri, 25 Jan 2002 10:17:35 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from erie.mcdata.com (mcgate380.mcdata.com [144.49.6.25]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0PFHXj02797 for ; Fri, 25 Jan 2002 10:17:33 -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 DQ5P61KS; Fri, 25 Jan 2002 08:17:27 -0700 Received: from 144.49.154.169 by erie.mcdata.com (InterScan E-Mail VirusWall NT); Fri, 25 Jan 2002 08:17:26 -0700 Received: by grizzly.mcdata.com with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jan 2002 10:17:25 -0500 Message-ID: <1B8A58D6C376FE4DB329408E27013842447FBD@grizzly.mcdata.com> From: Robert Grant To: ips@ece.cmu.edu Subject: RE: iSCSI:eui64node Date: Fri, 25 Jan 2002 10:17:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-3017dd61-3cba-4384-be3b-2513fc9793a2" 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-3017dd61-3cba-4384-be3b-2513fc9793a2 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A5B3.5FAF0840" ------_=_NextPart_001_01C1A5B3.5FAF0840 Content-Type: text/plain; charset="iso-8859-1" Hello, > This came up at the last, IETF meeting, and most folks disagreed with it. > But I think it was useful to get it put into a draft form where we could > respond completely. The Draft seems to confuse the NODE > name with a physical HBA ID. And it is not obvious that there is a complete > understanding of Multiple Connections per Session as they apply across HBAs (Portals). The draft might go too far giving examples of HOW a node identifier could be arrived at - and leave the impression that these are the ONLY methods. The example of using the MAC address does give the impression that the HBA should be the node - but then goes on to say that for more sophisticated implementations, the node could consist of multiple HBAs/NICs. The point trying to be made was that providing a 64-bit node identifier isn't an onerous task - but it did end up confusing things. But in fact you touch upon a key point - that the NODE is quite different from the HBA. A single host with 2 HBAs should be able to present a single NODE. There are occasions, however, where it's desirable for a single host with 2 HBAs to appear as 2 NODEs. Which comes back to a main point of the draft - that the best place to determine what is and isn't a node is the node itself. So - for topologies using a gateway, having a gateway try to determine this would be bad. > I think you were trying to make sure that the WWNN was unique across the > different Gateways, but since it includes a eui that has a vendor ID, you > must be worried about Gateways from the same vendor. Actually, the draft was trying to make sure the WWNN was the SAME across different Gateways. The draft suggests the WWPN could be unique across different gateways - and doesn't suggest that there are issues with the WWPN. The vendor ID of the EUI64NN would be that of the NODE vendor (HBA/driver/OS) - not of the Gateway(s). > (which I also do not > see as a problem which others should worry about). In any event I did not > fully understand the problem, and the solution was even less clear. > > Anyway somehow you are trying to make iSCSI node name be a name of an > adapter, and we took many pains to absolutely avoid that. Agreed - the iSCSI node should not necessarily be an adapter. > > I also did not understand in your negotiation examples. Yeah - just like the example of "one could use the MAC address to make a 64-bit identifier" led to some confusion, I think trying to pack too much into the negotiation example was confusing, too. The example kinda said "the Initiator offered 'abc', the gateway/target offer 'def', 'ghi' and 'jkl', the Initiator rejected those and offered 'abc', the Gateway accepted 'abc'". Should just give a simple "Initiator says 'abc', gateway/target accepts 'abc'". > > What you are asking for is iSCSI Initiators to have a 64bit name on top of > the 48 bit ISID and the long REAL node name that can be 255 Bytes long. > Just so some gateway does not coordinate with its partner Gateway. I think having Gateways "coordinate" in a truly robust fashion is a lot more complicated than it sounds. Once you consider error scenarios, I'd suggest its not practical for large (with many Gateways) "5-nines or greater" installations. > That means that either ALL HBAs and iSCSI Device Drivers must deal with this > total name, just in case there is a non coordinating Gateway in the middle > some where. This was a sub-text to the more complicated "negotiation example" - that if an HBA/driver DIDN'T support the EUI64NN key, things could still work in many configurations (configurations having no or a single Gateway) by having the Gateway offer an identifier. So - no, the draft states pretty clearly that it would be optional (for instance "an optional Operational Key is added") and not ALL HBAs would need to deal with this. If a vendor wanted an HBA to work well in an environment with multiple Gateways, however, the use of iSNS or an EUI64NN operational key is required. > This does not seem like a good idea to me. Thanks for the comments. > . > John L. Hufferd Regards, Rob Rob Grant McDATA Corporation ------_=_NextPart_001_01C1A5B3.5FAF0840 Content-Type: text/html; charset="iso-8859-1"
Hello,
 
> This came up at the last, IETF meeting, and most folks disagreed with it.
> But I think it was useful to get it put into a draft form where we could
> respond completely. The Draft seems to confuse the NODE
> name with a physical HBA ID.  And it is not obvious that there is a complete
> understanding of Multiple Connections per Session as they apply across HBAs (Portals).
 
The draft might go too far giving examples of HOW a node identifier could be arrived at - and leave the impression that these are the ONLY methods. The example of using the MAC address does give the impression that the HBA should be the node - but then goes on to say that for more sophisticated implementations, the node could consist of multiple HBAs/NICs. The point trying to be made was that providing a 64-bit node identifier isn't an onerous task - but it did end up confusing things.
 
But in fact you touch upon a key point - that the NODE is quite different from the HBA. A single host with 2 HBAs should be able to present a single NODE. There are occasions, however, where it's desirable for a single host with 2 HBAs to appear as 2 NODEs. Which comes back to a main point of the draft - that the best place to determine what is and isn't a node is the node itself. So - for topologies using a gateway, having a gateway try to determine this would be bad.

> I think you were trying to make sure that the WWNN was unique across the
> different Gateways, but since it includes a eui that has a vendor ID, you
> must be worried about Gateways from the same vendor.
 
Actually, the draft was trying to make sure the WWNN was the SAME across different Gateways. The draft suggests the WWPN could be unique across different gateways - and doesn't suggest that there are issues with the WWPN. The vendor ID of the EUI64NN would be that of the NODE vendor (HBA/driver/OS) - not of the Gateway(s).
 
> (which I also do not
> see as a problem which others should worry about).   In any event I did not
> fully understand the problem, and the solution was even less clear.
>
> Anyway somehow you are trying to make iSCSI node name be a name of an
> adapter, and we took many pains to absolutely avoid that.
Agreed - the iSCSI node should not necessarily be an adapter.

>
> I also did not understand in your negotiation examples.
 
Yeah - just like the example of "one could use the MAC address to make a 64-bit identifier" led to some confusion, I think trying to pack too much into the negotiation example was confusing, too. The example kinda said "the Initiator offered 'abc', the gateway/target offer 'def', 'ghi' and 'jkl', the Initiator rejected those and offered 'abc', the Gateway accepted 'abc'". Should just give a simple "Initiator says 'abc', gateway/target accepts 'abc'".

>
> What you are asking for is  iSCSI Initiators to have a 64bit name on top of
> the 48 bit ISID and the long REAL node name that can be 255 Bytes long.
> Just so some gateway does not coordinate with its partner Gateway. 
 
I think having Gateways "coordinate" in a truly robust fashion is a lot more complicated than it sounds. Once you consider error scenarios, I'd suggest its not practical for large (with many Gateways) "5-nines or greater" installations.
 
> That means that either ALL HBAs and iSCSI Device Drivers must deal with this
> total name, just in case there is a non coordinating Gateway in the middle
> some where. 
 
This was a sub-text to the more complicated "negotiation example" - that if an HBA/driver DIDN'T support the EUI64NN key, things could still work in many configurations (configurations having no or a single Gateway) by having the Gateway offer an identifier. So - no, the draft states pretty clearly that it would be optional (for instance "an optional Operational Key is added") and not ALL HBAs would need to deal with this. If a vendor wanted an HBA to work well in an environment with multiple Gateways, however, the use of iSNS or an EUI64NN operational key is required.
 
> This does not seem like a good idea to me.
Thanks for the comments.

>                       .
>                       John L. Hufferd

Regards,
Rob
 
Rob Grant
McDATA Corporation

------_=_NextPart_001_01C1A5B3.5FAF0840-- ------=_NextPartTM-000-3017dd61-3cba-4384-be3b-2513fc9793a2-- From owner-ips@ece.cmu.edu Fri Jan 25 12:02:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07504 for ; Fri, 25 Jan 2002 12:02:04 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0PFvGd05909 for ips-outgoing; Fri, 25 Jan 2002 10:57:16 -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 g0PFvEj05903 for ; Fri, 25 Jan 2002 10:57:14 -0500 (EST) Received: from cisco.com (dhcp-161-44-68-189.cisco.com [161.44.68.189]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA24532; Fri, 25 Jan 2002 10:57:08 -0500 (EST) Message-ID: <3C51803B.F2141925@cisco.com> Date: Fri, 25 Jan 2002 09:56:43 -0600 From: Steve Senum X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ips CC: Eddy Quicksall Subject: Re: iSCSI: invalid key value References: <25369470B6F0D41194820002B328BDD220253C@ATLOPS> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Eddy, If someone sends me "DataDigest=#$C32C,none". I will respond "DataDigest=none". I think responding with "DataDigest=NotUnderstoood" or one of the other special responses would be wrong, as there is nothing wrong with the key ("DataDigest"). Since I support "none", and can't tell "#$C32C" is really "CRC32C", I believe "DataDigest=none" is the only correct response. Steve Senum ----------------------------------------- Subject: iSCSI: invalid key value Date: Fri, 25 Jan 2002 10:17:12 -0500 From: Eddy Quicksall To: "ips@ece. cmu. edu (E-mail)" If a key has a value that is not valid, do you know how I respond? For example, DataDigest=#$C32C,none. The valid values are CRC32C,none. If I say DataDigest=NotUnderstood, wouldn't that mean the key was not understood? If I say DataDigest=Reject, that would mean I don't support the key for the current initiator. If I say DataDigest=Irrelevant, that would mean the digest is not relevant for the current negotiation. If I say DataDigest=none, that would mean I don’t support CRC32C when in reality I do. It could be that, since there is no digest in login, the 1st two letters got changed. If I treat it as a protocol error and send a response with status == 0200 or 0201, then the initiator does not know why. Eddy From owner-ips@ece.cmu.edu Fri Jan 25 12:13: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 MAA07894 for ; Fri, 25 Jan 2002 12:13:37 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0PGNHo08005 for ips-outgoing; Fri, 25 Jan 2002 11:23:17 -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 g0PGNFj08000 for ; Fri, 25 Jan 2002 11:23:15 -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 61F941E63; Fri, 25 Jan 2002 09:23:14 -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 63FD2136; Fri, 25 Jan 2002 09:23:11 -0700 (MST) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 25 Jan 2002 09:23:11 -0700 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jan 2002 09:23:11 -0700 Message-ID: <9F8400020EC5D311AF62009027C3961605F267F8@axcs09.cos.agilent.com> From: kevin_lemay@agilent.com To: ssenum@cisco.com, ips@ece.cmu.edu Cc: Eddy_Quicksall@ivivity.com Subject: RE: iSCSI: invalid key value Date: Fri, 25 Jan 2002 09:23:10 -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 disagree, This is an initiator error and the login should be rejected as such. NotUnderStood should be returned in the key with the login rejected. Kevin Lemay Agilent Technologies -----Original Message----- From: Steve Senum [mailto:ssenum@cisco.com] Sent: Friday, January 25, 2002 7:57 AM To: ietf-ips Cc: Eddy Quicksall Subject: Re: iSCSI: invalid key value Eddy, If someone sends me "DataDigest=#$C32C,none". I will respond "DataDigest=none". I think responding with "DataDigest=NotUnderstoood" or one of the other special responses would be wrong, as there is nothing wrong with the key ("DataDigest"). Since I support "none", and can't tell "#$C32C" is really "CRC32C", I believe "DataDigest=none" is the only correct response. Steve Senum ----------------------------------------- Subject: iSCSI: invalid key value Date: Fri, 25 Jan 2002 10:17:12 -0500 From: Eddy Quicksall To: "ips@ece. cmu. edu (E-mail)" If a key has a value that is not valid, do you know how I respond? For example, DataDigest=#$C32C,none. The valid values are CRC32C,none. If I say DataDigest=NotUnderstood, wouldn't that mean the key was not understood? If I say DataDigest=Reject, that would mean I don't support the key for the current initiator. If I say DataDigest=Irrelevant, that would mean the digest is not relevant for the current negotiation. If I say DataDigest=none, that would mean I don't support CRC32C when in reality I do. It could be that, since there is no digest in login, the 1st two letters got changed. If I treat it as a protocol error and send a response with status == 0200 or 0201, then the initiator does not know why. Eddy From owner-ips@ece.cmu.edu Fri Jan 25 12:14: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 MAA07946 for ; Fri, 25 Jan 2002 12:14:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0PGWm808826 for ips-outgoing; Fri, 25 Jan 2002 11:32:48 -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 g0PA6hj14313 for ; Fri, 25 Jan 2002 05:06:43 -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 g0PA6cUj002614; Fri, 25 Jan 2002 05:06:38 -0500 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.2/8.12.1/Submit) with ESMTP id g0PA6cvd002611; Fri, 25 Jan 2002 05:06:38 -0500 Date: Fri, 25 Jan 2002 05:06:38 -0500 (EST) From: "Robert D. Russell" To: Julian Satran cc: Eddy Quicksall , "ips@ece. cmu. edu (E-mail)" Subject: Re: iSCSI: keys allowed during security stage In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian: I thought InitiatorAlias and TargetAlias were also allowed during security negotiation. Is this incorrect? There doesn't seem to be any reason to disallow them, and they could be used to provide extra information in the case of a negotiation failure that could be helpful. Bob Russell On Fri, 25 Jan 2002, Julian Satran wrote: > you are correct - I will consider the list. Julo > > > > > Eddy Quicksall > 25-01-02 00:33 > > > To: Julian Satran/Haifa/IBM@IBMIL, "ips@ece. cmu. edu (E-mail)" > > cc: > Subject: iSCSI: keys allowed during security stage > > > > Julian, > > What would you think about putting a list of keys that are allowed during > security stage in Section 11? The reason I ask this is because currently > you have to read through each key to figure that out. > > I think the only keys allowed during security stage are: > > SessionType > InitiatorName > TargetName > AuthMethod > And all keys listed under AuthMethod along with all of their associated > keys. > > If you don't want to list them, can you please confirm that I am correct > above (e.g., HeaderDigest is not allowed in security stage)? > > Eddy > > From owner-ips@ece.cmu.edu Fri Jan 25 12:30: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 MAA08229 for ; Fri, 25 Jan 2002 12:30:41 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0PGfbB09517 for ips-outgoing; Fri, 25 Jan 2002 11:41:37 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0PGfZj09513 for ; Fri, 25 Jan 2002 11:41:35 -0500 (EST) 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 IAA07231; Fri, 25 Jan 2002 08:41:06 -0800 (PST) Message-ID: <3C518778.C892B925@cisco.com> Date: Fri, 25 Jan 2002 10:27:36 -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: kevin_lemay@agilent.com CC: ssenum@cisco.com, ips@ece.cmu.edu, Eddy_Quicksall@ivivity.com Subject: Re: iSCSI: invalid key value References: <9F8400020EC5D311AF62009027C3961605F267F8@axcs09.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 Kevin- How can this be rejected, if at least one of the values is understood and supported? One of the original reasons to negotiate digest methods, authentication methods, and such is so newer methods can be added to iSCSI as they become available. If I have an initiator that sends: DataDigest=LatestGreatestDigest,CRC32C,none and a target that supports CRC32C, it should pick CRC32C, rather than sending back a notunderstood. This way, the initiator can say what it wants, and the target can pick from the set of methods it supports. If we let the target reject these, we will degenerate iSCSI login into a "try this, nope, try that, nope, then let's try this" sort of negotiation: I->T DataDigest=LatestGreatest,NextBestThing,CRC32C,none T->I reject I->T DataDigest=NextBestThing,CRC32C,none T->I reject I->T DataDigest=CRC32C,none T->I DataDigest=CRC32C The initiator had to guess at which value the target didn't like, then keep trying to log in with different sets of methods until they were reduced to the subset known by the target. This would default the purpose of having a relatively simple negotiation for these things. Steve is right, the only good way to do this is to accept the value that's understood, even if it's "none", rejecting only if none of the values are understood. If the initiator didn't want "none", it shouldn't have offered. BTW, if "CRC32C" is corrupted into "#$C32C", we will have much worse problems than text key corruption, and trying to get around it this way will not work. -- Mark kevin_lemay@agilent.com wrote: > > I disagree, > > This is an initiator error and the login should be rejected as such. > NotUnderStood should be returned in the key with the login rejected. > > Kevin Lemay > Agilent Technologies > > -----Original Message----- > From: Steve Senum [mailto:ssenum@cisco.com] > Sent: Friday, January 25, 2002 7:57 AM > To: ietf-ips > Cc: Eddy Quicksall > Subject: Re: iSCSI: invalid key value > > Eddy, > > If someone sends me "DataDigest=#$C32C,none". > I will respond "DataDigest=none". > > I think responding with "DataDigest=NotUnderstoood" > or one of the other special responses would be wrong, > as there is nothing wrong with the key ("DataDigest"). > > Since I support "none", and can't tell "#$C32C" > is really "CRC32C", I believe "DataDigest=none" > is the only correct response. > > Steve Senum > > ----------------------------------------- > Subject: iSCSI: invalid key value > Date: Fri, 25 Jan 2002 10:17:12 -0500 > From: Eddy Quicksall > To: "ips@ece. cmu. edu (E-mail)" > > If a key has a value that is not valid, do you know how I respond? > > > > For example, DataDigest=#$C32C,none. The valid values are CRC32C,none. > > > > If I say DataDigest=NotUnderstood, wouldn't that mean the key was not > understood? > > > > If I say DataDigest=Reject, that would mean I don't support the key for the > current initiator. > > > > If I say DataDigest=Irrelevant, that would mean the digest is not relevant > for > the current negotiation. > > > > If I say DataDigest=none, that would mean I don't support CRC32C when in > reality > I do. It could be that, since there is no digest in login, > the 1st two letters got changed. > > > > If I treat it as a protocol error and send a response with status == 0200 or > 0201, then the initiator does not know why. > > > > Eddy -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri Jan 25 12:32: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 MAA08299 for ; Fri, 25 Jan 2002 12:32:01 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0PH6bt11734 for ips-outgoing; Fri, 25 Jan 2002 12:06:37 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lightsand.com ([64.214.104.163]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0PH6Zj11728 for ; Fri, 25 Jan 2002 12:06:35 -0500 (EST) Received: from MURALIRLAPTOP ([192.168.2.60]) by lightsand.com (8.9.3+Sun/8.9.1) with SMTP id JAA20444 for ; Fri, 25 Jan 2002 09:06:29 -0800 (PST) From: "Murali Rajagopal" To: Subject: FCIP: Minutes of Authors conf call 1/23/02 Date: Fri, 25 Jan 2002 09:06:24 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit FCIP Authors conf call 1/23/02 Minutes submitted by Anil Rijhsinghani, McDATA Attendees: Ralph Weber Milan Merhar Brian Forbes Bill Krieg Murali Rajagopal Raj Bhagwat Larry Lamers Andy Helland Jim Nelson Neil Wanamaker Bob Snively Bret Ketchum Venkat Rangan Anil Rijhsingani 1. FCIP Protocol draft-ietf-ips-fcovertcpip-08.txt has been submitted to I-D office. This will be reviewed during the face-to-face meeting at Huntington Beach with a goal to sending the document out for last call and advancement. Any issues that would hold that up needs to be brought up at that time. 2. This latest version contains all agreed updates for security and is synchronized with the IPS security framework draft. 3. FCIP MIB draft-ietf-ips-fcip-mib-01.txt has been submitted to I-D office. This document contains: updated FCIP model; representation of FCIP device containing multiple FCIP entities; decoupled from FC management framework MIB for time being; specified static FCIP configuration table; removed TCP-specific counters; added "Relationships to other MIBs" listing other MIBs assumed as implemented. From owner-ips@ece.cmu.edu Fri Jan 25 12:34: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 MAA08398 for ; Fri, 25 Jan 2002 12:34:19 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0PGoNA10350 for ips-outgoing; Fri, 25 Jan 2002 11:50:23 -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 g0PGoKj10341; Fri, 25 Jan 2002 11:50:20 -0500 (EST) Received: from amirdesktop (dhcp62 [172.21.2.62]) by astutenetworks.com (8.11.6/8.11.2) with SMTP id g0PGnr606570; Fri, 25 Jan 2002 08:49:53 -0800 From: "Amir Shalit" To: "Julian Satran" Cc: "ips@ece. cmu. edu \(E-mail\)" , Subject: RE: SCSI Format/Copy CDB support Date: Fri, 25 Jan 2002 08:49:51 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0086_01C1A57D.40C19CD0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0086_01C1A57D.40C19CD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Julo, I agree with you on (2). Section 2.2.2.1 is saying: "A numbered iSCSI request will not change its allocated CmdSN regardless of the number of times and circumstances in which it is reissued." A long duration SCSI command may be aborted by a task management command and than reissued by iSCSI with a stale CmdSN. Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Friday, January 25, 2002 1:21 AM To: Amir Shalit Cc: ips@ece. cmu. edu (E-mail); owner-ips@ece.cmu.edu Subject: Re: SCSI Format/Copy CDB support Amir, The draft says in several places that CmdSN is not important after the task gets to SCSI. On 2 yes you might be right but that is purely an implementation issue. Format commands do not time-out at SCSI level and iSCSI has no cause to e "nervous" - nothing is expected. Julo "Amir Shalit" Sent by: owner-ips@ece.cmu.edu 25-01-02 02:10 To: "ips@ece. cmu. edu \(E-mail\)" cc: Subject: SCSI Format/Copy CDB support I see a few problems in implementing the format/copy commands over iSCSI 1) CmdSN may wrap between command and response (assuming multiple LUNs) 2) iSCSI keepalive NOPs may be required to keep the connection open during format ------=_NextPart_000_0086_01C1A57D.40C19CD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Julo,
 
I=20 agree with you on (2).
 
Section 2.2.2.1 is = saying:
"A=20 numbered iSCSI request will not change its allocated = CmdSN 
regardless=20 of the number of times and circumstances in which it = is 
reissued."
 
A long=20 duration SCSI command may be aborted by a task management =
command and than reissued by iSCSI with a = stale=20 CmdSN.
 
Amir 
-----Original Message-----
From: = owner-ips@ece.cmu.edu=20 [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian=20 Satran
Sent: Friday, January 25, 2002 1:21 AM
To: = Amir=20 Shalit
Cc: ips@ece. cmu. edu (E-mail);=20 owner-ips@ece.cmu.edu
Subject: Re: SCSI Format/Copy CDB=20 support


Amir,=20

The draft says in several = places that=20 CmdSN is not important after the task gets to SCSI.
On 2 yes you might be right but that is = purely an=20 implementation issue. Format commands do not time-out
at SCSI level and iSCSI has no cause to e = "nervous" -=20 nothing is expected.


Julo




"Amir Shalit"=20 <amir@astutenetworks.com>
Sent by: owner-ips@ece.cmu.edu=20

25-01-02 02:10 =

        =
        To: =    =20    "ips@ece. cmu. edu \(E-mail\)"=20 <ips@ece.cmu.edu>
 =20       cc:         =
        Subject: =  =20      SCSI Format/Copy CDB support =

     =20  


I=20 see a few problems in implementing the format/copy commands over = iSCSI=20
 
1) CmdSN may wrap between command and response = (assuming=20 multiple LUNs)
 =20
2) iSCSI keepalive NOPs = may be required=20 to keep the connection open during format  
  =

------=_NextPart_000_0086_01C1A57D.40C19CD0-- From owner-ips@ece.cmu.edu Fri Jan 25 12:40: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 MAA08650 for ; Fri, 25 Jan 2002 12:40:16 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0PH1YI11302 for ips-outgoing; Fri, 25 Jan 2002 12:01:34 -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 g0PH1Wj11298 for ; Fri, 25 Jan 2002 12:01:32 -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 A7491329E; Fri, 25 Jan 2002 10:01:31 -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 67F06136; Fri, 25 Jan 2002 10:01:31 -0700 (MST) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 25 Jan 2002 10:01:31 -0700 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jan 2002 10:01:31 -0700 Message-ID: <9F8400020EC5D311AF62009027C3961605F267F9@axcs09.cos.agilent.com> From: "LEMAY,KEVIN (A-Roseville,ex1)" To: "'Mark Bakke'" , "LEMAY,KEVIN (A-Roseville,ex1)" Cc: ssenum@cisco.com, ips@ece.cmu.edu, Eddy_Quicksall@ivivity.com Subject: RE: iSCSI: invalid key value Date: Fri, 25 Jan 2002 10:01:29 -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 This is an area that is open to interpretation in the spec. My interpretation is: Any parameter defined in appendix D can only have the values represented in the appendix. To offer any thing not defined in the spec for these well defined parameters is a format error. The first option offered is an invalid one, thus a format error has occurred. If newer options are added to the spec, then they would be defined for that revision and see no problem. The values offered must be consistent with the version number sent in the login request. If new key values are added to a spec and the initiator supports a range of versions. Only key pairs and values common to the requests versions should be offered. If this is not true, then the spec needs to be updated to make it clear that not understood key values should be passed over and only rejected if no valid option exists. The spec is clear on the behavior when a format error occurs. A target should reject the login and close the connection. On further review, NotUnderStood is not the correct response. The correct response would be: "DataDigest=Reject" Kevin Lemay Agilent Technologies -----Original Message----- From: Mark Bakke [mailto:mbakke@cisco.com] Sent: Friday, January 25, 2002 8:28 AM To: kevin_lemay@agilent.com Cc: ssenum@cisco.com; ips@ece.cmu.edu; Eddy_Quicksall@ivivity.com Subject: Re: iSCSI: invalid key value Kevin- How can this be rejected, if at least one of the values is understood and supported? One of the original reasons to negotiate digest methods, authentication methods, and such is so newer methods can be added to iSCSI as they become available. If I have an initiator that sends: DataDigest=LatestGreatestDigest,CRC32C,none and a target that supports CRC32C, it should pick CRC32C, rather than sending back a notunderstood. This way, the initiator can say what it wants, and the target can pick from the set of methods it supports. If we let the target reject these, we will degenerate iSCSI login into a "try this, nope, try that, nope, then let's try this" sort of negotiation: I->T DataDigest=LatestGreatest,NextBestThing,CRC32C,none T->I reject I->T DataDigest=NextBestThing,CRC32C,none T->I reject I->T DataDigest=CRC32C,none T->I DataDigest=CRC32C The initiator had to guess at which value the target didn't like, then keep trying to log in with different sets of methods until they were reduced to the subset known by the target. This would default the purpose of having a relatively simple negotiation for these things. Steve is right, the only good way to do this is to accept the value that's understood, even if it's "none", rejecting only if none of the values are understood. If the initiator didn't want "none", it shouldn't have offered. BTW, if "CRC32C" is corrupted into "#$C32C", we will have much worse problems than text key corruption, and trying to get around it this way will not work. -- Mark kevin_lemay@agilent.com wrote: > > I disagree, > > This is an initiator error and the login should be rejected as such. > NotUnderStood should be returned in the key with the login rejected. > > Kevin Lemay > Agilent Technologies > > -----Original Message----- > From: Steve Senum [mailto:ssenum@cisco.com] > Sent: Friday, January 25, 2002 7:57 AM > To: ietf-ips > Cc: Eddy Quicksall > Subject: Re: iSCSI: invalid key value > > Eddy, > > If someone sends me "DataDigest=#$C32C,none". > I will respond "DataDigest=none". > > I think responding with "DataDigest=NotUnderstoood" > or one of the other special responses would be wrong, > as there is nothing wrong with the key ("DataDigest"). > > Since I support "none", and can't tell "#$C32C" > is really "CRC32C", I believe "DataDigest=none" > is the only correct response. > > Steve Senum > > ----------------------------------------- > Subject: iSCSI: invalid key value > Date: Fri, 25 Jan 2002 10:17:12 -0500 > From: Eddy Quicksall > To: "ips@ece. cmu. edu (E-mail)" > > If a key has a value that is not valid, do you know how I respond? > > > > For example, DataDigest=#$C32C,none. The valid values are CRC32C,none. > > > > If I say DataDigest=NotUnderstood, wouldn't that mean the key was not > understood? > > > > If I say DataDigest=Reject, that would mean I don't support the key for the > current initiator. > > > > If I say DataDigest=Irrelevant, that would mean the digest is not relevant > for > the current negotiation. > > > > If I say DataDigest=none, that would mean I don't support CRC32C when in > reality > I do. It could be that, since there is no digest in login, > the 1st two letters got changed. > > > > If I treat it as a protocol error and send a response with status == 0200 or > 0201, then the initiator does not know why. > > > > Eddy -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri Jan 25 12:49: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 MAA09025 for ; Fri, 25 Jan 2002 12:49:03 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0PHIM212752 for ips-outgoing; Fri, 25 Jan 2002 12:18:22 -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 g0PHIKj12747 for ; Fri, 25 Jan 2002 12:18:20 -0500 (EST) Received: from cisco.com (dhcp-161-44-68-189.cisco.com [161.44.68.189]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA22500 for ; Fri, 25 Jan 2002 12:18:15 -0500 (EST) Message-ID: <3C51933E.39D023DE@cisco.com> Date: Fri, 25 Jan 2002 11:17:50 -0600 From: Steve Senum X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ips Subject: Re: iSCSI: invalid key value References: <9F8400020EC5D311AF62009027C3961605F267F9@axcs09.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 The spec also says: Proprietary algorithms MAY also be negotiated for digests. Whenever a proprietary algorithm is negotiated, "none" or "CRC32C" should be listed as an option in order to guarantee interoperability. I would consider any option not recoginzed as proprietary, and simply ignore it. I would only send "DataDigest=Reject" if I don't support any of the options. Steve Senum "LEMAY,KEVIN (A-Roseville,ex1)" wrote: > > This is an area that is open to interpretation in the spec. > > My interpretation is: > > Any parameter defined in appendix D can only have the values represented in > the appendix. To offer any thing not defined in the spec for these well > defined parameters is a format error. The first option offered is an invalid > one, thus a format error has occurred. > > If newer options are added to the spec, then they would be defined for that > revision and see no problem. The values offered must be consistent with the > version number sent in the login request. If new key values are added to a > spec and the initiator supports a range of versions. Only key pairs and > values common to the requests versions should be offered. If this is not > true, then the spec needs to be updated to make it clear that not understood > key values should be passed over and only rejected if no valid option > exists. > > The spec is clear on the behavior when a format error occurs. A target > should reject the login and close the connection. > > On further review, NotUnderStood is not the correct response. The correct > response would be: "DataDigest=Reject" > > Kevin Lemay > Agilent Technologies > > -----Original Message----- > From: Mark Bakke [mailto:mbakke@cisco.com] > Sent: Friday, January 25, 2002 8:28 AM > To: kevin_lemay@agilent.com > Cc: ssenum@cisco.com; ips@ece.cmu.edu; Eddy_Quicksall@ivivity.com > Subject: Re: iSCSI: invalid key value > > Kevin- > > How can this be rejected, if at least one of the values > is understood and supported? One of the original reasons > to negotiate digest methods, authentication methods, and > such is so newer methods can be added to iSCSI as they > become available. If I have an initiator that sends: > > DataDigest=LatestGreatestDigest,CRC32C,none > > and a target that supports CRC32C, it should pick CRC32C, > rather than sending back a notunderstood. This way, the > initiator can say what it wants, and the target can pick > from the set of methods it supports. > > If we let the target reject these, we will degenerate > iSCSI login into a "try this, nope, try that, nope, then > let's try this" sort of negotiation: > > I->T DataDigest=LatestGreatest,NextBestThing,CRC32C,none > > T->I reject > > I->T DataDigest=NextBestThing,CRC32C,none > > T->I reject > > I->T DataDigest=CRC32C,none > > T->I DataDigest=CRC32C > > The initiator had to guess at which value the target didn't > like, then keep trying to log in with different sets of > methods until they were reduced to the subset known by the > target. This would default the purpose of having a relatively > simple negotiation for these things. > > Steve is right, the only good way to do this is to accept > the value that's understood, even if it's "none", rejecting > only if none of the values are understood. If the initiator > didn't want "none", it shouldn't have offered. > > BTW, if "CRC32C" is corrupted into "#$C32C", we will have > much worse problems than text key corruption, and trying > to get around it this way will not work. > > -- > Mark > > kevin_lemay@agilent.com wrote: > > > > I disagree, > > > > This is an initiator error and the login should be rejected as such. > > NotUnderStood should be returned in the key with the login rejected. > > > > Kevin Lemay > > Agilent Technologies > > > > -----Original Message----- > > From: Steve Senum [mailto:ssenum@cisco.com] > > Sent: Friday, January 25, 2002 7:57 AM > > To: ietf-ips > > Cc: Eddy Quicksall > > Subject: Re: iSCSI: invalid key value > > > > Eddy, > > > > If someone sends me "DataDigest=#$C32C,none". > > I will respond "DataDigest=none". > > > > I think responding with "DataDigest=NotUnderstoood" > > or one of the other special responses would be wrong, > > as there is nothing wrong with the key ("DataDigest"). > > > > Since I support "none", and can't tell "#$C32C" > > is really "CRC32C", I believe "DataDigest=none" > > is the only correct response. > > > > Steve Senum > > > > ----------------------------------------- > > Subject: iSCSI: invalid key value > > Date: Fri, 25 Jan 2002 10:17:12 -0500 > > From: Eddy Quicksall > > To: "ips@ece. cmu. edu (E-mail)" > > > > If a key has a value that is not valid, do you know how I respond? > > > > > > > > For example, DataDigest=#$C32C,none. The valid values are CRC32C,none. > > > > > > > > If I say DataDigest=NotUnderstood, wouldn't that mean the key was not > > understood? > > > > > > > > If I say DataDigest=Reject, that would mean I don't support the key for > the > > current initiator. > > > > > > > > If I say DataDigest=Irrelevant, that would mean the digest is not relevant > > for > > the current negotiation. > > > > > > > > If I say DataDigest=none, that would mean I don't support CRC32C when in > > reality > > I do. It could be that, since there is no digest in login, > > the 1st two letters got changed. > > > > > > > > If I treat it as a protocol error and send a response with status == 0200 > or > > 0201, then the initiator does not know why. > > > > > > > > Eddy > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 From owner-ips@ece.cmu.edu Fri Jan 25 13:09: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 NAA09638 for ; Fri, 25 Jan 2002 13:09:22 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0PHJXB12883 for ips-outgoing; Fri, 25 Jan 2002 12:19:33 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0PHJUj12870 for ; Fri, 25 Jan 2002 12:19:30 -0500 (EST) 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 JAA02750; Fri, 25 Jan 2002 09:19:03 -0800 (PST) Message-ID: <3C519058.50950260@cisco.com> Date: Fri, 25 Jan 2002 11:05:28 -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: "LEMAY,KEVIN (A-Roseville,ex1)" CC: ssenum@cisco.com, ips@ece.cmu.edu, Eddy_Quicksall@ivivity.com Subject: Re: iSCSI: invalid key value References: <9F8400020EC5D311AF62009027C3961605F267F9@axcs09.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 "LEMAY,KEVIN (A-Roseville,ex1)" wrote: > > This is an area that is open to interpretation in the spec. > > My interpretation is: > > Any parameter defined in appendix D can only have the values represented in > the appendix. To offer any thing not defined in the spec for these well > defined parameters is a format error. The first option offered is an invalid > one, thus a format error has occurred. This makes the iSCSI draft non-extensible through other drafts. There are a lot of value-added things that can be done, either by other drafts/RFCs adding new methods to iSCSI, or through vendor-specific methods. The iSCSI revision number has little to do with text keys; it is primarily a PDU format version number. If we have to change the base iSCSI spec and version every thing a new authentication method is made available, for example, we will be turning out too many big RFCs. Better to have a good, extensible "base" iSCSI protocol, and add new authentication or digest methods through separate RFCs. Otherwise, we would have done better to keep the login exchange as a set of binary keys and values, instead of text. > > If newer options are added to the spec, then they would be defined for that > revision and see no problem. The values offered must be consistent with the > version number sent in the login request. If new key values are added to a > spec and the initiator supports a range of versions. Only key pairs and > values common to the requests versions should be offered. If this is not > true, then the spec needs to be updated to make it clear that not understood > key values should be passed over and only rejected if no valid option > exists. I disagree. This makes it too difficult to add new methods to the iSCSI protocol. A new PDU format revision should not be necessary to add an authentication method. > The spec is clear on the behavior when a format error occurs. A target > should reject the login and close the connection. > > On further review, NotUnderStood is not the correct response. The correct > response would be: "DataDigest=Reject" This response should be sent only if NONE of the offered methods are supported. If any method offered is recognized and supported, that method will be returned by the target. -- Mark > Kevin Lemay > Agilent Technologies > > -----Original Message----- > From: Mark Bakke [mailto:mbakke@cisco.com] > Sent: Friday, January 25, 2002 8:28 AM > To: kevin_lemay@agilent.com > Cc: ssenum@cisco.com; ips@ece.cmu.edu; Eddy_Quicksall@ivivity.com > Subject: Re: iSCSI: invalid key value > > Kevin- > > How can this be rejected, if at least one of the values > is understood and supported? One of the original reasons > to negotiate digest methods, authentication methods, and > such is so newer methods can be added to iSCSI as they > become available. If I have an initiator that sends: > > DataDigest=LatestGreatestDigest,CRC32C,none > > and a target that supports CRC32C, it should pick CRC32C, > rather than sending back a notunderstood. This way, the > initiator can say what it wants, and the target can pick > from the set of methods it supports. > > If we let the target reject these, we will degenerate > iSCSI login into a "try this, nope, try that, nope, then > let's try this" sort of negotiation: > > I->T DataDigest=LatestGreatest,NextBestThing,CRC32C,none > > T->I reject > > I->T DataDigest=NextBestThing,CRC32C,none > > T->I reject > > I->T DataDigest=CRC32C,none > > T->I DataDigest=CRC32C > > The initiator had to guess at which value the target didn't > like, then keep trying to log in with different sets of > methods until they were reduced to the subset known by the > target. This would default the purpose of having a relatively > simple negotiation for these things. > > Steve is right, the only good way to do this is to accept > the value that's understood, even if it's "none", rejecting > only if none of the values are understood. If the initiator > didn't want "none", it shouldn't have offered. > > BTW, if "CRC32C" is corrupted into "#$C32C", we will have > much worse problems than text key corruption, and trying > to get around it this way will not work. > > -- > Mark > > kevin_lemay@agilent.com wrote: > > > > I disagree, > > > > This is an initiator error and the login should be rejected as such. > > NotUnderStood should be returned in the key with the login rejected. > > > > Kevin Lemay > > Agilent Technologies > > > > -----Original Message----- > > From: Steve Senum [mailto:ssenum@cisco.com] > > Sent: Friday, January 25, 2002 7:57 AM > > To: ietf-ips > > Cc: Eddy Quicksall > > Subject: Re: iSCSI: invalid key value > > > > Eddy, > > > > If someone sends me "DataDigest=#$C32C,none". > > I will respond "DataDigest=none". > > > > I think responding with "DataDigest=NotUnderstoood" > > or one of the other special responses would be wrong, > > as there is nothing wrong with the key ("DataDigest"). > > > > Since I support "none", and can't tell "#$C32C" > > is really "CRC32C", I believe "DataDigest=none" > > is the only correct response. > > > > Steve Senum > > > > ----------------------------------------- > > Subject: iSCSI: invalid key value > > Date: Fri, 25 Jan 2002 10:17:12 -0500 > > From: Eddy Quicksall > > To: "ips@ece. cmu. edu (E-mail)" > > > > If a key has a value that is not valid, do you know how I respond? > > > > > > > > For example, DataDigest=#$C32C,none. The valid values are CRC32C,none. > > > > > > > > If I say DataDigest=NotUnderstood, wouldn't that mean the key was not > > understood? > > > > > > > > If I say DataDigest=Reject, that would mean I don't support the key for > the > > current initiator. > > > > > > > > If I say DataDigest=Irrelevant, that would mean the digest is not relevant > > for > > the current negotiation. > > > > > > > > If I say DataDigest=none, that would mean I don't support CRC32C when in > > reality > > I do. It could be that, since there is no digest in login, > > the 1st two letters got changed. > > > > > > > > If I treat it as a protocol error and send a response with status == 0200 > or > > 0201, then the initiator does not know why. > > > > > > > > Eddy > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri Jan 25 13:23: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 NAA09975 for ; Fri, 25 Jan 2002 13:23:28 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0PHigN15129 for ips-outgoing; Fri, 25 Jan 2002 12:44:42 -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 g0PHiej15120 for ; Fri, 25 Jan 2002 12:44:40 -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 2FF94B8A; Fri, 25 Jan 2002 10:44:39 -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 D532F3E2; Fri, 25 Jan 2002 10:44:38 -0700 (MST) Received: from 130.29.152.150 by axcsbh5.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 25 Jan 2002 10:44:38 -0700 Received: by axcsbh5.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jan 2002 10:44:38 -0700 Message-ID: <9F8400020EC5D311AF62009027C3961605F267FB@axcs09.cos.agilent.com> From: "LEMAY,KEVIN (A-Roseville,ex1)" To: "'Mark Bakke'" , "'Satran, Julian'" Cc: ssenum@cisco.com, ips@ece.cmu.edu, Eddy_Quicksall@ivivity.com Subject: RE: iSCSI: invalid key value Date: Fri, 25 Jan 2002 10:44:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I think that your interpretation is more extendable and probably better in the long run. The point is, that it is an interpretation and an area that the iSCSI spec does not address. We need to have Julian add language to the spec to clarify the operation. I understand what you are trying to accomplish. But, on the other hand, I am not changing my code until the spec is changed to say what the correct behavior is.... Kevin Lemay Agilent Technologies -----Original Message----- From: Mark Bakke [mailto:mbakke@cisco.com] Sent: Friday, January 25, 2002 9:05 AM To: LEMAY,KEVIN (A-Roseville,ex1) Cc: ssenum@cisco.com; ips@ece.cmu.edu; Eddy_Quicksall@ivivity.com Subject: Re: iSCSI: invalid key value "LEMAY,KEVIN (A-Roseville,ex1)" wrote: > > This is an area that is open to interpretation in the spec. > > My interpretation is: > > Any parameter defined in appendix D can only have the values represented in > the appendix. To offer any thing not defined in the spec for these well > defined parameters is a format error. The first option offered is an invalid > one, thus a format error has occurred. This makes the iSCSI draft non-extensible through other drafts. There are a lot of value-added things that can be done, either by other drafts/RFCs adding new methods to iSCSI, or through vendor-specific methods. The iSCSI revision number has little to do with text keys; it is primarily a PDU format version number. If we have to change the base iSCSI spec and version every thing a new authentication method is made available, for example, we will be turning out too many big RFCs. Better to have a good, extensible "base" iSCSI protocol, and add new authentication or digest methods through separate RFCs. Otherwise, we would have done better to keep the login exchange as a set of binary keys and values, instead of text. > > If newer options are added to the spec, then they would be defined for that > revision and see no problem. The values offered must be consistent with the > version number sent in the login request. If new key values are added to a > spec and the initiator supports a range of versions. Only key pairs and > values common to the requests versions should be offered. If this is not > true, then the spec needs to be updated to make it clear that not understood > key values should be passed over and only rejected if no valid option > exists. I disagree. This makes it too difficult to add new methods to the iSCSI protocol. A new PDU format revision should not be necessary to add an authentication method. > The spec is clear on the behavior when a format error occurs. A target > should reject the login and close the connection. > > On further review, NotUnderStood is not the correct response. The correct > response would be: "DataDigest=Reject" This response should be sent only if NONE of the offered methods are supported. If any method offered is recognized and supported, that method will be returned by the target. -- Mark > Kevin Lemay > Agilent Technologies > > -----Original Message----- > From: Mark Bakke [mailto:mbakke@cisco.com] > Sent: Friday, January 25, 2002 8:28 AM > To: kevin_lemay@agilent.com > Cc: ssenum@cisco.com; ips@ece.cmu.edu; Eddy_Quicksall@ivivity.com > Subject: Re: iSCSI: invalid key value > > Kevin- > > How can this be rejected, if at least one of the values > is understood and supported? One of the original reasons > to negotiate digest methods, authentication methods, and > such is so newer methods can be added to iSCSI as they > become available. If I have an initiator that sends: > > DataDigest=LatestGreatestDigest,CRC32C,none > > and a target that supports CRC32C, it should pick CRC32C, > rather than sending back a notunderstood. This way, the > initiator can say what it wants, and the target can pick > from the set of methods it supports. > > If we let the target reject these, we will degenerate > iSCSI login into a "try this, nope, try that, nope, then > let's try this" sort of negotiation: > > I->T DataDigest=LatestGreatest,NextBestThing,CRC32C,none > > T->I reject > > I->T DataDigest=NextBestThing,CRC32C,none > > T->I reject > > I->T DataDigest=CRC32C,none > > T->I DataDigest=CRC32C > > The initiator had to guess at which value the target didn't > like, then keep trying to log in with different sets of > methods until they were reduced to the subset known by the > target. This would default the purpose of having a relatively > simple negotiation for these things. > > Steve is right, the only good way to do this is to accept > the value that's understood, even if it's "none", rejecting > only if none of the values are understood. If the initiator > didn't want "none", it shouldn't have offered. > > BTW, if "CRC32C" is corrupted into "#$C32C", we will have > much worse problems than text key corruption, and trying > to get around it this way will not work. > > -- > Mark > > kevin_lemay@agilent.com wrote: > > > > I disagree, > > > > This is an initiator error and the login should be rejected as such. > > NotUnderStood should be returned in the key with the login rejected. > > > > Kevin Lemay > > Agilent Technologies > > > > -----Original Message----- > > From: Steve Senum [mailto:ssenum@cisco.com] > > Sent: Friday, January 25, 2002 7:57 AM > > To: ietf-ips > > Cc: Eddy Quicksall > > Subject: Re: iSCSI: invalid key value > > > > Eddy, > > > > If someone sends me "DataDigest=#$C32C,none". > > I will respond "DataDigest=none". > > > > I think responding with "DataDigest=NotUnderstoood" > > or one of the other special responses would be wrong, > > as there is nothing wrong with the key ("DataDigest"). > > > > Since I support "none", and can't tell "#$C32C" > > is really "CRC32C", I believe "DataDigest=none" > > is the only correct response. > > > > Steve Senum > > > > ----------------------------------------- > > Subject: iSCSI: invalid key value > > Date: Fri, 25 Jan 2002 10:17:12 -0500 > > From: Eddy Quicksall > > To: "ips@ece. cmu. edu (E-mail)" > > > > If a key has a value that is not valid, do you know how I respond? > > > > > > > > For example, DataDigest=#$C32C,none. The valid values are CRC32C,none. > > > > > > > > If I say DataDigest=NotUnderstood, wouldn't that mean the key was not > > understood? > > > > > > > > If I say DataDigest=Reject, that would mean I don't support the key for > the > > current initiator. > > > > > > > > If I say DataDigest=Irrelevant, that would mean the digest is not relevant > > for > > the current negotiation. > > > > > > > > If I say DataDigest=none, that would mean I don't support CRC32C when in > > reality > > I do. It could be that, since there is no digest in login, > > the 1st two letters got changed. > > > > > > > > If I treat it as a protocol error and send a response with status == 0200 > or > > 0201, then the initiator does not know why. > > > > > > > > Eddy > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri Jan 25 14:18: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 OAA11575 for ; Fri, 25 Jan 2002 14:18:17 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0PI7g116956 for ips-outgoing; Fri, 25 Jan 2002 13:07:42 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from aegis.indstorage.com ([208.132.17.2]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g0PI7ej16951 for ; Fri, 25 Jan 2002 13:07:40 -0500 (EST) Received: from markb2k (markb2k.indstorage.com [192.168.1.66]) by aegis.indstorage.com (8.11.0/8.11.0) with SMTP id g0PI4Q700799; Fri, 25 Jan 2002 11:04:26 -0700 Reply-To: From: "Mark Bradley" To: "LEMAY,KEVIN \(A-Roseville,ex1\)" , "'Mark Bakke'" Cc: , , Subject: RE: iSCSI: invalid key value Date: Fri, 25 Jan 2002 11:04:36 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <9F8400020EC5D311AF62009027C3961605F267F9@axcs09.cos.agilent.com> Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Kevin is generally correct. However, it should be possible to have in Appendix D such things as 'vendor-defined' and 'reserved' as well. I think this may address Steve S. and Mark Bakke's issues. -- markb > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > LEMAY,KEVIN (A-Roseville,ex1) > Sent: Friday, January 25, 2002 10:01 AM > To: 'Mark Bakke'; LEMAY,KEVIN (A-Roseville,ex1) > Cc: ssenum@cisco.com; ips@ece.cmu.edu; Eddy_Quicksall@ivivity.com > Subject: RE: iSCSI: invalid key value > > > This is an area that is open to interpretation in the spec. > > My interpretation is: > > Any parameter defined in appendix D can only have the values > represented in > the appendix. To offer any thing not defined in the spec for these well > defined parameters is a format error. The first option offered is > an invalid > one, thus a format error has occurred. > > If newer options are added to the spec, then they would be > defined for that > revision and see no problem. The values offered must be > consistent with the > version number sent in the login request. If new key values are added to a > spec and the initiator supports a range of versions. Only key pairs and > values common to the requests versions should be offered. If this is not > true, then the spec needs to be updated to make it clear that not > understood > key values should be passed over and only rejected if no valid option > exists. > > The spec is clear on the behavior when a format error occurs. A target > should reject the login and close the connection. > > On further review, NotUnderStood is not the correct response. The correct > response would be: "DataDigest=Reject" > > Kevin Lemay > Agilent Technologies > > -----Original Message----- > From: Mark Bakke [mailto:mbakke@cisco.com] > Sent: Friday, January 25, 2002 8:28 AM > To: kevin_lemay@agilent.com > Cc: ssenum@cisco.com; ips@ece.cmu.edu; Eddy_Quicksall@ivivity.com > Subject: Re: iSCSI: invalid key value > > > Kevin- > > How can this be rejected, if at least one of the values > is understood and supported? One of the original reasons > to negotiate digest methods, authentication methods, and > such is so newer methods can be added to iSCSI as they > become available. If I have an initiator that sends: > > DataDigest=LatestGreatestDigest,CRC32C,none > > and a target that supports CRC32C, it should pick CRC32C, > rather than sending back a notunderstood. This way, the > initiator can say what it wants, and the target can pick > from the set of methods it supports. > > If we let the target reject these, we will degenerate > iSCSI login into a "try this, nope, try that, nope, then > let's try this" sort of negotiation: > > I->T DataDigest=LatestGreatest,NextBestThing,CRC32C,none > > T->I reject > > I->T DataDigest=NextBestThing,CRC32C,none > > T->I reject > > I->T DataDigest=CRC32C,none > > T->I DataDigest=CRC32C > > The initiator had to guess at which value the target didn't > like, then keep trying to log in with different sets of > methods until they were reduced to the subset known by the > target. This would default the purpose of having a relatively > simple negotiation for these things. > > Steve is right, the only good way to do this is to accept > the value that's understood, even if it's "none", rejecting > only if none of the values are understood. If the initiator > didn't want "none", it shouldn't have offered. > > BTW, if "CRC32C" is corrupted into "#$C32C", we will have > much worse problems than text key corruption, and trying > to get around it this way will not work. > > -- > Mark > > kevin_lemay@agilent.com wrote: > > > > I disagree, > > > > This is an initiator error and the login should be rejected as such. > > NotUnderStood should be returned in the key with the login rejected. > > > > Kevin Lemay > > Agilent Technologies > > > > -----Original Message----- > > From: Steve Senum [mailto:ssenum@cisco.com] > > Sent: Friday, January 25, 2002 7:57 AM > > To: ietf-ips > > Cc: Eddy Quicksall > > Subject: Re: iSCSI: invalid key value > > > > Eddy, > > > > If someone sends me "DataDigest=#$C32C,none". > > I will respond "DataDigest=none". > > > > I think responding with "DataDigest=NotUnderstoood" > > or one of the other special responses would be wrong, > > as there is nothing wrong with the key ("DataDigest"). > > > > Since I support "none", and can't tell "#$C32C" > > is really "CRC32C", I believe "DataDigest=none" > > is the only correct response. > > > > Steve Senum > > > > ----------------------------------------- > > Subject: iSCSI: invalid key value > > Date: Fri, 25 Jan 2002 10:17:12 -0500 > > From: Eddy Quicksall > > To: "ips@ece. cmu. edu (E-mail)" > > > > If a key has a value that is not valid, do you know how I respond? > > > > > > > > For example, DataDigest=#$C32C,none. The valid values are CRC32C,none. > > > > > > > > If I say DataDigest=NotUnderstood, wouldn't that mean the key was not > > understood? > > > > > > > > If I say DataDigest=Reject, that would mean I don't support the key for > the > > current initiator. > > > > > > > > If I say DataDigest=Irrelevant, that would mean the digest is > not relevant > > for > > the current negotiation. > > > > > > > > If I say DataDigest=none, that would mean I don't support CRC32C when in > > reality > > I do. It could be that, since there is no digest in login, > > the 1st two letters got changed. > > > > > > > > If I treat it as a protocol error and send a response with > status == 0200 > or > > 0201, then the initiator does not know why. > > > > > > > > Eddy > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 > From owner-ips@ece.cmu.edu Fri Jan 25 14:21: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 OAA11646 for ; Fri, 25 Jan 2002 14:21:42 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0PIuex20725 for ips-outgoing; Fri, 25 Jan 2002 13:56:40 -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 g0PIuYj20706 for ; Fri, 25 Jan 2002 13:56:35 -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 g0PIuPJ28166 for ; Fri, 25 Jan 2002 13:56:25 -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 g0PIuP606913 for ; Fri, 25 Jan 2002 13:56:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15441.43610.109000.436594@gargle.gargle.HOWL> Date: Fri, 25 Jan 2002 13:56:26 -0500 From: Paul Koning To: ips@ece.cmu.edu Subject: Re: iSCSI: invalid key value References: <9F8400020EC5D311AF62009027C3961605F267F9@axcs09.cos.agilent.com> <3C519058.50950260@cisco.com> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I think the statement in the spec that "proprietary digest algorithms may also be negotiated" settles the matter for the case of the digest negotiation: an unrecognized value means a proprietary algorithm you don't know of, and clearly you have to keep scanning for another value that you *do* support. You can't just quit immediately, because that would conflict with the rule permitting proprietary key values. For other keys, that reasoning doesn't necessarily apply (i.e., if proprietary key values aren't explicitly listed as legal). You can then do one of two things: 1. Insist that the receiver should be extremely picky. If so, then you will *force* a version number change for every tiny change in the set of allowed values. 2. Expect the receiver to ignore values it doesn't understand, and not complain so long as one of the alternatives offered is one it *does* both understand and support. This is an application of the protocol design principle "be strict in what you send, lenient in what you receive". It's not an absolute rule, but as a design guideline it has served well for many decades. One reason why is that it eliminates the need to change version numbers except when you make "large" changes to the protocol. Nitpicking changes like adding new alternatives for keys are not changes that require version number incrementing, provided that you use this rule. Having had to deal with both approaches, I am strongly of the opinion that #1 is a bad idea and #2 is the only correct approach. paul From owner-ips@ece.cmu.edu Fri Jan 25 14:22: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 OAA11679 for ; Fri, 25 Jan 2002 14:22:13 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0PIuaI20712 for ips-outgoing; Fri, 25 Jan 2002 13:56:36 -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 g0PIuYj20707 for ; Fri, 25 Jan 2002 13:56:34 -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 D26DA3389; Fri, 25 Jan 2002 11:56:33 -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 89E203E2; Fri, 25 Jan 2002 11:56:33 -0700 (MST) Received: from 130.29.152.150 by axcsbh5.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 25 Jan 2002 11:56:33 -0700 Received: by axcsbh5.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jan 2002 11:56:33 -0700 Message-ID: <9F8400020EC5D311AF62009027C3961605F267FD@axcs09.cos.agilent.com> From: "LEMAY,KEVIN (A-Roseville,ex1)" To: "'Paul Koning'" Cc: ips@ece.cmu.edu Subject: RE: iSCSI: not offering a key Date: Fri, 25 Jan 2002 11:56:31 -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 disagree that it serves no purpose. It has code implications. If your implementation requires/desires values other than the defaults, then those parameters must be negotiated. For well chosen defaults, this should mean simplier login exchanges. The alternative would mean that every parameter must be negotiated every time. Kevin Lemay Agilent Technologies -----Original Message----- From: Paul Koning [mailto:ni1d@arrl.net] Sent: Friday, January 25, 2002 10:41 AM To: Eddy_Quicksall@ivivity.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: not offering a key Excerpt of message (sent 25 January 2002) by Eddy Quicksall: > The spec says: > > Not offering a key for negotiation is not > equivalent to offering the current (or default) value. > > Does anyone know why? I remember a long discussion about that some months ago. As far as I can tell, this rule in the spec is unnecessary complexity that serves no purpose. Certainly nothing was brought up in that discussion that sounded like a good reason to have the current rule. paul From owner-ips@ece.cmu.edu Fri Jan 25 14:24: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 OAA11793 for ; Fri, 25 Jan 2002 14:24:16 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0PIesl19440 for ips-outgoing; Fri, 25 Jan 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 cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g0PIenj19429 for ; Fri, 25 Jan 2002 13:40: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 g0PIeUJ28097; Fri, 25 Jan 2002 13:40:31 -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 g0PIeUt06277; Fri, 25 Jan 2002 13:40:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15441.42654.765000.221151@gargle.gargle.HOWL> Date: Fri, 25 Jan 2002 13:40:30 -0500 From: Paul Koning To: Eddy_Quicksall@ivivity.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: not offering a key References: <25369470B6F0D41194820002B328BDD220253B@ATLOPS> 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 25 January 2002) by Eddy Quicksall: > The spec says: > > Not offering a key for negotiation is not > equivalent to offering the current (or default) value. > > Does anyone know why? I remember a long discussion about that some months ago. As far as I can tell, this rule in the spec is unnecessary complexity that serves no purpose. Certainly nothing was brought up in that discussion that sounded like a good reason to have the current rule. paul From owner-ips@ece.cmu.edu Fri Jan 25 14:24: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 OAA11863 for ; Fri, 25 Jan 2002 14:24:49 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0PImD019989 for ips-outgoing; Fri, 25 Jan 2002 13:48:13 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0PImCj19985 for ; Fri, 25 Jan 2002 13:48:12 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.99.140.22]) by e34.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA35180; Fri, 25 Jan 2002 13:45:06 -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 g0PIm7471814; Fri, 25 Jan 2002 11:48:07 -0700 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI:eui64node To: Robert Grant Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Fri, 25 Jan 2002 10:47:11 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 01/25/2002 11:48:06 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 g0PImCj19986 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit The biggest problem with the draft is that it does not state, in a way that I could understand, what the problem is. You state it was to ensure that the WWNN was the same across the different Gateways, OK, but why. What does this give you that you would not have any way, that you think is important. Perhaps, there is a second level motivation that is not clear to me. You, also state, that the iSCSI Initiator would have two Nodes. I think you are mixing FC terminology and iSCSI terminology here. Lets review the iSCSI Terminology, as follows: iSCSI Client Network Entity will almost always contain a single iSCSI Initiator Node. And it has one name, the iSCSI Initiator Node Name (InitiatorName=......) There may be Multiple dynamically created SCSI Initiator Ports (with "n" different portals), but each SCSI Initiator Port will drive different sessions and have completely different I-T Nexus. A specific SCSI Port can be identified, within an iSCSI Initiator Node, by its 6 Byte ISID. I think that most FC Cards have both their own WWNN and their OWN WWPN, and they are considered to be the SCSI Port, and manage a FC "Session". So, if two different iSCSI Session are going through the Gateways and they are given different WWNNs I do not see the problem. I do not understand why you would want them to be the same, and what operational difference you think that would mean. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Robert Grant @ece.cmu.edu on 01/25/2002 07:17:16 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: RE: iSCSI:eui64node Hello, > This came up at the last, IETF meeting, and most folks disagreed with it. > But I think it was useful to get it put into a draft form where we could > respond completely. The Draft seems to confuse the NODE > name with a physical HBA ID.  And it is not obvious that there is a complete > understanding of Multiple Connections per Session as they apply across HBAs (Portals). The draft might go too far giving examples of HOW a node identifier could be arrived at - and leave the impression that these are the ONLY methods.The example of using the MAC address does give the impression that the HBA should be the node - but then goes on to say that for more sophisticated implementations, the node could consist of multiple HBAs/NICs. The point trying to be made was that providing a 64-bit node identifier isn't an onerous task - but it did end up confusing things. But in fact you touch upon a key point - that the NODE is quite different from the HBA. A single host with 2 HBAs should be able to present a single NODE. There are occasions, however, where it's desirable for a single host with 2 HBAs to appear as 2 NODEs.Which comes back to a main point of the draft - that the best place to determine what is and isn't a node is the node itself. So - for topologies using a gateway, having a gateway try to determine this would be bad. > I think you were trying to make sure that the WWNN was unique across the > different Gateways, but since it includes a eui that has a vendor ID, you > must be worried about Gateways from the same vendor. Actually, the draft was trying to make sure the WWNN was the SAME across different Gateways. The draft suggests the WWPN could be unique across different gateways - and doesn't suggest that there are issues with the WWPN. The vendor ID of the EUI64NN would be that of the NODE vendor (HBA/driver/OS) - not of the Gateway(s). >(which I also do not > see as a problem which others should worry about).   In any event I did not > fully understand the problem, and the solution was even less clear. > > Anyway somehow you are trying to make iSCSI node name be a name of an > adapter, and we took many pains to absolutely avoid that. Agreed - the iSCSI node should not necessarily be an adapter. > > I also did not understand in your negotiation examples. Yeah - just like the example of "one could use the MAC address to make a 64-bit identifier" led to some confusion, I think trying to pack too much into the negotiation example was confusing, too. The example kinda said "the Initiator offered 'abc', the gateway/target offer 'def', 'ghi' and 'jkl', the Initiator rejected those and offered 'abc', the Gateway accepted 'abc'". Should just give a simple "Initiator says 'abc', gateway/target accepts 'abc'". > > What you are asking for is  iSCSI Initiators to have a 64bit name on top of > the 48 bit ISID and the long REAL node name that can be 255 Bytes long. > Just so some gateway does not coordinate with its partner Gateway. I think having Gateways "coordinate" in a truly robust fashion is a lot more complicated than it sounds. Once you consider error scenarios, I'd suggest its not practical for large (with many Gateways) "5-nines or greater" installations. > That means that either ALL HBAs and iSCSI Device Drivers must deal with this > total name, just in case there is a non coordinating Gateway in the middle > some where. This was a sub-text to the more complicated "negotiation example" - that if an HBA/driver DIDN'T support the EUI64NN key, things could still work in many configurations (configurations having no or a single Gateway) by having the Gateway offer an identifier. So - no, the draft states pretty clearly that it would be optional (for instance "an optional Operational Key is added") and not ALL HBAs would need to deal with this. If a vendor wanted an HBA to work well in an environment with multiple Gateways, however, the use of iSNS or an EUI64NN operational key is required. >This does not seem like a good idea to me. Thanks for the comments. > >                       John L. Hufferd Regards, Rob Rob Grant McDATA Corporation From owner-ips@ece.cmu.edu Fri Jan 25 14:33: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 OAA12121 for ; Fri, 25 Jan 2002 14:33:40 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0PIxEN20953 for ips-outgoing; Fri, 25 Jan 2002 13:59:14 -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 g0PIxCj20948 for ; Fri, 25 Jan 2002 13:59:12 -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 TAA218324; Fri, 25 Jan 2002 19:59:05 +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 g0PJ09R102084; Fri, 25 Jan 2002 20:00:09 +0100 To: Eddy Quicksall Cc: "ips@ece. cmu. edu (E-mail)" MIME-Version: 1.0 Subject: Re: iSCSI: not offering a key X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 25 Jan 2002 21:00:15 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 25/01/2002 21:00:19, Serialize complete at 25/01/2002 21:00:19 Content-Type: multipart/alternative; boundary="=_alternative 0067F1CEC2256B4C_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0067F1CEC2256B4C_= Content-Type: text/plain; charset="us-ascii" To keep the negotiation stateless - Julo Eddy Quicksall 25-01-02 17:08 To: "ips@ece. cmu. edu (E-mail)" cc: Julian Satran/Haifa/IBM@IBMIL Subject: iSCSI: not offering a key The spec says: Not offering a key for negotiation is not equivalent to offering the current (or default) value. Does anyone know why? Eddy --=_alternative 0067F1CEC2256B4C_= Content-Type: text/html; charset="us-ascii"
To keep the negotiation stateless - Julo


Eddy Quicksall <Eddy_Quicksall@ivivity.com>

25-01-02 17:08

       
        To:        "ips@ece. cmu. edu (E-mail)" <ips@ece.cmu.edu>
        cc:        Julian Satran/Haifa/IBM@IBMIL
        Subject:        iSCSI: not offering a key

       


The spec says:
 
Not offering a key for negotiation is not
equivalent to offering the current (or default) value.

 

Does anyone know why?

 

Eddy

 

--=_alternative 0067F1CEC2256B4C_=-- From owner-ips@ece.cmu.edu Fri Jan 25 15:41: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 PAA13692 for ; Fri, 25 Jan 2002 15:41:48 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0PJl4524666 for ips-outgoing; Fri, 25 Jan 2002 14:47:04 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0PJl1j24660 for ; Fri, 25 Jan 2002 14:47:02 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel8.hp.com (Postfix) with ESMTP id 8E342E0021E for ; Fri, 25 Jan 2002 14:46:55 -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 LAA20869 for ; Fri, 25 Jan 2002 11:48:31 -0800 (PST) Message-Id: <200201251948.LAA20869@core.rose.hp.com> Date: Fri, 25 Jan 2002 12:00:50 -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: Fw: Session state and Text Sequence References: <002501c1a578$0530fe40$3b50d40a@vxindia.veritas.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Rahul, >The part of the statement "on another connection for a close the >session Logout command was received" does not seem correct. >T6 change happens only when target is in S3 (XPT_UP) state. >In this state, the connection cannot belong to any session... You are correct! I will remove the wording. Thanks for the review. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Hi, In the v10 specification, I think there is a problem in explanation of connection state transition T6 for target which reads "target: Timed out waiting for an iSCSI Login, or transport disconnect indication was received, or transport reset was received, or an internal event indicating a transport timeout was received, or an internal event of sending a Logout response (suc- cess) on another connection for a close the ses- sion Logout command was received. In all these cases, the connection is to be closed." The part of the statement "on another connection for a close the session Logout command was received" does not seem correct. T6 change happens only when target is in S3 (XPT_UP) state. In this state, the connection cannot belong to any session and must not be closed. In a specific case, if there was only one initiator and one session, (which means that the connection was actually intended for the session being logged out) the connection can probably get closed due to login timeout at target side or initiator explicitly closing it. Please let me know if this is correct. Regards, Rahul From owner-ips@ece.cmu.edu Fri Jan 25 15:47: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 PAA13823 for ; Fri, 25 Jan 2002 15:47:13 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0PJwSu25644 for ips-outgoing; Fri, 25 Jan 2002 14:58:28 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from fw.hel.fi.ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0PJwPj25634 for ; Fri, 25 Jan 2002 14:58:25 -0500 (EST) Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.27) with SMTP id g0PJwNf23150 for ; Fri, 25 Jan 2002 21:58:23 +0200 (EET) Received: (qmail 18943 invoked from network); 25 Jan 2002 19:58:23 -0000 Received: from unknown (HELO sshb3qf0i5anf6) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 25 Jan 2002 19:58:23 -0000 Message-ID: <01e901c1a5da$a3e8a170$65c2210a@sshb3qf0i5anf6> Reply-To: "Jussi Kukkonen" From: "Jussi Kukkonen" To: "Julian Satran" Cc: , "Vaishali Deshpande" References: Subject: Re: iSCSI + IPsec ? Date: Fri, 25 Jan 2002 11:58:19 -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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Plugfest is what thought of as well, but from IOL website and Stephen Schaeffer I got information that February Plugfest is not going to include any IPsec testing. Jussi Kukkonen Technical Product Manager (IPsec OEM Toolkit) SSH Communications Security www.ssh.com ----- Original Message ----- From: Julian Satran To: Jussi Kukkonen Cc: ips@ece.cmu.edu ; owner-ips@ece.cmu.edu ; Vaishali Deshpande Sent: Friday, January 25, 2002 12:50 AM Subject: Re: iSCSI + IPsec ? You may want to try the upcoming plugfest at the University of NewHampshire. Julo "Jussi Kukkonen" Sent by: owner-ips@ece.cmu.edu 25-01-02 00:13 Please respond to "Jussi Kukkonen" To: cc: "Vaishali Deshpande" Subject: iSCSI + IPsec ? We (SSH Communications) are following the developements of IP storage industry closely. Our interest is delivering security components that go with storage protocol implementations. Are there any IP storage industry forums where vendors would already be testing with integrated iSCSI + IPsec stacks? Jussi Kukkonen Technical Product Manager (IPsec OEM Toolkit) SSH Communications Security www.ssh.com From owner-ips@ece.cmu.edu Fri Jan 25 15:48: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 PAA13866 for ; Fri, 25 Jan 2002 15:48:41 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0PJtdL25379 for ips-outgoing; Fri, 25 Jan 2002 14:55:39 -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 g0PJtbj25374 for ; Fri, 25 Jan 2002 14:55:37 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jan 2002 14:55:36 -0500 Message-ID: <25369470B6F0D41194820002B328BDD2202547@ATLOPS> From: Eddy Quicksall To: Julian Satran Cc: "ips@ece. cmu. edu (E-mail)" Subject: RE: iSCSI: not offering a key Date: Fri, 25 Jan 2002 14:55:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A5DA.3E84D1F0" 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_01C1A5DA.3E84D1F0 Content-Type: text/plain; charset="iso-8859-1" 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). I think I get it ... the default for MaxConnections is 1. If I offer MaxConnections=1 (the default) then the target can't negotiate for more connections even though I could have supported more connections. Is that what you are trying to say? It is probably just me but is there a clearer way to convey what you are trying to say? Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, January 25, 2002 2:00 PM To: Eddy Quicksall Cc: ips@ece. cmu. edu (E-mail) Subject: Re: iSCSI: not offering a key To keep the negotiation stateless - Julo Eddy Quicksall 25-01-02 17:08 To: "ips@ece. cmu. edu (E-mail)" cc: Julian Satran/Haifa/IBM@IBMIL Subject: iSCSI: not offering a key The spec says: Not offering a key for negotiation is not equivalent to offering the current (or default) value. Does anyone know why? Eddy ------_=_NextPart_001_01C1A5DA.3E84D1F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

M= aybe 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).

<= ![if = !supportEmptyParas]> 

=

I= think I get it … the default for MaxConnections is 1. If I offer = MaxConnections=3D1 (the default) then the target can’t negotiate for more connections = even though I could have supported more connections. Is that what you are trying to = say?

<= ![if = !supportEmptyParas]> 

=

I= t is probably just me but is there a clearer way to convey what you are = trying to say?

<= ![if = !supportEmptyParas]> 

=

<= ![if = !supportEmptyParas]> 

=

E= ddy

<= ![if = !supportEmptyParas]> 

=

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, January = 25, 2002 2:00 PM
To: Eddy Quicksall
Cc: ips@ece. cmu. edu = (E-mail)
Subject: Re: iSCSI: not = offering a key

 


To keep the negotiation = stateless - Julo

 

Eddy Quicksall <Eddy_Quicksall@ivivity.com> =

25-01-02 17:08 =

    =    
  =       To:        "ips@ece. cmu. edu = (E-mail)" <ips@ece.cmu.edu>
  =       cc:        Julian = Satran/Haifa/IBM@IBMIL
  =       Subject:        iSCSI: not offering a = key

      =  =



The spec says:
 
Not = offering a key for negotiation is not
equivalent to offering the current (or default) value.

  =

Does anyone = know why? =

  =

Eddy =

  =

------_=_NextPart_001_01C1A5DA.3E84D1F0-- From owner-ips@ece.cmu.edu Fri Jan 25 16:47: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 QAA15209 for ; Fri, 25 Jan 2002 16:47:36 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0PL2wc01239 for ips-outgoing; Fri, 25 Jan 2002 16:02:58 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0PL2uj01229 for ; Fri, 25 Jan 2002 16:02:56 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.99.140.22]) by e34.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA23380 for ; Fri, 25 Jan 2002 15:59:51 -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 g0PL2s497320 for ; Fri, 25 Jan 2002 14:02:54 -0700 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: invalid key value To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Fri, 25 Jan 2002 13:02:06 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 01/25/2002 02:02:54 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I agree with Paul, Steve, Mark Bakke, and I think Eddy. Unknown values in a list that contain known values should be ignored. This makes things extensible without version changes. Julian, perhaps it would be useful to add such a statement to 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 Paul Koning @ece.cmu.edu on 01/25/2002 10:56:26 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: iSCSI: invalid key value I think the statement in the spec that "proprietary digest algorithms may also be negotiated" settles the matter for the case of the digest negotiation: an unrecognized value means a proprietary algorithm you don't know of, and clearly you have to keep scanning for another value that you *do* support. You can't just quit immediately, because that would conflict with the rule permitting proprietary key values. For other keys, that reasoning doesn't necessarily apply (i.e., if proprietary key values aren't explicitly listed as legal). You can then do one of two things: 1. Insist that the receiver should be extremely picky. If so, then you will *force* a version number change for every tiny change in the set of allowed values. 2. Expect the receiver to ignore values it doesn't understand, and not complain so long as one of the alternatives offered is one it *does* both understand and support. This is an application of the protocol design principle "be strict in what you send, lenient in what you receive". It's not an absolute rule, but as a design guideline it has served well for many decades. One reason why is that it eliminates the need to change version numbers except when you make "large" changes to the protocol. Nitpicking changes like adding new alternatives for keys are not changes that require version number incrementing, provided that you use this rule. Having had to deal with both approaches, I am strongly of the opinion that #1 is a bad idea and #2 is the only correct approach. paul From owner-ips@ece.cmu.edu Fri Jan 25 18:12: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 SAA17651 for ; Fri, 25 Jan 2002 18:12:05 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0PMUGD07747 for ips-outgoing; Fri, 25 Jan 2002 17:30: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 g0PMUDj07741; Fri, 25 Jan 2002 17:30:13 -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 XAA35264; Fri, 25 Jan 2002 23:30: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 g0PMV4C187130; Fri, 25 Jan 2002 23:31:07 +0100 Subject: RE: SCSI Format/Copy CDB support To: "Amir Shalit" Cc: "ips@ece. cmu. edu \(E-mail\)" , "Julian Satran" , owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Sat, 26 Jan 2002 00:14:02 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 26/01/2002 00:31:21 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Amir, CmdSN is completely secondary in abort task. The main element is the Initiator Task Tag. If ITT is not found at abort then the target, under some cirscumstances, will look for a hole at CmdSN to fill it or will answer negatively the Task Abort. Julo "Amir Shalit" cc: "ips@ece. cmu. edu \(E-mail\)" , 25-01-02 18:49 Subject: RE: SCSI Format/Copy CDB support Julo, I agree with you on (2). Section 2.2.2.1 is saying: "A numbered iSCSI request will not change its allocated CmdSN regardless of the number of times and circumstances in which it is reissued." A long duration SCSI command may be aborted by a task management command and than reissued by iSCSI with a stale CmdSN. Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Friday, January 25, 2002 1:21 AM To: Amir Shalit Cc: ips@ece. cmu. edu (E-mail); owner-ips@ece.cmu.edu Subject: Re: SCSI Format/Copy CDB support Amir, The draft says in several places that CmdSN is not important after the task gets to SCSI. On 2 yes you might be right but that is purely an implementation issue. Format commands do not time-out at SCSI level and iSCSI has no cause to e "nervous" - nothing is expected. Julo "Amir Shalit" To: "ips@ece. cmu. edu Sent by: owner-ips@ece.cmu.edu \(E-mail\)" cc: Subject: SCSI Format/Copy 25-01-02 02:10 CDB support I see a few problems in implementing the format/copy commands over iSCSI 1) CmdSN may wrap between command and response (assuming multiple LUNs) 2) iSCSI keepalive NOPs may be required to keep the connection open during format From owner-ips@ece.cmu.edu Fri Jan 25 18:26:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17861 for ; Fri, 25 Jan 2002 18:26:36 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0PLuwv05215 for ips-outgoing; Fri, 25 Jan 2002 16:56:58 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13903.mail.yahoo.com (web13903.mail.yahoo.com [216.136.175.29]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g0PLutj05209 for ; Fri, 25 Jan 2002 16:56:55 -0500 (EST) Message-ID: <20020125215654.56010.qmail@web13903.mail.yahoo.com> Received: from [209.179.193.185] by web13903.mail.yahoo.com via HTTP; Fri, 25 Jan 2002 13:56:54 PST Date: Fri, 25 Jan 2002 13:56:54 -0800 (PST) From: Mr Daniel Lee Subject: iSCSI: draft 10 editorial comment To: Julian Satran Cc: ips@ece.cmu.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I believe the following text in section 10.12.1 on pg. 145 is redundant (and confusing) and can be removed: If the response class is 0 the target MAY answer with a Login response with the T bit set to 1 ONLY if the T bit is set to 1 in the request. If the response class is not 0 the T bit value MUST be ignored by the initiator. The above text describes the Login Response PDU's 'T bit' and doesn't belong in the Login Request PDU's section. Also, the term 'response class' is confusing because it isn't used anywhere else in the spec. I think you probably meant to remove the above text anyhow because a beautifully concise version of the same text already exists in the Login Request PDU's section (see the last two lines of 10.13.6). Regards, Daniel Lee Unemployed Person dan@danielslee.com "iSCSI, therefore I am" __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com From owner-ips@ece.cmu.edu Fri Jan 25 18:32: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 SAA17956 for ; Fri, 25 Jan 2002 18:32:24 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0PMmR609010 for ips-outgoing; Fri, 25 Jan 2002 17:48:27 -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@www.splentec.com [207.219.118.226]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0PMmOj09005 for ; Fri, 25 Jan 2002 17:48:24 -0500 (EST) Received: from splentec.com (canoe.splentec.com [207.219.118.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g0PMjTU15415; Fri, 25 Jan 2002 17:45:30 -0500 Message-ID: <3C51E0A4.AAF32AF7@splentec.com> Date: Fri, 25 Jan 2002 17:48:04 -0500 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: "LEMAY,KEVIN (A-Roseville,ex1)" CC: "'Mark Bakke'" , "'Satran, Julian'" , ssenum@cisco.com, ips@ece.cmu.edu, Eddy_Quicksall@ivivity.com Subject: Re: iSCSI: invalid key value References: <9F8400020EC5D311AF62009027C3961605F267FB@axcs09.cos.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I agree with Paul. But wouldn't a straightforward implementation suggest the answer...? Separate the value in tokens with comma as the delimiter and then get the union of ``your'' tokens for that key's value(s) and the ones you extracted the from other end. Then you select the one most favourable to you, and either suggest it to the sender or ``state'' it to the sender -- that that's what you'll use. Thus, "CRC32C,none" UNION "$#CRC32C,none" = "none". So, nothing needs to be added to iSCSI regarding this matter. -- -l "LEMAY,KEVIN (A-Roseville,ex1)" wrote: > > I think that your interpretation is more extendable and probably better in > the long run. The point is, that it is an interpretation and an area that > the iSCSI spec does not address. > > We need to have Julian add language to the spec to clarify the operation. I > understand what you are trying to accomplish. > > But, on the other hand, I am not changing my code until the spec is changed > to say what the correct behavior is.... > > Kevin Lemay > Agilent Technologies > > -----Original Message----- > From: Mark Bakke [mailto:mbakke@cisco.com] > Sent: Friday, January 25, 2002 9:05 AM > To: LEMAY,KEVIN (A-Roseville,ex1) > Cc: ssenum@cisco.com; ips@ece.cmu.edu; Eddy_Quicksall@ivivity.com > Subject: Re: iSCSI: invalid key value > > "LEMAY,KEVIN (A-Roseville,ex1)" wrote: > > > > This is an area that is open to interpretation in the spec. > > > > My interpretation is: > > > > Any parameter defined in appendix D can only have the values represented > in > > the appendix. To offer any thing not defined in the spec for these well > > defined parameters is a format error. The first option offered is an > invalid > > one, thus a format error has occurred. > > This makes the iSCSI draft non-extensible through other drafts. > There are a lot of value-added things that can be done, either > by other drafts/RFCs adding new methods to iSCSI, or through > vendor-specific methods. The iSCSI revision number has little > to do with text keys; it is primarily a PDU format version > number. If we have to change the base iSCSI spec and version > every thing a new authentication method is made available, > for example, we will be turning out too many big RFCs. Better > to have a good, extensible "base" iSCSI protocol, and add > new authentication or digest methods through separate RFCs. > > Otherwise, we would have done better to keep the login exchange > as a set of binary keys and values, instead of text. > > > > > If newer options are added to the spec, then they would be defined for > that > > revision and see no problem. The values offered must be consistent with > the > > version number sent in the login request. If new key values are added to a > > spec and the initiator supports a range of versions. Only key pairs and > > values common to the requests versions should be offered. If this is not > > true, then the spec needs to be updated to make it clear that not > understood > > key values should be passed over and only rejected if no valid option > > exists. > > I disagree. This makes it too difficult to add new methods to > the iSCSI protocol. A new PDU format revision should not be > necessary to add an authentication method. > > > The spec is clear on the behavior when a format error occurs. A target > > should reject the login and close the connection. > > > > On further review, NotUnderStood is not the correct response. The correct > > response would be: "DataDigest=Reject" > > This response should be sent only if NONE of the offered methods > are supported. If any method offered is recognized and supported, > that method will be returned by the target. > > -- > Mark > > > Kevin Lemay > > Agilent Technologies > > > > -----Original Message----- > > From: Mark Bakke [mailto:mbakke@cisco.com] > > Sent: Friday, January 25, 2002 8:28 AM > > To: kevin_lemay@agilent.com > > Cc: ssenum@cisco.com; ips@ece.cmu.edu; Eddy_Quicksall@ivivity.com > > Subject: Re: iSCSI: invalid key value > > > > Kevin- > > > > How can this be rejected, if at least one of the values > > is understood and supported? One of the original reasons > > to negotiate digest methods, authentication methods, and > > such is so newer methods can be added to iSCSI as they > > become available. If I have an initiator that sends: > > > > DataDigest=LatestGreatestDigest,CRC32C,none > > > > and a target that supports CRC32C, it should pick CRC32C, > > rather than sending back a notunderstood. This way, the > > initiator can say what it wants, and the target can pick > > from the set of methods it supports. > > > > If we let the target reject these, we will degenerate > > iSCSI login into a "try this, nope, try that, nope, then > > let's try this" sort of negotiation: > > > > I->T DataDigest=LatestGreatest,NextBestThing,CRC32C,none > > > > T->I reject > > > > I->T DataDigest=NextBestThing,CRC32C,none > > > > T->I reject > > > > I->T DataDigest=CRC32C,none > > > > T->I DataDigest=CRC32C > > > > The initiator had to guess at which value the target didn't > > like, then keep trying to log in with different sets of > > methods until they were reduced to the subset known by the > > target. This would default the purpose of having a relatively > > simple negotiation for these things. > > > > Steve is right, the only good way to do this is to accept > > the value that's understood, even if it's "none", rejecting > > only if none of the values are understood. If the initiator > > didn't want "none", it shouldn't have offered. > > > > BTW, if "CRC32C" is corrupted into "#$C32C", we will have > > much worse problems than text key corruption, and trying > > to get around it this way will not work. > > > > -- > > Mark > > > > kevin_lemay@agilent.com wrote: > > > > > > I disagree, > > > > > > This is an initiator error and the login should be rejected as such. > > > NotUnderStood should be returned in the key with the login rejected. > > > > > > Kevin Lemay > > > Agilent Technologies > > > > > > -----Original Message----- > > > From: Steve Senum [mailto:ssenum@cisco.com] > > > Sent: Friday, January 25, 2002 7:57 AM > > > To: ietf-ips > > > Cc: Eddy Quicksall > > > Subject: Re: iSCSI: invalid key value > > > > > > Eddy, > > > > > > If someone sends me "DataDigest=#$C32C,none". > > > I will respond "DataDigest=none". > > > > > > I think responding with "DataDigest=NotUnderstoood" > > > or one of the other special responses would be wrong, > > > as there is nothing wrong with the key ("DataDigest"). > > > > > > Since I support "none", and can't tell "#$C32C" > > > is really "CRC32C", I believe "DataDigest=none" > > > is the only correct response. > > > > > > Steve Senum > > > > > > ----------------------------------------- > > > Subject: iSCSI: invalid key value > > > Date: Fri, 25 Jan 2002 10:17:12 -0500 > > > From: Eddy Quicksall > > > To: "ips@ece. cmu. edu (E-mail)" > > > > > > If a key has a value that is not valid, do you know how I respond? > > > > > > > > > > > > For example, DataDigest=#$C32C,none. The valid values are CRC32C,none. > > > > > > > > > > > > If I say DataDigest=NotUnderstood, wouldn't that mean the key was not > > > understood? > > > > > > > > > > > > If I say DataDigest=Reject, that would mean I don't support the key for > > the > > > current initiator. > > > > > > > > > > > > If I say DataDigest=Irrelevant, that would mean the digest is not > relevant > > > for > > > the current negotiation. > > > > > > > > > > > > If I say DataDigest=none, that would mean I don't support CRC32C when in > > > reality > > > I do. It could be that, since there is no digest in login, > > > the 1st two letters got changed. > > > > > > > > > > > > If I treat it as a protocol error and send a response with status == > 0200 > > or > > > 0201, then the initiator does not know why. > > > > > > > > > > > > Eddy > > > > -- > > Mark A. Bakke > > Cisco Systems > > mbakke@cisco.com > > 763.398.1054 > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- 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 Fri Jan 25 18:48: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 SAA18309 for ; Fri, 25 Jan 2002 18:48:41 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0PNDVJ10765 for ips-outgoing; Fri, 25 Jan 2002 18:13:31 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from intl-bjc-cn-1.inter-touch.net ([211.101.143.98]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0PNDSj10761 for ; Fri, 25 Jan 2002 18:13:28 -0500 (EST) Received: from littlejoy ([10.5.0.17]) by intl-bjc-cn-1.inter-touch.net (8.9.3/8.9.3) with SMTP id HAA23059; Sat, 26 Jan 2002 07:13:23 +0800 From: "Douglas Otis" To: Cc: "Tsvwg" Subject: RE: iSCSI: Framing Steps Date: Fri, 25 Jan 2002 15:13:08 -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) In-Reply-To: <277DD60FB639D511AC0400B0D068B71E029373CB@CORPMX14> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, Thank you for the response. I think a further point should have been strongly made. Such changes to TCP are not actions of the IPS workgroup. These matters should be discussed within the tsvwg. Even matters of Fixed Interval Marking brings concerns with respect to the impact even this seemingly innocuous iSCSI option may have. Should the interval within the FIM be a power of 2, guessing an initial sequence value allows injection of packets within existing connections. A layer below TCP, as devised for iSCSI, is to place de-encapsulated iSCSI information from isolated packets that include marker information despite prior packet loss. A general goal of all the framing approaches being sought by the IPS wg. This would require extensive modification of TCP to facilitate this behavior. In addition, without the specific details of this scheme, largely due to a desire to claim no changes, it is difficult to evaluate related security risks. One risk of this scheme is the requirement for application specific code to be routinely placed below the transport. There are no conventions for instituting the requisite signaling between this below the transport layer application process and the modified TCP. Should an attack successfully inject even null structures, it would not be clear how the transport would behave. FIM has been suggested by those within the IPS wg that implementers consider implementing an otherwise obnoxious scheme requiring the injection of markers or suffer from discarded data otherwise retained using standard versions of TCP. Clearly just sending these markers are not in themselves a risk to TCP. It is their intended use that causes concern. This FIM has also been indicated by several including the author of iSCSI that FIM is just an interim measure to be followed by a full framing scheme later. It is clear this group wishes extensive modifications to TCP and does not wish to share these details openly. One suggestion was to have each iSCSI PDU become framed by a TCP segment. Just the reduction in the average packet size within a high bandwidth stream will stress standard versions of TCP as well as the intervening equipment. SCTP had the foresight to include bundling methods. This is just one aspect of these proposals to fail consideration within the IPS wg. In general, I think the IETF made a wise choice in proposing SCTP as the means of incorporating framing within IP protocols and the IPS wg was informed of SCTP at the outset of their endeavors. SCTP provides many advantages with respect to pressing concerns especially the less disruptive nature incorporation of framing using SCTP would cause over an attempt of framing within TCP. It is clear there is consensus within the IPS wg that SCTP is not to be considered and that TCP framing is despite prohibitions within the charter and the good judgement of the IETF. The ongoing tacit approval of these discussions regarding modification of TCP within the IPS wg is troubling. Doug > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of > Black_David@emc.com [mailto:David_Black@emc.com] > Sent: Wednesday, January 23, 2002 11:10 PM > To: ips@ece.cmu.edu > Subject: iSCSI: Framing Steps > > > I want to attempt to make some steps towards resolving > the framing issues. In reviewing the recent discussions > on framing, I have a couple of conclusions: > > (1) I do not believe that WG consensus (rough or otherwise) > can be obtained for a "MUST implement" requirement > for any form of framing. > (2) The COWS mechanism has a lot of potential, but > its newness, the multiple versions that > have been mentioned, and the desire for some > sort of alignment with new work on DDP/RDMA > suggest that COWS is premature to specify as > part of iSCSI. > > I suggest that these conclusions form the > basis for further ips WG consideration of framing. > > Please think carefully before objecting to these > conclusions on the list (I'm happy to respond to > private questions/expressions of concern). If the > framing issue cannot be driven to closure in > the next few weeks, I will be forced to conclude > that the entire topic is experimental, and hence > needs to be removed from the iSCSI specification > and handled in separate drafts intended to become > experimental RFCs. > > Thanks, > --David > > p.s. A desire to build NICs that never behave in > accordance with an important SHOULD in RFC 1122 > (out-of-order segments SHOULD be queued) does not > strike me as a good reason for changing the first > conclusion above. > > --------------------------------------------------- > 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 Jan 25 18:52:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18497 for ; Fri, 25 Jan 2002 18:52:02 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0PMxrh09802 for ips-outgoing; Fri, 25 Jan 2002 17:59:53 -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 g0PMqdj09320 for ; Fri, 25 Jan 2002 17:52:40 -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 g0PMqYUj023559; Fri, 25 Jan 2002 17:52:34 -0500 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.2/8.12.1/Submit) with ESMTP id g0PMqYeY023556; Fri, 25 Jan 2002 17:52:34 -0500 Date: Fri, 25 Jan 2002 17:52:34 -0500 (EST) From: "Robert D. Russell" To: Eddy Quicksall cc: Julian Satran , "ips@ece. cmu. edu (E-mail)" Subject: RE: iSCSI: not offering a key In-Reply-To: <25369470B6F0D41194820002B328BDD2202547@ATLOPS> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk 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. Bob Russell On Fri, 25 Jan 2002, Eddy Quicksall wrote: > 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). > > I think I get it ... the default for MaxConnections is 1. If I offer > MaxConnections=1 (the default) then the target can't negotiate for more > connections even though I could have supported more connections. Is that > what you are trying to say? > > It is probably just me but is there a clearer way to convey what you are > trying to say? > > > Eddy > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Friday, January 25, 2002 2:00 PM > To: Eddy Quicksall > Cc: ips@ece. cmu. edu (E-mail) > Subject: Re: iSCSI: not offering a key > > > To keep the negotiation stateless - Julo > > > > > Eddy Quicksall > 25-01-02 17:08 > > To: "ips@ece. cmu. edu (E-mail)" > cc: Julian Satran/Haifa/IBM@IBMIL > Subject: iSCSI: not offering a key > > > > > The spec says: > > Not offering a key for negotiation is not > equivalent to offering the current (or default) value. > > Does anyone know why? > > Eddy > > From owner-ips@ece.cmu.edu Fri Jan 25 20:00:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19173 for ; Fri, 25 Jan 2002 20:00:07 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0Q03mh14280 for ips-outgoing; Fri, 25 Jan 2002 19:03:48 -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 g0Q03dj14261; Fri, 25 Jan 2002 19:03:45 -0500 (EST) Received: from amirdesktop (dhcp62 [172.21.2.62]) by astutenetworks.com (8.11.6/8.11.2) with SMTP id g0Q03N602990; Fri, 25 Jan 2002 16:03:23 -0800 From: "Amir Shalit" To: "Julian Satran" Cc: "ips@ece. cmu. edu \(E-mail\)" , Subject: RE: SCSI Format/Copy CDB support Date: Fri, 25 Jan 2002 16:03:20 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julo, I was talking about initiator aborting the command ,say two hours after it was sent, and than reissue the same command with the old CmdSN (according to the spec). I agree with you that the spec covers all other cases since once a command is delivered, CmdSN doesn't matter much and ITT or TTT are used to match the task. Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Friday, January 25, 2002 2:14 PM To: Amir Shalit Cc: ips@ece. cmu. edu (E-mail); Julian Satran; owner-ips@ece.cmu.edu Subject: RE: SCSI Format/Copy CDB support Amir, CmdSN is completely secondary in abort task. The main element is the Initiator Task Tag. If ITT is not found at abort then the target, under some cirscumstances, will look for a hole at CmdSN to fill it or will answer negatively the Task Abort. Julo "Amir Shalit" cc: "ips@ece. cmu. edu \(E-mail\)" , 25-01-02 18:49 Subject: RE: SCSI Format/Copy CDB support Julo, I agree with you on (2). Section 2.2.2.1 is saying: "A numbered iSCSI request will not change its allocated CmdSN regardless of the number of times and circumstances in which it is reissued." A long duration SCSI command may be aborted by a task management command and than reissued by iSCSI with a stale CmdSN. Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Friday, January 25, 2002 1:21 AM To: Amir Shalit Cc: ips@ece. cmu. edu (E-mail); owner-ips@ece.cmu.edu Subject: Re: SCSI Format/Copy CDB support Amir, The draft says in several places that CmdSN is not important after the task gets to SCSI. On 2 yes you might be right but that is purely an implementation issue. Format commands do not time-out at SCSI level and iSCSI has no cause to e "nervous" - nothing is expected. Julo "Amir Shalit" To: "ips@ece. cmu. edu Sent by: owner-ips@ece.cmu.edu \(E-mail\)" cc: Subject: SCSI Format/Copy 25-01-02 02:10 CDB support I see a few problems in implementing the format/copy commands over iSCSI 1) CmdSN may wrap between command and response (assuming multiple LUNs) 2) iSCSI keepalive NOPs may be required to keep the connection open during format From owner-ips@ece.cmu.edu Fri Jan 25 20:03: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 UAA19208 for ; Fri, 25 Jan 2002 20:03:45 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0Q0f1r16358 for ips-outgoing; Fri, 25 Jan 2002 19:41:01 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.nodeinfotech.com ([64.56.196.165]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0Q0exj16350; Fri, 25 Jan 2002 19:40:59 -0500 (EST) Received: from dsingh ([209.237.52.158]) by mail.nodeinfotech.com (8.8.7/8.8.7) with SMTP id RAA29493; Fri, 25 Jan 2002 17:28:42 GMT (envelope-from dsingh@nodeinfotech.com) Reply-To: From: "Delip Singh" To: , Subject: remove Date: Fri, 25 Jan 2002 15:54:19 -0800 Message-ID: <001d01c1a601$7f990f40$050aa8c0@dsingh> 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3C51E0A4.AAF32AF7@splentec.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit From owner-ips@ece.cmu.edu Fri Jan 25 20:20: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 UAA19378 for ; Fri, 25 Jan 2002 20:20:50 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0Q0fHO16387 for ips-outgoing; Fri, 25 Jan 2002 19:41:17 -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@www.splentec.com [207.219.118.226]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0Q0fDj16380 for ; Fri, 25 Jan 2002 19:41:13 -0500 (EST) Received: from splentec.com (canoe.splentec.com [207.219.118.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g0Q0caU15889; Fri, 25 Jan 2002 19:38:36 -0500 Message-ID: <3C51FB27.B5F94AD4@splentec.com> Date: Fri, 25 Jan 2002 19:41:11 -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: Eddy Quicksall CC: "ips@ece. cmu. edu (E-mail)" , "julian_satran@il. ibm. com (E-mail)" Subject: Re: iSCSI: not offering a key References: <25369470B6F0D41194820002B328BDD220253B@ATLOPS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 25 January 2002) by Eddy Quicksall: > The spec says: > > Not offering a key for negotiation is not > equivalent to offering the current (or default) value. > > Does anyone know why? And > 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). 1. The sentence ``Not offering a key for negotiation is not equivalent to offering the current (or default) value.'' means that one cannot assume the current (or default) value for a key which has not been offered for negotiation (negotiated). I.e. you cannot assume as to the value of a key, not the default, not the current. You always have to negotiate it... It may turn out that both T and I use the default, nevertheless they have to negotiate it. This is what the sentence means from a logical point of view. But what is meant by it the iSCSI draft, maybe someone else will confirm. I don't think that there is a better way to put this. Whether that is what is meant in the draft... is another topic. 2. Previous sentence in the draft: ``All negotiations are stateless (i.e., the result MUST be based only on newly exchanged values).'' means that no keys are inherited or persistent... _But_ the draft needs to specify a scope (connection, session, etc) for the non-persistence of negotiations of keys' values (just as persistence is explicitly specified in terms of scopes in formal definitions). There is probably a better way to put this, probably using words like ``scope'', ``persistence'', ``session'', ``connection'', etc., which will eliminate the ``(i.e. ...)''. -- -l From owner-ips@ece.cmu.edu Sat Jan 26 04:25: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 EAA04324 for ; Sat, 26 Jan 2002 04:25:09 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0Q8ioW07277 for ips-outgoing; Sat, 26 Jan 2002 03:44:50 -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 g0Q8imj07269 for ; Sat, 26 Jan 2002 03:44:48 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Sat, 26 Jan 2002 03:39:46 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E039C7EAB@CORPMX14> From: Black_David@emc.com To: dotis@sanlight.net, ips@ece.cmu.edu Cc: tsvwg@ietf.org Subject: RE: iSCSI: Framing Steps Date: Sat, 26 Jan 2002 03:31: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 Attempting to kill a few red herrings ... TCP is vulnerable to packet injection based on guessing or observing the initial sequence number in the absence of fixed-interval-markers (FIM). The well-known connection hijack attack is an example. An attacker can inject arbitrary data into a connection without FIM and cause TCP to misbehave as a result. FIM does not make this any easier or change the ways in which TCP would misbehave when attacked in this fashion. FIM does not entail any changes to TCP. TCP does not care about where incoming data is placed in memory - it cares about the order in which data is processed by TCP and delivered to the application. The intended usage of FIM affects only the placement of incoming data in memory and hence does not change TCP. Meanwhile, Doug appears to have resumed his smear campaign against the IPS wg. Here are three examples: > FIM has been suggested by those within the IPS wg that implementers consider > implementing an otherwise obnoxious scheme requiring the injection of > markers or suffer from discarded data otherwise retained using standard > versions of TCP. Indeed it is obnoxious, and Doug conveniently omitted the fact that the original message in this thread contains a strong suggestion from this IPS wg chair that such an implementation approach is a bad idea because it violates an important SHOULD in RFC 1122 (SHOULD queue out of order data). Scroll to the bottom of this email - it's still there ... > It is clear this group wishes extensive modifications to TCP and > does not wish to share these details openly. Extensive is in the eye of the beholder, but ALL of the proposed framing schemes have been openly described on the IPS and/or TSVWG lists and/or in Internet-Drafts. > One suggestion was to have each iSCSI PDU become framed by a TCP segment. > Just the reduction in the average packet size within a high bandwidth stream > will stress standard versions of TCP as well as the intervening equipment. > SCTP had the foresight to include bundling methods. This is just one aspect > of these proposals to fail consideration within the IPS wg. This refers to draft-ietf-tsvwg-tcp-ulp-frame-01.txt, a tsvwg that proposes changing TCP. Despite Doug's proclamations that the IPS wg should not be discussing changes to TCP, he now criticizes the IPS wg for failing to discuss an aspect of a change to TCP??? There's just no pleasing some people ... especially as I don't recall this specific issue being raised in the past. 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: Douglas Otis [mailto:dotis@sanlight.net] > Sent: Friday, January 25, 2002 6:13 PM > To: ips@ece.cmu.edu > Cc: Tsvwg > Subject: RE: iSCSI: Framing Steps > > > David, > > Thank you for the response. I think a further point should have been > strongly made. Such changes to TCP are not actions of the IPS workgroup. > These matters should be discussed within the tsvwg. Even matters of Fixed > Interval Marking brings concerns with respect to the impact even this > seemingly innocuous iSCSI option may have. > > Should the interval within the FIM be a power of 2, guessing an initial > sequence value allows injection of packets within existing connections. A > layer below TCP, as devised for iSCSI, is to place de-encapsulated iSCSI > information from isolated packets that include marker information despite > prior packet loss. A general goal of all the framing approaches being > sought by the IPS wg. > > This would require extensive modification of TCP to facilitate this > behavior. In addition, without the specific details of this scheme, largely > due to a desire to claim no changes, it is difficult to evaluate related > security risks. One risk of this scheme is the requirement for application > specific code to be routinely placed below the transport. There are no > conventions for instituting the requisite signaling between this below the > transport layer application process and the modified TCP. Should an attack > successfully inject even null structures, it would not be clear how the > transport would behave. > > FIM has been suggested by those within the IPS wg that implementers consider > implementing an otherwise obnoxious scheme requiring the injection of > markers or suffer from discarded data otherwise retained using standard > versions of TCP. Clearly just sending these markers are not in themselves a > risk to TCP. It is their intended use that causes concern. This FIM has > also been indicated by several including the author of iSCSI that FIM is > just an interim measure to be followed by a full framing scheme later. It > is clear this group wishes extensive modifications to TCP and does not wish > to share these details openly. > > One suggestion was to have each iSCSI PDU become framed by a TCP segment. > Just the reduction in the average packet size within a high bandwidth stream > will stress standard versions of TCP as well as the intervening equipment. > SCTP had the foresight to include bundling methods. This is just one aspect > of these proposals to fail consideration within the IPS wg. In general, I > think the IETF made a wise choice in proposing SCTP as the means of > incorporating framing within IP protocols and the IPS wg was informed of > SCTP at the outset of their endeavors. SCTP provides many advantages with > respect to pressing concerns especially the less disruptive nature > incorporation of framing using SCTP would cause over an attempt of framing > within TCP. It is clear there is consensus within the IPS wg that SCTP is > not to be considered and that TCP framing is despite prohibitions within the > charter and the good judgement of the IETF. The ongoing tacit approval of > these discussions regarding modification of TCP within the IPS wg is troubling. > > Doug > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] > On Behalf Of > > Black_David@emc.com [mailto:David_Black@emc.com] > > Sent: Wednesday, January 23, 2002 11:10 PM > > To: ips@ece.cmu.edu > > Subject: iSCSI: Framing Steps > > > > > > I want to attempt to make some steps towards resolving > > the framing issues. In reviewing the recent discussions > > on framing, I have a couple of conclusions: > > > > (1) I do not believe that WG consensus (rough or otherwise) > > can be obtained for a "MUST implement" requirement > > for any form of framing. > > (2) The COWS mechanism has a lot of potential, but > > its newness, the multiple versions that > > have been mentioned, and the desire for some > > sort of alignment with new work on DDP/RDMA > > suggest that COWS is premature to specify as > > part of iSCSI. > > > > I suggest that these conclusions form the > > basis for further ips WG consideration of framing. > > > > Please think carefully before objecting to these > > conclusions on the list (I'm happy to respond to > > private questions/expressions of concern). If the > > framing issue cannot be driven to closure in > > the next few weeks, I will be forced to conclude > > that the entire topic is experimental, and hence > > needs to be removed from the iSCSI specification > > and handled in separate drafts intended to become > > experimental RFCs. > > > > Thanks, > > --David > > > > p.s. A desire to build NICs that never behave in > > accordance with an important SHOULD in RFC 1122 > > (out-of-order segments SHOULD be queued) does not > > strike me as a good reason for changing the first > > conclusion above. > > > > --------------------------------------------------- > > 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 Sat Jan 26 04:27: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 EAA04361 for ; Sat, 26 Jan 2002 04:27:18 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0Q8iuB07299 for ips-outgoing; Sat, 26 Jan 2002 03:44:56 -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 g0Q8isj07289 for ; Sat, 26 Jan 2002 03:44:54 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Sat, 26 Jan 2002 03:44:48 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E039C7EAD@CORPMX14> From: Black_David@emc.com To: amir@astutenetworks.com Cc: ips@ece.cmu.edu Subject: RE: SCSI Format/Copy CDB support Date: Sat, 26 Jan 2002 03:31:30 -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 Ah, I see the confusion. In that section, "reissued" refers to reissuing a command due to holes in the command sequence (e.g., digest failure, connection drop). In the scenario of interest, the command is not being reissued by iSCSI - SCSI is aborting the old command based on the task tag and issuing a new command which will get a new CmdSN (iSCSI will probably have long since forgotten the CmdSN assigned to the original command). A sentence or two to clarify this wouldn't hurt. --David > -----Original Message----- > From: Amir Shalit [mailto:amir@astutenetworks.com] > Sent: Friday, January 25, 2002 7:03 PM > To: Julian Satran > Cc: ips@ece. cmu. edu (E-mail); owner-ips@ece.cmu.edu > Subject: RE: SCSI Format/Copy CDB support > > > Julo, > > I was talking about initiator aborting the command > ,say two hours after it was sent, and than reissue > the same command with the old CmdSN (according to > the spec). > > I agree with you that the spec covers all other cases > since once a command is delivered, CmdSN doesn't > matter much and ITT or TTT are used to match the > task. > > Amir > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Friday, January 25, 2002 2:14 PM > To: Amir Shalit > Cc: ips@ece. cmu. edu (E-mail); Julian Satran; owner-ips@ece.cmu.edu > Subject: RE: SCSI Format/Copy CDB support > > > > Amir, > CmdSN is completely secondary in abort task. > The main element is the Initiator Task Tag. > If ITT is not found at abort then the target, under some > cirscumstances, > will look for a hole at CmdSN to fill it or will answer > negatively the Task > Abort. > > Julo > > > > "Amir Shalit" > Satran/Haifa/IBM@IBMIL > works.com> cc: "ips@ece. cmu. edu > \(E-mail\)" , > > 25-01-02 18:49 Subject: RE: > SCSI Format/Copy > CDB support > > > > > > > Julo, > > I agree with you on (2). > > Section 2.2.2.1 is saying: > "A numbered iSCSI request will not change its allocated CmdSN > regardless of the number of times and circumstances in which it is > reissued." > > A long duration SCSI command may be aborted by a task management > command and than reissued by iSCSI with a stale CmdSN. > > Amir > -----Original Message----- > From: owner-ips@ece.cmu.edu > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Friday, January 25, 2002 1:21 AM > To: Amir Shalit > Cc: ips@ece. cmu. edu (E-mail); owner-ips@ece.cmu.edu > Subject: Re: SCSI Format/Copy CDB support > > > Amir, > > The draft says in several places that CmdSN is not > important after the > task gets to SCSI. > On 2 yes you might be right but that is purely an implementation > issue. Format commands do not time-out > at SCSI level and iSCSI has no cause to e "nervous" - nothing is > expected. > > > Julo > > > > > "Amir Shalit" > To: > "ips@ece. cmu. edu > Sent by: owner-ips@ece.cmu.edu \(E-mail\)" > cc: > Subject: > SCSI Format/Copy > 25-01-02 02:10 CDB support > > > > > > > > I see a few problems in implementing the format/copy > commands over > iSCSI > > 1) CmdSN may wrap between command and response (assuming multiple > LUNs) > > 2) iSCSI keepalive NOPs may be required to keep the > connection open > during format > > > > > > > From owner-ips@ece.cmu.edu Sat Jan 26 04:33: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 EAA04434 for ; Sat, 26 Jan 2002 04:33:35 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0Q8irO07285 for ips-outgoing; Sat, 26 Jan 2002 03:44:53 -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 g0Q8iqj07281 for ; Sat, 26 Jan 2002 03:44:52 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Sat, 26 Jan 2002 03:44:45 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E039C7EAC@CORPMX14> From: Black_David@emc.com To: Eddy_Quicksall@ivivity.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: not offering a key Date: Sat, 26 Jan 2002 03:31:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A643.D9D37C60" 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_01C1A643.D9D37C60 Content-Type: text/plain; charset="iso-8859-1" > 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_01C1A643.D9D37C60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
> Maybe I don’t understand = the sentence. I=20 interpret it to mean that if the
> default value is acceptable to = me then not=20 offering it is somehow different
> than the default … and = that confuses me=20 (well, actually it makes me wonder
> if the sentence is trying to say = something=20 else).
 
Here are two=20 examples of how it's different:
 
(1) If for=20 some reason the other party doesn't have the
    same default (bugs=20 happen), negotiation should drive
    both=20 parties to an agreed value, but in the absence=20 of
   =20 negotiation, the other party might do something=20 different.
    = Moral: if a key = value is=20 important, it MUST be negotiated.
    This is a little weaker = than Luben's=20 statement that
    all keys = always have to=20 be negotiated.  That strength
    was never = intended.
 
(2) If the=20 other party wants to negotiate the value and
    both offer the same = default value,=20 not offering the default
    results in an additional = step before=20 the negotiation can
    conclude, = viz:
 
    -> Nothing&nb= sp;      =20 -> Key=3DDefault
    <- = Key=3DDefault   =20 <- Key=3DDefault
    ->=20 Key=3DDefault
 
--David
 
------_=_NextPart_001_01C1A643.D9D37C60-- From owner-ips@ece.cmu.edu Sat Jan 26 05:33: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 EAA04372 for ; Sat, 26 Jan 2002 04:27:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0Q8ivh07301 for ips-outgoing; Sat, 26 Jan 2002 03:44:57 -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 g0Q8itj07294 for ; Sat, 26 Jan 2002 03:44:55 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Sat, 26 Jan 2002 03:39:53 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E039C7EAE@CORPMX14> From: Black_David@emc.com To: ni1d@arrl.net, ips@ece.cmu.edu Subject: RE: Error in ips-security-07 Date: Sat, 26 Jan 2002 03:31:32 -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 is the infamous "dangling SA" issue discussed in ipsec in the past. While I don't recall its resolution, the IKEv2 draft prohibits dangling SAs, and the IPS Security draft is taking the same position. OTOH, I seem to recall that IKEv1 implementations differ on whether dangling SAs are allowed. Paul - are you suggesting that prohibiting dangling SAs would unnecessarily exclude some IKEv1 implementations to our detriment? 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: Paul Koning [mailto:ni1d@arrl.net] > Sent: Wednesday, January 23, 2002 7:10 PM > To: marjorie_krueger@hp.com; ips@ece.cmu.edu > Subject: RE: Error in ips-security-07 > > > Excerpt of message (sent 23 January 2002) by KRUEGER,MARJORIE > (HP-Roseville,ex1): > > Was this a typo?: > > > > > The text in the security draft is based on a mistaken > assumption. In > > > fact, sessions are not bound to Phase 2 SAs in the first > place -- only > > > to Phase 2 SAs. > > ^^^^^^^ > > Did you mean Phase 1 SAs? Otherwise this sentence doesn't > make sense? > > Oops, yes, that's a typo, but not that way around. Here's what I > meant: > > The text in the security draft is based on a mistaken assumption. > In fact, sessions are not bound to Phase 1 SAs in the first place -- > only to Phase 2 SAs. > > paul > From owner-ips@ece.cmu.edu Sat Jan 26 11: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 LAA08702 for ; Sat, 26 Jan 2002 11:46:32 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0QFjkX03353 for ips-outgoing; Sat, 26 Jan 2002 10:45:46 -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 g0QFjij03347 for ; Sat, 26 Jan 2002 10:45:44 -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 g0QFfxc06117 for ; Sat, 26 Jan 2002 07:41:59 -0800 (PST) Received: from vxindia.veritas.com(revati.vxindia.veritas.com[202.41.69.12]) (4751 bytes) by megami.veritas.com via sendmail with P:esmtp/R:smart_host/T:smtp (sender: ) id for ; Sat, 26 Jan 2002 07:45:37 -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 VAA09268 for ; Sat, 26 Jan 2002 21:14:59 +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 VAA21984 for ; Sat, 26 Jan 2002 21:23:08 -0530 (GMT) Message-ID: <00cd01c1a680$f2b0eaf0$3b50d40a@vxindia.veritas.com> From: "Rahul Bhagwat" To: Subject: iSCSI Keys Date: Sat, 26 Jan 2002 21:18:44 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CA_01C1A6AF.090FE9D0" 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 This is a multi-part message in MIME format. ------=_NextPart_000_00CA_01C1A6AF.090FE9D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have two questions here. When does the negotiated value for a key come into effect ?=20 At the end of the negotiation OR immediately OR on receipt of next PDU in negotiation sequence (so as to be sure that other end has received the value that comes into effect). By negotiation, I mean here succesful login or end of a Text task. For example, MaxConnections key starts with a default=20 value of 1. During operational negotiation phase of login, if the value becomes 2, can the initiator immediately open another TCP connection (without the leading login concluding successfully). Another question is about MaxRecvPDULength. It is the only numeric key that is allowed during Full feature phase. I tried to look through the archieve but could not find a discussion=20 on this. What is the reason for this key to be allowed like this ? The possible reason I could think of this is a target or initiator becomes less loaded and can handle bigger PDUs. Regards, Rahul ------=_NextPart_000_00CA_01C1A6AF.090FE9D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I have two questions here.
 
When does the negotiated value for a = key come into=20 effect ?
At the end of the negotiation OR = immediately OR on=20 receipt
of next PDU in negotiation sequence (so = as to be=20 sure that
other end has received the value that = comes into=20 effect).
 
By negotiation, I mean here succesful = login or end=20 of a
Text task.
 
For example, MaxConnections key starts = with a=20 default
value of 1. During operational = negotiation phase of=20 login, if
the value becomes 2, can the initiator = immediately=20 open
another TCP connection (without the = leading login=20 concluding
successfully).
 
Another question is about = MaxRecvPDULength. It is=20 the only
numeric key that is allowed during Full = feature=20 phase. I tried
to look through the archieve but could = not find a=20 discussion
on this. What is the reason for this = key to be=20 allowed like
this ? The possible reason I could = think of this is=20 a target or
initiator becomes less loaded and can = handle bigger=20 PDUs.
 
 
Regards,
Rahul
------=_NextPart_000_00CA_01C1A6AF.090FE9D0-- From owner-ips@ece.cmu.edu Sat Jan 26 14:04: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 OAA09747 for ; Sat, 26 Jan 2002 14:04:48 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0QIFK509622 for ips-outgoing; Sat, 26 Jan 2002 13:15:20 -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 g0QIFDj09616 for ; Sat, 26 Jan 2002 13:15:18 -0500 (EST) Received: from amirdesktop (dhcp62 [172.21.2.62]) by astutenetworks.com (8.11.6/8.11.2) with SMTP id g0QIF0629419; Sat, 26 Jan 2002 10:15:00 -0800 From: "Amir Shalit" To: Cc: Subject: RE: SCSI Format/Copy CDB support Date: Sat, 26 Jan 2002 10:14:58 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <277DD60FB639D511AC0400B0D068B71E039C7EAD@CORPMX14> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, I agree. Lets clarify it in the spec. We also must make sure that iSCSI doesn't reissue a command due to connection drop that happened a "long time" after the command was originally issued. Amir -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Saturday, January 26, 2002 12:32 AM To: amir@astutenetworks.com Cc: ips@ece.cmu.edu Subject: RE: SCSI Format/Copy CDB support Ah, I see the confusion. In that section, "reissued" refers to reissuing a command due to holes in the command sequence (e.g., digest failure, connection drop). In the scenario of interest, the command is not being reissued by iSCSI - SCSI is aborting the old command based on the task tag and issuing a new command which will get a new CmdSN (iSCSI will probably have long since forgotten the CmdSN assigned to the original command). A sentence or two to clarify this wouldn't hurt. --David > -----Original Message----- > From: Amir Shalit [mailto:amir@astutenetworks.com] > Sent: Friday, January 25, 2002 7:03 PM > To: Julian Satran > Cc: ips@ece. cmu. edu (E-mail); owner-ips@ece.cmu.edu > Subject: RE: SCSI Format/Copy CDB support > > > Julo, > > I was talking about initiator aborting the command > ,say two hours after it was sent, and than reissue > the same command with the old CmdSN (according to > the spec). > > I agree with you that the spec covers all other cases > since once a command is delivered, CmdSN doesn't > matter much and ITT or TTT are used to match the > task. > > Amir > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Friday, January 25, 2002 2:14 PM > To: Amir Shalit > Cc: ips@ece. cmu. edu (E-mail); Julian Satran; owner-ips@ece.cmu.edu > Subject: RE: SCSI Format/Copy CDB support > > > > Amir, > CmdSN is completely secondary in abort task. > The main element is the Initiator Task Tag. > If ITT is not found at abort then the target, under some > cirscumstances, > will look for a hole at CmdSN to fill it or will answer > negatively the Task > Abort. > > Julo > > > > "Amir Shalit" > Satran/Haifa/IBM@IBMIL > works.com> cc: "ips@ece. cmu. edu > \(E-mail\)" , > > 25-01-02 18:49 Subject: RE: > SCSI Format/Copy > CDB support > > > > > > > Julo, > > I agree with you on (2). > > Section 2.2.2.1 is saying: > "A numbered iSCSI request will not change its allocated CmdSN > regardless of the number of times and circumstances in which it is > reissued." > > A long duration SCSI command may be aborted by a task management > command and than reissued by iSCSI with a stale CmdSN. > > Amir > -----Original Message----- > From: owner-ips@ece.cmu.edu > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Friday, January 25, 2002 1:21 AM > To: Amir Shalit > Cc: ips@ece. cmu. edu (E-mail); owner-ips@ece.cmu.edu > Subject: Re: SCSI Format/Copy CDB support > > > Amir, > > The draft says in several places that CmdSN is not > important after the > task gets to SCSI. > On 2 yes you might be right but that is purely an implementation > issue. Format commands do not time-out > at SCSI level and iSCSI has no cause to e "nervous" - nothing is > expected. > > > Julo > > > > > "Amir Shalit" > To: > "ips@ece. cmu. edu > Sent by: owner-ips@ece.cmu.edu \(E-mail\)" > cc: > Subject: > SCSI Format/Copy > 25-01-02 02:10 CDB support > > > > > > > > I see a few problems in implementing the format/copy > commands over > iSCSI > > 1) CmdSN may wrap between command and response (assuming multiple > LUNs) > > 2) iSCSI keepalive NOPs may be required to keep the > connection open > during format > > > > > > > From owner-ips@ece.cmu.edu Sat Jan 26 15:59: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 PAA10726 for ; Sat, 26 Jan 2002 15:59:45 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0QK1qV13892 for ips-outgoing; Sat, 26 Jan 2002 15:01:52 -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 g0QK1nj13885 for ; Sat, 26 Jan 2002 15:01:49 -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 OAA109832; Sat, 26 Jan 2002 14:58:43 -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 g0QK1kW22252; Sat, 26 Jan 2002 13:01:46 -0700 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI Keys To: "Rahul Bhagwat" Cc: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Sat, 26 Jan 2002 12:00:55 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 01/26/2002 01:01:46 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 g0QK1oj13888 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit The Leading Login is a serial only process until it concludes into full featured phase. No other connection can be established until the end of the Leading Login. . . . 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 "Rahul Bhagwat" @ece.cmu.edu on 01/26/2002 07:48:44 AM Sent by: owner-ips@ece.cmu.edu To: cc: Subject: iSCSI Keys Hi, I have two questions here. When does the negotiated value for a key come into effect ? At the end of the negotiation OR immediately OR on receipt of next PDU in negotiation sequence (so as to be sure that other end has received the value that comes into effect). By negotiation, I mean here succesful login or end of a Text task. For example, MaxConnections key starts with a default value of 1. During operational negotiation phase of login, if the value becomes 2, can the initiator immediately open another TCP connection (without the leading login concluding successfully). Another question is about MaxRecvPDULength. It is the only numeric key that is allowed during Full feature phase. I tried to look through the archieve but could not find a discussion on this. What is the reason for this key to be allowed like this ? The possible reason I could think of this is a target or initiator becomes less loaded and can handle bigger PDUs. Regards, Rahul From owner-ips@ece.cmu.edu Sat Jan 26 17:30: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 RAA11411 for ; Sat, 26 Jan 2002 17:30:20 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0QLYmW17879 for ips-outgoing; Sat, 26 Jan 2002 16:34:48 -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 g0QLYgj17871 for ; Sat, 26 Jan 2002 16:34:46 -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 QAA82022; Sat, 26 Jan 2002 16:31:36 -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 g0QLYeD52240; Sat, 26 Jan 2002 14:34:40 -0700 X-Priority: 1 (High) Importance: Normal Subject: IPS: Security Draft 07 To: "Bernard Aboba" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Sat, 26 Jan 2002 13:33:50 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 01/26/2002 02:34:39 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Bernard, In Security Draft 07, in section 5.6 Fragmentation Issues, you went through things that could be done to deal with the problem. However, I did not detect any MUSTs, SHOULDs, MAYs etc. It looks like good advise, but doesn't it need some requirement language? You had some lower case "should", but do you think that some upper case requirement words are approprate there? . . . 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 Jan 26 19: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 TAA12249 for ; Sat, 26 Jan 2002 19:02:39 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0QNJNn23118 for ips-outgoing; Sat, 26 Jan 2002 18:19:23 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from femail13.sdc1.sfba.home.com (femail13.sdc1.sfba.home.com [24.0.95.140]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0QNJKj23112 for ; Sat, 26 Jan 2002 18:19:21 -0500 (EST) Received: from splentec.com ([24.42.134.59]) by femail13.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20020126231919.GERX16642.femail13.sdc1.sfba.home.com@splentec.com>; Sat, 26 Jan 2002 15:19:19 -0800 Message-ID: <3C533976.EC0BB65E@splentec.com> Date: Sat, 26 Jan 2002 18:19:18 -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: "LEMAY,KEVIN (A-Roseville,ex1)" , "'Mark Bakke'" , "'Satran, Julian'" , ssenum@cisco.com, ips@ece.cmu.edu, Eddy_Quicksall@ivivity.com Subject: Re: iSCSI: invalid key value References: <9F8400020EC5D311AF62009027C3961605F267FB@axcs09.cos.agilent.com> <3C51E0A4.AAF32AF7@splentec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Luben Tuikov wrote: > > Thus, > "CRC32C,none" UNION "$#CRC32C,none" = "none". ^^^^^ I meant INTERSECTION... (too many things in my head...) -- -l From owner-ips@ece.cmu.edu Sun Jan 27 14:19:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02470 for ; Sun, 27 Jan 2002 14:19:42 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0RIPqF28559 for ips-outgoing; Sun, 27 Jan 2002 13:25:52 -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 g0RIPpj28554 for ; Sun, 27 Jan 2002 13:25:51 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Sun, 27 Jan 2002 13:25:41 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029373D6@CORPMX14> From: Black_David@emc.com To: amir@astutenetworks.com Cc: ips@ece.cmu.edu Subject: RE: SCSI Format/Copy CDB support Date: Sun, 27 Jan 2002 13:12: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 The CmdSN window should take care of the "long time" issue - once the Window (ExpCmdSN/MaxCmdSN) has moved past a particular CmdSN, the initiator knows that the target successfully received the command, and reissuing the command with the same CmdSN would be an error. Julian - please add a suitable clarification to the next version of the spec. Thanks, --David > -----Original Message----- > From: Amir Shalit [mailto:amir@astutenetworks.com] > Sent: Saturday, January 26, 2002 1:15 PM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: RE: SCSI Format/Copy CDB support > > > David, > > I agree. Lets clarify it in the spec. We also must make > sure that iSCSI doesn't reissue a command due to connection > drop that happened a "long time" after the command was > originally issued. > > Amir > > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Saturday, January 26, 2002 12:32 AM > To: amir@astutenetworks.com > Cc: ips@ece.cmu.edu > Subject: RE: SCSI Format/Copy CDB support > > > Ah, I see the confusion. In that section, "reissued" > refers to reissuing a command due to holes in the command > sequence (e.g., digest failure, connection drop). In > the scenario of interest, the command is not being > reissued by iSCSI - SCSI is aborting the old command > based on the task tag and issuing a new command which > will get a new CmdSN (iSCSI will probably have long since > forgotten the CmdSN assigned to the original command). > A sentence or two to clarify this wouldn't hurt. > > --David > > > -----Original Message----- > > From: Amir Shalit [mailto:amir@astutenetworks.com] > > Sent: Friday, January 25, 2002 7:03 PM > > To: Julian Satran > > Cc: ips@ece. cmu. edu (E-mail); owner-ips@ece.cmu.edu > > Subject: RE: SCSI Format/Copy CDB support > > > > > > Julo, > > > > I was talking about initiator aborting the command > > ,say two hours after it was sent, and than reissue > > the same command with the old CmdSN (according to > > the spec). > > > > I agree with you that the spec covers all other cases > > since once a command is delivered, CmdSN doesn't > > matter much and ITT or TTT are used to match the > > task. > > > > Amir > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Julian Satran > > Sent: Friday, January 25, 2002 2:14 PM > > To: Amir Shalit > > Cc: ips@ece. cmu. edu (E-mail); Julian Satran; owner-ips@ece.cmu.edu > > Subject: RE: SCSI Format/Copy CDB support > > > > > > > > Amir, > > CmdSN is completely secondary in abort task. > > The main element is the Initiator Task Tag. > > If ITT is not found at abort then the target, under some > > cirscumstances, > > will look for a hole at CmdSN to fill it or will answer > > negatively the Task > > Abort. > > > > Julo > > > > > > > > "Amir Shalit" > > > Satran/Haifa/IBM@IBMIL > > works.com> cc: "ips@ece. cmu. edu > > \(E-mail\)" , > > > > 25-01-02 18:49 Subject: RE: > > SCSI Format/Copy > > CDB support > > > > > > > > > > > > > > Julo, > > > > I agree with you on (2). > > > > Section 2.2.2.1 is saying: > > "A numbered iSCSI request will not change its allocated CmdSN > > regardless of the number of times and circumstances in which it is > > reissued." > > > > A long duration SCSI command may be aborted by a task management > > command and than reissued by iSCSI with a stale CmdSN. > > > > Amir > > -----Original Message----- > > From: owner-ips@ece.cmu.edu > > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Julian Satran > > Sent: Friday, January 25, 2002 1:21 AM > > To: Amir Shalit > > Cc: ips@ece. cmu. edu (E-mail); owner-ips@ece.cmu.edu > > Subject: Re: SCSI Format/Copy CDB support > > > > > > Amir, > > > > The draft says in several places that CmdSN is not > > important after the > > task gets to SCSI. > > On 2 yes you might be right but that is purely an > implementation > > issue. Format commands do not time-out > > at SCSI level and iSCSI has no cause to e "nervous" - > nothing is > > expected. > > > > > > Julo > > > > > > > > > > "Amir Shalit" > > To: > > "ips@ece. cmu. edu > > Sent by: owner-ips@ece.cmu.edu \(E-mail\)" > > cc: > > Subject: > > SCSI Format/Copy > > 25-01-02 02:10 CDB support > > > > > > > > > > > > > > > > I see a few problems in implementing the format/copy > > commands over > > iSCSI > > > > 1) CmdSN may wrap between command and response > (assuming multiple > > LUNs) > > > > 2) iSCSI keepalive NOPs may be required to keep the > > connection open > > during format > > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Sun Jan 27 20:19:36 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05518 for ; Sun, 27 Jan 2002 20:19:36 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0S0M6317526 for ips-outgoing; Sun, 27 Jan 2002 19:22:06 -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 g0S0M5j17522 for ; Sun, 27 Jan 2002 19:22:05 -0500 (EST) Received: (cpmta 13006 invoked from network); 27 Jan 2002 16:21:57 -0800 Received: from 64.130.130.105 (HELO dougrmt) by smtp.telocity.com (209.228.32.214) with SMTP; 27 Jan 2002 16:21:57 -0800 X-Sent: 28 Jan 2002 00:21:57 GMT From: "Douglas Otis" To: , Cc: Subject: RE: iSCSI: Framing Steps Date: Sun, 27 Jan 2002 16:23:14 -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 Importance: Normal In-Reply-To: <277DD60FB639D511AC0400B0D068B71E039C7EAB@CORPMX14> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, > Attempting to kill a few red herrings ... A "red herring" is irrelevance offered to distract. For red herrings, your statements are examples. > TCP is vulnerable to packet injection based on guessing or observing > the initial sequence number in the absence of fixed-interval-markers > (FIM). The well-known connection hijack attack is an example. An > attacker can inject arbitrary data into a connection without FIM and > cause TCP to misbehave as a result. FIM does not make this any > easier or change the ways in which TCP would misbehave when attacked > in this fashion. FIM enables *processing* of packets out of sequence from the initial send. The intent of FIM is to make such processing possible and that *does* enable a greater opportunity for attack especially if the measure is predictable within future headers. > FIM does not entail any changes to TCP. TCP does not care about > where incoming data is placed in memory - it cares about the order > in which data is processed by TCP and delivered to the application. A process that examines application specific structures at the packet (IP) level, to then move portions of the expected TCP byte stream into user space based on application references matching these structures, is *not* a modification to TCP provided there is a *sequential* order of delivery? Clearly placing a portion of the application below TCP is a modification to TCP and network layering. Are you referring to a means at the TCP API to hide this activity? Are you saying that the TCP API does not change? How is this done without changing TCP? The application specific processing below this modified TCP transport is to de-encapsulate the iSCSI payloads into user space. iSCSI user space may not be satisfied in the sequence they were established. The complexity involved will require modification of TCP to support this buffer handling and application specific structure processing. In the case of iSCSI, the content of the byte stream is not known before hand. This activity below TCP places and splices sections of the TCP byte stream into designated iSCSI user space. Clearly there are many questions one may have with respect to what and when TCP validates and delivers. TCP could easily reject a packet based on the byte sequence within headers that was not rejected by this "below the transport process" that would be unable to see the header continuum. This added state below the TCP transport provides opportunity for attack or in some implementations, poor behavior. > The intended usage of FIM affects only the placement of incoming > data in memory and hence does not change TCP. Placement of application specific payloads into regions matched against application specific structure content prior to being handled by the TCP layer is a change to TCP. TCP is not able to manipulate buffers in this manner without extensive modification. Such modification is quite possible however, and all the details should be explored before the use of this scheme is placed into a standards draft however. My concern remains that the IPS wg is NOT the place to discuss these concerns as that is not their expertise nor their charter. > Meanwhile, Doug appears to have resumed his smear campaign against > the IPS wg. Here are three examples: > > > FIM has been suggested by those within the IPS wg that implementers > > consider implementing an otherwise obnoxious scheme requiring the > > injection of markers or suffer from discarded data otherwise > > retained using standard versions of TCP. > > Indeed it is obnoxious, and Doug conveniently omitted the fact that the > original message in this thread contains a strong suggestion from this > IPS wg chair that such an implementation approach is a bad idea because > it violates an important SHOULD in RFC 1122 (SHOULD queue out of order > data). > Scroll to the bottom of this email - it's still there ... As you point out, I did include such a statement made by you. You have also asked the group to drive the framing issue to conclusion but you failed to indicate that such discussion should not take place within the IPS. Ensure that an error is not made where everyone expects such modifications to TCP even if done unofficially by the IPS. > > It is clear this group wishes extensive modifications to TCP and > > does not wish to share these details openly. > > Extensive is in the eye of the beholder, but ALL of the proposed framing > schemes have been openly described on the IPS and/or TSVWG lists and/or > in Internet-Drafts. That is a valid statement. In this case, these details should be extensive to ensure some problem is not overlooked. > > One suggestion was to have each iSCSI PDU become framed by a > > TCP segment. Just the reduction in the average packet size within > > a high bandwidth stream will stress standard versions of TCP as > > well as the intervening equipment. SCTP had the foresight to > > include bundling methods. This is just one aspect of these > > proposals to fail consideration within the IPS wg. > > This refers to draft-ietf-tsvwg-tcp-ulp-frame-01.txt, a tsvwg that > proposes changing TCP. Despite Doug's proclamations that the IPS wg > should not be discussing changes to TCP, he now criticizes the IPS > wg for failing to discuss an aspect of a change to TCP??? There's > just no pleasing some people ... especially as I don't recall this > specific issue being raised in the past. I think your using the word smear and this cynical statement are intended to divert attention from concerns expressed rather than addressing them. My critique was with respect to expertise within the IPS in regard to transport related issues. A discussion within the IPS should not be expected to fully vent transport related concerns nor should the IPS be able to declare closure on this subject. 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 > --------------------------------------------------- > > > -----Original Message----- > > From: Douglas Otis [mailto:dotis@sanlight.net] > > Sent: Friday, January 25, 2002 6:13 PM > > To: ips@ece.cmu.edu > > Cc: Tsvwg > > Subject: RE: iSCSI: Framing Steps > > > > > > David, > > > > Thank you for the response. I think a further point should have been > > strongly made. Such changes to TCP are not actions of the IPS > > workgroup. These matters should be discussed within the tsvwg. Even > > matters of Fixed Interval Marking brings concerns with respect to the > > impact even this seemingly innocuous iSCSI option may have. > > > > Should the interval within the FIM be a power of 2, guessing an initial > > sequence value allows injection of packets within existing connections. > > A layer below TCP, as devised for iSCSI, is to place de-encapsulated > > iSCSI information from isolated packets that include marker information > > despite prior packet loss. A general goal of all the framing > > approaches being sought by the IPS wg. > > > > This would require extensive modification of TCP to facilitate this > > behavior. In addition, without the specific details of this scheme, > > largely due to a desire to claim no changes, it is difficult to evaluate > > related security risks. One risk of this scheme is the requirement for > > application specific code to be routinely placed below the transport. > > There are no conventions for instituting the requisite signaling between > > this below the transport layer application process and the modified TCP. > > Should an attack successfully inject even null structures, it would not > > be clear how the transport would behave. > > > > FIM has been suggested by those within the IPS wg that implementers > > consider implementing an otherwise obnoxious scheme requiring the > > injection of markers or suffer from discarded data otherwise retained > > using standard versions of TCP. Clearly just sending these markers are > > not in themselves a risk to TCP. It is their intended use that causes > > concern. This FIM has also been indicated by several including the > > author of iSCSI that FIM is just an interim measure to be followed by a > > full framing scheme later. It is clear this group wishes extensive > > modifications to TCP and does not wish to share these details openly. > > > > One suggestion was to have each iSCSI PDU become framed by a > > TCP segment. Just the reduction in the average packet size within > > a high bandwidth stream will stress standard versions of TCP as > > well as the intervening equipment. SCTP had the foresight to > > include bundling methods. This is just one aspect of these > > proposals to fail consideration within the IPS wg. In general, > > I think the IETF made a wise choice in proposing SCTP as the means > > of incorporating framing within IP protocols and the IPS wg was > > informed of SCTP at the outset of their endeavors. SCTP provides > > many advantages with respect to pressing concerns especially the > > less disruptive nature incorporation of framing using SCTP would > > cause over an attempt of framing within TCP. It is clear there is > > consensus within the IPS wg that SCTP is not to be considered and > > that TCP framing is despite prohibitions within the charter and > > the good judgment of the IETF. The ongoing tacit approval of > > these discussions regarding modification of TCP within the IPS wg > > is troubling. > > > > Doug > > > > > -----Original Message----- > > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] > > On Behalf Of > > > Black_David@emc.com [mailto:David_Black@emc.com] > > > Sent: Wednesday, January 23, 2002 11:10 PM > > > To: ips@ece.cmu.edu > > > Subject: iSCSI: Framing Steps > > > > > > > > > I want to attempt to make some steps towards resolving > > > the framing issues. In reviewing the recent discussions > > > on framing, I have a couple of conclusions: > > > > > > (1) I do not believe that WG consensus (rough or otherwise) > > > can be obtained for a "MUST implement" requirement > > > for any form of framing. > > > (2) The COWS mechanism has a lot of potential, but > > > its newness, the multiple versions that > > > have been mentioned, and the desire for some > > > sort of alignment with new work on DDP/RDMA > > > suggest that COWS is premature to specify as > > > part of iSCSI. > > > > > > I suggest that these conclusions form the > > > basis for further ips WG consideration of framing. > > > > > > Please think carefully before objecting to these > > > conclusions on the list (I'm happy to respond to > > > private questions/expressions of concern). If the > > > framing issue cannot be driven to closure in > > > the next few weeks, I will be forced to conclude > > > that the entire topic is experimental, and hence > > > needs to be removed from the iSCSI specification > > > and handled in separate drafts intended to become > > > experimental RFCs. > > > > > > Thanks, > > > --David > > > > > > p.s. A desire to build NICs that never behave in > > > accordance with an important SHOULD in RFC 1122 > > > (out-of-order segments SHOULD be queued) does not > > > strike me as a good reason for changing the first > > > conclusion above. > > > > > > --------------------------------------------------- > > > 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 Sun Jan 27 23:03: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 XAA08925 for ; Sun, 27 Jan 2002 23:03:54 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0S3Ds626732 for ips-outgoing; Sun, 27 Jan 2002 22:13:54 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bosvwl01 ([216.52.49.35]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g0S3Dpj26724; Sun, 27 Jan 2002 22:13:51 -0500 (EST) Received: from 192.168.200.82 by bosvwl01 (InterScan E-Mail VirusWall NT); Sun, 27 Jan 2002 22:12:44 -0500 Received: from punmsg02.ad.infosys.com ([192.168.170.15]) by INDHUBBHS02.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 28 Jan 2002 08:42:08 +0530 Received: from punmsg01.ad.infosys.com ([192.168.170.16]) by punmsg02.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 28 Jan 2002 08:42:07 +0530 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: remove Date: Mon, 28 Jan 2002 08:42:07 +0530 Message-ID: Thread-Topic: remove Thread-Index: AcGmB+gSpty26oFmSGW1HGWHv8RRQABoZpUg From: "rachna_jain" To: , X-OriginalArrivalTime: 28 Jan 2002 03:12:07.0554 (UTC) FILETIME=[9180E620:01C1A7A9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g0S3Dqj26726 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit remove From owner-ips@ece.cmu.edu Sun Jan 27 23:52:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09924 for ; Sun, 27 Jan 2002 23:52:01 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0S3wpe29213 for ips-outgoing; Sun, 27 Jan 2002 22:58: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 g0S3wnj29207 for ; Sun, 27 Jan 2002 22:58:49 -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 EAA36776; Mon, 28 Jan 2002 04:58:41 +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 g0S401f42290; Mon, 28 Jan 2002 05:00:02 +0100 To: Mr Daniel Lee Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: draft 10 editorial comment X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Mon, 28 Jan 2002 05:59:57 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 28/01/2002 06:00:00, Serialize complete at 28/01/2002 06:00:00 Content-Type: multipart/alternative; boundary="=_alternative 007CEA9CC2256B4C_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 007CEA9CC2256B4C_= Content-Type: text/plain; charset="us-ascii" You are correct - I will remove the text. Thanks, Julo Mr Daniel Lee 25-01-02 23:56 To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: iSCSI: draft 10 editorial comment I believe the following text in section 10.12.1 on pg. 145 is redundant (and confusing) and can be removed: If the response class is 0 the target MAY answer with a Login response with the T bit set to 1 ONLY if the T bit is set to 1 in the request. If the response class is not 0 the T bit value MUST be ignored by the initiator. The above text describes the Login Response PDU's 'T bit' and doesn't belong in the Login Request PDU's section. Also, the term 'response class' is confusing because it isn't used anywhere else in the spec. I think you probably meant to remove the above text anyhow because a beautifully concise version of the same text already exists in the Login Request PDU's section (see the last two lines of 10.13.6). Regards, Daniel Lee Unemployed Person dan@danielslee.com "iSCSI, therefore I am" __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com --=_alternative 007CEA9CC2256B4C_= Content-Type: text/html; charset="us-ascii"
You are correct - I will remove the text.

Thanks,
Julo


Mr Daniel Lee <dan@danielslee.com>

25-01-02 23:56

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        iSCSI: draft 10 editorial comment

       


I believe the following text in section 10.12.1 on pg.
145 is redundant (and confusing) and can be removed:

<TextThatCanBeRemoved>
If the response class is 0 the target MAY answer with
a Login response with the T bit set to 1 ONLY if the T
bit is set to 1 in the request.

If the response class is not 0 the T bit value MUST be
ignored by the initiator.
</TextThatCanBeRemoved>

The above text describes the Login Response PDU's 'T
bit' and doesn't belong in the Login Request PDU's
section.  Also, the term 'response class' is confusing
because it isn't used anywhere else in the spec.  

I think you probably meant to remove the above text
anyhow because a beautifully concise version of the
same text already exists in the Login Request PDU's
section (see the last two lines of 10.13.6).

Regards,

Daniel Lee
Unemployed Person
dan@danielslee.com
"iSCSI, therefore I am"


__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions!
http://auctions.yahoo.com

--=_alternative 007CEA9CC2256B4C_=-- From owner-ips@ece.cmu.edu Mon Jan 28 01:08: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 BAA10720 for ; Mon, 28 Jan 2002 01:08:15 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0S55bV02911 for ips-outgoing; Mon, 28 Jan 2002 00:05:37 -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 g0S55Yj02906 for ; Mon, 28 Jan 2002 00:05:34 -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 GAA84710 for ; Mon, 28 Jan 2002 06:05:27 +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 g0S56kC45892 for ; Mon, 28 Jan 2002 06:06:46 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: Framing Steps X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Mon, 28 Jan 2002 07:06:40 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 28/01/2002 07:06:44, Serialize complete at 28/01/2002 07:06:44 Content-Type: multipart/alternative; boundary="=_alternative 001B0F7EC2256B4F_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001B0F7EC2256B4F_= Content-Type: text/plain; charset="us-ascii" David and team, I have to admit that I am not die-hard fan of Doug Otis's journalistic prose. However by populating with his missives so many working groups he was able to carry some work from IPS to SCTP where CRC32C was selected (that's what bees do but in good faith). And BTW the CRC32C was carried over without so much as a nod to this group or quoting the long analytic and experimental review that some of us (Dafna Sheinwald, Pat Thaler, Vince Cena and myself) worked on for more than a month. On the other hand it sports a CRC implementation (instead of a concise mathematical definition) at least 5 years old and can somewhat mislead implementers, implementation that Doug tried to peddle to this group. I find this behavior highly distasteful in a professional working group and somewhat peculiar as an engineering feat. I will have to carefully consider when and how to use RFC2026 compliance statement in the future. Julian Satran Distinguished Engineer, IBM Reaserch Lab. at Haifa Black_David@emc.com Sent by: owner-ips@ece.cmu.edu 26-01-02 10:31 To: dotis@sanlight.net, ips@ece.cmu.edu cc: tsvwg@ietf.org Subject: RE: iSCSI: Framing Steps Attempting to kill a few red herrings ... TCP is vulnerable to packet injection based on guessing or observing the initial sequence number in the absence of fixed-interval-markers (FIM). The well-known connection hijack attack is an example. An attacker can inject arbitrary data into a connection without FIM and cause TCP to misbehave as a result. FIM does not make this any easier or change the ways in which TCP would misbehave when attacked in this fashion. FIM does not entail any changes to TCP. TCP does not care about where incoming data is placed in memory - it cares about the order in which data is processed by TCP and delivered to the application. The intended usage of FIM affects only the placement of incoming data in memory and hence does not change TCP. Meanwhile, Doug appears to have resumed his smear campaign against the IPS wg. Here are three examples: > FIM has been suggested by those within the IPS wg that implementers consider > implementing an otherwise obnoxious scheme requiring the injection of > markers or suffer from discarded data otherwise retained using standard > versions of TCP. Indeed it is obnoxious, and Doug conveniently omitted the fact that the original message in this thread contains a strong suggestion from this IPS wg chair that such an implementation approach is a bad idea because it violates an important SHOULD in RFC 1122 (SHOULD queue out of order data). Scroll to the bottom of this email - it's still there ... > It is clear this group wishes extensive modifications to TCP and > does not wish to share these details openly. Extensive is in the eye of the beholder, but ALL of the proposed framing schemes have been openly described on the IPS and/or TSVWG lists and/or in Internet-Drafts. > One suggestion was to have each iSCSI PDU become framed by a TCP segment. > Just the reduction in the average packet size within a high bandwidth stream > will stress standard versions of TCP as well as the intervening equipment. > SCTP had the foresight to include bundling methods. This is just one aspect > of these proposals to fail consideration within the IPS wg. This refers to draft-ietf-tsvwg-tcp-ulp-frame-01.txt, a tsvwg that proposes changing TCP. Despite Doug's proclamations that the IPS wg should not be discussing changes to TCP, he now criticizes the IPS wg for failing to discuss an aspect of a change to TCP??? There's just no pleasing some people ... especially as I don't recall this specific issue being raised in the past. 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: Douglas Otis [mailto:dotis@sanlight.net] > Sent: Friday, January 25, 2002 6:13 PM > To: ips@ece.cmu.edu > Cc: Tsvwg > Subject: RE: iSCSI: Framing Steps > > > David, > > Thank you for the response. I think a further point should have been > strongly made. Such changes to TCP are not actions of the IPS workgroup. > These matters should be discussed within the tsvwg. Even matters of Fixed > Interval Marking brings concerns with respect to the impact even this > seemingly innocuous iSCSI option may have. > > Should the interval within the FIM be a power of 2, guessing an initial > sequence value allows injection of packets within existing connections. A > layer below TCP, as devised for iSCSI, is to place de-encapsulated iSCSI > information from isolated packets that include marker information despite > prior packet loss. A general goal of all the framing approaches being > sought by the IPS wg. > > This would require extensive modification of TCP to facilitate this > behavior. In addition, without the specific details of this scheme, largely > due to a desire to claim no changes, it is difficult to evaluate related > security risks. One risk of this scheme is the requirement for application > specific code to be routinely placed below the transport. There are no > conventions for instituting the requisite signaling between this below the > transport layer application process and the modified TCP. Should an attack > successfully inject even null structures, it would not be clear how the > transport would behave. > > FIM has been suggested by those within the IPS wg that implementers consider > implementing an otherwise obnoxious scheme requiring the injection of > markers or suffer from discarded data otherwise retained using standard > versions of TCP. Clearly just sending these markers are not in themselves a > risk to TCP. It is their intended use that causes concern. This FIM has > also been indicated by several including the author of iSCSI that FIM is > just an interim measure to be followed by a full framing scheme later. It > is clear this group wishes extensive modifications to TCP and does not wish > to share these details openly. > > One suggestion was to have each iSCSI PDU become framed by a TCP segment. > Just the reduction in the average packet size within a high bandwidth stream > will stress standard versions of TCP as well as the intervening equipment. > SCTP had the foresight to include bundling methods. This is just one aspect > of these proposals to fail consideration within the IPS wg. In general, I > think the IETF made a wise choice in proposing SCTP as the means of > incorporating framing within IP protocols and the IPS wg was informed of > SCTP at the outset of their endeavors. SCTP provides many advantages with > respect to pressing concerns especially the less disruptive nature > incorporation of framing using SCTP would cause over an attempt of framing > within TCP. It is clear there is consensus within the IPS wg that SCTP is > not to be considered and that TCP framing is despite prohibitions within the > charter and the good judgement of the IETF. The ongoing tacit approval of > these discussions regarding modification of TCP within the IPS wg is troubling. > > Doug > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] > On Behalf Of > > Black_David@emc.com [mailto:David_Black@emc.com] > > Sent: Wednesday, January 23, 2002 11:10 PM > > To: ips@ece.cmu.edu > > Subject: iSCSI: Framing Steps > > > > > > I want to attempt to make some steps towards resolving > > the framing issues. In reviewing the recent discussions > > on framing, I have a couple of conclusions: > > > > (1) I do not believe that WG consensus (rough or otherwise) > > can be obtained for a "MUST implement" requirement > > for any form of framing. > > (2) The COWS mechanism has a lot of potential, but > > its newness, the multiple versions that > > have been mentioned, and the desire for some > > sort of alignment with new work on DDP/RDMA > > suggest that COWS is premature to specify as > > part of iSCSI. > > > > I suggest that these conclusions form the > > basis for further ips WG consideration of framing. > > > > Please think carefully before objecting to these > > conclusions on the list (I'm happy to respond to > > private questions/expressions of concern). If the > > framing issue cannot be driven to closure in > > the next few weeks, I will be forced to conclude > > that the entire topic is experimental, and hence > > needs to be removed from the iSCSI specification > > and handled in separate drafts intended to become > > experimental RFCs. > > > > Thanks, > > --David > > > > p.s. A desire to build NICs that never behave in > > accordance with an important SHOULD in RFC 1122 > > (out-of-order segments SHOULD be queued) does not > > strike me as a good reason for changing the first > > conclusion above. > > > > --------------------------------------------------- > > 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 001B0F7EC2256B4F_= Content-Type: text/html; charset="us-ascii"
David and team,

I have to admit that I am not die-hard fan of Doug Otis's journalistic prose.
However by populating with his missives so many working groups he was able to carry some work from IPS to SCTP where CRC32C was selected (that's what bees do but in good faith).  And BTW the CRC32C was carried over without so much as a nod to this group or quoting the long analytic and experimental review that some of us (Dafna Sheinwald, Pat Thaler, Vince Cena and myself) worked on for more than a month.

On the other hand it sports a CRC implementation (instead of a concise mathematical definition) at least 5 years old and can somewhat mislead implementers, implementation that Doug tried to peddle to this group.

I find this behavior highly distasteful in a professional working group and somewhat peculiar as an engineering feat.

I will have to carefully consider when and how to use RFC2026 compliance statement in the future.

Julian Satran

Distinguished Engineer,
IBM Reaserch Lab. at Haifa




Black_David@emc.com
Sent by: owner-ips@ece.cmu.edu

26-01-02 10:31

       
        To:        dotis@sanlight.net, ips@ece.cmu.edu
        cc:        tsvwg@ietf.org
        Subject:        RE: iSCSI: Framing Steps

       


Attempting to kill a few red herrings ...

TCP is vulnerable to packet injection based on guessing or observing
the initial sequence number in the absence of fixed-interval-markers
(FIM).  The well-known connection hijack attack is an example.  An
attacker can inject arbitrary data into a connection without FIM and
cause TCP to misbehave as a result.  FIM does not make this any
easier or change the ways in which TCP would misbehave when attacked
in this fashion.

FIM does not entail any changes to TCP.  TCP does not care about
where incoming data is placed in memory - it cares about the order
in which data is processed by TCP and delivered to the application.
The intended usage of FIM affects only the placement of incoming
data in memory and hence does not change TCP.

Meanwhile, Doug appears to have resumed his smear campaign against
the IPS wg.  Here are three examples:

> FIM has been suggested by those within the IPS wg that implementers
consider
> implementing an otherwise obnoxious scheme requiring the injection of
> markers or suffer from discarded data otherwise retained using standard
> versions of TCP.

Indeed it is obnoxious, and Doug conveniently omitted the fact that the
original message in this thread contains a strong suggestion from this
IPS wg chair that such an implementation approach is a bad idea because
it violates an important SHOULD in RFC 1122 (SHOULD queue out of order
data).
Scroll to the bottom of this email - it's still there ...

> It is clear this group wishes extensive modifications to TCP and
> does not wish to share these details openly.

Extensive is in the eye of the beholder, but ALL of the proposed framing
schemes have been openly described on the IPS and/or TSVWG lists and/or
in Internet-Drafts.

> One suggestion was to have each iSCSI PDU become framed by a TCP segment.
> Just the reduction in the average packet size within a high bandwidth
stream
> will stress standard versions of TCP as well as the intervening equipment.
> SCTP had the foresight to include bundling methods.  This is just one
aspect
> of these proposals to fail consideration within the IPS wg.

This refers to draft-ietf-tsvwg-tcp-ulp-frame-01.txt, a tsvwg that
proposes changing TCP.  Despite Doug's proclamations that the IPS wg
should not be discussing changes to TCP, he now criticizes the IPS
wg for failing to discuss an aspect of a change to TCP???  There's
just no pleasing some people ... especially as I don't recall this
specific issue being raised in the past.

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: Douglas Otis [mailto:dotis@sanlight.net]
> Sent: Friday, January 25, 2002 6:13 PM
> To: ips@ece.cmu.edu
> Cc: Tsvwg
> Subject: RE: iSCSI: Framing Steps
>
>
> David,
>
> Thank you for the response.  I think a further point should have been
> strongly made.  Such changes to TCP are not actions of the IPS workgroup.
> These matters should be discussed within the tsvwg.  Even matters of Fixed
> Interval Marking brings concerns with respect to the impact even this
> seemingly innocuous iSCSI option may have.
>
> Should the interval within the FIM be a power of 2, guessing an initial
> sequence value allows injection of packets within existing connections.  A
> layer below TCP, as devised for iSCSI, is to place de-encapsulated iSCSI
> information from isolated packets that include marker information  despite
> prior packet loss.  A general goal of all the framing approaches being
> sought by the IPS wg.
>
> This would require extensive modification of TCP to facilitate this
> behavior.  In addition, without the specific details of this scheme,
largely
> due to a desire to claim no changes, it is difficult to evaluate related
> security risks.  One risk of this scheme is the requirement for
application
> specific code to be routinely placed below the transport.  There are no
> conventions for instituting the requisite signaling between this below the
> transport layer application process and the modified TCP.  Should an
attack
> successfully inject even null structures, it would not be clear how the
> transport would behave.
>
> FIM has been suggested by those within the IPS wg that implementers
consider
> implementing an otherwise obnoxious scheme requiring the injection of
> markers or suffer from discarded data otherwise retained using standard
> versions of TCP.  Clearly just sending these markers are not in themselves
a
> risk to TCP.  It is their intended use that causes concern.  This FIM has
> also been indicated by several including the author of iSCSI that FIM is
> just an interim measure to be followed by a full framing scheme later.  It
> is clear this group wishes extensive modifications to TCP and does not
wish
> to share these details openly.
>
> One suggestion was to have each iSCSI PDU become framed by a TCP segment.
> Just the reduction in the average packet size within a high bandwidth
stream
> will stress standard versions of TCP as well as the intervening equipment.
> SCTP had the foresight to include bundling methods.  This is just one
aspect
> of these proposals to fail consideration within the IPS wg.  In general, I
> think the IETF made a wise choice in proposing SCTP as the means of
> incorporating framing within IP protocols and the IPS wg was informed of
> SCTP at the outset of their endeavors.  SCTP provides many advantages with
> respect to pressing concerns especially the less disruptive nature
> incorporation of framing using SCTP would cause over an attempt of framing
> within TCP.  It is clear there is consensus within the IPS wg that SCTP is
> not to be considered and that TCP framing is despite prohibitions within
the
> charter and the good judgement of the IETF.  The ongoing tacit approval of
> these discussions regarding modification of TCP within the IPS wg is
troubling.
>
> Doug
>
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]
> On Behalf Of
> > Black_David@emc.com [mailto:David_Black@emc.com]
> > Sent: Wednesday, January 23, 2002 11:10 PM
> > To: ips@ece.cmu.edu
> > Subject: iSCSI: Framing Steps
> >
> >
> > I want to attempt to make some steps towards resolving
> > the framing issues.  In reviewing the recent discussions
> > on framing, I have a couple of conclusions:
> >
> > (1) I do not believe that WG consensus (rough or otherwise)
> >                  can be obtained for a "MUST implement" requirement
> >                  for any form of framing.
> > (2) The COWS mechanism has a lot of potential, but
> >                  its newness, the multiple versions that
> >                  have been mentioned, and the desire for some
> >                  sort of alignment with new work on DDP/RDMA
> >                  suggest that COWS is premature to specify as
> >                  part of iSCSI.
> >
> > I suggest that these conclusions form the
> > basis for further ips WG consideration of framing.
> >
> > Please think carefully before objecting to these
> > conclusions on the list (I'm happy to respond to
> > private questions/expressions of concern).  If the
> > framing issue cannot be driven to closure in
> > the next few weeks, I will be forced to conclude
> > that the entire topic is experimental, and hence
> > needs to be removed from the iSCSI specification
> > and handled in separate drafts intended to become
> > experimental RFCs.
> >
> > Thanks,
> > --David
> >
> > p.s. A desire to build NICs that never behave in
> > accordance with an important SHOULD in RFC 1122
> > (out-of-order segments SHOULD be queued) does not
> > strike me as a good reason for changing the first
> > conclusion above.
> >
> > ---------------------------------------------------
> > 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 001B0F7EC2256B4F_=-- From owner-ips@ece.cmu.edu Mon Jan 28 04:03: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 EAA20763 for ; Mon, 28 Jan 2002 04:03:14 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0S86pQ12474 for ips-outgoing; Mon, 28 Jan 2002 03:06:51 -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 g0S86oj12470 for ; Mon, 28 Jan 2002 03:06:50 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 03:01:46 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029373D7@CORPMX14> From: Black_David@emc.com To: dotis@sanlight.net, ips@ece.cmu.edu Cc: tsvwg@ietf.org Subject: RE: iSCSI: Framing Steps Date: Mon, 28 Jan 2002 02:53: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 > > TCP is vulnerable to packet injection based on guessing or observing > > the initial sequence number in the absence of fixed-interval-markers > > (FIM). The well-known connection hijack attack is an example. An > > attacker can inject arbitrary data into a connection without FIM and > > cause TCP to misbehave as a result. FIM does not make this any > > easier or change the ways in which TCP would misbehave when attacked > > in this fashion. > > FIM enables *processing* of packets out of sequence from the initial send. > The intent of FIM is to make such processing possible and that *does* enable > a greater opportunity for attack especially if the measure is predictable > within future headers. Nonsense. TCP processes packets in the same order (i.e., the order received) with or without FIM. TCP would not need or use FIM to find TCP headers, hence FIM provides no additional opportunity to inject a fake TCP header. Every TCP receiver already has to perform processing on packets "out of sequence from the initial send" due to drops and reordering that may happen in the network; this processing may include queuing to wait for missing segments to arrive. FIM changes only the memory locations of the packets that are processed, not the order of their processing. > > FIM does not entail any changes to TCP. TCP does not care about > > where incoming data is placed in memory - it cares about the order > > in which data is processed by TCP and delivered to the application. > > A process that examines application specific structures at the packet (IP) > level, to then move portions of the expected TCP byte stream into user space > based on application references matching these structures, is *not* a > modification to TCP provided there is a *sequential* order of delivery? That is correct. RFC 793 specifically allows sharing of storage between TCP and the user provided that delivery order is maintained at the interface, and even gives an example of a data structure that could be used (see below). > Clearly placing a portion of the application below TCP is a modification to > TCP and network layering. Are you referring to a means at the TCP API to > hide this activity? Are you saying that the TCP API does not change? > How is this done without changing TCP? The only change TCP sees is that the location of packets in memory is different. As far as TCP is concerned, this is equivalent to replacing the operating system's memory allocator, including possible modifications to TCP code to use the new allocator (e.g., the BSD and streams implementations of TCP use rather different memory allocators). As for the "TCP API" ... > The application specific processing below this modified TCP transport is to > de-encapsulate the iSCSI payloads into user space. iSCSI user space may not > be satisfied in the sequence they were established. Both the de-encapsulation into user space and the satisfaction of receive operations out of order are allowed by RFC 793. Here's the text from pp. 48-49 (definition of Receive in the nominal TCP/user interface): To distinguish among several outstanding RECEIVEs and to take care of the case that a buffer is not completely filled, the return code is accompanied by both a buffer pointer and a byte count indicating the actual length of the data received. Alternative implementations of RECEIVE might have the TCP allocate buffer storage, or the TCP might share a ring buffer with the user. The first paragraph appears to allow completion of RECEIVEs out of order and the second definitely allows sharing of TCP's data storage with "the user". In practice, most TCP implementations complete RECEIVEs in order for simplicity and to avoid surprises at the socket API ... Picking up the "TCP API" issue from above, no modifications are needed to the nominal API defined in RFC 793. The intended use of FIM is not possible through the socket API (not an IETF standard, FWIW), but there is no proposal to expose FIM through that API - it's intended for combined implementations of TCP, FIM, and iSCSI, and hence would only be specified as part of iSCSI. > The complexity involved > will require modification of TCP to support this buffer handling and > application specific structure processing. In the case of iSCSI, the > content of the byte stream is not known before hand. This activity below > TCP places and splices sections of the TCP byte stream into designated iSCSI > user space. Clearly there are many questions one may have with respect to > what and when TCP validates and delivers. Modifications to TCP implementations are definitely involved. The answers to the questions can generally be found in RFC 793 and 1122 because FIM makes no changes to "what and when TCP validates and delivers". For example ... > TCP could easily reject a packet > based on the byte sequence within headers that was not rejected by this > "below the transport process" that would be unable to see the header > continuum. Since FIM performs no protocol processing (it only allocates memory for the incoming packet), TCP rejects the packet in the usual fashion, causing it never to be delivered to iSCSI. Even with FIM, data is not delivered to iSCSI until TCP delivers it in sequence, hence the rejected packet has no effect on iSCSI. > This added state below the TCP transport provides opportunity > for attack or in some implementations, poor behavior. Any work on implementations has the potential to introduce bugs; in this respect FIM is no different from any other implementation work. > > The intended usage of FIM affects only the placement of incoming > > data in memory and hence does not change TCP. > > Placement of application specific payloads into regions matched against > application specific structure content prior to being handled by the TCP > layer is a change to TCP. TCP is not able to manipulate buffers in this > manner without extensive modification. Such modification is quite possible > however, and all the details should be explored before the use of this > scheme is placed into a standards draft however. I would agree insofar as changes to TCP implementation code are required to use FIM in the fashion intended. I maintain that FIM does not change the TCP protocol as specified in RFC 793 and 1122. The memory and buffer allocation aspects of TCP have not been standardized by the IETF for very good reasons. > My concern remains that the IPS wg is NOT the place to discuss these > concerns as that is not their expertise nor their charter. I have no problem with bringing this sort of issue to tsvwg, as long as it's done in an honest fashion. Specifically, given Doug's past insistence that the IPS wg not discuss TCP changes, he should not complain that the IPS wg has failed to adequately discuss TCP changes in the TSVWG TCP ULP framing draft. Finally, on requirements: > You have also > asked the group to drive the framing issue to conclusion but you failed to > indicate that such discussion should not take place within the IPS. iSCSI requirements for use of framing mechanisms are proper for discussion in IPS. That requirements discussion will be driven to a conclusion in IPS because that conclusion will be reflected in the iSCSI specification. > Ensure that an error is not made where everyone expects such modifications > to TCP even if done unofficially by the IPS. Just in case anyone else is confused - TCP ULP framing is a tsvwg draft, and FIM is currently in the iSCSI draft because it does not modify the TCP protocol. 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 Jan 28 06: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 GAA22227 for ; Mon, 28 Jan 2002 06:20:39 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0SAFOv29608 for ips-outgoing; Mon, 28 Jan 2002 05:15:24 -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 g0SAFNj29603 for ; Mon, 28 Jan 2002 05:15:23 -0500 (EST) Received: (cpmta 10842 invoked from network); 28 Jan 2002 02:15:15 -0800 Received: from 64.130.130.105 (HELO dougrmt) by smtp.telocity.com (209.228.32.218) with SMTP; 28 Jan 2002 02:15:15 -0800 X-Sent: 28 Jan 2002 10:15:15 GMT From: "Douglas Otis" To: , Cc: Subject: RE: iSCSI: Framing Steps Date: Mon, 28 Jan 2002 02:16:34 -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 Importance: Normal In-Reply-To: <277DD60FB639D511AC0400B0D068B71E029373D7@CORPMX14> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, > > > TCP is vulnerable to packet injection based on guessing or observing > > > the initial sequence number in the absence of fixed-interval-markers > > > (FIM). The well-known connection hijack attack is an example. An > > > attacker can inject arbitrary data into a connection without FIM and > > > cause TCP to misbehave as a result. FIM does not make this any > > > easier or change the ways in which TCP would misbehave when attacked > > > in this fashion. > > > > FIM enables *processing* of packets out of sequence from the > > initial send. The intent of FIM is to make such processing > > possible and that *does* enable a greater opportunity for > > attack especially if the measure is predictable within future > > headers. > > Nonsense. TCP processes packets in the same order (i.e., the order > received) with or without FIM. TCP would not need or use FIM to > find TCP headers, hence FIM provides no additional opportunity to > inject a fake TCP header. Every TCP receiver already has to perform > processing on packets "out of sequence from the initial send" due to > drops and reordering that may happen in the network; this processing > may include queuing to wait for missing segments to arrive. FIM > changes only the memory locations of the packets that are processed, > not the order of their processing. The concerns are not with TCP but with this process running below TCP. This would be a stateful process that could indeed be confused by an inappropriate reliance on a marker. This change in location of content arrival would be a complex process that includes application specific structure handling. This "only changes memory locations of" is an application specific process. In addition, it is not the packet location that is being changed, but the content of the packet or it would be of little value. There are already zero copy schemes that do not rely on markers to achieve appropriate packet placement. The iSCSI appendix clearly indicates the value of these markers is to locate iSCSI specific structures within the TCP byte stream should there be dropped packets. FIM is to allow processing of these structures in the face of previously dropped packets. > > > FIM does not entail any changes to TCP. TCP does not care about > > > where incoming data is placed in memory - it cares about the order > > > in which data is processed by TCP and delivered to the application. > > > > A process that examines application specific structures at the > > packet (IP) level, to then move portions of the expected TCP byte > > stream into user space based on application references matching > > these structures, is *not* a modification to TCP provided there > > is a *sequential* order of delivery? > > That is correct. RFC 793 specifically allows sharing of storage between > TCP and the user provided that delivery order is maintained at the > interface, and even gives an example of a data structure that could be > used (see below). > > > Clearly placing a portion of the application below TCP is a modification > > to TCP and network layering. Are you referring to a means at the > > TCP API to hide this activity? Are you saying that the TCP API does not > > change? How is this done without changing TCP? > > The only change TCP sees is that the location of packets in memory is > different. As far as TCP is concerned, this is equivalent to replacing > the operating system's memory allocator, including possible modifications > to TCP code to use the new allocator (e.g., the BSD and streams > implementations of TCP use rather different memory allocators). As for > the "TCP API" ... > > > The application specific processing below this modified TCP transport is > > to de-encapsulate the iSCSI payloads into user space. iSCSI user space > > may not be satisfied in the sequence they were established. > > Both the de-encapsulation into user space and the satisfaction of receive > operations out of order are allowed by RFC 793. Here's the text from > pp. 48-49 (definition of Receive in the nominal TCP/user interface): > > To distinguish among several outstanding RECEIVEs and to take > care of the case that a buffer is not completely filled, the > return code is accompanied by both a buffer pointer and a byte > count indicating the actual length of the data received. > > Alternative implementations of RECEIVE might have the TCP > allocate buffer storage, or the TCP might share a ring buffer > with the user. > > The first paragraph appears to allow completion of RECEIVEs out of order > and the second definitely allows sharing of TCP's data storage with > "the user". In practice, most TCP implementations complete RECEIVEs in > order for simplicity and to avoid surprises at the socket API ... > > Picking up the "TCP API" issue from above, no modifications are needed > to the nominal API defined in RFC 793. The intended use of FIM is > not possible through the socket API (not an IETF standard, FWIW), but > there is no proposal to expose FIM through that API - it's intended > for combined implementations of TCP, FIM, and iSCSI, and hence would > only be specified as part of iSCSI. TCP buffer treatment does not begin to compare to the complex process that would be employed to handle the dispatching of the TCP byte stream anticipated by iSCSI. The TCP byte stream is commonly stored out of sequence from the send but this process does not depend on the data. This iSCSI structure marker process goes well beyond a simple buffer assignment, is highly stateful, and prone to errors where recovery would be difficult. Indeed, TCP allows flexibility within the API with respect to buffer handling, but I think it would be a mistake to assume this flexibility allows modes of operation dependent upon the recognition and handling of application specific structures. iSCSI wishes to run a portion of the application in front of TCP and to do this on a byte by byte basis. TCP can not "deliver" data to the application out of sequence so logically there should be no need for such markers if TCP were allowed to run first. iSCSI structure recognition, synchronization, validation would be run prior to the normal TCP delivery and is the reasoning for the use of these PDU markers. > > The complexity involved will require modification of TCP to support > > this buffer handling and application specific structure processing. > > In the case of iSCSI, the content of the byte stream is not known > > before hand. This activity below TCP places and splices sections > > of the TCP byte stream into designated iSCSI user space. Clearly > > there are many questions one may have with respect to what and when > > TCP validates and delivers. > > Modifications to TCP implementations are definitely involved. The > answers to the questions can generally be found in RFC 793 and 1122 > because FIM makes no changes to "what and when TCP validates and > delivers". > For example ... > > > TCP could easily reject a packet based on the byte sequence within > > headers that was not rejected by this "below the transport process" > > that would be unable to see the header continuum. > > Since FIM performs no protocol processing (it only allocates > memory for the incoming packet), TCP rejects the packet in the usual > fashion, causing it never to be delivered to iSCSI. Even with FIM, > data is not delivered to iSCSI until TCP delivers it in sequence, > hence the rejected packet has no effect on iSCSI. The goal of the marker has nothing to do with what may be described as zero copy TCP. FIM is to locate iSCSI PDUs as defined in the iSCSI draft. The driving motivation behind this effort is to allow a direct placement of the data payload portion of the iSCSI structures into the associated user space referenced by the tags within these structures. In other words, a type of direct data placement. The "deliveries" to TCP from this process would be an interesting topic. Deliveries in turn from TCP back into the application would need to know if this "below the transport" process had finished successfully or had even been run. This is not TCP. > > This added state below the TCP transport provides opportunity > > for attack or in some implementations, poor behavior. > > Any work on implementations has the potential to introduce bugs; in > this respect FIM is no different from any other implementation work. This will impact many applications that will also be using the same stack. Ensuring sound concepts would be to the benefit of IPS as well as other working groups. Should the implementation of FIM create substantial security risks by nature of its design, then such design should be stopped. > > > The intended usage of FIM affects only the placement of incoming > > > data in memory and hence does not change TCP. > > > > Placement of application specific payloads into regions matched against > > application specific structure content prior to being handled by the TCP > > layer is a change to TCP. TCP is not able to manipulate buffers in this > > manner without extensive modification. Such modification is quite > > possible however, and all the details should be explored before the use > > of this scheme is placed into a standards draft however. > > I would agree insofar as changes to TCP implementation code are > required to use FIM in the fashion intended. I maintain that FIM does > not change the TCP protocol as specified in RFC 793 and 1122. The memory > and buffer allocation aspects of TCP have not been standardized > by the IETF for very good reasons. Please refer to my prior statement. > > My concern remains that the IPS wg is NOT the place to discuss these > > concerns as that is not their expertise nor their charter. > > I have no problem with bringing this sort of issue to tsvwg, as long > as it's done in an honest fashion. Specifically, given Doug's past > insistence that the IPS wg not discuss TCP changes, he should not > complain that the IPS wg has failed to adequately discuss TCP changes > in the TSVWG TCP ULP framing draft. > > Finally, on requirements: > > > You have also asked the group to drive the framing issue to conclusion > > but you failed to indicate that such discussion should not take place > > within the IPS. > > iSCSI requirements for use of framing mechanisms are proper for discussion > in IPS. That requirements discussion will be driven to a conclusion in > IPS because that conclusion will be reflected in the iSCSI specification. > > > Ensure that an error is not made where everyone expects such > > modifications to TCP even if done unofficially by the IPS. > > Just in case anyone else is confused - TCP ULP framing is a tsvwg draft, > and FIM is currently in the iSCSI draft because it does not modify the > TCP protocol. I think it would be a reasonable statement that I do not agree with your assessment on the impact to TCP created by the optional markers used in iSCSI. The IPS group represents talented people highly skilled in the field of storage but could benefit from the advice of the community at large with respect to this topic. As I do feel an implementation as intended of the iSCSI marker scheme would be a modification to TCP, I also felt strongly that this topic get raised within the tsvwg work group. I would like to 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 Mon Jan 28 11:37: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 LAA01901 for ; Mon, 28 Jan 2002 11:37:35 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0SG9NM21809 for ips-outgoing; Mon, 28 Jan 2002 11:09:23 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lmoxch04.veritas.com (london-bridge.east.veritas.com [207.30.27.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0SG9Jj21800 for ; Mon, 28 Jan 2002 11:09:20 -0500 (EST) Received: by LMOXCH04 with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 11:03:29 -0500 Message-ID: <8BE017CC8923D511A00A0008C78605EE01544BF3@LMOXCH04> From: David Dillard To: "IETF IPS Workgroup Reflector (E-mail)" Subject: iSCSI: One Node or Two? Date: Mon, 28 Jan 2002 11:03:24 -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 As defined in the latest draft an iSCSI Node "... represents a single iSCSI initiator or iSCSI target." By this definition an LU that acts as both an initiator and a target, such as a data mover for extended copy, is two iSCSI nodes. This LU will have two iSCSI names, one for the initiator side of the LU and one for the target. Therefore, there will be two iSNS "entries" for this LU. My question is: Is this intended? Regards, David From owner-ips@ece.cmu.edu Mon Jan 28 11:37: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 LAA01913 for ; Mon, 28 Jan 2002 11:37:47 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0SFZrY19041 for ips-outgoing; Mon, 28 Jan 2002 10:35:53 -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 g0SFZnj19029 for ; Mon, 28 Jan 2002 10:35: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 g0SFZWJ16188; Mon, 28 Jan 2002 10:35:32 -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 g0SFZVQ10307; Mon, 28 Jan 2002 10:35:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15445.28613.975000.100455@gargle.gargle.HOWL> Date: Mon, 28 Jan 2002 10:35:33 -0500 From: Paul Koning To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: Error in ips-security-07 References: <277DD60FB639D511AC0400B0D068B71E039C7EAE@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 26 January 2002) by Black_David@emc.com: > This is the infamous "dangling SA" issue discussed in ipsec > in the past. While I don't recall its resolution, the IKEv2 > draft prohibits dangling SAs, and the IPS Security draft is > taking the same position. OTOH, I seem to recall that IKEv1 > implementations differ on whether dangling SAs are allowed. > Paul - are you suggesting that prohibiting dangling SAs > would unnecessarily exclude some IKEv1 implementations to > our detriment? I'm not sure what "dangling SAs" are, or whether that term applies to the case you're talking about here. I'll have to look at IKEv2 to see what the story is there. As for IKEv1, the spec explicitly discusses deleting the Phase 1 SA immediately after the Phase 2 negotation (Quick Mode) has been performed, in situations where you want Perfect Forward Secrecy. So it's not just that this is silently permitted -- it is explicitly recommended. Therefore I think it is a very bad idea for the IPS security spec to explicitly disallow that same behavior! I've run into several implementations that built in an assumption that the Phase 2 SA is subordinate to the Phase 1 SA. That's simply a wrong assumption, as the text I quoted makes clear, and such assumptions caused interop problems in interop test sessions. I remember having to fix this bug in our implementation at some point. We need to make sure we don't duplicate those bugs here. In any event, I cannot see any reason for the IPS spec to discuss this topic at all. SAs should be deleted when the IKE/IPsec specs call for their deletion and not otherwise. Why should IPS care what those rules are? We already have a lot of dabbling in internal IPsec/IKE detail going on in the IPS security spec. Talking about requirements subsetting is one thing -- restating IKE algorithms is quite another, especially if the restatement conflicts with the authoritative text. It *is* correct for the IPS spec to say what you do to a connection when the SA protecting it goes away. That's already covered (on page 12); the current text makes sense to me. paul From owner-ips@ece.cmu.edu Mon Jan 28 11:46: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 LAA02085 for ; Mon, 28 Jan 2002 11:46:09 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0SFelw19379 for ips-outgoing; Mon, 28 Jan 2002 10:40:47 -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 g0SFegj19369 for ; Mon, 28 Jan 2002 10:40:43 -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 g0SFeQJ16218; Mon, 28 Jan 2002 10:40:26 -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 g0SFeOt10767; Mon, 28 Jan 2002 10:40:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15445.28907.317000.999263@gargle.gargle.HOWL> Date: Mon, 28 Jan 2002 10:40:27 -0500 From: Paul Koning To: Black_David@emc.com Cc: Eddy_Quicksall@ivivity.com, ips@ece.cmu.edu Subject: RE: iSCSI: not offering a key References: <277DD60FB639D511AC0400B0D068B71E039C7EAC@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 26 January 2002) by Black_David@emc.com: > > 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: > ... > (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 But that's an artifact of a peculiar design approach for a negotiation algorithm. The obvious design approach says that there are two ways to *encode* a key having the default value: by sending the key with that value, and by omitting that key. Those two encodings should have the same effect on the negotiation state machine. That approach is far easier to understand and implement. Given that approach, there cannot possibly be an extra message resulting from one encoding or the other, because the state machine reacts the same. What we see now is reasoning backwards from the design. In other words: the starting position was to make the two encodings mean different things; the state machine was constructed in such a way that one results in more messages than the other; finally, that property is used as an argument for why the distinction has to exist. But that's circular reasoning: do away with the distinction, and reduce the state machine to the shorter of the two cases, and the whole problem goes away. paul From owner-ips@ece.cmu.edu Mon Jan 28 13:15: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 NAA04834 for ; Mon, 28 Jan 2002 13:15:55 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0SGiHe24869 for ips-outgoing; Mon, 28 Jan 2002 11:44:17 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0SGiFj24865 for ; Mon, 28 Jan 2002 11:44:15 -0500 (EST) 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 IAA19642; Mon, 28 Jan 2002 08:44:03 -0800 (PST) Message-ID: <3C557CA1.333E2781@cisco.com> Date: Mon, 28 Jan 2002 10:30:25 -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: David Dillard CC: "IETF IPS Workgroup Reflector (E-mail)" Subject: Re: iSCSI: One Node or Two? References: <8BE017CC8923D511A00A0008C78605EE01544BF3@LMOXCH04> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David- The "or" is meant to be a non-exclusive or. An iSCSI Node can be both an initiator and a target, and have the same iSCSI name for both. See draft-ietf-ips-iscsi-name-disc-04: > 2. iSCSI Names > > The main addressable, discoverable entity in iSCSI is an iSCSI > Node. An iSCSI node can be either an initiator, a target, or > both. I agree that we should fix up the wording in the iSCSI draft to clarify this. How about changing: Section 1. Definitions: > - iSCSI Name: The name of an iSCSI initiator or iSCSI target. To: - iSCSI Name: The name of an iSCSI node, which can be an iSCSI initiator, target, or both. 2.5.1 iSCSI Architecture Model > b) iSCSI Node - The iSCSI Node represents a single iSCSI > initiator or iSCSI target. There are one or more iSCSI > Nodes within a Network Entity. To: b) iSCSI Node - The iSCSI Node represents a single iSCSI initiator and/or iSCSI target. An iSCSI Node can be both and initiator and a target. There are one or more iSCSI Nodes within a Network Entity. I think that these two changes should clear this up. -- Mark David Dillard wrote: > > As defined in the latest draft an iSCSI Node "... represents a single iSCSI > initiator or iSCSI target." > > By this definition an LU that acts as both an initiator and a target, such > as a data mover for extended copy, is two iSCSI nodes. This LU will have > two iSCSI names, one for the initiator side of the LU and one for the > target. Therefore, there will be two iSNS "entries" for this LU. > > My question is: Is this intended? > > Regards, > > David -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Mon Jan 28 13:20: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 NAA04930 for ; Mon, 28 Jan 2002 13:20:48 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0SHg9i00114 for ips-outgoing; Mon, 28 Jan 2002 12:42: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 g0SHg7j00110 for ; Mon, 28 Jan 2002 12:42:07 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 12:41:47 -0500 Message-ID: <25369470B6F0D41194820002B328BDD220256A@ATLOPS> From: Eddy Quicksall To: "julian_satran@il. ibm. com (E-mail)" Cc: ips@ece.cmu.edu, "Robert D. Russell" Subject: RE: iSCSI: not offering a key Date: Mon, 28 Jan 2002 12:41:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A823.0E0ED7A0" 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_01C1A823.0E0ED7A0 Content-Type: text/plain; charset="iso-8859-1" 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_01C1A823.0E0ED7A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

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<= o:p>

 

=

-----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_01C1A823.0E0ED7A0-- From owner-ips@ece.cmu.edu Mon Jan 28 13:24: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 NAA05082 for ; Mon, 28 Jan 2002 13:24:04 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0SHRDb28688 for ips-outgoing; Mon, 28 Jan 2002 12:27:13 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lmoxch04.veritas.com (london-bridge.east.veritas.com [207.30.27.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0SHR9j28682 for ; Mon, 28 Jan 2002 12:27:10 -0500 (EST) Received: by LMOXCH04 with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 12:21:17 -0500 Message-ID: <8BE017CC8923D511A00A0008C78605EE01544BF8@LMOXCH04> From: David Dillard To: "'Mark Bakke'" Cc: "IETF IPS Workgroup Reflector (E-mail)" Subject: RE: iSCSI: One Node or Two? Date: Mon, 28 Jan 2002 12:21: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 Mark, I agree that your suggested rewordings clear things up (certainly works for me anyway). Thanks, David > -----Original Message----- > From: Mark Bakke [mailto:mbakke@cisco.com] > Sent: Monday, January 28, 2002 11:30 AM > To: David Dillard > Cc: IETF IPS Workgroup Reflector (E-mail) > Subject: Re: iSCSI: One Node or Two? > > > David- > > The "or" is meant to be a non-exclusive or. An iSCSI Node can > be both an initiator and a target, and have the same iSCSI name > for both. See draft-ietf-ips-iscsi-name-disc-04: > > > 2. iSCSI Names > > > > The main addressable, discoverable entity > in iSCSI is an iSCSI > > Node. An iSCSI node can be either an > initiator, a target, or > > both. > > I agree that we should fix up the wording in the iSCSI draft to > clarify this. How about changing: > > Section 1. Definitions: > > - iSCSI Name: The name of an iSCSI initiator or > iSCSI target. > > To: > > - iSCSI Name: The name of an iSCSI node, which can be an iSCSI > initiator, target, or both. > > 2.5.1 iSCSI Architecture Model > > b) iSCSI Node - The iSCSI Node represents a > single iSCSI > > initiator or iSCSI target. There are one > or more iSCSI > > Nodes within a Network Entity. > > To: > > b) iSCSI Node - The iSCSI Node represents a > single iSCSI > initiator and/or iSCSI target. An iSCSI Node > can be both > and initiator and a target. There are one or > more iSCSI > Nodes within a Network Entity. > > > I think that these two changes should clear this up. > > -- > Mark > > > David Dillard wrote: > > > > As defined in the latest draft an iSCSI Node "... > represents a single iSCSI > > initiator or iSCSI target." > > > > By this definition an LU that acts as both an initiator and > a target, such > > as a data mover for extended copy, is two iSCSI nodes. > This LU will have > > two iSCSI names, one for the initiator side of the LU and > one for the > > target. Therefore, there will be two iSNS "entries" for this LU. > > > > My question is: Is this intended? > > > > Regards, > > > > David > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 > From owner-ips@ece.cmu.edu Mon Jan 28 13:29: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 NAA05168 for ; Mon, 28 Jan 2002 13:29:45 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0SHnpv00787 for ips-outgoing; Mon, 28 Jan 2002 12:49:51 -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 g0SHnnj00782 for ; Mon, 28 Jan 2002 12:49:49 -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 MAA60854; Mon, 28 Jan 2002 12:46:41 -0500 Received: from d03nm014.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 g0SHngl254480; Mon, 28 Jan 2002 10:49:42 -0700 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: One Node or Two? To: David Dillard Cc: "IETF IPS Workgroup Reflector (E-mail)" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Mon, 28 Jan 2002 09:48:46 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 01/28/2002 10:49:42 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk David. It is possible that this 2 way target has two different Names. However, since the SCSI Initiator Port is a dynamically created entity, and the only unique part of its ID (within the Initiator Node) is its ISID, there is no reason there has to be a different iSCSI Node Name. An implementation, however, could create a node that is uses for all iSCSI Initiator functions, however, there is no hard reason for that, and depending on how it is named it may either be more or less confusing to the Administrator. . . . 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 David Dillard @ece.cmu.edu on 01/28/2002 08:03:24 AM Sent by: owner-ips@ece.cmu.edu To: "IETF IPS Workgroup Reflector (E-mail)" cc: Subject: iSCSI: One Node or Two? As defined in the latest draft an iSCSI Node "... represents a single iSCSI initiator or iSCSI target." By this definition an LU that acts as both an initiator and a target, such as a data mover for extended copy, is two iSCSI nodes. This LU will have two iSCSI names, one for the initiator side of the LU and one for the target. Therefore, there will be two iSNS "entries" for this LU. My question is: Is this intended? Regards, David From owner-ips@ece.cmu.edu Mon Jan 28 14:40: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 OAA06878 for ; Mon, 28 Jan 2002 14:40:51 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0SIOWH03747 for ips-outgoing; Mon, 28 Jan 2002 13:24:32 -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 g0SIOUj03742 for ; Mon, 28 Jan 2002 13:24:30 -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 TAA132516; Mon, 28 Jan 2002 19:24:11 +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 g0SIPT183042; Mon, 28 Jan 2002 19:25:31 +0100 To: "Amir Shalit" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: SCSI Format/Copy CDB support X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Mon, 28 Jan 2002 20:25:22 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 28/01/2002 20:25:29, Serialize complete at 28/01/2002 20:25:29 Content-Type: multipart/alternative; boundary="=_alternative 00645D60C2256B4F_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00645D60C2256B4F_= Content-Type: text/plain; charset="us-ascii" That would be a mistake. It may affect commands intended to be dropped. If the window has moved past CmdSN you DO NOT reissue the command (that is clear in the text). Julo "Amir Shalit" 28-01-02 19:35 To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: SCSI Format/Copy CDB support Julo, We only need to ADD a single line to section 2.2.2.1 as follows: "CmdSN must change if the ExpCmdSN/MaxCmdSN window has moved." Section 2.2.2.1 is saying: > "A numbered iSCSI request will not change its allocated CmdSN > regardless of the number of times and circumstances in which it is > reissued." Amir From David Black: The CmdSN window should take care of the "long time" issue - once the Window (ExpCmdSN/MaxCmdSN) has moved past a particular CmdSN, the initiator knows that the target successfully received the command, and reissuing the command with the same CmdSN would be an error. Julian - please add a suitable clarification to the next version of the spec. Thanks, --David -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, January 27, 2002 9:17 PM To: Amir Shalit Subject: RE: SCSI Format/Copy CDB support Amir, A carefull reading of the spec will enable you to see that things are covered. I do not plan to add text - it only creates new sources of errors. Julo "Amir Shalit" Sent by: owner-ips@ece.cmu.edu 26-01-02 20:14 To: cc: Subject: RE: SCSI Format/Copy CDB support David, I agree. Lets clarify it in the spec. We also must make sure that iSCSI doesn't reissue a command due to connection drop that happened a "long time" after the command was originally issued. Amir -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Saturday, January 26, 2002 12:32 AM To: amir@astutenetworks.com Cc: ips@ece.cmu.edu Subject: RE: SCSI Format/Copy CDB support Ah, I see the confusion. In that section, "reissued" refers to reissuing a command due to holes in the command sequence (e.g., digest failure, connection drop). In the scenario of interest, the command is not being reissued by iSCSI - SCSI is aborting the old command based on the task tag and issuing a new command which will get a new CmdSN (iSCSI will probably have long since forgotten the CmdSN assigned to the original command). A sentence or two to clarify this wouldn't hurt. --David > -----Original Message----- > From: Amir Shalit [mailto:amir@astutenetworks.com] > Sent: Friday, January 25, 2002 7:03 PM > To: Julian Satran > Cc: ips@ece. cmu. edu (E-mail); owner-ips@ece.cmu.edu > Subject: RE: SCSI Format/Copy CDB support > > > Julo, > > I was talking about initiator aborting the command > ,say two hours after it was sent, and than reissue > the same command with the old CmdSN (according to > the spec). > > I agree with you that the spec covers all other cases > since once a command is delivered, CmdSN doesn't > matter much and ITT or TTT are used to match the > task. > > Amir > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Friday, January 25, 2002 2:14 PM > To: Amir Shalit > Cc: ips@ece. cmu. edu (E-mail); Julian Satran; owner-ips@ece.cmu.edu > Subject: RE: SCSI Format/Copy CDB support > > > > Amir, > CmdSN is completely secondary in abort task. > The main element is the Initiator Task Tag. > If ITT is not found at abort then the target, under some > cirscumstances, > will look for a hole at CmdSN to fill it or will answer > negatively the Task > Abort. > > Julo > > > > "Amir Shalit" > Satran/Haifa/IBM@IBMIL > works.com> cc: "ips@ece. cmu. edu > \(E-mail\)" , > > 25-01-02 18:49 Subject: RE: > SCSI Format/Copy > CDB support > > > > > > > Julo, > > I agree with you on (2). > > Section 2.2.2.1 is saying: > "A numbered iSCSI request will not change its allocated CmdSN > regardless of the number of times and circumstances in which it is > reissued." > > A long duration SCSI command may be aborted by a task management > command and than reissued by iSCSI with a stale CmdSN. > > Amir > -----Original Message----- > From: owner-ips@ece.cmu.edu > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Friday, January 25, 2002 1:21 AM > To: Amir Shalit > Cc: ips@ece. cmu. edu (E-mail); owner-ips@ece.cmu.edu > Subject: Re: SCSI Format/Copy CDB support > > > Amir, > > The draft says in several places that CmdSN is not > important after the > task gets to SCSI. > On 2 yes you might be right but that is purely an implementation > issue. Format commands do not time-out > at SCSI level and iSCSI has no cause to e "nervous" - nothing is > expected. > > > Julo > > > > > "Amir Shalit" > To: > "ips@ece. cmu. edu > Sent by: owner-ips@ece.cmu.edu \(E-mail\)" > cc: > Subject: > SCSI Format/Copy > 25-01-02 02:10 CDB support > > > > > > > > I see a few problems in implementing the format/copy > commands over > iSCSI > > 1) CmdSN may wrap between command and response (assuming multiple > LUNs) > > 2) iSCSI keepalive NOPs may be required to keep the > connection open > during format > > > > > > > --=_alternative 00645D60C2256B4F_= Content-Type: text/html; charset="us-ascii"
That would be a mistake. It may affect commands intended to be dropped.

If the window has moved past CmdSN you DO NOT reissue the command (that is clear in the text).

Julo


"Amir Shalit" <amir@astutenetworks.com>

28-01-02 19:35

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        
        Subject:        RE: SCSI Format/Copy CDB support

       


Julo,

We only need to ADD a single line to section 2.2.2.1 as follows:

"CmdSN must change if the ExpCmdSN/MaxCmdSN window has moved."

Section 2.2.2.1 is saying:
> "A numbered iSCSI request will not change its allocated CmdSN
> regardless of the number of times and circumstances in which it is
> reissued."

Amir

From David Black:

The CmdSN window should take care of the "long time"

issue - once the Window (ExpCmdSN/MaxCmdSN) has moved

past a particular CmdSN, the initiator knows that the

target successfully received the command, and reissuing

the command with the same CmdSN would be an error.

Julian - please add a suitable clarification to the

next version of the spec.

Thanks,

--David

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Sunday, January 27, 2002 9:17 PM
To: Amir Shalit
Subject: RE: SCSI Format/Copy CDB support

Amir,

A carefull reading of the spec will enable you to see that things are covered.
I do not plan to add text - it only creates new sources of errors.

Julo

"Amir Shalit" <amir@astutenetworks.com>
Sent by: owner-ips@ece.cmu.edu

26-01-02 20:14

       
       To:        <Black_David@emc.com>
       cc:        <ips@ece.cmu.edu>
       Subject:        RE: SCSI Format/Copy CDB support

     



David,

I agree. Lets clarify it in the spec. We also must make
sure that iSCSI doesn't reissue a command due to connection
drop that happened a "long time" after the command was
originally issued.

Amir

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Saturday, January 26, 2002 12:32 AM
To: amir@astutenetworks.com
Cc: ips@ece.cmu.edu
Subject: RE: SCSI Format/Copy CDB support


Ah, I see the confusion.  In that section, "reissued"
refers to reissuing a command due to holes in the command
sequence (e.g., digest failure, connection drop).  In
the scenario of interest, the command is not being
reissued by iSCSI - SCSI is aborting the old command
based on the task tag and issuing a new command which
will get a new CmdSN (iSCSI will probably have long since
forgotten the CmdSN assigned to the original command).
A sentence or two to clarify this wouldn't hurt.

--David

> -----Original Message-----
> From: Amir Shalit [mailto:amir@astutenetworks.com]
> Sent: Friday, January 25, 2002 7:03 PM
> To: Julian Satran
> Cc: ips@ece. cmu. edu (E-mail); owner-ips@ece.cmu.edu
> Subject: RE: SCSI Format/Copy CDB support
>
>
> Julo,
>
> I was talking about initiator aborting the command
> ,say two hours after it was sent, and than reissue
> the same command with the old CmdSN (according to
> the spec).
>
> I agree with you that the spec covers all other cases
> since once a command is delivered, CmdSN doesn't
> matter much and ITT or TTT are used to match the
> task.
>
> Amir
>
> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Julian Satran
> Sent: Friday, January 25, 2002 2:14 PM
> To: Amir Shalit
> Cc: ips@ece. cmu. edu (E-mail); Julian Satran; owner-ips@ece.cmu.edu
> Subject: RE: SCSI Format/Copy CDB support
>
>
>
> Amir,
> CmdSN is completely secondary in abort task.
> The main element is the Initiator Task Tag.
> If ITT is not found at abort then the target, under some
> cirscumstances,
> will look for a hole at CmdSN to fill it or will answer
> negatively the Task
> Abort.
>
> Julo
>
>
>
>                     "Amir Shalit"
>                     <amir@astutenet       To:     Julian
> Satran/Haifa/IBM@IBMIL
>                     works.com>            cc:     "ips@ece. cmu. edu
> \(E-mail\)" <ips@ece.cmu.edu>,
>                                            <owner-ips@ece.cmu.edu>
>                     25-01-02 18:49        Subject:     RE:
> SCSI Format/Copy
> CDB support
>
>
>
>
>
>
> Julo,
>
> I agree with you on (2).
>
> Section 2.2.2.1 is saying:
> "A numbered iSCSI request will not change its allocated CmdSN
> regardless of the number of times and circumstances in which it is
> reissued."
>
> A long duration SCSI command may be aborted by a task management
> command and than reissued by iSCSI with a stale CmdSN.
>
> Amir
>      -----Original Message-----
>      From: owner-ips@ece.cmu.edu
> [mailto:owner-ips@ece.cmu.edu]On Behalf Of
>      Julian Satran
>      Sent: Friday, January 25, 2002 1:21 AM
>      To: Amir Shalit
>      Cc: ips@ece. cmu. edu (E-mail); owner-ips@ece.cmu.edu
>      Subject: Re: SCSI Format/Copy CDB support
>
>
>      Amir,
>
>      The draft says in several places that CmdSN is not
> important after the
>      task gets to SCSI.
>      On 2 yes you might be right but that is purely an implementation
>      issue. Format commands do not time-out
>      at SCSI level and iSCSI has no cause to e "nervous" - nothing is
>      expected.
>
>
>      Julo
>
>
>
>
>    "Amir Shalit"
>    <amir@astutenetworks.com>              To:        
> "ips@ece. cmu. edu
>    Sent by: owner-ips@ece.cmu.edu \(E-mail\)" <ips@ece.cmu.edu>
>                                           cc:
>                                           Subject:        
> SCSI Format/Copy
>    25-01-02 02:10                 CDB support
>
>
>
>
>
>
>
>      I see a few problems in implementing the format/copy
> commands over
>      iSCSI
>
>      1) CmdSN may wrap between command and response (assuming multiple
>      LUNs)
>
>      2) iSCSI keepalive NOPs may be required to keep the
> connection open
>      during format
>
>
>
>
>
>
>






--=_alternative 00645D60C2256B4F_=-- From owner-ips@ece.cmu.edu Mon Jan 28 15:18:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07730 for ; Mon, 28 Jan 2002 15:18:31 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0SJHfK08381 for ips-outgoing; Mon, 28 Jan 2002 14:17:41 -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 g0SJHdj08377 for ; Mon, 28 Jan 2002 14:17:39 -0500 (EST) Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom MMS-2 SMTP Relay (MMS v4.7)); Mon, 28 Jan 2002 11:16:27 -0800 X-Server-Uuid: 2a12fa22-b688-11d4-a6a1-00508bfc9626 Received: from mail-sj1-1.sj.broadcom.com (mail-sj1-1.sj.broadcom.com [10.16.128.231]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id LAA14892; Mon, 28 Jan 2002 11:17:35 -0800 (PST) Received: from PCSJCGNAVEEN (dhcpe1-sj3-103 [10.21.65.103]) by mail-sj1-1.sj.broadcom.com (8.8.8/8.8.8/MS01) with SMTP id LAA11969; Mon, 28 Jan 2002 11:17:36 -0800 (PST) From: "Naveen Nimmu" To: julian_satran@il.ibm.com cc: ips@ece.cmu.edu Subject: minor comment on draft.10 Date: Mon, 28 Jan 2002 11:17:29 -0800 Message-ID: MIME-Version: 1.0 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 X-WSS-ID: 104B7C0148967-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 The index generated is not consistent with the text. Looks like the section ' 2.3 iSCSI Session Types' became part of 2.2.9.4 and hence all the rest of the headers in chapter 2 after 2.3 are shifted by 0.1.0.0 For example index says 2.5 as Request/Response Summary, Actual text shows 2.4 Request/Response Summary. Hope this can be fixed in the next rev.. Thanks Naveen Nimmu From owner-ips@ece.cmu.edu Mon Jan 28 15:21: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 PAA07804 for ; Mon, 28 Jan 2002 15:21:11 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0SJkiW11174 for ips-outgoing; Mon, 28 Jan 2002 14:46:44 -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 g0SJkgj11169 for ; Mon, 28 Jan 2002 14:46:42 -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 LAA19011; Mon, 28 Jan 2002 11:44:56 -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 LAA01115; Mon, 28 Jan 2002 11:28:16 -0800 (PST) Received: by aimexc06.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 11:43:43 -0800 Message-ID: From: "Sperry, Todd" To: "'John Hufferd'" , ips@ece.cmu.edu Subject: RE: iSCSI Markers and Framing, a recomendation Date: Mon, 28 Jan 2002 11:43:42 -0800 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 John, I believe that the reasons you've outlined for FIM now, some kind of framing later, is the right approach. So, #6 would be my vote as well. I also agree that the 'SHOULD' language would be appropriate on the send side (as per RFC2119). Thanks, Todd. -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Monday, January 14, 2002 12:37 PM To: ips@ece.cmu.edu Subject: iSCSI Markers and Framing, a recomendation Now that I have punished you all with the notes defining what is Framing and COWS. I will lobby for one. Here again are the choices 1. FIM now, and Bare Framing later 2. FIM now, and COWS Framing later 3. COWS now, and Bare Framing later 4. COWS now, and COWS Framing Later 5. Nothing now, and some kind of Framing Later 6. FIM now, and some kind of Framing Later Two arguments one for FIM now and one for Bare Framing later: Let me start with "Framing Later": The more I have seen of the work going on defining RDMA/iWARP, and the work that is going into the Framing Experimental Status, the more I believe, we can NOT now know how this will work out. Let me give you an example. The only significant concern, with Bare Framing, is the case of a false positive indicator only when the network has re-segmented the TCP Segment. The Bare Framing protocol has a 48-bit Random number and a 16 bit length field to detect this. I believe this has a lower probability of false positives then passing an undetected error through the 16 bit TCP/IP XOR Checksum, and possibly even the 32-bit CRC. So the Experimental work was started to prove that this was not an issue. Now, even though Bare Framing is the easiest to implement, and probably statically just fine (at least in my opinion), some folks are attempting to come up with a fool proof approach, which probably causes more implementation costs. (You can bet that will be a major shoot out.) No one yet has been able to do the needed math to prove that Bare Framing is a problem or not a problem (volunteers anyone?). But sooner or later some one will do that. There is even a chance that another word could be added to the Random Number to make it even stronger. In the mean time we have two Different COWS proposals, and no one knows if something now unknown will bleed over from the RDMA work. We simply do not know how the Framing will work out. iSCSI choosing a Marking approach to match one of the perceived Framing approaches, will not cause that approach to happen, and it is probably going to cause turf wars, and other non productive interactions. Therefore, I have come to the conclusion that Markers and Framing are disjoint issues. Further, we have no control over the direction of framing. Now my arguments for "FIM now": FIM is the lowest overhead Marker approach we have been able to come up with. I think we need something that can easily be placed into SW ( In this context I am talking about SW that does not "OWN" the Host TCP/IP stack.). As I have stated before, FIM is simple to implement and can greatly help some HW. It needs to be Sent only if requested, and not other wise. It has been in the spec for some time, is therefore well understood and I think it has been scrubbed my a number of different vendors. Some of which have told me that they have either placed it in their product or are working on that. This is NOT to say that we can not change it, but that because of its longevity in the spec, has undergone a lot of study. And we should have important reasons not to do FIM (such as if it doesn't work). Now, Jonathan Stone, has stated that "transatlantic can regularly show 50% drop rate". I would like the vendors to have some approach to enable a reasonable solution, to this and other long haul requirements, which keeps the Adapter cost as low as possible. Also, that would mean that it can NOT wait until 10 Gig. Now to the issue of MUST or SHOULD implement. I have been persuaded that "SHOULD implement on Send" but optional to use, would be a more acceptable position, since vendors with good and just reasons would not have to implement it, yet the customer could find solutions if they needed them. Therefore, based on the above reasoning, I am recommending: Choice 6, with "SHOULD implement on Send". That is, Leave FIM in the Spec, and add an enabling statement about "SHOULD implement on Send if requested by the receiving side". . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Mon Jan 28 15:24: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 PAA08014 for ; Mon, 28 Jan 2002 15:24:50 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0SJnvQ11465 for ips-outgoing; Mon, 28 Jan 2002 14:49:57 -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 g0SJnsj11457; Mon, 28 Jan 2002 14:49:54 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 14:49:48 -0500 Message-ID: <93F527C91A6ED411AFE10050040665D00401E6E5@corpusmx1.us.dg.com> From: dibb_tom@emc.com To: owner-ips@ece.cmu.edu, ips@ece.cmu.edu Subject: remove Date: Mon, 28 Jan 2002 14:49: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 From owner-ips@ece.cmu.edu Mon Jan 28 18:13: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 SAA10880 for ; Mon, 28 Jan 2002 18:13:31 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0SLnHi22027 for ips-outgoing; Mon, 28 Jan 2002 16:49:17 -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 g0SD22j08323 for ; Mon, 28 Jan 2002 08:02:02 -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 IAA23498; Mon, 28 Jan 2002 08:01:59 -0500 (EST) Message-Id: <200201281301.IAA23498@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-ifcp-09.txt,.pdf Date: Mon, 28 Jan 2002 08:01:59 -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 : iFCP - A Protocol for Internet Fibre Channel Storage Networking Author(s) : C. Monia et al. Filename : draft-ietf-ips-ifcp-09.txt,.pdf Pages : 97 Date : 25-Jan-02 This document specifies an architecture and gateway-to-gateway protocol for the implementation of Fibre Channel fabric functionality on a network in which TCP/IP switching and routing elements replace Fibre Channel components. The protocol enables the attachment of Fibre Channel devices to an IP network by supporting the fabric services required by such devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-ifcp-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-ifcp-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-ifcp-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: <20020125134223.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-ifcp-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-ifcp-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020125134223.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Mon Jan 28 20:00: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 UAA12453 for ; Mon, 28 Jan 2002 20:00:27 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0SNlWa00674 for ips-outgoing; Mon, 28 Jan 2002 18:47:32 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web21103.mail.yahoo.com (web21103.mail.yahoo.com [216.136.227.105]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g0SNlOj00668 for ; Mon, 28 Jan 2002 18:47:29 -0500 (EST) Message-ID: <20020128234723.75551.qmail@web21103.mail.yahoo.com> Received: from [206.40.79.241] by web21103.mail.yahoo.com via HTTP; Mon, 28 Jan 2002 15:47:23 PST Date: Mon, 28 Jan 2002 15:47:23 -0800 (PST) From: Pat LaVarre Reply-To: p.lavarre@ieee.org Subject: to iScsi from Scsi, quickly please To: ips@ece.cmu.edu Cc: p.lavarre@ieee.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk > http://www.ietf.org/internet-drafts/ > draft-ietf-ips-iscsi-10.txt > Expires August 2002 > 1.3.5 Expected Data Transfer Length > 1.4.4 Residual Count > 1.4.5 Bidirectional Read Residual Count Would someone here be happy to quickly sketch for me how iScsi defines measurable residues? (I'm newly subscribed here.) I ask because legacy Scsi work once taught me to always measure two residues between command out and status in: 1) Expected minus actual count of data bytes that moved in, negative only if the host of the device discards data in. 2) Expected minus actual count of data bytes that moved out, negative only if the host of the device fabricates data out. To understand ips-scsi-10, I gather I should have a different model in mind? At first glance, the ips-scsi model doesn't seem as general as, for example, Scsi2 is on paper. In ips-scsi I think I see more provision for unexpected data moving in that for unexpected data moving out? Clue me in, anyone? Thanks in advance, cluelessly yours. Pat LaVarre P.S. The web links that brought me here included: http://www.usenix.org/events/fast/tech.html http://www.almaden.ibm.com/cs/storagesystems/iscsi/index.html http://www.ece.cmu.edu/~ips/ http://www.pdl.cmu.edu/mailinglists/ips/mail/maillist.html http://www.pdl.cmu.edu/cgi-bin/htsearchIPS resid __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com From owner-ips@ece.cmu.edu Mon Jan 28 21: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 VAA13689 for ; Mon, 28 Jan 2002 21:19:34 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0T15ml05400 for ips-outgoing; Mon, 28 Jan 2002 20:05:48 -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 g0T15gj05388 for ; Mon, 28 Jan 2002 20:05:46 -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 08693109; Mon, 28 Jan 2002 19:05:33 -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, 28 Jan 2002 19:05:32 -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: iSCSI: Draft 10 Section Numbers Different in PDF vs. TXT Date: Mon, 28 Jan 2002 19:05:31 -0600 Message-ID: <31891B757C09184BBFEC5275F85D5595104E1D@cceexc18.americas.cpqcorp.net> Thread-Topic: to iScsi from Scsi, quickly please Thread-Index: AcGoVpj/xJz928JvSm6fK1hg5nYylAACJ0rQ From: "Martin, Nick" To: , X-OriginalArrivalTime: 29 Jan 2002 01:05:32.0825 (UTC) FILETIME=[0D1AF890:01C1A861] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g0T15kj05393 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Unable to locate the following references in my PDF version, I discovered that the section numbers of this section in the PDF are 1.0.0.0 greater than in the TXT version. I saw another message about section numbers but it did not sound so severe. Thanks, Nick > -----Original Message----- > From: Pat LaVarre [mailto:p_lavarre@yahoo.com] > Sent: Monday, January 28, 2002 5:47 PM > To: ips@ece.cmu.edu > Cc: p.lavarre@ieee.org > Subject: to iScsi from Scsi, quickly please > > > > http://www.ietf.org/internet-drafts/ > > draft-ietf-ips-iscsi-10.txt > > Expires August 2002 > > 1.3.5 Expected Data Transfer Length > > 1.4.4 Residual Count > > 1.4.5 Bidirectional Read Residual Count > > Would someone here be happy to quickly sketch for me > how iScsi defines measurable residues? (I'm newly > subscribed here.) > > I ask because legacy Scsi work once taught me to > always measure two residues between command out and > status in: > > 1) Expected minus actual count of data bytes that > moved in, negative only if the host of the device > discards data in. > > 2) Expected minus actual count of data bytes that > moved out, negative only if the host of the device > fabricates data out. > > To understand ips-scsi-10, I gather I should have a > different model in mind? > > At first glance, the ips-scsi model doesn't seem as > general as, for example, Scsi2 is on paper. In > ips-scsi I think I see more provision for unexpected > data moving in that for unexpected data moving out? > > Clue me in, anyone? > > Thanks in advance, cluelessly yours. Pat LaVarre > > > P.S. The web links that brought me here included: > > http://www.usenix.org/events/fast/tech.html > http://www.almaden.ibm.com/cs/storagesystems/iscsi/index.html > http://www.ece.cmu.edu/~ips/ > http://www.pdl.cmu.edu/mailinglists/ips/mail/maillist.html > http://www.pdl.cmu.edu/cgi-bin/htsearchIPS resid > > > __________________________________________________ > Do You Yahoo!? > Great stuff seeking new owners in Yahoo! Auctions! > http://auctions.yahoo.com > From owner-ips@ece.cmu.edu Mon Jan 28 21:48: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 VAA14913 for ; Mon, 28 Jan 2002 21:48:31 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0T1nbc08020 for ips-outgoing; Mon, 28 Jan 2002 20:49:37 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mms1.broadcom.com (mms1.broadcom.com [63.70.210.58]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g0T1nZj08016 for ; Mon, 28 Jan 2002 20:49:35 -0500 (EST) Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom MMS-1 SMTP Relay (MMS v4.7)); Mon, 28 Jan 2002 17:49:17 -0800 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from mail-sj1-1.sj.broadcom.com (mail-sj1-1.sj.broadcom.com [10.16.128.231]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id RAA23790; Mon, 28 Jan 2002 17:49:32 -0800 (PST) Received: from PCSJCGNAVEEN (dhcpe1-sj3-103 [10.21.65.103]) by mail-sj1-1.sj.broadcom.com (8.8.8/8.8.8/MS01) with SMTP id RAA00978; Mon, 28 Jan 2002 17:49:33 -0800 (PST) From: "Naveen Nimmu" To: cbm@rose.hp.com cc: ips@ece.cmu.edu Subject: State Transitions.. Date: Mon, 28 Jan 2002 17:49:26 -0800 Message-ID: MIME-Version: 1.0 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 X-WSS-ID: 104B201742236-01-01 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C1A824.20A33360" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C1A824.20A33360 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit This may have been discussed before , I will ask this anyway. The states S6 and S7 seem to be flipped if we consider all the states in the time scale For example I could put the state diagram in page 68 (v.10) in a timeline kind of state diagram (text diagram attached), Where S7 appears naturally before S6. It seems to me by Exchanging S6 and S7 definitions we might have more clear (almost unidirectional) state diagrams.. All comments welcome.. Naveen Nimmu ------=_NextPart_000_0000_01C1A824.20A33360 Content-Type: application/octet-stream; name=diagram Content-Disposition: attachment; filename=diagram Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= /----> (S2)=0A= / / |=0A= / T2/ |=0A= / / |T4=0A= T1 / / |=0A= / / V=0A= / |<----(S4)=0A= / | T7 |=0A= / | |T5=0A= / | V=0A= (S1)<------|<----(S5)___=0A= | T8 | \ \=0A= | |T11\ \=0A= | V \ \=0A= |<----(S7) |T9 \=0A= \ T18 | \ / \=0A= \ |T10X \=0A= T13\__ V / \ |T15=0A= (S6) |T16 /=0A= | / /=0A= T17| _/ _/=0A= V /____/=0A= (S8) =0A= ------=_NextPart_000_0000_01C1A824.20A33360-- From owner-ips@ece.cmu.edu Mon Jan 28 22:31: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 WAA15970 for ; Mon, 28 Jan 2002 22:31:28 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0T2mWc11506 for ips-outgoing; Mon, 28 Jan 2002 21:48:32 -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 g0T2mTj11500 for ; Mon, 28 Jan 2002 21:48:29 -0500 (EST) Received: from cceexg11.americas.cpqcorp.net (cceexg11.americas.cpqcorp.net [16.110.250.125]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 322901661; Mon, 28 Jan 2002 20:48:23 -0600 (CST) Received: from cceexc18.americas.cpqcorp.net ([16.110.250.64]) by cceexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 28 Jan 2002 20:48:23 -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: to iScsi from Scsi, quickly please Date: Mon, 28 Jan 2002 20:48:22 -0600 Message-ID: <31891B757C09184BBFEC5275F85D5595104E1E@cceexc18.americas.cpqcorp.net> Thread-Topic: to iScsi from Scsi, quickly please Thread-Index: AcGoVpj/xJz928JvSm6fK1hg5nYylAACtgzA From: "Martin, Nick" To: , X-OriginalArrivalTime: 29 Jan 2002 02:48:23.0073 (UTC) FILETIME=[6ADC1910:01C1A86F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g0T2mUj11502 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Pat, I will attempt this one because I think I understand it. The O (overrun) and U (underrun) bits indicate (redundantly) the sign of the residual you describe for Scsi2. O (overrun) indicates not all the data was used (residual contains actual minus expected). U (underrun) indicates that the data supplied is less than expected (residual contains expected minus actual). Data is transferred in only one direction by each command except for bi-directional commands. For bi-directional commands only, two residual fields and two pairs of bits (ou and OU) are used to indicate data transfer result in each direction. All this is detected and reported from the target's point of view. The potential overrun or underrun are detected between the iSCSI session and the SCSI layer within the target node, and reported back to the initiator via iSCSI protocol. Any failure to transfer the expected number of bytes between the initiator and the target iSCSI sessions is handled within TCP and/or iSCSI. Any failure of the iSCSI session to transfer the expected number of bytes into or out of initiator memory is an internal matter within the initiator. A common or expected case would involve a variable length read. The expected data transfer length is in this case better described as a maximum data transfer length or initiator buffer allocation size. The actual transfer length is determined by the length of the data available from the logical unit within the target. The U bit (set) and the residual count report the expected (max) data transfer length minus the actual data length available from the logical unit. The number of data bytes transferred from the target to the initiator by iSCSI will be the number of bytes available. In summary, these residuals report differences between the length in the original request and the length processed by the target logical unit. The iSCSI session is expected to always transfer the correct number of bytes over the network between initiator and target data buffers. There are no additional residual counts reported. Someone will correct the precise semantics I should have used. I hope this explanation answers your question and can be clearly understood. Thanks, Nick > -----Original Message----- > From: Pat LaVarre [mailto:p_lavarre@yahoo.com] > Sent: Monday, January 28, 2002 5:47 PM > To: ips@ece.cmu.edu > Cc: p.lavarre@ieee.org > Subject: to iScsi from Scsi, quickly please > > > > http://www.ietf.org/internet-drafts/ > > draft-ietf-ips-iscsi-10.txt > > Expires August 2002 > > 1.3.5 Expected Data Transfer Length > > 1.4.4 Residual Count > > 1.4.5 Bidirectional Read Residual Count > > Would someone here be happy to quickly sketch for me > how iScsi defines measurable residues? (I'm newly > subscribed here.) > > I ask because legacy Scsi work once taught me to > always measure two residues between command out and > status in: > > 1) Expected minus actual count of data bytes that > moved in, negative only if the host of the device > discards data in. > > 2) Expected minus actual count of data bytes that > moved out, negative only if the host of the device > fabricates data out. > > To understand ips-scsi-10, I gather I should have a > different model in mind? > > At first glance, the ips-scsi model doesn't seem as > general as, for example, Scsi2 is on paper. In > ips-scsi I think I see more provision for unexpected > data moving in that for unexpected data moving out? > > Clue me in, anyone? > > Thanks in advance, cluelessly yours. Pat LaVarre > > > P.S. The web links that brought me here included: > > http://www.usenix.org/events/fast/tech.html > http://www.almaden.ibm.com/cs/storagesystems/iscsi/index.html > http://www.ece.cmu.edu/~ips/ > http://www.pdl.cmu.edu/mailinglists/ips/mail/maillist.html > http://www.pdl.cmu.edu/cgi-bin/htsearchIPS resid > > > __________________________________________________ > Do You Yahoo!? > Great stuff seeking new owners in Yahoo! Auctions! > http://auctions.yahoo.com > From owner-ips@ece.cmu.edu Mon Jan 28 22:38:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16326 for ; Mon, 28 Jan 2002 22:38:20 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0T2ioY11247 for ips-outgoing; Mon, 28 Jan 2002 21:44:50 -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 g0T2ilj11237 for ; Mon, 28 Jan 2002 21:44:47 -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 SAA28647; Mon, 28 Jan 2002 18:44:06 -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 SAA12375; Mon, 28 Jan 2002 18:27:25 -0800 (PST) Received: by aimexc07.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 18:42:59 -0800 Message-ID: From: "Mukund, Shridhar" To: "'Douglas Otis'" , Black_David@emc.com, ips@ece.cmu.edu Cc: tsvwg@ietf.org Subject: RE: iSCSI: Framing Steps Date: Mon, 28 Jan 2002 18:42: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 Dear colleagues, 1. Doug : David made the point, "it(FIM) does not modify the TCP protocol", as lucid as it gets. It will be nice to hear some opinions from the TCP gurus out there without mixing it up with SCTP and TUF. 2. It will also be nice if other iSCSI folks on the reflector cast their votes per John's request. Putting on my politician hat :-), pl. vote for option 6. >>>> 6. FIM now, and some kind of Framing later 3. I do agree with David that the implication, "Senders that do not insert markers on send should be willing to accept up to RTT*BW drops" in my email was too strong as it goes against a RFC1122-SHOULD. ( See reference below ). I stand corrected. The current iSCSI draft addresses my point anyway: "In certain environments, a sender not willing to supply markers to a receiver willing to accept markers MAY suffer from a considerable performance degradation." In my interpretation, the spirit behind the RFC1122-SHOULD is to save IP networks from having to transport same data all over again in the event of packet drop. In fact, FIM directly addresses this very spirit. We may want to add a note in the iSCSI draft that implementations should try to honor the RFC1122-SHOULD when the sender is not willing to supply markers. Thanks. -Shridhar Mukund ------------------------------------------------------------------------ Reference : David's response dtd 14 Jan. to my email: > b. I strongly recommend SHOULD implement FIM on the send side. > Implication -> Senders that do not insert markers should be > willing to accept up to RTT*BW data drops! Headers being > "reasonably" out-of-order is OK. Of course, senders that do not > insert markers but are willing to pay big $$$ to the SSP will > get their buffer/BW allocation as usual and customary :-) I think the Implication is too strong, as it goes against the following SHOULD from RFC 1122 (which modifies RFC 793): 4.2.2.20 Event Processing: RFC-793 Section 3.9 While it is not strictly required, a TCP SHOULD be capable of queueing out-of-order TCP segments. A drop causes the segments up to the retransmission of the drop to be out-of-order. This does not preclude "SHOULD implement FIM", but the above Implication is overdone in my view as it appears to condone drops of all out-of-order segments. From owner-ips@ece.cmu.edu Tue Jan 29 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 AAA17918 for ; Tue, 29 Jan 2002 00:24:46 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0T4D8H16162 for ips-outgoing; Mon, 28 Jan 2002 23:13:08 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from parmenion.hosting.pacbell.net (parmenion.hosting.pacbell.net [216.100.98.31]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0T4D2j16150 for ; Mon, 28 Jan 2002 23:13:06 -0500 (EST) Received: from somesh ([65.172.158.93]) by parmenion.hosting.pacbell.net id XAA20286; Mon, 28 Jan 2002 23:12:47 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Reply-To: From: "Somesh Gupta" To: Subject: RE: iSCSI: Framing Steps Date: Mon, 28 Jan 2002 20:10:25 -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.00.2919.6700 Importance: Normal In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sridhar, > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Mukund, Shridhar > Sent: Monday, January 28, 2002 6:43 PM > To: 'Douglas Otis'; Black_David@emc.com; ips@ece.cmu.edu > Cc: tsvwg@ietf.org > Subject: RE: iSCSI: Framing Steps > > > > Dear colleagues, > > 1. Doug : David made the point, "it(FIM) does not modify > the TCP protocol", as lucid as it gets. It will be nice > to hear some opinions from the TCP gurus out there > without mixing it up with SCTP and TUF. > > 2. It will also be nice if other iSCSI folks on the reflector > cast their votes per John's request. > Putting on my politician hat :-), pl. vote for option 6. > >>>> 6. FIM now, and some kind of Framing later > > 3. I do agree with David that the implication, "Senders that > do not insert markers on send should be willing to accept > up to RTT*BW drops" in my email was too strong as it goes > against a RFC1122-SHOULD. ( See reference below ). I > stand corrected. > > The current iSCSI draft addresses my point anyway: > "In certain environments, a sender not willing to supply > markers to a receiver willing to accept markers MAY > suffer from a considerable performance degradation." > > In my interpretation, the spirit behind the RFC1122-SHOULD > is to save IP networks from having to transport > same data all over again in the event of packet drop. IP networks so far have managed to handle packet drops (without complete retransmissions) without FIM. Again, I think the statement below is way overstating the case and you may want to add the significant number of qualifiers associated with it. > In fact, FIM directly addresses this very spirit. > > We may want to add a note in the iSCSI draft that > implementations should try to honor the RFC1122-SHOULD > when the sender is not willing to supply markers. > > Thanks. > > -Shridhar Mukund I think there is substantial disagreement as to whether any approach meets the objectives that people are attempting (of course there is probably no agreement on the requirements either). The debate so far, even though intelligent, has been at the surface and high level. I think to resolve this requires experimentation, or at least a very detailed hypothetical technical design and analysis (I would be more than happy to at least take pot-shots so the design and analysis would be more thorough). It will make visible at the compromises and assumptions being made - people can then decide whether we want iSCSI to make those assumptions and compromises. (or perhaps that will require people to share too much?) > > > ------------------------------------------------------------------------ > Reference : David's response dtd 14 Jan. to my email: > > > b. I strongly recommend SHOULD implement FIM on the send side. > > Implication -> Senders that do not insert markers should be > > willing to accept up to RTT*BW data drops! Headers being > > "reasonably" out-of-order is OK. Of course, senders that do not > > insert markers but are willing to pay big $$$ to the SSP will > > get their buffer/BW allocation as usual and customary :-) > > I think the Implication is too strong, as it goes against the following > SHOULD from RFC 1122 (which modifies RFC 793): > > 4.2.2.20 Event Processing: RFC-793 Section 3.9 > > While it is not strictly required, a TCP SHOULD be capable > of queueing out-of-order TCP segments. > > A drop causes the segments up to the retransmission of the drop to > be out-of-order. This does not preclude "SHOULD implement FIM", but > the above Implication is overdone in my view as it appears to condone > drops of all out-of-order segments. > > > From owner-ips@ece.cmu.edu Tue Jan 29 01:17: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 BAA18423 for ; Tue, 29 Jan 2002 01:17:16 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0T5Un120374 for ips-outgoing; Tue, 29 Jan 2002 00:30:49 -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 g0T5Ukj20365 for ; Tue, 29 Jan 2002 00:30:46 -0500 (EST) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 21:30:19 -0800 Message-ID: From: Charles Monia To: "Ips (E-mail)" Cc: "Franco Travostino (E-mail)" , "David Black (E-mail)" , "Elizabeth Rodriguez (E-mail)" Subject: iFCP Revision 9 Review Date: Mon, 28 Jan 2002 21:30: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 Colleagues: Aside from anticipated changes related to security, the co-authors believe that, with revision 9, the iFCP spec is done and otherwise ready for the 'last call' process. With that in mind, the co-authors invite a careful review of the spec prior to the formal start of the process. URLs for this Internet-Draft are: http://www.ietf.org/internet-drafts/draft-ietf-ips-ifcp-09.txt http://www.ietf.org/internet-drafts/draft-ietf-ips-ifcp-09.pdf -- version with markups visible The release notes for revisions 8 and 9 are archived at: ftp://ftp.t11.org/t11/member/incoming/02-028v1.txt ftp://ftp.t11.org/t11/member/incoming/02-028v1.pdf By 1/29, these will be moved to ftp://ftp.t11.org/t11/docs/02-028v1.txt ftp://ftp.t11.org/t11/docs/02-028v1.pdf. 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 Tue Jan 29 01:17: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 BAA18437 for ; Tue, 29 Jan 2002 01:17:35 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0T5Zsd20693 for ips-outgoing; Tue, 29 Jan 2002 00:35:54 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ns1.in-biz.net (IDENT:root@ptil-196-150-hyd.primus-india.net [203.196.150.196] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0T5Zlj20682 for ; Tue, 29 Jan 2002 00:35:48 -0500 (EST) Received: from yahoo.com ([203.196.150.219]) by ns1.in-biz.net (8.9.3/8.9.3) with ESMTP id LAA12931; Tue, 29 Jan 2002 11:05:21 +0530 Message-ID: <3C563562.1070909@yahoo.com> Date: Tue, 29 Jan 2002 11:08:42 +0530 From: Ajit Aryan Reply-To: digital_aryan@yahoo.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: somesh_gupta@silverbacksystems.com CC: ips@ece.cmu.edu Subject: Re: iSCSI: Framing Steps References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Somesh Gupta wrote: > Sridhar, > > >>-----Original Message----- >>From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of >>Mukund, Shridhar >>Sent: Monday, January 28, 2002 6:43 PM >>To: 'Douglas Otis'; Black_David@emc.com; ips@ece.cmu.edu >>Cc: tsvwg@ietf.org >>Subject: RE: iSCSI: Framing Steps >> >> >> >>Dear colleagues, >> >>1. Doug : David made the point, "it(FIM) does not modify >> the TCP protocol", as lucid as it gets. It will be nice >> to hear some opinions from the TCP gurus out there >> without mixing it up with SCTP and TUF. >> >>2. It will also be nice if other iSCSI folks on the reflector >> cast their votes per John's request. >> Putting on my politician hat :-), pl. vote for option 6. >> >>>> 6. FIM now, and some kind of Framing later >> >>3. I do agree with David that the implication, "Senders that >> do not insert markers on send should be willing to accept >> up to RTT*BW drops" in my email was too strong as it goes >> against a RFC1122-SHOULD. ( See reference below ). I >> stand corrected. >> >> The current iSCSI draft addresses my point anyway: >> "In certain environments, a sender not willing to supply >> markers to a receiver willing to accept markers MAY >> suffer from a considerable performance degradation." >> >> In my interpretation, the spirit behind the RFC1122-SHOULD >> is to save IP networks from having to transport >> same data all over again in the event of packet drop. >> > > IP networks so far have managed to handle packet drops > (without complete retransmissions) without FIM. Again, > I think the statement below is way overstating the case > and you may want to add the significant number of > qualifiers associated with it. > Its true that the current day IP networks are capable of handling packet drops .... But it is high time to have a mechanism to handle this more efficiently, keeping in view the importance of SANs and their intended use. I think otion 6 with proper interpretation of *SHOULD* is a good option to opt for. > >> In fact, FIM directly addresses this very spirit. >> >> We may want to add a note in the iSCSI draft that >> implementations should try to honor the RFC1122-SHOULD >> when the sender is not willing to supply markers. >> >>Thanks. >> >>-Shridhar Mukund >> > > I think there is substantial disagreement as to whether > any approach meets the objectives that people are > attempting (of course there is probably no agreement > on the requirements either). The debate so far, even > though intelligent, has been at the surface and high > level. > > I think to resolve this requires experimentation, or > at least a very detailed hypothetical technical design > and analysis (I would be more than happy to at least > take pot-shots so the design and analysis would be > more thorough). > > It will make visible at the compromises and assumptions > being made - people can then decide whether we want > iSCSI to make those assumptions and compromises. > > (or perhaps that will require people to share too much?) > > >> >> >>------------------------------------------------------------------------ >>Reference : David's response dtd 14 Jan. to my email: >> >> >>> b. I strongly recommend SHOULD implement FIM on the send side. >>> Implication -> Senders that do not insert markers should be >>> willing to accept up to RTT*BW data drops! Headers being >>> "reasonably" out-of-order is OK. Of course, senders that do not >>> insert markers but are willing to pay big $$$ to the SSP will >>> get their buffer/BW allocation as usual and customary :-) >>> >>I think the Implication is too strong, as it goes against the following >>SHOULD from RFC 1122 (which modifies RFC 793): >> >> 4.2.2.20 Event Processing: RFC-793 Section 3.9 >> >> While it is not strictly required, a TCP SHOULD be capable >> of queueing out-of-order TCP segments. >> >>A drop causes the segments up to the retransmission of the drop to >>be out-of-order. This does not preclude "SHOULD implement FIM", but >>the above Implication is overdone in my view as it appears to condone >>drops of all out-of-order segments. >> >> >> >> > From owner-ips@ece.cmu.edu Tue Jan 29 04: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 EAA28612 for ; Tue, 29 Jan 2002 04:19:53 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0T8akm00119 for ips-outgoing; Tue, 29 Jan 2002 03:36:46 -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 g0T8ajj00115 for ; Tue, 29 Jan 2002 03:36:46 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 03:31:41 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029373E2@CORPMX14> From: Black_David@emc.com To: ni1d@arrl.net Cc: ips@ece.cmu.edu Subject: RE: iSCSI: not offering a key Date: Tue, 29 Jan 2002 03:23:14 -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 > But that's an artifact of a peculiar design approach for a negotiation > algorithm. The obvious design approach says that there are two ways > to *encode* a key having the default value: by sending the key with > that value, and by omitting that key. Those two encodings should have > the same effect on the negotiation state machine. The problem with this line of reasoning is that it assumes completely identical state machines at both ends of the negotiation. We decided a while ago on this list that there would be no such thing as an implicit offer, i.e., omitting the key is a decision not to offer it for negotiation. This results in a more robust negotiation protocol, as we have no lack of things that are potentially negotiable, and it's too easy to make a mistake in setting some of the default values. > That approach is far easier to understand and implement. Given that > approach, there cannot possibly be an extra message resulting from one > encoding or the other, because the state machine reacts the same. Only if the state machines are identical. One simple mistake in setting a default value, and the assumption that it doesn't need to be negotiated leads to unpleasant surprises. The right solution to this is in Eddy's recent mail and my reply - there are no implicit offers -- if you care about the value of a key, it's your responsibility to negotiate it. > What we see now is reasoning backwards from the design. In other > words: the starting position was to make the two encodings mean > different things; the state machine was constructed in such a way that > one results in more messages than the other; finally, that property is > used as an argument for why the distinction has to exist. But that's > circular reasoning: do away with the distinction, and reduce the state > machine to the shorter of the two cases, and the whole problem goes > away. And creates a login process that is significantly more brittle. The more robust solution that causes anything that's important to be negotiated is preferable. 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 Jan 29 04:23: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 EAA28649 for ; Tue, 29 Jan 2002 04:23:52 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0T8U7S29778 for ips-outgoing; Tue, 29 Jan 2002 03:30:07 -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 g0T8U6j29774 for ; Tue, 29 Jan 2002 03:30:06 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 03:29:59 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029373E1@CORPMX14> From: Black_David@emc.com To: Eddy_Quicksall@ivivity.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: not offering a key Date: Tue, 29 Jan 2002 03:16:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A89D.3E578720" 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_01C1A89D.3E578720 Content-Type: text/plain; charset="iso-8859-1" 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_01C1A89D.3E578720 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

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

&n= bsp;  =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_01C1A89D.3E578720-- From owner-ips@ece.cmu.edu Tue Jan 29 05: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 FAA29221 for ; Tue, 29 Jan 2002 05:11:55 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0T9IQS02222 for ips-outgoing; Tue, 29 Jan 2002 04:18:26 -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 g0T9IOj02217 for ; Tue, 29 Jan 2002 04:18:24 -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 EAA57874; Tue, 29 Jan 2002 04:15:18 -0500 Received: from d03nm014.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 g0T9IMl44750; Tue, 29 Jan 2002 02:18:22 -0700 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: Framing Steps To: Cc: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Tue, 29 Jan 2002 01:17:26 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 01/29/2002 02:18:21 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Somesh, Since the team convinced me to come off my proposal for "Must Implement on Send", to "Should Implement on Send", I think it gives you the ability to Not do it for all the reasons that are of major importance to you. The others, that can will Implement FIM. You can then meet in the market place. Option 6 (FIM today and some type of Framing later) along with "Should Implement" seem to be the right mix for you and the others. . . . 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 01/28/2002 08:10:25 PM Please respond to Sent by: owner-ips@ece.cmu.edu To: cc: Subject: RE: iSCSI: Framing Steps Sridhar, > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Mukund, Shridhar > Sent: Monday, January 28, 2002 6:43 PM > To: 'Douglas Otis'; Black_David@emc.com; ips@ece.cmu.edu > Cc: tsvwg@ietf.org > Subject: RE: iSCSI: Framing Steps > > > > Dear colleagues, > > 1. Doug : David made the point, "it(FIM) does not modify > the TCP protocol", as lucid as it gets. It will be nice > to hear some opinions from the TCP gurus out there > without mixing it up with SCTP and TUF. > > 2. It will also be nice if other iSCSI folks on the reflector > cast their votes per John's request. > Putting on my politician hat :-), pl. vote for option 6. > >>>> 6. FIM now, and some kind of Framing later > > 3. I do agree with David that the implication, "Senders that > do not insert markers on send should be willing to accept > up to RTT*BW drops" in my email was too strong as it goes > against a RFC1122-SHOULD. ( See reference below ). I > stand corrected. > > The current iSCSI draft addresses my point anyway: > "In certain environments, a sender not willing to supply > markers to a receiver willing to accept markers MAY > suffer from a considerable performance degradation." > > In my interpretation, the spirit behind the RFC1122-SHOULD > is to save IP networks from having to transport > same data all over again in the event of packet drop. IP networks so far have managed to handle packet drops (without complete retransmissions) without FIM. Again, I think the statement below is way overstating the case and you may want to add the significant number of qualifiers associated with it. > In fact, FIM directly addresses this very spirit. > > We may want to add a note in the iSCSI draft that > implementations should try to honor the RFC1122-SHOULD > when the sender is not willing to supply markers. > > Thanks. > > -Shridhar Mukund I think there is substantial disagreement as to whether any approach meets the objectives that people are attempting (of course there is probably no agreement on the requirements either). The debate so far, even though intelligent, has been at the surface and high level. I think to resolve this requires experimentation, or at least a very detailed hypothetical technical design and analysis (I would be more than happy to at least take pot-shots so the design and analysis would be more thorough). It will make visible at the compromises and assumptions being made - people can then decide whether we want iSCSI to make those assumptions and compromises. (or perhaps that will require people to share too much?) > > > ------------------------------------------------------------------------ > Reference : David's response dtd 14 Jan. to my email: > > > b. I strongly recommend SHOULD implement FIM on the send side. > > Implication -> Senders that do not insert markers should be > > willing to accept up to RTT*BW data drops! Headers being > > "reasonably" out-of-order is OK. Of course, senders that do not > > insert markers but are willing to pay big $$$ to the SSP will > > get their buffer/BW allocation as usual and customary :-) > > I think the Implication is too strong, as it goes against the following > SHOULD from RFC 1122 (which modifies RFC 793): > > 4.2.2.20 Event Processing: RFC-793 Section 3.9 > > While it is not strictly required, a TCP SHOULD be capable > of queueing out-of-order TCP segments. > > A drop causes the segments up to the retransmission of the drop to > be out-of-order. This does not preclude "SHOULD implement FIM", but > the above Implication is overdone in my view as it appears to condone > drops of all out-of-order segments. > > > From owner-ips@ece.cmu.edu Tue Jan 29 05:18: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 FAA29303 for ; Tue, 29 Jan 2002 05:18:41 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0T9kWO03672 for ips-outgoing; Tue, 29 Jan 2002 04:46:32 -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 g0T9kUj03667 for ; Tue, 29 Jan 2002 04:46:30 -0500 (EST) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 04:49:11 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029373E3@CORPMX14> From: Black_David@emc.com To: dotis@sanlight.net, ips@ece.cmu.edu Cc: tsvwg@ietf.org Subject: RE: iSCSI: Framing Steps Date: Tue, 29 Jan 2002 04:32:58 -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 A few more clarifications: (1) If the data-dependent memory allocator below TCP gets confused, that's its problem, and iSCSI's problem, not TCP's. As long as the inbound data is presented to TCP in the order it came off the wire, TCP's processing behavior is unchanged. If the data is delivered by TCP in locations other than those iSCSI was expecting, it can be copied to the right locations with suitable safeguards. (2) FIM processing makes no changes to packet contents, period. I have no idea where Doug got the impression "it is not the packet location that is being changed, but the content of the packet or it would be of little value". That is simply not true - the FIM markers can't be removed below TCP because they were sent in the TCP bytestream and have to be presented to TCP. The contents of each packet may not be contiguous in memory, but that has been common in TCP implementations from the beginning (e.g., see the original BSD mbuf code). (3) Zero-copy TCP is irrelevant to this discussion. In an integrated TCP/FIM/iSCSI implementation, there would be no address boundaries between any of the components and hence no need to avoid the copy across address boundaries that is the motivation for zero-copy TCP. Zero copy TCP schemes cannot achieve "appropriate packet placement" for iSCSI by themselves because they're not capable of ensuring that a 4k SCSI data payload lands in 4k of contiguous memory aligned to a 4k boundary, and hence will cause copies to be made. Beyond this, Doug continues to claim that there are new security issues in FIM but has failed to describe any significant new risks, aside from a general concern that implementation work could introduce security bugs - that is the case for most IETF protocols, and is not a reason to stop working on protocols. 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 Jan 29 10:51: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 KAA06838 for ; Tue, 29 Jan 2002 10:51:04 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0TEhlX01124 for ips-outgoing; Tue, 29 Jan 2002 09:43:47 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sandmail.sandburst.com (sandmail.sandburst.com [216.57.132.42]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0TEhkj01119 for ; Tue, 29 Jan 2002 09:43:46 -0500 (EST) To: ips@ece.cmu.edu Cc: digital_aryan@yahoo.com Subject: Re: iSCSI: Framing Steps In-Reply-To: Message from Ajit Aryan of "Tue, 29 Jan 2002 11:08:42 +0530." <3C563562.1070909@yahoo.com> References: <3C563562.1070909@yahoo.com> Date: Tue, 29 Jan 2002 09:43:22 -0500 From: Stephen Bailey Message-Id: <20020129144344.995B64F10@sandmail.sandburst.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Sridhar, > Its true that the current day IP networks are capable of handling packet > drops .... But it is high time to have a mechanism to handle this > more efficiently, keeping in view the importance of SANs and their > intended use. The combination of IP+transport (TCP/IP) is precisely designed to deliver data efficiently and scalably (as a function of network size). It is the transport layer's role to maximize `goodput'. Dropping packets in the network as a result of congestion and having the transport adjust to this is what results in IP's scalability as compared to system area (flow controlled) network technologies. In other words, it's a feature, not a bug. It's a large part of what made IP the dominant networking technology, and it's never going away. It is not the case that the designers of TCP said `heck, we've got these miserable, lossy networks, I guess we'll just suck it up and do the best we can, even though it'd work a lot better if we had some other characteristics.' TCP does have some warts in providing the best possible goodput, but those are problems for TCP (or other transport) to fix. Anyway, that doesn't seem to be what you're referring to. The RFC 1122 SHOULD says TCP endpoints should cling tightly to each correctly received byte. If an implementation is discarding portions or entire flights of data because a packet is lost that's certainly NOT TCP's problem, and not what FIM is intended to fix. FIM's (or any framing technique's) ONLY goal is to reduce the COST (which may equate with `tractability' if the cost is otherwise prohibitive) of an efficient implementation. It does not improve the data transport efficiency itself at all. Steph From owner-ips@ece.cmu.edu Tue Jan 29 10:55: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 KAA06959 for ; Tue, 29 Jan 2002 10:55:23 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0TEp8O01748 for ips-outgoing; Tue, 29 Jan 2002 09:51: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 g0TEp6j01741 for ; Tue, 29 Jan 2002 09:51:06 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 09:51:05 -0500 Message-ID: <25369470B6F0D41194820002B328BDD211640B@ATLOPS> From: Sanjay Goyal To: "'Julian Satran'" Cc: ips@ece.cmu.edu Subject: iSCSI: MaxRcvPDULength Date: Tue, 29 Jan 2002 09:51:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A8D4.5F21FA80" 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_01C1A8D4.5F21FA80 Content-Type: text/plain; charset="iso-8859-1" Hi Any reasons to make the default value as 8191 instead of 8k(8192). draft 10, page 183 MaxRecvPDULength Use: ALL Senders: Initiator and Target Scope: CO MaxRecvPDULength= Default is 8191 bytes. Regards Sanjay G ------_=_NextPart_001_01C1A8D4.5F21FA80 Content-Type: text/html; charset="iso-8859-1"

Hi

 Any reasons to make the default value as 8191 instead of 8k(8192).

draft 10, page 183

MaxRecvPDULength

Use: ALL Senders: Initiator and Target Scope: CO

MaxRecvPDULength=<number-512-to-(2**24-1)>

Default is 8191 bytes.

 
Regards
Sanjay G
 
 
------_=_NextPart_001_01C1A8D4.5F21FA80-- From owner-ips@ece.cmu.edu Tue Jan 29 10:58: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 KAA07079 for ; Tue, 29 Jan 2002 10:58:18 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0TFLBg04332 for ips-outgoing; Tue, 29 Jan 2002 10:21:11 -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 g0TFL9j04327 for ; Tue, 29 Jan 2002 10:21:09 -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 KAA61744 for ; Tue, 29 Jan 2002 10:18:02 -0500 Received: from d03nm800.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 g0TFKJC115644 for ; Tue, 29 Jan 2002 08:20:19 -0700 Importance: Normal Subject: iSCSI: Discovery Session Functionality To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Kaladhar Voruganti" Date: Tue, 29 Jan 2002 07:17:25 -0800 X-MIMETrack: Serialize by Router on D03NM801/03/M/IBM(Release 5.0.9 |November 16, 2001) at 01/29/2002 08:20:20 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk This note describes the Naming and Discovery teams's current resolution regarding the use of NOPs and Asynch messages in the discovery session: There was no agreement on the need or appropriateness of this requirement. So the general concensus from the Naming and Discovery team, was not to add NOPs or any other commands to the Discovery Session. It will be left as only SendTargets can be sent during the Discovery Session. Kaladhar Voruganti From owner-ips@ece.cmu.edu Tue Jan 29 11:05: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 LAA07463 for ; Tue, 29 Jan 2002 11:05:46 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0TEsxQ02058 for ips-outgoing; Tue, 29 Jan 2002 09:54:59 -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 g0TEsvj02052 for ; Tue, 29 Jan 2002 09:54:57 -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 g0TEsjJ23676; Tue, 29 Jan 2002 09:54:45 -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 g0TEsis29357; Tue, 29 Jan 2002 09:54:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15446.47033.144000.646036@gargle.gargle.HOWL> Date: Tue, 29 Jan 2002 09:54:49 -0500 From: Paul Koning To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: not offering a key References: <277DD60FB639D511AC0400B0D068B71E029373E2@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 29 January 2002) by Black_David@emc.com: > > But that's an artifact of a peculiar design approach for a negotiation > > algorithm. The obvious design approach says that there are two ways > > to *encode* a key having the default value: by sending the key with > > that value, and by omitting that key. Those two encodings should have > > the same effect on the negotiation state machine. > > The problem with this line of reasoning is that it assumes completely > identical state machines at both ends of the negotiation. 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. paul From owner-ips@ece.cmu.edu Tue Jan 29 11:07: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 LAA07510 for ; Tue, 29 Jan 2002 11:07:13 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0TFAlk03461 for ips-outgoing; Tue, 29 Jan 2002 10:10: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 g0TFAjj03456 for ; Tue, 29 Jan 2002 10:10:45 -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 QAA61614; Tue, 29 Jan 2002 16:10:22 +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 g0TFBfN70770; Tue, 29 Jan 2002 16:11:41 +0100 To: Sanjay Goyal Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: MaxRcvPDULength X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 29 Jan 2002 17:11:33 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 29/01/2002 17:11:42, Serialize complete at 29/01/2002 17:11:42 Content-Type: multipart/alternative; boundary="=_alternative 00526D10C2256B50_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00526D10C2256B50_= Content-Type: text/plain; charset="us-ascii" editorial - I'll fix it. Julo Sanjay Goyal 29-01-02 16:51 To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: iSCSI: MaxRcvPDULength Hi Any reasons to make the default value as 8191 instead of 8k(8192). draft 10, page 183 MaxRecvPDULength Use: ALL Senders: Initiator and Target Scope: CO MaxRecvPDULength= Default is 8191 bytes. Regards Sanjay G --=_alternative 00526D10C2256B50_= Content-Type: text/html; charset="us-ascii"
editorial - I'll fix it. Julo


Sanjay Goyal <sanjay_goyal@ivivity.com>

29-01-02 16:51

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

       


Hi

 Any reasons to make the default value as 8191 instead of 8k(8192).

draft 10, page 183

MaxRecvPDULength

Use: ALL Senders: Initiator and Target Scope: CO

MaxRecvPDULength=<number-512-to-(2**24-1)>

Default is 8191 bytes.

 
Regards
Sanjay G
 
 

--=_alternative 00526D10C2256B50_=-- From owner-ips@ece.cmu.edu Tue Jan 29 13:39: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 NAA13176 for ; Tue, 29 Jan 2002 13:39:31 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0THBtR13802 for ips-outgoing; Tue, 29 Jan 2002 12:11:55 -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 g0TCdAj23457 for ; Tue, 29 Jan 2002 07:39:10 -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 g0TCd5Uj022585; Tue, 29 Jan 2002 07:39:05 -0500 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.2/8.12.1/Submit) with ESMTP id g0TCd5D8022582; Tue, 29 Jan 2002 07:39:05 -0500 Date: Tue, 29 Jan 2002 07:39:05 -0500 (EST) From: "Robert D. Russell" To: Black_David@emc.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: not offering a key In-Reply-To: <277DD60FB639D511AC0400B0D068B71E029373E2@CORPMX14> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk David: You say: > Only if the state machines are identical. One simple mistake in setting > a default value, and the assumption that it doesn't need to be negotiated > leads to unpleasant surprises. The right solution to this is in Eddy's > recent mail and my reply - there are no implicit offers -- if you care > about the value of a key, it's your responsibility to negotiate it. It seems to me that your interpretation is adding something new that is not in the standard and was never intended to be in the standard. That is that the value of keys that were not negotiated is "unknown" or uncertain. On the contrary, the standard is quit explicit that all keys have default values, and if a key is not negotiated then it retains its default value on both sides of the connection, initiator and target. If this were not the case, then we would be in the situation of essentially requiring the negotiation of every key, just to confirm the defaults, and this is clearly contrary to the whole idea of the negotiation process. Am I misunderstanding what you are saying? Thanks, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Tue Jan 29 14:48: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 OAA19005 for ; Tue, 29 Jan 2002 14:48:41 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0TIlYr21594 for ips-outgoing; Tue, 29 Jan 2002 13:47:34 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from parmenion.hosting.pacbell.net (parmenion.hosting.pacbell.net [216.100.98.31]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0TIlVj21586 for ; Tue, 29 Jan 2002 13:47:32 -0500 (EST) Received: from somesh ([65.172.158.93]) by parmenion.hosting.pacbell.net id NAA19100; Tue, 29 Jan 2002 13:47:29 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Reply-To: From: "Somesh Gupta" To: Subject: RE: iSCSI: Framing Steps Date: Tue, 29 Jan 2002 10:45: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.00.2919.6700 Importance: Normal In-Reply-To: <20020129144344.995B64F10@sandmail.sandburst.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit While I support a generic direct data placement model, the following are additional points for consideration for analysis of memory bandwidths and sizes. 1. A 10G link dropping packets will not do TCP at 10Gbps. The rate drops as the packet loss increases. I don't recall but Franco or Victor from Nortel had posted an equation once. 2. The amount of memory needed is of the order of delay-bandwidth product and is reasonably independent of the number of connections. Of course, statistically, worse situations are possible, but that is not a design point. If lots of packets are being lost, things are going significantly slower anyway (thus reducing the delay- bandwidth product). 3. The analysis of 10Gbps, half way round the world was initially used in this debate. ALthough interesting, the person with the scenario above is not going to blink at the cost of 256MBytes of fastest memory considering what they are paying for the link. 4. All assumptions are based on existing SCSI API models at targets. Changes to target APIs/meta-data management would let some vendors not have to do data copies anyway. 5. A solutions that is iSCSI specific is not likely to give the savings (especially when it may not work) people expect. As I mentioned, I think we should take the same approach as we did for error recovery (if it is not spilling the beans too much) and come up with a more detailed analysis. Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Stephen Bailey > Sent: Tuesday, January 29, 2002 6:43 AM > To: ips@ece.cmu.edu > Cc: digital_aryan@yahoo.com > Subject: Re: iSCSI: Framing Steps > > > Sridhar, > > > Its true that the current day IP networks are capable of handling packet > > drops .... But it is high time to have a mechanism to handle this > > more efficiently, keeping in view the importance of SANs and their > > intended use. > > The combination of IP+transport (TCP/IP) is precisely designed to > deliver data efficiently and scalably (as a function of network size). > It is the transport layer's role to maximize `goodput'. Dropping > packets in the network as a result of congestion and having the > transport adjust to this is what results in IP's scalability as > compared to system area (flow controlled) network technologies. In > other words, it's a feature, not a bug. It's a large part of what > made IP the dominant networking technology, and it's never going away. > > It is not the case that the designers of TCP said `heck, we've got > these miserable, lossy networks, I guess we'll just suck it up and do > the best we can, even though it'd work a lot better if we had some > other characteristics.' > > TCP does have some warts in providing the best possible goodput, but > those are problems for TCP (or other transport) to fix. Anyway, that > doesn't seem to be what you're referring to. > > The RFC 1122 SHOULD says TCP endpoints should cling tightly to each > correctly received byte. If an implementation is discarding portions > or entire flights of data because a packet is lost that's certainly > NOT TCP's problem, and not what FIM is intended to fix. FIM's (or any > framing technique's) ONLY goal is to reduce the COST (which may equate > with `tractability' if the cost is otherwise prohibitive) of an > efficient implementation. It does not improve the data transport > efficiency itself at all. > > Steph > > > From owner-ips@ece.cmu.edu Tue Jan 29 14:52: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 OAA19098 for ; Tue, 29 Jan 2002 14:52:16 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0TJ4HR23304 for ips-outgoing; Tue, 29 Jan 2002 14:04:17 -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 g0TJ4Ej23295 for ; Tue, 29 Jan 2002 14:04:14 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 14:04:08 -0500 Message-ID: <25369470B6F0D41194820002B328BDD220259E@ATLOPS> From: Eddy Quicksall To: "julian_satran@il. ibm. com (E-mail)" , "ips@ece. cmu. edu (E-mail)" Subject: iSCSI: error text Date: Tue, 29 Jan 2002 14:04:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A8F7.B64BE460" 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_01C1A8F7.B64BE460 Content-Type: text/plain; charset="iso-8859-1" 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_01C1A8F7.B64BE460 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

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_01C1A8F7.B64BE460-- From owner-ips@ece.cmu.edu Tue Jan 29 15:44: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 PAA20439 for ; Tue, 29 Jan 2002 15:44:17 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0TJPZv25222 for ips-outgoing; Tue, 29 Jan 2002 14:25:35 -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 g0TJPUj25212 for ; Tue, 29 Jan 2002 14:25:31 -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 LAA14338; Tue, 29 Jan 2002 11:24:13 -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 LAA28996; Tue, 29 Jan 2002 11:07:31 -0800 (PST) Received: by aimexc06.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 11:22:57 -0800 Message-ID: From: "Fischer, Michael" To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: not offering a key Date: Tue, 29 Jan 2002 11:22:51 -0800 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 My question is that if there is no such thing as an implicit value, then a "default value" shouldn't exist, right? Isn't a "default" implicit? What I am reading from this discussion is that all iSCSI initiators must send _all_ keys. How else is behavior going to be stable? Michael -----Original Message----- From: Paul Koning [mailto:ni1d@arrl.net] Sent: Tuesday, January 29, 2002 6:55 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: not offering a key Excerpt of message (sent 29 January 2002) by Black_David@emc.com: > > But that's an artifact of a peculiar design approach for a negotiation > > algorithm. The obvious design approach says that there are two ways > > to *encode* a key having the default value: by sending the key with > > that value, and by omitting that key. Those two encodings should have > > the same effect on the negotiation state machine. > > The problem with this line of reasoning is that it assumes completely > identical state machines at both ends of the negotiation. 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. paul From owner-ips@ece.cmu.edu Tue Jan 29 16:11: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 QAA21122 for ; Tue, 29 Jan 2002 16:11:29 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0TK65g28812 for ips-outgoing; Tue, 29 Jan 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 cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g0TK5xj28794 for ; Tue, 29 Jan 2002 15:06:00 -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 g0TK5QJ26687; Tue, 29 Jan 2002 15:05:26 -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 g0TK5PR14598; Tue, 29 Jan 2002 15:05:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15447.137.377000.169715@gargle.gargle.HOWL> Date: Tue, 29 Jan 2002 15:05:29 -0500 From: Paul Koning To: somesh_gupta@silverbacksystems.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Framing Steps References: <20020129144344.995B64F10@sandmail.sandburst.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 29 January 2002) by Somesh Gupta: > While I support a generic direct data placement model, > the following are additional points for consideration for > analysis of memory bandwidths and sizes. > > 1. A 10G link dropping packets will not do TCP at 10Gbps. > The rate drops as the packet loss increases. I don't recall > but Franco or Victor from Nortel had posted an equation once. A very old (40 years?) rule of thumb is that 1% loss costs you 50% in throughput. I expect that it gets a lot worse as links get faster. > ... > 3. The analysis of 10Gbps, half way round the world > was initially used in this debate. ALthough interesting, the person > with the scenario above is not going to blink at the cost of > 256MBytes of fastest memory considering what they are paying > for the link. Exactly. One reason ATM failed as a LAN is that its design was burdened with complexity based on that sort of scenario. (In other words: "it has to work at umpteen Gig, across the globe, and only use a tiny little bit of memory because implementations can't handle a megabyte of buffers".) A design optimized for the combination of very high bit rate and very long latency will inevitably be way overpriced for the predominant case, which is the LAN case. paul From owner-ips@ece.cmu.edu Tue Jan 29 16:28: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 QAA21421 for ; Tue, 29 Jan 2002 16:28:54 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0TL1Sx03973 for ips-outgoing; Tue, 29 Jan 2002 16:01:28 -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 g0TL1Pj03965 for ; Tue, 29 Jan 2002 16:01:25 -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 WAA15224 for ; Tue, 29 Jan 2002 22:01:18 +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 g0TL2cB36540 for ; Tue, 29 Jan 2002 22:02:38 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: Framing Steps X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 29 Jan 2002 23:02:33 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 29/01/2002 23:02:37, Serialize complete at 29/01/2002 23:02:37 Content-Type: multipart/alternative; boundary="=_alternative 007323CCC2256B50_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 007323CCC2256B50_= Content-Type: text/plain; charset="us-ascii" How wonderfull to have among us people that can tell us in one short sentence why ATM failed [to reach the desktop because otherwise it is still gaining ground]. That adds a lot of clarity and technical argument to our discussion. Julo Paul Koning Sent by: owner-ips@ece.cmu.edu 29-01-02 22:05 To: somesh_gupta@silverbacksystems.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: Framing Steps Excerpt of message (sent 29 January 2002) by Somesh Gupta: > While I support a generic direct data placement model, > the following are additional points for consideration for > analysis of memory bandwidths and sizes. > > 1. A 10G link dropping packets will not do TCP at 10Gbps. > The rate drops as the packet loss increases. I don't recall > but Franco or Victor from Nortel had posted an equation once. A very old (40 years?) rule of thumb is that 1% loss costs you 50% in throughput. I expect that it gets a lot worse as links get faster. > ... > 3. The analysis of 10Gbps, half way round the world > was initially used in this debate. ALthough interesting, the person > with the scenario above is not going to blink at the cost of > 256MBytes of fastest memory considering what they are paying > for the link. Exactly. One reason ATM failed as a LAN is that its design was burdened with complexity based on that sort of scenario. (In other words: "it has to work at umpteen Gig, across the globe, and only use a tiny little bit of memory because implementations can't handle a megabyte of buffers".) A design optimized for the combination of very high bit rate and very long latency will inevitably be way overpriced for the predominant case, which is the LAN case. paul --=_alternative 007323CCC2256B50_= Content-Type: text/html; charset="us-ascii"
How wonderfull to have among us people that can tell us in one short sentence why ATM failed [to reach the desktop because otherwise it is still gaining ground].  That adds a lot of clarity and technical argument to our discussion.  Julo


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

29-01-02 22:05

       
        To:        somesh_gupta@silverbacksystems.com
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: Framing Steps

       


Excerpt of message (sent 29 January 2002) by Somesh Gupta:
> While I support a generic direct data placement model,
> the following are additional points for consideration for
> analysis of memory bandwidths and sizes.
>
> 1. A 10G link dropping packets will not do TCP at 10Gbps.
> The rate drops as the packet loss increases. I don't recall
> but Franco or Victor from Nortel had posted an equation once.

A very old (40 years?) rule of thumb is that 1% loss costs you 50% in
throughput.  I expect that it gets a lot worse as links get faster.
> ...
> 3. The analysis of 10Gbps, half way round the world
> was initially used in this debate. ALthough interesting, the person
> with the scenario above is not going to blink at the cost of
> 256MBytes of fastest memory considering what they are paying
> for the link.

Exactly.

One reason ATM failed as a LAN is that its design was burdened with
complexity based on that sort of scenario.  (In other words: "it has
to work at umpteen Gig, across the globe, and only use a tiny little
bit of memory because implementations can't handle a megabyte of
buffers".)

A design optimized for the combination of very high bit rate and very
long latency will inevitably be way overpriced for the predominant
case, which is the LAN case.

     paul

--=_alternative 007323CCC2256B50_=-- From owner-ips@ece.cmu.edu Tue Jan 29 16:30: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 QAA21474 for ; Tue, 29 Jan 2002 16:30:04 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0TKb4r01670 for ips-outgoing; Tue, 29 Jan 2002 15:37:04 -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 g0TKb2j01662 for ; Tue, 29 Jan 2002 15:37:02 -0500 (EST) Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel9.hp.com (Postfix) with ESMTP id 8FEFFE00723; Tue, 29 Jan 2002 15:36:56 -0500 (EST) Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 393F6113; Tue, 29 Jan 2002 15:36:56 -0500 (EST) Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 15:36:56 -0500 Message-ID: <499DC368E25AD411B3F100902740AD6508E99EB6@xrose03.rose.hp.com> From: "ERICKSON,SHAWN (HP-Roseville,ex1)" To: "'Paul Koning'" , somesh_gupta@silverbacksystems.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Framing Steps Date: Tue, 29 Jan 2002 15:36:54 -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 29 January 2002) by Somesh Gupta: > > While I support a generic direct data placement model, > > the following are additional points for consideration for > > analysis of memory bandwidths and sizes. > > > > 1. A 10G link dropping packets will not do TCP at 10Gbps. > > The rate drops as the packet loss increases. I don't recall > > but Franco or Victor from Nortel had posted an equation once. > > A very old (40 years?) rule of thumb is that 1% loss costs you 50% in > throughput. I expect that it gets a lot worse as links get faster. I would expect is to stay the same, as in your example stay 50% regardless of link speed. However 50% of a 1Gbps connection is ten times smaller then 50% of 10Gbps a connection. In other words 50% of 10Gbps hurts a lot more then 50% 1 Gbps if you focus on the bit rate. > > ... > > 3. The analysis of 10Gbps, half way round the world > > was initially used in this debate. ALthough interesting, the person > > with the scenario above is not going to blink at the cost of > > 256MBytes of fastest memory considering what they are paying > > for the link. > > Exactly. Yup. I believe the concern about high-speed connections and longer round trip times can be solved by upping the TCP window and correspondingly upping the resource requirements (mostly additional RAM) to deal with it. This could be avoided by not using TCP as it exists today but the issues with that are many (already heavily discussed) and can IMHO outstrip the costs of additional RAM. In general I think the costs of RAM are dropping far faster then the costs of upgrading the network. > One reason ATM failed as a LAN is that its design was burdened with > complexity based on that sort of scenario. (In other words: "it has > to work at umpteen Gig, across the globe, and only use a tiny little > bit of memory because implementations can't handle a megabyte of > buffers".) > > A design optimized for the combination of very high bit rate and very > long latency will inevitably be way overpriced for the predominant > case, which is the LAN case. I would tend to agree. -Shawn p.s. I am not speaking for Hewlett-Packard this is just my opinion. From owner-ips@ece.cmu.edu Tue Jan 29 16:30: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 QAA21512 for ; Tue, 29 Jan 2002 16:30:46 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0TKsfJ03333 for ips-outgoing; Tue, 29 Jan 2002 15:54:41 -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 g0TJRpj25410 for ; Tue, 29 Jan 2002 14:27:51 -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 g0TJRcJ26516; Tue, 29 Jan 2002 14:27:38 -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 g0TJRbu12107; Tue, 29 Jan 2002 14:27:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15446.63406.187000.809769@gargle.gargle.HOWL> Date: Tue, 29 Jan 2002 14:27:42 -0500 From: Paul Koning To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: MaxRcvPDULength 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 Broken record time... Changes that affect the behavior of implementations are NOT editorial changes. Only changes that make no difference to the bits on the wire and the bits in the implementations can be editorial. Yes, changing a default from 8191 to 8192 is a very small change, but it's a technical change nonetheless. paul From owner-ips@ece.cmu.edu Tue Jan 29 16:52: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 QAA21984 for ; Tue, 29 Jan 2002 16:52:44 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0TKou702910 for ips-outgoing; Tue, 29 Jan 2002 15:50:56 -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 g0TKorj02905 for ; Tue, 29 Jan 2002 15:50:53 -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 VAA110276; Tue, 29 Jan 2002 21:50: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 g0TKq6N82086; Tue, 29 Jan 2002 21:52:06 +0100 To: Eddy Quicksall Cc: "ips@ece. cmu. edu (E-mail)" 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: Tue, 29 Jan 2002 22:51:59 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 29/01/2002 22:52:03, Serialize complete at 29/01/2002 22:52:03 Content-Type: multipart/alternative; boundary="=_alternative 007190E0C2256B50_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 007190E0C2256B50_= Content-Type: text/plain; charset="us-ascii" 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 --=_alternative 007190E0C2256B50_= Content-Type: text/html; charset="us-ascii"
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

--=_alternative 007190E0C2256B50_=-- From owner-ips@ece.cmu.edu Tue Jan 29 17:29: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 RAA23064 for ; Tue, 29 Jan 2002 17:29:23 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0TLW8306345 for ips-outgoing; Tue, 29 Jan 2002 16:32:08 -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 g0TLW6j06340 for ; Tue, 29 Jan 2002 16:32:06 -0500 (EST) Received: (cpmta 4346 invoked from network); 29 Jan 2002 13:31:55 -0800 Received: from 64.130.130.105 (HELO dougrmt) by smtp.telocity.com (209.228.32.214) with SMTP; 29 Jan 2002 13:31:55 -0800 X-Sent: 29 Jan 2002 21:31:55 GMT From: "Douglas Otis" To: Cc: Subject: RE: [Tsvwg] RE: iSCSI: Framing Steps Date: Tue, 29 Jan 2002 13:33:18 -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 Importance: Normal In-Reply-To: <277DD60FB639D511AC0400B0D068B71E029373E3@CORPMX14> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Shridhar, David, >Shridhar Mukund wrote: >>A few more clarifications: >> >>(1) If the data-dependent memory allocator below TCP gets confused, >> that's its problem, and iSCSI's problem, not TCP's. As long >> as the inbound data is presented to TCP in the order it came >> off the wire, TCP's processing behavior is unchanged. If the >> data is delivered by TCP in locations other than those iSCSI >> was expecting, it can be copied to the right locations with >> suitable safeguards. Let's say the packet received off of the wire is not in contagious memory (as typical) but is a memory array. The layer below TCP constructs this array to present information in the correct location as per the iSCSI structures found within the content of the expected TCP byte stream. This assignment process will require prior state to be considered in performing this assignment, in addition to sharing the identification of these locations with the iSCSI application. Should there be an error in this process, the normal expectations of correct placement is no longer valid as a result. As there must already be communication between the application and this "below TCP layer process", posting error information seems like a small detail. Indeed, one could assume the application would track each piece of information in this array to detect an error, but this would not likely the solution used as the intent is to minimize overhead. I would hope that if this scheme is to be used, a definition of the information relayed between the application and the application specific "below TCP layer process" would be included within the description of this technique. The safeguards would need to include that this layer acts to prevent duplications to avoid overwritting information that may be already found in a prior array sent to TCP. Should TCP processing of these packets not match exactly with this "below TCP layer process", there would be potential for these differences to create problems. In addition to matching the view of TCP within this "below TCP layer process", errors found in the processing of the iSCSI structures within the "below TCP layer process" will also need special handling. The simple act of placing the iSCSI data into the correct location based on the content of the TCP byte stream implies that the "below TCP layer process" understand beforehand this byte stream. >>(2) FIM processing makes no changes to packet contents, period. >> I have no idea where Doug got the impression "it is not the packet >> location that is being changed, but the content of the packet >> or it would be of little value". That is simply not true - >> the FIM markers can't be removed below TCP because they were >> sent in the TCP bytestream and have to be presented to TCP. >> The contents of each packet may not be contiguous in >> memory, but that has been common in TCP implementations >> from the beginning (e.g., see the original BSD mbuf code). It is not a reassignment of the packet, but detailed placement of the content within the packet that I was referencing. This operation is not done on the packet as a whole, but to many portions of information found within the packet. This operation is not a simple, linear, sequential placement of information. An array could make such appear as a contagious packet following this operation. I agree with that point. I was attempting to make clear the function that was being performed and the level of complexity involved. >>(3) Zero-copy TCP is irrelevant to this discussion. In an integrated >> TCP/FIM/iSCSI implementation, there would be no address boundaries >> between any of the components and hence no need to avoid the copy >> across address boundaries that is the motivation for zero-copy TCP. >> Zero copy TCP schemes cannot achieve "appropriate packet placement" >> for iSCSI by themselves because they're not capable of ensuring that >> a 4k SCSI data payload lands in 4k of contiguous memory aligned to >> a 4k boundary, and hence will cause copies to be made. The description that David was using sounded as if he was describing Zero Copy TCP. I felt there was detail lacking in this description. iSCSI structures would not ensure page alignment, and the process of placing and splicing together prior information would be part of this "below TCP layer process." In addition, there would be a requirement to hold some packets should information arrive not aligned within the TCP segment or before the marker. This additional requirement together with a more complex state becomes motivation for transitioning this scheme toward creating a framed version of TCP. My argument from the very beginning was that we should not consider changing TCP and that SCTP provided the needed framing as well as removed the need for placing the application below the transport. This debate has evolved into semantics as to what constitutes a change to TCP. Placing the application below TCP seems like a change. David Black wrote: > > Beyond this, Doug continues to claim that there are new security > issues in FIM but has failed to describe any significant new risks, > aside from a general concern that implementation work could introduce > security bugs - that is the case for most IETF protocols, and is not > a reason to stop working on protocols. Perhaps a full description of the "below TCP layer process" would be helpful. Examining the state created, the types of commutations relayed between this layer and the application would be needed for assessment. If the goal is to allow applications a common service or API as was once possible with TCP, then these definitions are important and to allow risks to be assessed. My added concern was that using an interval that was a power of 2 would allow a prediction of a where the mark would be found in the future. I think it would be incumbent to present full details of this scheme to allow a complete review and for a standardize interface to emerge. The state found in this "below TCP layer process" in conjunction with the types of application communications are potential areas where security may become problematic. Doug From owner-ips@ece.cmu.edu Tue Jan 29 17:33: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 RAA23189 for ; Tue, 29 Jan 2002 17:33:23 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0TLrxp08054 for ips-outgoing; Tue, 29 Jan 2002 16:53:59 -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 g0TLrvj08050 for ; Tue, 29 Jan 2002 16:53:57 -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 g0TLrqUj012185 for ; Tue, 29 Jan 2002 16:53:52 -0500 Message-ID: <3C5717F2.D01A8DCF@iol.unh.edu> Date: Tue, 29 Jan 2002 16:45:22 -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 To: IP Storage CMU Subject: Link update Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, On the page http://www.ece.cmu.edu/~ips/IPS_Projects/ips_projects.html there is a link to one of the UNH consortia, which is incorrect. The correct link is: http://www.iol.unh.edu/consortiums/iscsi/iscsi_linux.html or even http://www.iol.unh.edu/consortiums/iscsi/ Sorry to send this to the list, but I'm not sure who at CMU should get it. -- 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 Tue Jan 29 17:35: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 RAA23271 for ; Tue, 29 Jan 2002 17:35:23 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0TLtb508204 for ips-outgoing; Tue, 29 Jan 2002 16:55: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 g0TLtYj08196 for ; Tue, 29 Jan 2002 16: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 g0TLtSJ27482 for ; Tue, 29 Jan 2002 16:55:28 -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 g0TLtRZ20606 for ; Tue, 29 Jan 2002 16:55:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15447.6739.601000.229275@gargle.gargle.HOWL> Date: Tue, 29 Jan 2002 16:55:31 -0500 From: Paul Koning To: ips@ece.cmu.edu Subject: RE: iSCSI: Framing Steps 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 29 January 2002) by Julian Satran: > How wonderfull to have among us people that can tell us in one short > sentence why ATM failed [to reach the desktop because otherwise it is > still gaining ground]. That adds a lot of clarity and technical argument > to our discussion. Actually, my ATM comment was mostly on the ABR service; I don't think that has gained ground anywhere. And, sarcastic comments aside, there's a lot of history of both good and bad decisions in other protocol designs. It wouldn't hurt for people to consider that some of those lessons might even be applicable to iSCSI. paul From owner-ips@ece.cmu.edu Tue Jan 29 18:30:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24331 for ; Tue, 29 Jan 2002 18:30:34 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0TMTtT10749 for ips-outgoing; Tue, 29 Jan 2002 17:29:55 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ausxc08.us.dell.com (ausxc08.us.dell.com [143.166.227.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0TMTrj10743 for ; Tue, 29 Jan 2002 17:29:54 -0500 (EST) Received: by ausxc08.us.dell.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Jan 2002 16:29:10 -0600 Message-ID: <71714C04806CD511935200902728921701A6EEC1@ausxmrr502.us.dell.com> From: Dan_McConnell@Dell.com To: ips@ece.cmu.edu Subject: "Lower overhead" iSCSI Date: Tue, 29 Jan 2002 16:29:44 -0600 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 Let me start off by saying that I am interested in doing "iSCSI" protocol over UDP. Now I realize that this is an old issue and will probably start some "religious" battles, but let me state the scenarios before I receive death threats. The planned environment that this will go into is a small one with say 10 servers connected through a "non-blocking" switch to the storage device (ie no routers, gateways, etc...just direct point-to-point connections). This is assuming that the switch is really non-blocking and hopefully implements flow control or pause frames. So technically all you should have to worry about is port/device contention. However, when you think about it...this is similar to FC. FCP runs on class 3 FC which is a non-reliable transport protocol such as UDP and handles contention, also some of the early "SAN interconnect" guys are doing this today with relatively good performance and few issues. The attempt here is to maintain low CPU utilization at high performance rates. While I realize that these TOE devices are moving along rapidly, there are some situations where they are not feasible, such as a blade server environment (no PCI slots, and no real estate/power available for onboard TOE). Worst case scenario is that a packet is dropped or received out of order and the ULP (SCSI) must resend the cmd/data sequence - still no data lost, just a temporary performance hit. So my question is: is this feasible?, and why not implement an "iSCSI" protocol layer that can run over TCP or UDP(though I realize it won't be considered "standards compliant")? Thanks, Dan From owner-ips@ece.cmu.edu Tue Jan 29 19:34: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 TAA25638 for ; Tue, 29 Jan 2002 19:34:28 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0TNuOL17155 for ips-outgoing; Tue, 29 Jan 2002 18:56:24 -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 g0TNuIj17138 for ; Tue, 29 Jan 2002 18:56:18 -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 PAA12824 for ; Tue, 29 Jan 2002 15:56:12 -0800 (PST) Received: from aimexc02.corp.adaptec.com (aimexc02.corp.adaptec.com [162.62.62.40]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id PAA27528 for ; Tue, 29 Jan 2002 15:39:29 -0800 (PST) Received: from adaptec.com (ws10-20-142-76.corp.adaptec.com [10.20.142.76]) by aimexc02.corp.adaptec.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DPT3988Q; Tue, 29 Jan 2002 15:55:11 -0800 Message-ID: <3C5736AD.C21FD81A@adaptec.com> Date: Tue, 29 Jan 2002 15:56:29 -0800 From: Tow Wang X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: iSCSI: draft 9, yes=1 no=0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian: I have a suggestion to improve readability: in appendix D, would you indicate that for binary values, "yes=1 no=0", and that the "result function" is the logical operation that you would apply to the offered values in order to obtain the final negotiated result. Granted, the above can be inferred if one went back to 2.2.4 and took some educated guesses, but I think the above should be made clear to a reader who has not been following the discussions of this reflector. -- Tow Wang Adaptec Software Engineer From owner-ips@ece.cmu.edu Tue Jan 29 19:36: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 TAA25658 for ; Tue, 29 Jan 2002 19:36:04 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0TNo1g16754 for ips-outgoing; Tue, 29 Jan 2002 18:50:01 -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 g0TNnwj16742 for ; Tue, 29 Jan 2002 18:49:58 -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 PAA12099 for ; Tue, 29 Jan 2002 15:49:52 -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 PAA26782 for ; Tue, 29 Jan 2002 15:33:10 -0800 (PST) Received: by aimexc07.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 15:48:44 -0800 Message-ID: From: "Ranganathan, Deva" To: "'ips@ece.cmu.edu'" Subject: ISCSI: Login request/response Statusn/expstatsn clarification.. Date: Tue, 29 Jan 2002 15:48:34 -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 Julian, all, I am looking at the latest draft draft-ietf-ips-iSCSI-10.txt and also the earlier 0.8 and 0.9 draft. Under login request, expStatSN is described in draft 10 page 66 - Section 1.12.10 as " ExpStatSN This is ExpStatSN for the old connection. This field is valid only if the Login request restarts a connection (i.e., X bit is 1 and TSID is not zero). " However for login response, StatSN is described in page 70, Section 1.13.4 as "StatSN For the first Login Response (the response to the first Login Request), this is the starting status Sequence Num- ber for the connection. The next response of any kind, including the next login response, if any, in the same login phase, will carry this number + 1. This field is valid only if the Status Class is 0. " Am I missing something? -Thanks Deva Adaptec Inc From owner-ips@ece.cmu.edu Tue Jan 29 19:38: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 TAA25756 for ; Tue, 29 Jan 2002 19:38:48 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0TNmXo16611 for ips-outgoing; Tue, 29 Jan 2002 18:48:33 -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 g0TNmSj16600 for ; Tue, 29 Jan 2002 18:48:29 -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 PAA11894 for ; Tue, 29 Jan 2002 15:48:22 -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 PAA26593 for ; Tue, 29 Jan 2002 15:31:40 -0800 (PST) Received: by aimexc07.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 15:47:14 -0800 Message-ID: From: "Ranganathan, Deva" To: "'ips@ece.cmu.edu'" Cc: "Ranganathan, Deva" Date: Tue, 29 Jan 2002 15:47:07 -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 Julian, all, I am looking at the latest draft draft-ietf-ips-iSCSI-10.txt and also the earlier 0.8 and 0.9 draft. Under login request, expStatSN is described in draft 10 page 66 - Section 1.12.10 as " ExpStatSN This is ExpStatSN for the old connection. This field is valid only if the Login request restarts a connection (i.e., X bit is 1 and TSID is not zero). " However for login response, StatSN is described in page 70, Section 1.13.4 as "StatSN For the first Login Response (the response to the first Login Request), this is the starting status Sequence Num- ber for the connection. The next response of any kind, including the next login response, if any, in the same login phase, will carry this number + 1. This field is valid only if the Status Class is 0. " Am I missing something? -Thanks Deva Adaptec Inc. From owner-ips@ece.cmu.edu Wed Jan 30 00:24: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 AAA01906 for ; Wed, 30 Jan 2002 00:24:16 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0U4P7r03456 for ips-outgoing; Tue, 29 Jan 2002 23:25:07 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from osmtp3.electric.net (osmtp3.electric.net [216.129.90.30]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0U4P5j03452 for ; Tue, 29 Jan 2002 23:25:06 -0500 (EST) Received: from [64.170.220.14] (helo=EGRodriguez) by osmtp3.electric.net with esmtp (Exim 3.22 #1) id 16VmIv-000MrV-04; Tue, 29 Jan 2002 20:25:01 -0800 From: "Elizabeth G. Rodriguez" To: "'Stephen Schaeffer'" , "'IP Storage CMU'" Subject: RE: Link update Date: Tue, 29 Jan 2002 22:22:10 -0600 Keywords: IETF-IPS Message-ID: <00e001c1a945$b0a1b5f0$0edcaa40@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 In-Reply-To: <3C5717F2.D01A8DCF@iol.unh.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Stephen, The CMU web page is no longer an official web page for IPS. It has be decommissioned, since the person who was maintaining it can no longer do so. (BTW: The link to the CMU page from the IPS charte page has been removed.) Sorry, Elizabeth -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of Stephen Schaeffer Sent: Tuesday, January 29, 2002 3:45 PM To: IP Storage CMU Subject: Link update Hi all, On the page http://www.ece.cmu.edu/~ips/IPS_Projects/ips_projects.html there is a link to one of the UNH consortia, which is incorrect. The correct link is: http://www.iol.unh.edu/consortiums/iscsi/iscsi_linux.html or even http://www.iol.unh.edu/consortiums/iscsi/ Sorry to send this to the list, but I'm not sure who at CMU should get it. -- 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 Jan 30 01:58: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 BAA03095 for ; Wed, 30 Jan 2002 01:58:26 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0U6Wio10492 for ips-outgoing; Wed, 30 Jan 2002 01:32:44 -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 g0U6Wgj10487 for ; Wed, 30 Jan 2002 01:32:42 -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 HAA38528 for ; Wed, 30 Jan 2002 07:32: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 g0U6XuD49442 for ; Wed, 30 Jan 2002 07:33:56 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: "Lower overhead" iSCSI X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 30 Jan 2002 08:33:53 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 30/01/2002 08:33:56, Serialize complete at 30/01/2002 08:33:56 Content-Type: multipart/alternative; boundary="=_alternative 00238AC9C2256B51_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00238AC9C2256B51_= Content-Type: text/plain; charset="us-ascii" Dan, We don't want start this discussion - it is out of the charter of this group. A bit of advise - before even getting to the public - we at IBM did run a testbed with the following results: no advantage for UDP on any relevant performance metric (including CPU utilization) even before considering the effects or recovery code on most stacks it performed worse (rumor has it that stacks have TCP very well tuned, not so UDP) Adding to that the lack of congestion control took it out of our vocabulary. DCP if successful and widely deployed may change that in the future. Or SCTP may. Julo Dan_McConnell@Dell.com Sent by: owner-ips@ece.cmu.edu 30-01-02 00:29 To: ips@ece.cmu.edu cc: Subject: "Lower overhead" iSCSI Let me start off by saying that I am interested in doing "iSCSI" protocol over UDP. Now I realize that this is an old issue and will probably start some "religious" battles, but let me state the scenarios before I receive death threats. The planned environment that this will go into is a small one with say 10 servers connected through a "non-blocking" switch to the storage device (ie no routers, gateways, etc...just direct point-to-point connections). This is assuming that the switch is really non-blocking and hopefully implements flow control or pause frames. So technically all you should have to worry about is port/device contention. However, when you think about it...this is similar to FC. FCP runs on class 3 FC which is a non-reliable transport protocol such as UDP and handles contention, also some of the early "SAN interconnect" guys are doing this today with relatively good performance and few issues. The attempt here is to maintain low CPU utilization at high performance rates. While I realize that these TOE devices are moving along rapidly, there are some situations where they are not feasible, such as a blade server environment (no PCI slots, and no real estate/power available for onboard TOE). Worst case scenario is that a packet is dropped or received out of order and the ULP (SCSI) must resend the cmd/data sequence - still no data lost, just a temporary performance hit. So my question is: is this feasible?, and why not implement an "iSCSI" protocol layer that can run over TCP or UDP(though I realize it won't be considered "standards compliant")? Thanks, Dan --=_alternative 00238AC9C2256B51_= Content-Type: text/html; charset="us-ascii"
Dan,

We don't want start this discussion - it is out of the charter of this group.
A bit of advise - before even getting to the public - we at IBM did run a testbed with the following results:

  • no advantage for UDP on any relevant performance metric (including CPU utilization) even before considering the effects or recovery code
  • on most stacks it performed worse (rumor has it that stacks have TCP very well tuned, not so UDP)

    Adding to that the lack of congestion control took it out of our vocabulary.

    DCP if successful and widely deployed may change that in the future. Or SCTP may.

    Julo




    Dan_McConnell@Dell.com
    Sent by: owner-ips@ece.cmu.edu

    30-01-02 00:29

    		       
            To:        ips@ece.cmu.edu
            cc:        
            Subject:        "Lower overhead" iSCSI

           


    Let me start off by saying that I am interested in doing "iSCSI" protocol
    over UDP.  Now I realize that this is an old issue and will probably start
    some "religious" battles, but let me state the scenarios before I receive
    death threats.  The planned environment that this will go into is a small
    one with say 10 servers connected through a "non-blocking" switch to the
    storage device (ie no routers, gateways, etc...just direct point-to-point
    connections).  This is assuming that the switch is really non-blocking and
    hopefully implements flow control or pause frames.  So technically all you
    should have to worry about is port/device contention.  However, when you
    think about it...this is similar to FC.  FCP runs on class 3 FC which is a
    non-reliable transport protocol such as UDP and handles contention, also
    some of the early "SAN interconnect" guys are doing this today with
    relatively good performance and few issues.
                    The attempt here is to maintain low CPU utilization at high
    performance rates.  While I realize that these TOE devices are moving along
    rapidly, there are some situations where they are not feasible, such as a
    blade server environment (no PCI slots, and no real estate/power available
    for onboard TOE).  Worst case scenario is that a packet is dropped or
    received out of order and the ULP (SCSI) must resend the cmd/data sequence -
    still no data lost, just a temporary performance hit.
                    So my question is:  is this feasible?, and why not implement an
    "iSCSI" protocol layer that can run over TCP or UDP(though I realize it
    won't be considered "standards compliant")?

    Thanks,
    Dan

--=_alternative 00238AC9C2256B51_=-- From owner-ips@ece.cmu.edu Wed Jan 30 02:01: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 CAA05434 for ; Wed, 30 Jan 2002 02:01:44 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0U6hEr10998 for ips-outgoing; Wed, 30 Jan 2002 01:43:14 -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 g0U6hDj10992 for ; Wed, 30 Jan 2002 01:43: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 HAA110624 for ; Wed, 30 Jan 2002 07:43: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 g0U6iRD51774 for ; Wed, 30 Jan 2002 07:44:27 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: ISCSI: Login request/response Statusn/expstatsn clarification.. X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 30 Jan 2002 08:44:24 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 30/01/2002 08:44:26, Serialize complete at 30/01/2002 08:44:26 Content-Type: multipart/alternative; boundary="=_alternative 00249246C2256B51_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00249246C2256B51_= Content-Type: text/plain; charset="us-ascii" Deva, ExpStatSN in a restart Login is meant to convey to the target "up to which point where statuses received" on the old connection. StatSN in the response is completely related to the new connection (new numbering, recall statuses are numbered per connection). Julo "Ranganathan, Deva" Sent by: owner-ips@ece.cmu.edu 30-01-02 01:48 To: "'ips@ece.cmu.edu'" cc: Subject: ISCSI: Login request/response Statusn/expstatsn clarification.. Julian, all, I am looking at the latest draft draft-ietf-ips-iSCSI-10.txt and also the earlier 0.8 and 0.9 draft. Under login request, expStatSN is described in draft 10 page 66 - Section 1.12.10 as " ExpStatSN This is ExpStatSN for the old connection. This field is valid only if the Login request restarts a connection (i.e., X bit is 1 and TSID is not zero). " However for login response, StatSN is described in page 70, Section 1.13.4 as "StatSN For the first Login Response (the response to the first Login Request), this is the starting status Sequence Num- ber for the connection. The next response of any kind, including the next login response, if any, in the same login phase, will carry this number + 1. This field is valid only if the Status Class is 0. " Am I missing something? -Thanks Deva Adaptec Inc --=_alternative 00249246C2256B51_= Content-Type: text/html; charset="us-ascii"
Deva,

ExpStatSN in a restart Login is meant to convey to the target "up to which point where statuses received" on the old connection.
StatSN in the response is completely related to the new connection (new numbering, recall statuses are numbered per connection).

Julo


"Ranganathan, Deva" <Deva_Ranganathan@adaptec.com>
Sent by: owner-ips@ece.cmu.edu

30-01-02 01:48

       
        To:        "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
        cc:        
        Subject:        ISCSI: Login request/response Statusn/expstatsn clarification..

       


Julian, all,
I am looking at the latest draft draft-ietf-ips-iSCSI-10.txt  and also the
earlier 0.8 and 0.9 draft.  
Under login request, expStatSN is described in draft 10 page 66 - Section
1.12.10 as
" ExpStatSN This is ExpStatSN for the old connection. This field is valid
only if the Login request restarts a connection (i.e., X bit is 1 and TSID
is not zero). "
However for login response, StatSN is described in page 70, Section 1.13.4
as

"StatSN For the first Login Response (the response to the first Login
Request), this is the starting status Sequence Num- ber for the connection.
The next response of any kind, including the next login response, if any, in
the same login phase, will carry this number + 1. This field is valid only
if the Status Class is 0. "
Am I missing something?
-Thanks
Deva
Adaptec Inc



--=_alternative 00249246C2256B51_=-- From owner-ips@ece.cmu.edu Wed Jan 30 02:07: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 CAA11423 for ; Wed, 30 Jan 2002 02:07:00 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0U6Be809439 for ips-outgoing; Wed, 30 Jan 2002 01:11:40 -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 g0U6Bbj09434 for ; Wed, 30 Jan 2002 01:11:37 -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 HAA16068 for ; Wed, 30 Jan 2002 07:11: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 g0U6CrJ69070 for ; Wed, 30 Jan 2002 07:12:53 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: MaxRcvPDULength X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 30 Jan 2002 08:12:48 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 30/01/2002 08:12:51, Serialize complete at 30/01/2002 08:12:51 Content-Type: multipart/alternative; boundary="=_alternative 00212082C2256B51_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00212082C2256B51_= Content-Type: text/plain; charset="us-ascii" Broken record indeed... julo Paul Koning Sent by: owner-ips@ece.cmu.edu 29-01-02 21:27 To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI: MaxRcvPDULength Broken record time... Changes that affect the behavior of implementations are NOT editorial changes. Only changes that make no difference to the bits on the wire and the bits in the implementations can be editorial. Yes, changing a default from 8191 to 8192 is a very small change, but it's a technical change nonetheless. paul --=_alternative 00212082C2256B51_= Content-Type: text/html; charset="us-ascii"
Broken record indeed... julo


Paul Koning <pkoning@equallogic.com>
Sent by: owner-ips@ece.cmu.edu

29-01-02 21:27

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

       


Broken record time...

Changes that affect the behavior of implementations are NOT editorial
changes.  Only changes that make no difference to the bits on the wire
and the bits in the implementations can be editorial.

Yes, changing a default from 8191 to 8192 is a very small change, but
it's a technical change nonetheless.

    paul

--=_alternative 00212082C2256B51_=-- From owner-ips@ece.cmu.edu Wed Jan 30 02:32: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 CAA11747 for ; Wed, 30 Jan 2002 02:32:43 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0U6kvv11199 for ips-outgoing; Wed, 30 Jan 2002 01:46:57 -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 g0U6ktj11194 for ; Wed, 30 Jan 2002 01:46:55 -0500 (EST) Received: from xparelay1.corp.hp.com (xparelay1.corp.hp.com [15.58.136.173]) by palrel12.hp.com (Postfix) with ESMTP id EEBA26003CC for ; Tue, 29 Jan 2002 22:46:49 -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 D6E3AE0008B for ; Tue, 29 Jan 2002 22:46:49 -0800 (PST) Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 22:46:49 -0800 Message-ID: <499DC368E25AD411B3F100902740AD650AFC7D96@xrose03.rose.hp.com> From: "WENDT,JIM (HP-Roseville,ex1)" To: ips@ece.cmu.edu Subject: iSCSI: No Framing Date: Tue, 29 Jan 2002 22:46: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 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 Wed Jan 30 11:09:10 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23610 for ; Wed, 30 Jan 2002 11:09:10 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0UEX8h17372 for ips-outgoing; Wed, 30 Jan 2002 09:33: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 g0UEX5j17363 for ; Wed, 30 Jan 2002 09:33:06 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jan 2002 09:33:05 -0500 Message-ID: <25369470B6F0D41194820002B328BDD211640F@ATLOPS> From: Sanjay Goyal To: "'roweber@acm.org'" Cc: ips@ece.cmu.edu Subject: iSCSI: SCSI Cmd PDU larger than 48 bytes Date: Wed, 30 Jan 2002 09:33:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A99B.070556E0" 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_01C1A99B.070556E0 Content-Type: text/plain; charset="iso-8859-1" what is the probability that the SCSI Cmd PDU will be more than 48 bytes? the cases are: 1. Bi-Di command 2. CDB larger than 16 bytes Regards Sanjay G ------_=_NextPart_001_01C1A99B.070556E0 Content-Type: text/html; charset="iso-8859-1"

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

the cases are:

1. Bi-Di command

2. CDB larger than 16 bytes

Regards

Sanjay G

------_=_NextPart_001_01C1A99B.070556E0-- From owner-ips@ece.cmu.edu Wed Jan 30 11: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 LAA23676 for ; Wed, 30 Jan 2002 11:11:11 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0UFI9v20991 for ips-outgoing; Wed, 30 Jan 2002 10:18:09 -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 g0UFI7j20983 for ; Wed, 30 Jan 2002 10:18:07 -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 g0UFI0J31720; Wed, 30 Jan 2002 10:18:00 -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 g0UFHuM22341; Wed, 30 Jan 2002 10:17:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15448.3753.134000.246344@gargle.gargle.HOWL> Date: Wed, 30 Jan 2002 10:18:01 -0500 From: Paul Koning To: jim_wendt@hp.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: No Framing References: <499DC368E25AD411B3F100902740AD650AFC7D96@xrose03.rose.hp.com> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 29 January 2002) by WENDT,JIM (HP-Roseville,ex1): > 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): > ....... I agree with all the points you made, and I support your conclusion. paul From owner-ips@ece.cmu.edu Wed Jan 30 13: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 NAA28785 for ; Wed, 30 Jan 2002 13:46:29 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0UHH9900530 for ips-outgoing; Wed, 30 Jan 2002 12:17:09 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail1.aarohicommunications.com (cpe-66-87-94-158.ca.sprintbbd.net [66.87.94.158]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0UHDQj00082 for ; Wed, 30 Jan 2002 12:13:27 -0500 (EST) Received: from srirampc ([24.245.56.218]) by mail1.aarohicommunications.com (Mirapoint) with ESMTP id AAK05820 (AUTH sriramr); Wed, 30 Jan 2002 09:28:06 -0800 (PST) From: "Sriram Rupanagunta" To: "WENDT,JIM \(HP-Roseville,ex1\)" , Subject: RE: iSCSI: No Framing Date: Wed, 30 Jan 2002 11:18:04 -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.50.4133.2400 In-Reply-To: <499DC368E25AD411B3F100902740AD650AFC7D96@xrose03.rose.hp.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > Perhaps we should discuss the possibility of not > specifying any framing mechanism (FIM or COWS) in the > first version of iSCSI. > I agree with all your comments, and this seems to be the reasonable approach to take. Brute force method, as you pointed out correctly, may be acceptable for NICs/Off-load engines working over long-fat pipes. -Sriram Aarohi Communications, Inc. > 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 Wed Jan 30 13:53: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 NAA28976 for ; Wed, 30 Jan 2002 13:53:00 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0UI1Jf04039 for ips-outgoing; Wed, 30 Jan 2002 13:01:19 -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 g0UI1Gj04032 for ; Wed, 30 Jan 2002 13:01:16 -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 CC032402B; Wed, 30 Jan 2002 12:01:10 -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, 30 Jan 2002 12:01:04 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A9B8.154FA02A" Subject: RE: iSCSI: SCSI Cmd PDU larger than 48 bytes Date: Wed, 30 Jan 2002 12:01:03 -0600 Message-ID: <31891B757C09184BBFEC5275F85D5595104E20@cceexc18.americas.cpqcorp.net> Thread-Topic: iSCSI: SCSI Cmd PDU larger than 48 bytes Thread-Index: AcGpm/ho+pUWe1V0SOeT0AT39yfT3AADUrcA From: "Martin, Nick" To: "Sanjay Goyal" , Cc: X-OriginalArrivalTime: 30 Jan 2002 18:01:04.0644 (UTC) FILETIME=[15B67440:01C1A9B8] Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C1A9B8.154FA02A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sanjay, =20 This is a reasonable question. Here is my opinion. =20 Firstly the occurrence of such commands in most iSCSI sessions is not a random function with predictable distribution. =20 For a target, the likelihood of a bi-directional command or a CDB larger than 16 bytes is near zero unless the target supports such commands. Many of today's targets will support (understand and execute) neither bi-directional nor large CDB commands. =20 For an initiator (HBA), the probability is zero until support is added to upper layer (device class) software to be able to send such commands. Further the OS's interface to the HBA must comprehend and permit such requests to be passed from the device class drivers to the HBA drivers. The HBA might not know whether device drivers will send such commands until they do so. =20 Still these can not be effectively used unless the same customer has both. For a bridge device which might be translating between iSCSI and Fibre Channel, again there must be support in both end points. Otherwise the command will not be generated, or when generated and delivered, will be rejected. Hopefully after the first such rejected command, additional similar commands will be very few and far between. =20 There are SCSI commands defined today which require long CDBs or bi-directional data transfers and there are more commands being proposed which would require one or both. At least one major vendor has already built devices which use them. They may be widely used someday. They are not yet "main-stream" or "common place". =20 If a customer has a device which supports or depends on this functionality and an initiator which can use them, iSCSI must be able to deliver them. In sessions with such a device, a high percentage of the commands could fall into these categories.=20 =20 Thanks, Nick -----Original Message----- From: Sanjay Goyal [mailto:sanjay_goyal@ivivity.com] Sent: Wednesday, January 30, 2002 8:33 AM To: 'roweber@acm.org' Cc: ips@ece.cmu.edu Subject: iSCSI: SCSI Cmd PDU larger than 48 bytes what is the probability that the SCSI Cmd PDU will be more than 48 bytes?=20 the cases are: 1. Bi-Di command 2. CDB larger than 16 bytes Regards Sanjay G ------_=_NextPart_001_01C1A9B8.154FA02A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Sanjay,
 
This=20 is a reasonable question.  Here is my opinion.
 
Firstly the occurrence of such commands in most = iSCSI sessions=20 is not a random function with predictable = distribution.
 
For a=20 target, the likelihood of a bi-directional command or a CDB larger = than 16=20 bytes is near zero unless the target supports such = commands.  Many of=20 today's targets will support (understand and execute) neither=20 bi-directional nor large CDB commands.
 
For an=20 initiator (HBA), the probability is zero until support is added to = upper=20 layer (device class) software to be able to send such commands.  = Further=20 the OS's interface to the HBA must comprehend and permit = such=20 requests to be passed from the device class drivers to the HBA = drivers.   The HBA might not know whether device=20 drivers will send such commands until they do = so.
 
Still=20 these can not be effectively used unless the same customer has = both.  For a=20 bridge device which might be translating between iSCSI and Fibre = Channel, again=20 there must be support in both end points.  Otherwise the command = will not=20 be generated, or when generated and delivered, will be = rejected. =20 Hopefully after the first such rejected command, additional=20 similar commands will be very few and far = between.
 
There=20 are SCSI commands defined today which require long CDBs or = bi-directional=20 data transfers and there are more commands being proposed which = would=20 require one or both.  At least one major vendor has = already built=20 devices which use them.  They may be widely used = someday.  They are=20 not yet "main-stream" or "common place".
 
If a=20 customer has a device which supports or depends on this functionality = and an=20 initiator which can use them, iSCSI must be able to deliver=20 them.  In sessions with such a device, a high percentage of = the=20 commands could fall into these = categories. 
 
Thanks,
Nick
-----Original Message-----
From: Sanjay Goyal=20 [mailto:sanjay_goyal@ivivity.com]
Sent: Wednesday, January = 30, 2002=20 8:33 AM
To: 'roweber@acm.org'
Cc:=20 ips@ece.cmu.edu
Subject: iSCSI: SCSI Cmd PDU larger than 48=20 bytes

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

the cases = are:

1. Bi-Di = command

2. CDB larger than 16=20 bytes

Regards

Sanjay=20 G

------_=_NextPart_001_01C1A9B8.154FA02A-- From owner-ips@ece.cmu.edu Wed Jan 30 13:57: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 NAA29099 for ; Wed, 30 Jan 2002 13:57:11 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0UHbZL02242 for ips-outgoing; Wed, 30 Jan 2002 12:37:35 -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 g0UHbWj02233 for ; Wed, 30 Jan 2002 12:37:32 -0500 (EST) Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom MMS-2 SMTP Relay (MMS v4.7)); Wed, 30 Jan 2002 09:36:19 -0800 X-Server-Uuid: 2a12fa22-b688-11d4-a6a1-00508bfc9626 Received: from mail-sj1-1.sj.broadcom.com (mail-sj1-1.sj.broadcom.com [10.16.128.231]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id JAA15539; Wed, 30 Jan 2002 09:37:28 -0800 (PST) Received: from PCSJCGNAVEEN (dhcpe1-sj3-103 [10.21.65.103]) by mail-sj1-1.sj.broadcom.com (8.8.8/8.8.8/MS01) with SMTP id JAA16420; Wed, 30 Jan 2002 09:37:29 -0800 (PST) From: "Naveen Nimmu" To: "WENDT,JIM (HP-Roseville,ex1)" , ips@ece.cmu.edu Subject: RE: iSCSI: No Framing Date: Wed, 30 Jan 2002 09:37:16 -0800 Message-ID: MIME-Version: 1.0 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: <499DC368E25AD411B3F100902740AD650AFC7D96@xrose03.rose.hp.com> X-WSS-ID: 1046F099433476-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 I second all the points made here and vote for no framing... Naveen Nimmu -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of WENDT,JIM (HP-Roseville,ex1) 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 Wed Jan 30 14:30: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 OAA00213 for ; Wed, 30 Jan 2002 14:30:04 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0UIVnN06612 for ips-outgoing; Wed, 30 Jan 2002 13:31:49 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lucy.trebia.com ([65.192.191.151]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0UIVlj06603 for ; Wed, 30 Jan 2002 13:31:47 -0500 (EST) Received: from trebia.com (trebia-dhcp-20-122.trebia.com [192.168.20.122]) by lucy.trebia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id D2KMYC6Y; Wed, 30 Jan 2002 12:46:07 -0500 Message-ID: <3C58315E.1090104@trebia.com> Date: Wed, 30 Jan 2002 12:46:06 -0500 From: James Smart Reply-To: james.smart@trebia.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI Markers and Framing References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit As you were looking for more votes from those on the reflector... I would vote for either 5 or 6, where 6 is defined as - FIM optional to use, separately enabled/disabled for tx and rx paths, and should implement on the tx path. -- James John Hufferd wrote: >Now that I have punished you all with the notes defining what is Framing >and COWS. I will lobby for one. > >Here again are the choices > >1. FIM now, and Bare Framing later >2. FIM now, and COWS Framing later >3. COWS now, and Bare Framing later >4. COWS now, and COWS Framing Later >5. Nothing now, and some kind of Framing Later >6. FIM now, and some kind of Framing Later > >Two arguments one for FIM now and one for Bare Framing later: > >Let me start with "Framing Later": > >The more I have seen of the work going on defining RDMA/iWARP, and the work >that is going into the Framing Experimental Status, the more I believe, we >can NOT now know how this will work out. Let me give you an example. The >only significant concern, with Bare Framing, is the case of a false >positive indicator only when the network has re-segmented the TCP Segment. >The Bare Framing protocol has a 48-bit Random number and a 16 bit length >field to detect this. I believe this has a lower probability of false >positives then passing an undetected error through the 16 bit TCP/IP XOR >Checksum, and possibly even the 32-bit CRC. So the Experimental work was >started to prove that this was not an issue. Now, even though Bare Framing >is the easiest to implement, and probably statically just fine (at least in >my opinion), some folks are attempting to come up with a fool proof >approach, which probably causes more implementation costs. (You can bet >that will be a major shoot out.) No one yet has been able to do the needed >math to prove that Bare Framing is a problem or not a problem (volunteers >anyone?). But sooner or later some one will do that. There is even a >chance that another word could be added to the Random Number to make it >even stronger. In the mean time we have two Different COWS proposals, >and no one knows if something now unknown will bleed over from the RDMA >work. > >We simply do not know how the Framing will work out. > >iSCSI choosing a Marking approach to match one of the perceived Framing >approaches, will not cause that approach to happen, and it is probably >going to cause turf wars, and other non productive interactions. > >Therefore, I have come to the conclusion that Markers and Framing are >disjoint issues. Further, we have no control over the direction of >framing. > >Now my arguments for "FIM now": > >FIM is the lowest overhead Marker approach we have been able to come up >with. I think we need something that can easily be placed into SW ( In >this context I am talking about SW that does not "OWN" the Host TCP/IP >stack.). As I have stated before, FIM is simple to implement and can >greatly help some HW. It needs to be Sent only if requested, and not >other wise. It has been in the spec for some time, is therefore well >understood and I think it has been scrubbed my a number of different >vendors. Some of which have told me that they have either placed it in >their product or are working on that. This is NOT to say that we can not >change it, but that because of its longevity in the spec, has undergone a >lot of study. And we should have important reasons not to do FIM (such as >if it doesn't work). >Now, Jonathan Stone, has stated that "transatlantic can regularly show 50% >drop rate". I would like the vendors to have some approach to enable a >reasonable solution, to this and other long haul requirements, which keeps >the Adapter cost as low as possible. Also, that would mean that it can NOT >wait until 10 Gig. > >Now to the issue of MUST or SHOULD implement. > >I have been persuaded that "SHOULD implement on Send" but optional to use, >would be a more acceptable position, since vendors with good and just >reasons would not have to implement it, yet the customer could find >solutions if they needed them. > >Therefore, based on the above reasoning, I am recommending: > >Choice 6, with "SHOULD implement on Send". That is, > >Leave FIM in the Spec, and add an enabling statement about "SHOULD >implement on Send if requested by the receiving side". > > >. >. >. >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 Wed Jan 30 15: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 PAA01042 for ; Wed, 30 Jan 2002 15:05:39 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0UJBvZ10056 for ips-outgoing; Wed, 30 Jan 2002 14:11:57 -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 g0UJBtj10052 for ; Wed, 30 Jan 2002 14:11:55 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel10.hp.com (Postfix) with ESMTP id A24A7C0033C; Wed, 30 Jan 2002 11:11:49 -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 LAA14050; Wed, 30 Jan 2002 11:13:26 -0800 (PST) Message-Id: <200201301913.LAA14050@core.rose.hp.com> Date: Wed, 30 Jan 2002 11:25:51 -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: Naveen Nimmu Cc: ips@ece.cmu.edu Subject: Re: iSCSI: State Transitions.. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Naveen, I see that you are suggesting a different "lay-out" for the current state diagram. The lay-out logic for the current state diagram is different. All the "regular" transitions (that take place in the absence of exceptions) are laid out in a single flow (two segments, one vertical to LOGGED_IN, one horizontal to log out). Please note that S7 is not a regular state - ditto for S8. In any case, there's a subjective element here. I need more voices wanting an exception state in the middle of the "regular" flow, to convince me to invest my time in doing ASCII redrawings in a FrameMaker doc... Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Naveen Nimmu wrote: > > This may have been discussed before , I will ask this anyway. > The states S6 and S7 seem to be flipped if we consider all the states in the > time scale > For example I could put the state diagram in page 68 (v.10) in a timeline > kind of state diagram (text diagram attached), > Where S7 appears naturally before S6. > > It seems to me by Exchanging S6 and S7 definitions we might have more clear > (almost unidirectional) state diagrams.. > All comments welcome.. > Naveen Nimmu > > ------------------------------------------------------------------------ > Name: diagram > diagram Type: unspecified type (application/octet-stream) > Encoding: quoted-printable From owner-ips@ece.cmu.edu Wed Jan 30 15:10: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 PAA01217 for ; Wed, 30 Jan 2002 15:10:17 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0UIaXO07070 for ips-outgoing; Wed, 30 Jan 2002 13:36:33 -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 g0UIaVj07065 for ; Wed, 30 Jan 2002 13:36:31 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel12.hp.com (Postfix) with ESMTP id CA23760070F for ; Wed, 30 Jan 2002 10:36:25 -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 KAA04083 for ; Wed, 30 Jan 2002 10:38:03 -0800 (PST) Message-Id: <200201301838.KAA04083@core.rose.hp.com> Date: Wed, 30 Jan 2002 10:50:27 -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: iSCSI: clearing effects Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit All: At the URL below, please find a table describing the "clearing effects" of various events on an iSCSI target's protocol variables and/or states. I was prompted by some online and offline requests suggesting a table like this, this is generally similar to FCP-2's table with the same name. I propose to incorporate this into the iSCSI main draft - ERT had already reviewed this. The only downside I can see is that it introduces some (minor) redundancy, but I believe that the interoperability benefits (that this brings about) would greatly outweigh this disadvantage. The URL is: http://storage-arch.hp.com/clearing_effects.pdf - There are several footnotes in the table that detail the reasoning. I would like to draw your attention to one specific note (19). This points out that the SCSI persistent reservations are released (if the SCSI APTPL bit was not used in securing the reservations) on a target cold reset - IOW, cold reset is identical to a powercycle in all protocol aspects. - Sorry for the acronyms for the column names (than rotating the full name to be vertical in the cell), that was done keeping in mind the eventual need to translate this into ASCII. All the acronyms have footnotes describing them. Comments are welcome. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com From owner-ips@ece.cmu.edu Wed Jan 30 15:14: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 PAA01331 for ; Wed, 30 Jan 2002 15:14:35 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0UJhKD12725 for ips-outgoing; Wed, 30 Jan 2002 14:43:20 -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 g0UJhHj12720 for ; Wed, 30 Jan 2002 14:43:17 -0500 (EST) Received: from amirdesktop (dhcp62 [172.21.2.62]) by astutenetworks.com (8.11.6/8.11.2) with SMTP id g0UJgx604155; Wed, 30 Jan 2002 11:42:59 -0800 From: "Amir Shalit" To: , Subject: RE: iSCSI Markers and Framing Date: Wed, 30 Jan 2002 11:42:59 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <3C58315E.1090104@trebia.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I would vote for 6. Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of James Smart Sent: Wednesday, January 30, 2002 9:46 AM To: ips@ece.cmu.edu Subject: Re: iSCSI Markers and Framing As you were looking for more votes from those on the reflector... I would vote for either 5 or 6, where 6 is defined as - FIM optional to use, separately enabled/disabled for tx and rx paths, and should implement on the tx path. -- James John Hufferd wrote: >Now that I have punished you all with the notes defining what is Framing >and COWS. I will lobby for one. > >Here again are the choices > >1. FIM now, and Bare Framing later >2. FIM now, and COWS Framing later >3. COWS now, and Bare Framing later >4. COWS now, and COWS Framing Later >5. Nothing now, and some kind of Framing Later >6. FIM now, and some kind of Framing Later > >Two arguments one for FIM now and one for Bare Framing later: > >Let me start with "Framing Later": > >The more I have seen of the work going on defining RDMA/iWARP, and the work >that is going into the Framing Experimental Status, the more I believe, we >can NOT now know how this will work out. Let me give you an example. The >only significant concern, with Bare Framing, is the case of a false >positive indicator only when the network has re-segmented the TCP Segment. >The Bare Framing protocol has a 48-bit Random number and a 16 bit length >field to detect this. I believe this has a lower probability of false >positives then passing an undetected error through the 16 bit TCP/IP XOR >Checksum, and possibly even the 32-bit CRC. So the Experimental work was >started to prove that this was not an issue. Now, even though Bare Framing >is the easiest to implement, and probably statically just fine (at least in >my opinion), some folks are attempting to come up with a fool proof >approach, which probably causes more implementation costs. (You can bet >that will be a major shoot out.) No one yet has been able to do the needed >math to prove that Bare Framing is a problem or not a problem (volunteers >anyone?). But sooner or later some one will do that. There is even a >chance that another word could be added to the Random Number to make it >even stronger. In the mean time we have two Different COWS proposals, >and no one knows if something now unknown will bleed over from the RDMA >work. > >We simply do not know how the Framing will work out. > >iSCSI choosing a Marking approach to match one of the perceived Framing >approaches, will not cause that approach to happen, and it is probably >going to cause turf wars, and other non productive interactions. > >Therefore, I have come to the conclusion that Markers and Framing are >disjoint issues. Further, we have no control over the direction of >framing. > >Now my arguments for "FIM now": > >FIM is the lowest overhead Marker approach we have been able to come up >with. I think we need something that can easily be placed into SW ( In >this context I am talking about SW that does not "OWN" the Host TCP/IP >stack.). As I have stated before, FIM is simple to implement and can >greatly help some HW. It needs to be Sent only if requested, and not >other wise. It has been in the spec for some time, is therefore well >understood and I think it has been scrubbed my a number of different >vendors. Some of which have told me that they have either placed it in >their product or are working on that. This is NOT to say that we can not >change it, but that because of its longevity in the spec, has undergone a >lot of study. And we should have important reasons not to do FIM (such as >if it doesn't work). >Now, Jonathan Stone, has stated that "transatlantic can regularly show 50% >drop rate". I would like the vendors to have some approach to enable a >reasonable solution, to this and other long haul requirements, which keeps >the Adapter cost as low as possible. Also, that would mean that it can NOT >wait until 10 Gig. > >Now to the issue of MUST or SHOULD implement. > >I have been persuaded that "SHOULD implement on Send" but optional to use, >would be a more acceptable position, since vendors with good and just >reasons would not have to implement it, yet the customer could find >solutions if they needed them. > >Therefore, based on the above reasoning, I am recommending: > >Choice 6, with "SHOULD implement on Send". That is, > >Leave FIM in the Spec, and add an enabling statement about "SHOULD >implement on Send if requested by the receiving side". > > >. >. >. >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 Wed Jan 30 23:34: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 XAA10174 for ; Wed, 30 Jan 2002 23:34:37 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0V39x111403 for ips-outgoing; Wed, 30 Jan 2002 22:09:59 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from osmtp3.electric.net (osmtp3.electric.net [216.129.90.30]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0V39uj11398 for ; Wed, 30 Jan 2002 22:09:57 -0500 (EST) Received: from [64.170.220.14] (helo=EGRodriguez) by osmtp3.electric.net with esmtp (Exim 3.22 #1) id 16W7bg-0001Qr-04 for ips@ece.cmu.edu; Wed, 30 Jan 2002 19:09:50 -0800 From: "Elizabeth G. Rodriguez" To: Subject: Draft Agenda for Interim IPS meeting Feb 6-8 Date: Wed, 30 Jan 2002 21:06:54 -0600 Message-ID: <00f001c1aa04$58e4df30$0edcaa40@EGRodriguez> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F1_01C1A9D2.0E4A6F30" 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_00F1_01C1A9D2.0E4A6F30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit IPS Interim Meeting Hilton Waterfront Beach Resort 21100 Pacific Coast Highway Huntington Beach, CA 92648 Phone: (714) 960-7873 or (800) 822-7893 Wednesday, February 6 0800-1800 Thursday, February 7 1600-2100 (4pm start assumes T11 Plenary completed prior to 4pm. If runs over, meeting will start immediately after T11 plenary) Friday, February 8 0900-1800 ================================= CHAIRS: David L. Black Elizabeth Rodriguez DRAFT AGENDA: SUBJECT TO CHANGE Announcement: Working Group Last call is anticipated soon after this meeting for iSCSI, FC encapsulation, iFCP, FCIP, and Security documents. Everyone is encouraged to review the all documents, prior to the meeting and 1) provide editorial type feedback directly to the editors/authors 2) bring up any remaining/outstanding issues immediately on the reflector. Note: While the co-chairs are currently anticipating Working Group Last Call on the aforementioned documents, this is by no means a guarantee that Working Group Last Call will happen on any of the documents. That decision will be made after the interim meeting and the drafts have been revised, if needed. ---- Wednesday, February 6 at 0800-1800 ---- - Agenda Bashing and Administrivia (5 min) - BLUE SHEETS - NOTE WELL - Charter and Milestone revisions (coming soon) - iSCSI Boot (5 min) draft-ietf-ips-iscsi-boot-04.txt Status update. - iSCSI stringprep (5 min) draft-ietf-ips-iscsi-string-prep-00.txt Status update. - Use of SLP with ISCSI (5 min) draft-ietf-ips-iscsi-slp-02.txt Status update. - iSNS (5 min) draft-ietf-ips-isns-07.txt Security of iSNS and iSNS as used with iFCP and iSCSI, including security policy distribution. - iSNS MIB (5 min) draft-ietf-ips-isns-mib-01.txt Status update. - iSCSI MIB (30 min) draft-ietf-ips-iscsi-mib-03.txt Status update and relationship to SCSI MIB. Table structure diagram available at: ftp://ftpeng.cisco.com/mbakke/ips/iscsi-mib/Visio-ietf-iscsi-uml-model-0 3-access.pdf - iSCSI Naming and Discovery Requirements (2 hours) draft-ietf-ips-iscsi-name-disc-04.txt Includes ISID changes. - iSCSI EUI64-based Node Naming (30 minutes) draft-grant-iscsi-eui64node-00.txt - Lunch (1.5 hours) - iSCSI Markers and Framing (2 hours) Fixed Interval Markers: - "SHOULD" or "MAY" implement? (MUST has been ruled out) - If "MAY", keep in main iSCSI draft or put in separate experimental draft? Should a new experimental draft addressing ULP Framing be created? - iSCSI Open Mike (3 hours) draft-ietf-ips-iscsi-10.txt Note: It is anticipated that this draft will go to working group last call some sometime around the end of February. Announcement: QLogic has invited participants to attend a social on Wed evening, from 6-9pm. ---- Thursday, February 7 at 1600-2100 ---- (May start late, depending on what time the T11 plenary completes) - Agenda Re-Bashing and Administrivia (15 min) - BLUE SHEETS - NOTE WELL - Last Call process - SCSI MIB (30 minutes) draft-ietf-ips-scsi-mib-00.txt - iSCSI SRP Intellectual Property Rights (30 min) Report on known status of IPR issues for SRP. NOTE: Progress is being made on these issues. - Security (3 hours) draft-ietf-ips-security-07.txt Certificate issues and encapsulation mode (transport/tunnel)requirements Note: It is anticipated that this draft will go to working group last call some sometime around the end of February. - Security, SCSI MIB and common issues open mike (45 minutes) ---- Friday, February 8 at 0900-1800 ---- - Agenda Re-Bashing and Administrivia (5 min) - BLUE SHEETS - NOTE WELL - FC Management MIB (45 minutes) draft-ietf-ips-fcmgmt-mib-00.txt This is the initial draft of the IPS FC Management MIB, which replaces the work formerly done in the IPFC working group. - FCIP MIB (30 minutes) draft-ietf-ips-fcip-mib-01.txt - iFCP MIB (5 minutes) Status update. - FC Encapsulation (5 min) draft-ietf-ips-fcencapsulation-05.txt Status update Note: It is anticipated that this draft will go to working group last call some sometime around the end of February. - iFCP (30 min) draft-ietf-ips-ifcp-09.txt Note: It is anticipated that this draft will go to working group last call some sometime around the end of February. - iSNS for iFCP (5 minutes) Status update. - FCIP (1 hour) draft-ietf-ips-fcovertcipip-08.txt Note: It is anticipated that this draft will go to working group last call some sometime around the end of February. - SLP and FCIP (5 min) draft-ietf-ips-fcip-slp-01.txt Status update. - Lunch (1 hour, 20 minutes) - Open Mike (4.5 hours) Any IPS related issues, including, but not limited to: FCIP and iFCP related issues T11 (FC-BB2)/FCIP relationship issues Security issues (not addressed on Thursday) iSCSI issues (not addressed on Wed) ------=_NextPart_000_00F1_01C1A9D2.0E4A6F30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IPS Interim Meeting

Hilton Waterfront Beach =
Resort
21100 =
Pacific Coast Highway
Huntington Beach, CA =
92648
Phone:  (714) 960-7873 or (800) =
822-7893

 

Wednesday, February 6 =
0800-1800
Thursday,  February 7 1600-2100 (4pm =
start assumes T11 Plenary completed prior to 4pm.  If =
runs over, meeting will start immediately after T11 =
plenary)
Friday,    February 8 =
0900-1800
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
CHAIRS: =
David L. Black 
       &nbs=
p;Elizabeth Rodriguez =

 
DRAFT =
AGENDA: SUBJECT TO CHANGE
 
Announcement:  Working Group Last call =
is anticipated soon after this meeting for iSCSI, FC encapsulation, =
iFCP, FCIP, and Security documents.
Everyone =
is encouraged to review the all documents, prior to the meeting and =

1)    provide editorial type feedback =
directly to the editors/authors
2)    bring up any =
remaining/outstanding issues immediately on the =
reflector.
 
Note:  While the co-chairs are currently =
anticipating Working Group Last Call on the aforementioned documents, =
this is by no means a guarantee that Working Group Last Call will happen =
on any of the documents.  That decision will be made after the =
interim meeting and the drafts have been revised, if =
needed.
 
 
---- =
Wednesday, February 6 at 0800-1800 ----
 
- Agenda =
Bashing and Administrivia (5 min)
        - =
BLUE SHEETS
  =
      - NOTE =
WELL
        - =
Charter and Milestone revisions (coming =
soon)
 
- iSCSI =
Boot (5 min)
        =
draft-ietf-ips-iscsi-boot-04.txt
 
        =
Status update.
 
- iSCSI =
stringprep (5 min)
        =
draft-ietf-ips-iscsi-string-prep-00.txt
 
        =
Status update.
 
- Use of =
SLP with ISCSI (5 min)
        =
draft-ietf-ips-iscsi-slp-02.txt
 
        =
Status update.
 
- iSNS (5 =
min)
        =
draft-ietf-ips-isns-07.txt
 
        =
Security of iSNS and iSNS as used with iFCP and iSCSI, =
including
       &nbs=
p;        security policy =
distribution.
 
- iSNS =
MIB (5 min)
        =
draft-ietf-ips-isns-mib-01.txt
 
        =
Status update.
 
 
- iSCSI =
MIB (30 min)
        =
draft-ietf-ips-iscsi-mib-03.txt
 
        =
Status update and relationship to SCSI MIB.  Table =
structure
       &nbs=
p;        diagram available =
at:
        ftp://ftpeng.cisco.com/mbakke/ips/iscsi-mib/Visio-ie=
tf-iscsi-uml-model-03-access.pdf
 
- iSCSI =
Naming and Discovery Requirements (2 =
hours)
        =
draft-ietf-ips-iscsi-name-disc-04.txt
 
        =
Includes ISID changes.
 

- iSCSI EUI64-based = Node Naming (30 minutes)

      draft-grant-iscsi-eui64node-00.txt

 

- Lunch (1.5 =
hours)
 
- iSCSI Markers and =
Framing (2 hours)

      = ;      Fixed Interval Markers:

      - "SHOULD" or "MAY" implement? (MUST has been ruled = out)

      - If "MAY", keep in main iSCSI draft or put in separate = experimental draft?

 

      Should a new experimental draft addressing ULP Framing be = created?

 
 
- iSCSI Open Mike =
(3 hours)
        =
draft-ietf-ips-iscsi-10.txt
        =
Note:  It is anticipated that this draft will go to working group =
last call some sometime around the end of =
February.
 
Announcement:  QLogic has invited =
participants to attend a social on Wed evening, from =
6-9pm.
 
---- =
Thursday, February 7 at 1600-2100 ----
(May =
start late, depending on what time the T11 plenary =
completes)
 
- Agenda =
Re-Bashing and Administrivia (15 min)
        - =
BLUE SHEETS
        - =
NOTE WELL
        - =
Last Call process
 
- SCSI =
MIB (30 minutes)
        =
draft-ietf-ips-scsi-mib-00.txt
 
- iSCSI =
SRP Intellectual Property Rights (30 min)
 
        =
Report on known status of IPR issues for SRP.  =

        =
NOTE: Progress is being made on these =
issues.
 
- =
Security (3 hours)
        =
draft-ietf-ips-security-07.txt
        =

        =
Certificate issues and encapsulation mode =
(transport/tunnel)requirements
        =

        =
Note:  It is anticipated that this draft will go to working group =
last call some sometime around the end of =
February.
 
- =
Security, SCSI MIB and common issues open mike (45 =
minutes)
 
 
---- =
Friday, February 8 at 0900-1800 ----
 
- Agenda =
Re-Bashing and Administrivia (5 min)
        - =
BLUE SHEETS
        - =
NOTE WELL
 
- FC =
Management MIB (45 minutes)
        =
draft-ietf-ips-fcmgmt-mib-00.txt
 
        =
This is the initial draft of the IPS FC Management MIB, which replaces =
the work formerly done in the IPFC working =
group.
 
- FCIP =
MIB (30 minutes)
        =
draft-ietf-ips-fcip-mib-01.txt
 
- iFCP =
MIB (5 minutes) 
 
        =
Status update.
 
- FC =
Encapsulation (5 min)
        =
draft-ietf-ips-fcencapsulation-05.txt
 
        =
Status update
        =
Note:  It is anticipated that this draft will go to working group =
last call some sometime around the end of =
February.
 
- iFCP =
(30 min)
        =
draft-ietf-ips-ifcp-09.txt
        =
Note:  It is anticipated that this draft will go to working group =
last call some sometime around the end of =
February.
 
- iSNS =
for iFCP (5 minutes) 
        =

        =
Status update.
 
 
- FCIP (1 =
hour)
        =
draft-ietf-ips-fcovertcipip-08.txt
 
        =
Note:  It is anticipated that this draft will go to working group =
last call some sometime around the end of =
February.
 
- SLP and =
FCIP (5 min)
        =
draft-ietf-ips-fcip-slp-01.txt
 
        =
Status update.
 
- Lunch =
(1 hour, 20 minutes)
 
- Open =
Mike (4.5 hours)
        =
Any IPS related issues, including, but not limited =
to:
        =
FCIP and iFCP related issues
        =
T11 (FC-BB2)/FCIP relationship issues
        =
Security issues (not addressed on =
Thursday)
        =
iSCSI issues (not addressed on Wed)
        =

        =

 
 =
------=_NextPart_000_00F1_01C1A9D2.0E4A6F30-- From owner-ips@ece.cmu.edu Wed Jan 30 23:54: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 XAA10613 for ; Wed, 30 Jan 2002 23:54:38 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0V48RM14056 for ips-outgoing; Wed, 30 Jan 2002 23:08:27 -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 g0V48Pj14051 for ; Wed, 30 Jan 2002 23:08:25 -0500 (EST) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel11.hp.com (Postfix) with ESMTP id 6E12D60091F; Wed, 30 Jan 2002 20:08:19 -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 UAA10100; Wed, 30 Jan 2002 20:08:14 -0800 (PST) Message-ID: <3C58C3A9.52109B7@cup.hp.com> Date: Wed, 30 Jan 2002 20:10: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 , T10 Reflector Subject: iscsi : iscsi specific CHECK CONDITIONS. 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 specifies that SCSI layer CHECK CONDITIONs be used to indicate some iscsi specific transport errors such as : - Unexpected unsolicited data SK=Aborted Cmd. ASC = 0x0c. ASCQ = 0x0c - Not enough unsolicited data SK=Aborted Cmd. ASC = 0x0c. ASCQ = 0x0d. - Protocol Service CRC SK=Aborted Cmd. ASC = 0x47 ASCQ = 0x05 - SNACK rejected SK=Aborted Cmd. ASC = 0x11 ASCQ = 0x13 However, SPC-2 mandates certain restrictions on when the CHECK CONDITION scsi status may be used for a REPORT LUNs : "The device server shall return a CHECK CONDITION only when it is unable to return the requested LUN inventory" Section 7.19 How should an iscsi target indicate a protocol service crc or SNACK rejected for a REPORT LUNs command ? Would a CHECK CONDITION generated as above render iscsi targets SPC-2 non-compliant and break any functionality w.r.t REPORT LUNs ? Regards, 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 Jan 31 10:57: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 KAA00670 for ; Thu, 31 Jan 2002 10:57:52 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0VEsbu23104 for ips-outgoing; Thu, 31 Jan 2002 09:54:37 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sandmail.sandburst.com (sandmail.sandburst.com [216.57.132.42]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0VEsaj23099 for ; Thu, 31 Jan 2002 09:54:36 -0500 (EST) To: ips@ece.cmu.edu Subject: Re: iSCSI: Framing Steps In-Reply-To: Message from "Somesh Gupta" of "Tue, 29 Jan 2002 10:45:09 PST." References: Date: Thu, 31 Jan 2002 09:54:07 -0500 From: Stephen Bailey Message-Id: <20020131145434.50F484E8C@sandmail.sandburst.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk > While I support a generic direct data placement model, While you know that's the model I like, it isn't specifically what I was talking about. My only point was to enforce some separation of concerns between iSCSI, which is basically an application protocol to carry the RPC-type interactions defined by SAM, and how it is carried. Agreed that TCP has `performance problems' at high speed (AI and MD diverge). Your following point: > 5. A solutions that is iSCSI specific is not likely to give > the savings (especially when it may not work) people expect. hits it on the head. TCP (or whatever transport) needs to solve this problem in a general way. The reason Ethernet/TCP/IP is economical is because its approach to data transport is scalable and general. The various dimensions of cheapness start to evaporate when you say `we just need this special hook to get application X to work well'. I'm am so down with not specifying ANY framing in iSCSI. Steph From owner-ips@ece.cmu.edu Thu Jan 31 12:01: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 MAA03363 for ; Thu, 31 Jan 2002 12:01:18 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0VFufA28042 for ips-outgoing; Thu, 31 Jan 2002 10:56:41 -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 g0VFucj28036 for ; Thu, 31 Jan 2002 10:56:38 -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 0830A3D08; Thu, 31 Jan 2002 09:56:32 -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, 31 Jan 2002 09:56: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="US-ASCII" Subject: RE: iscsi : iscsi specific CHECK CONDITIONS. Date: Thu, 31 Jan 2002 09:56:29 -0600 Message-ID: <78AF3C342AEAEF4BA33B35A8A15668C6019E2180@cceexc17.americas.cpqcorp.net> Thread-Topic: iscsi : iscsi specific CHECK CONDITIONS. Thread-Index: AcGqDTxBPvX6/ImQSHGewa2bLNzCeQAYOGzg From: "Elliott, Robert" To: "IPS Reflector" , "T10 Reflector" X-OriginalArrivalTime: 31 Jan 2002 15:56:31.0367 (UTC) FILETIME=[D9B4A170:01C1AA6F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g0VFuej28039 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Wednesday, January 30, 2002 10:10 PM > To: IPS Reflector; T10 Reflector > Subject: iscsi : iscsi specific CHECK CONDITIONS. > > iSCSI specifies that SCSI layer CHECK CONDITIONs be used to > indicate some iscsi specific transport errors such as : > > - Unexpected unsolicited data > SK=Aborted Cmd. ASC = 0x0c. ASCQ = 0x0c > - Not enough unsolicited data > SK=Aborted Cmd. ASC = 0x0c. ASCQ = 0x0d. > - Protocol Service CRC > SK=Aborted Cmd. ASC = 0x47 ASCQ = 0x05 > - SNACK rejected > SK=Aborted Cmd. ASC = 0x11 ASCQ = 0x13 > > However, SPC-2 mandates certain restrictions on when the > CHECK CONDITION scsi status may be used for a REPORT LUNs: > "The device server shall return a CHECK CONDITION only when > it is unable to return the requested LUN inventory" > Section 7.19 > > How should an iscsi target indicate a protocol service crc > or SNACK rejected for a REPORT LUNs command ? Would a > CHECK CONDITION generated as above render iscsi targets > SPC-2 non-compliant and break any functionality w.r.t > REPORT LUNs ? If you get such errors in the service delivery subsystem, the REPORT LUNS is not "able to return the requested LUN inventory." The command must be considered unsuccessful if a CRC error occurs, the data length is suspect, etc. I don't think there is any conflict in the wording today. INQUIRY is worded exactly the same way as REPORT LUNS. Perhaps the REQUEST SENSE wording is clearer and should be applied to REPORT LUNS and INQUIRY: The device server shall return CHECK CONDITION status for a REQUEST SENSE command only to report exception conditions specific to the command itself. For example: a) An invalid field value is detected in the CDB; b) An unrecovered parity error is detected by the service delivery subsystem; or c) A target malfunction that prevents return of the sense data. --- Rob Elliott, Compaq Server Storage Robert.Elliott@compaq.com From owner-ips@ece.cmu.edu Thu Jan 31 12:03: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 MAA03467 for ; Thu, 31 Jan 2002 12:03:19 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0VFmnp27352 for ips-outgoing; Thu, 31 Jan 2002 10:48:49 -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 g0VFmlj27344 for ; Thu, 31 Jan 2002 10:48:48 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 10:43:12 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E039C84A6@CORPMX14> From: Black_David@emc.com To: Dan_McConnell@Dell.com, ips@ece.cmu.edu Subject: RE: "Lower overhead" iSCSI Date: Thu, 31 Jan 2002 10:34:40 -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 Some comments from an IETF perspective: (1) The IETF does not standardize protocols that are intended only for use in private networks, especially when the topology of those private networks has to be limited to ensure proper operation. (2) The best intentions to restrict use of a protocol to such private networks often go awry - if the protocol is seriously useful, it will get used in other places. (3) IETF will only consider standardization of an iSCSI over UDP protocol when TCP-equivalent/friendly congestion control is included. This is not negotiable - don't even ask. (4) The NFS experience should be considered - NFS was originally specified to run over UDP, but most NFS servers in use today run over TCP due to its better behavior on real networks. The TCP vs. UDP performance deltas for NFS are not that large even when the CPU is saturated. Thanks, --David > -----Original Message----- > From: Dan_McConnell@Dell.com [mailto:Dan_McConnell@Dell.com] > Sent: Tuesday, January 29, 2002 5:30 PM > To: ips@ece.cmu.edu > Subject: "Lower overhead" iSCSI > > > Let me start off by saying that I am interested in doing "iSCSI" protocol > over UDP. Now I realize that this is an old issue and will probably start > some "religious" battles, but let me state the scenarios before I receive > death threats. The planned environment that this will go into is a small > one with say 10 servers connected through a "non-blocking" switch to the > storage device (ie no routers, gateways, etc...just direct point-to-point > connections). This is assuming that the switch is really non-blocking and > hopefully implements flow control or pause frames. So technically all you > should have to worry about is port/device contention. However, when you > think about it...this is similar to FC. FCP runs on class 3 FC which is a > non-reliable transport protocol such as UDP and handles contention, also > some of the early "SAN interconnect" guys are doing this today with > relatively good performance and few issues. > The attempt here is to maintain low CPU utilization at high > performance rates. While I realize that these TOE devices are moving along > rapidly, there are some situations where they are not feasible, such as a > blade server environment (no PCI slots, and no real estate/power available > for onboard TOE). Worst case scenario is that a packet is dropped or > received out of order and the ULP (SCSI) must resend the cmd/data sequence - > still no data lost, just a temporary performance hit. > So my question is: is this feasible?, and why not implement an > "iSCSI" protocol layer that can run over TCP or UDP(though I realize it > won't be considered "standards compliant")? > > Thanks, > Dan > From owner-ips@ece.cmu.edu Thu Jan 31 13:52: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 NAA07799 for ; Thu, 31 Jan 2002 13:52:55 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0VHrkw07550 for ips-outgoing; Thu, 31 Jan 2002 12:53:46 -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 g0VHrfj07535 for ; Thu, 31 Jan 2002 12:53:42 -0500 (EST) Received: from bursar.muttsnuts.com (193.120.246.22) by mail.san.yahoo.com (5.5.056) id 3C58830D0002E9A1 for ips@ece.cmu.edu; Thu, 31 Jan 2002 09:53:13 -0800 Message-Id: <5.1.0.14.2.20020131174436.02a9be60@mail.muttsnuts.com> X-Sender: markemuttsnuts@mail.muttsnuts.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 31 Jan 2002 17:48:41 +0000 To: ips@ece.cmu.edu From: "Mark S. Edwards" Subject: Re: iSCSI: No Framing In-Reply-To: <499DC368E25AD411B3F100902740AD650AFC7D96@xrose03.rose.hp.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ips@ece.cmu.edu Precedence: bulk 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 Thu Jan 31 16:27: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 QAA13043 for ; Thu, 31 Jan 2002 16:27:11 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0VKStd20096 for ips-outgoing; Thu, 31 Jan 2002 15:28:55 -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 g0VKSqj20086 for ; Thu, 31 Jan 2002 15:28:53 -0500 (EST) Received: from amirdesktop (dhcp62 [172.21.2.62]) by astutenetworks.com (8.11.6/8.11.2) with SMTP id g0VKSg600630; Thu, 31 Jan 2002 12:28:42 -0800 From: "Amir Shalit" To: "Mark S. Edwards" , Subject: RE: iSCSI: No Framing Date: Thu, 31 Jan 2002 12:28:42 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <5.1.0.14.2.20020131174436.02a9be60@mail.muttsnuts.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit 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 Thu Jan 31 19:11: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 TAA16088 for ; Thu, 31 Jan 2002 19:11:41 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0VNVPM04215 for ips-outgoing; Thu, 31 Jan 2002 18:31:25 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g0VNVOj04211 for ; Thu, 31 Jan 2002 18:31:24 -0500 (EST) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Thu Jan 31 18:24:11 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 g0VNTWL80127; Thu, 31 Jan 2002 18:29:32 -0500 (EST) Received: (from jkf@localhost) by zydeco.research.bell-labs.com (8.9.1/8.9.1) id SAA20946; Thu, 31 Jan 2002 18:29:32 -0500 (EST) Date: Thu, 31 Jan 2002 18:29:32 -0500 (EST) From: Jeff Fellin Message-Id: <200201312329.SAA20946@zydeco.research.bell-labs.com> To: amir@astutenetworks.com, ips@ece.cmu.edu Subject: RE: iSCSI: No Framing X-Sun-Charset: US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk 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 Thu Jan 31 19:13: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 TAA16115 for ; Thu, 31 Jan 2002 19:13:10 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0VNMGH03567 for ips-outgoing; Thu, 31 Jan 2002 18:22:16 -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 g0VNMDj03559 for ; Thu, 31 Jan 2002 18:22:14 -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); Thu, 31 Jan 2002 15:22:02 -0800 Received: from 157.54.8.109 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 31 Jan 2002 15:22:07 -0800 Received: from red-msg-02.redmond.corp.microsoft.com ([157.54.12.70]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 31 Jan 2002 15:22:03 -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: Thu, 31 Jan 2002 15:21:51 -0800 Message-ID: <24A715275661C8428C00432EFCA5CB7C03FCAB3D@red-msg-02.redmond.corp.microsoft.com> Thread-Topic: iSCSI: No Framing Thread-Index: AcGqm++BzhjQ75NKQxiTGDiUe0zSrQAEdCBg From: "Jim Pinkerton" To: "Amir Shalit" , "Mark S. Edwards" , X-OriginalArrivalTime: 31 Jan 2002 23:22:03.0762 (UTC) FILETIME=[17746520:01C1AAAE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g0VNMEj03560 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit 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 Thu Jan 31 21:37:46 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18930 for ; Thu, 31 Jan 2002 21:37:46 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g111VZ911737 for ips-outgoing; Thu, 31 Jan 2002 20:31:35 -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 g111VXj11732 for ; Thu, 31 Jan 2002 20:31:33 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id <1B5ZXRT7>; Thu, 31 Jan 2002 20:31:27 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029373F0@CORPMX14> From: Black_David@emc.com To: Michael_Fischer@adaptec.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: not offering a key Date: Thu, 31 Jan 2002 20:17:54 -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 question is that if there is no such thing as an implicit value, then a > "default value" shouldn't exist, right? Isn't a "default" implicit? There are two senses of implicit here that are subtly different: (1) A "default value" is what is used in the absence of negotiation. It is implicit only in the sense of "what results from the absence of negotiation". (2) An absence of negotiation is an absence of negotiation. iSCSI login does not treat the absence of a key as equivalent to sending =. There are NO implicit negotiation steps. So a "default value" is to be used implicitly if it's not negotiated, but negotiation is *always* completely explicit to avoid possible confusion - if an implementation wants to negotiate something, it has to explicitly negotiate it, and the other side must explicitly respond. > 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. > 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). 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. In contrast, if there are no implicit offers, an implementation has the choice of always choosing to negotiate the keys whose default values differ between versions, which looks like a simpler approach to me. The upshot is that default values are supposed to be used in the absence of negotiation, but having them play no special role in negotiation results in a more robust negotiation protocol and potentially simpler implementations. Picking up Robert Russell's question on this issue: > It seems to me that your interpretation is adding something new that > is not in the standard and was never intended to be in the standard. > That is that the value of keys that were not negotiated is "unknown" > or uncertain. On the contrary, the standard is quit explicit that > all keys have default values, and if a key is not negotiated then it > retains its default value on both sides of the connection, initiator > and target. If this were not the case, then we would be in the > situation of essentially requiring the negotiation of every key, > just to confirm the defaults, and this is clearly contrary to > the whole idea of the negotiation process. > > Am I misunderstanding what you are saying? Yes, see above. The Initiator who thinks the default is still 8191 has a bug, but causing the whole negotiation to fail for that sort of bug appears to be going seriously overboard. Negotiation is optional, but once negotiation of a key is commenced, it must be concluded explicitly. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Jan 31 22:10: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 WAA19330 for ; Thu, 31 Jan 2002 22:10:45 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g112PbK15017 for ips-outgoing; Thu, 31 Jan 2002 21:25:37 -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 g112Paj15013 for ; Thu, 31 Jan 2002 21:25:36 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 21:20:25 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029373F3@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: IPsec Usage Question Date: Thu, 31 Jan 2002 21:11:53 -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 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. Please send me the answers directly. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Jan 31 22:11: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 WAA19356 for ; Thu, 31 Jan 2002 22:11:41 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g112T2b15209 for ips-outgoing; Thu, 31 Jan 2002 21:29:02 -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 g112T0j15199 for ; Thu, 31 Jan 2002 21:29:00 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 21:23:53 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029373F4@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: RE: iSCSI: No Framing Date: Thu, 31 Jan 2002 21:15:21 -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 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 Thu Jan 31 22:12:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19369 for ; Thu, 31 Jan 2002 22:12:45 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g112EA114338 for ips-outgoing; Thu, 31 Jan 2002 21:14:10 -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 g112E9j14334 for ; Thu, 31 Jan 2002 21:14:09 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 21:09:02 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029373F1@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: Edited Minutes of the 1/29/02 IPS Security Conference call Date: Thu, 31 Jan 2002 21:00:30 -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 These minutes have been edited somewhat. Summary of important topics discussed on the call: - IKE Identity Payloads. Allowing use of FQDNs in addition to IP addresses as IKE identities will resolve an issue regarding dynamic addresses raised on the list. The entire list of possible IKE identities needs to be reviewed as part of this change. - IPsec and authorization. New iSCSI MIB model proposes to list IKE identities for authorization purposes, iSNS can also help with this. - IPsec certificates. A warning will be added about large keys increasing the likelihood of IKE running into IP fragmentation which often causes failure in practice. - Rekey intervals - The intervals specified in the draft were calculated under overly pessimistic assumptions and hence are unduly short. They'll be removed and replaced with a general description of the issue. - Security policy, Send Targets and iSNS. Independent of whether iSNS is in use an iSCSI Initiator needs to know whether IPsec is needed to contact a Target. Beyond that, IKE can handle all required feature negotiation. iSNS can distribute the info about whether a target requires IPsec, and can store IKE proposals for convenience. An attribute indicating whether a Target requires IPsec will be added to SLPv2 for iSCSI. The easiest way to deal with Send Targets is to make it homogeneous wrt IPsec usage - if IPsec is used for the session on which the Send Targets is performed, it's used to contact the Targets obtained. - Dangling SAs. Paul Koning was correct about the prohibition of dangling SAs being excessive. The requirement to delete phase 2 SAs when the corresponding phase 1 SA goes away will be removed. - Transport mode vs. tunnel mode. A key observation is that unlike remote access, IP Storage protocols do not generally need to dynamically allocate IP addresses through IPsec tunnels. Long email with diagrams will be forwarded to the list shortly. This removes the specification and significantly reduces interoperability concerns in this area, removing the last major obstacle to requiring tunnel mode. Summary of proposed requirements for tunnel and transport mode: - Tunnel mode would be REQUIRED in all cases for interoperability. - RFC 2401 classifies every IPsec implementation as either a host or security gateway; Transport mode would also be REQUIRED for host IPsec implementations. This condition is *solely* about IPsec implementations - it is in principle possible to use a security gateway in conjunction with any iSCSI, FCIP, or iFCP system, even to the point of integrating the gateway onto an HBA or NIC. More details below. - Tunnel mode address usage. Configuration and discovery can be painful if the inner and outer IP addresses are different. There are no good solutions to this in the current IPsec world beyond manual configuration. Query to list on this topic coming shortly. Detailed minutes: We got into a discussion of the -07 draft, posted in December. The changes were relatively minor from -06; major difference was the attempt to be more general by referring to "IP storage protocols" when text intends to apply to iSCSI, FCIP and iFCP. That way, if a new IP storage protocol comes along it will be covered and we won't have to revise the draft again. Participants were urged to read over the -07 drafts and send any issues to the iSCSI security list and/or the IPS WG list. We then talked about IKE identity payloads. David Black noted that the current text requires use of IP addresses as identifiers. This is limiting because if the addresses are dynamically assigned you will effectively be requiring group pre-shared keys, which was what we were trying to avoid by favoring aggressive mode for pre-shared keys. The solution is to change the text to also enable use of FQDNs as identifiers. There was discussion about whether other ID payloads would also be acceptable. This depends on whether we are talking about transport mode or tunnel mode. For transport mode, IP subnets or ranges doesn't make sense; it might make sense for tunnel mode. It was resolved that Bernard will consolidate the text relating to ID payloads and make a proposal to the list on how it should be changed, so that we can make progress. We then got into a discussion of IPsec and authorization. In our discussion of SLPv2 security as part of the IPS security effort, we had gotten into a discussion of whether IPsec could be used for SLPv2 security, instead of the RFC2608 security. We decided this was ok, and Erik Guttman subsequently incorporated IPsec into the RFC2608bis security model, removing the previous model. This has caused some discussion about how authorization is done. For example, how do you know that a host is authorized to act as SA? DA? David noted that with FQDN identifiers, an iSCSI target might be configured with a list of authorized FQDNs. Assuming that IPsec authentication was successful, this list of FQDNs could be examined to determine Initiator authorization. IPsec is also capable of doing some basic authentication, by configuring Initiators and Targets with the appropriate trusted roots. The trusted root for IPS protocols might be different from trusted roots for other purposes. The implication here is that IPsec is really most appropriate for intra-domain use -- as has been pointed out by the IESG. Looked at the other way, an Initiator doing iSCSI logon authentication via a mutually authenticating method (e.g. SRP) would know whether a Target was authenticated or not. David Black pointed out that with CHAP the Target is not authenticated, only the Initiator, so you might not always know that. It is also possible for iSNS to supply authorization information, which can make the process of maintaining this more scalable. Text will be drafted describing how authorization could be accomplished: via iSNS, manually, etc. It was noted that since RFC2608bis now incorporates the IPsec security text, that we can probably remove the text from the IPS security draft and just reference RFC2608bis, assuming it goes through. This seems cleaner and less likely to result in conflicts down the road. We had a short discussion of IPsec certificate handling. It was noted that PKIX is going to be working on this -- but that they have traditionally been slow at completing things. We talked a bit about the IKE cert fragmentation problem. Hillarie Orman's draft on key sizes implies a 2048bit key recommendation for use with AES. The larger key sizes in turn imply larger certs, particularly if OIDs are added. This means that an IKE certificate chain will almost certainly cause fragmentation, and even a single cert may get close to causing IKE fragmentation. IKE fragmentation is a problem because most NATs will drop fragments as will many routers (recent versions of Cisco IOS can handle this correctly). David Black requested that we insert a warning describing the problem. Unfortunately it is a nasty one because it doesn't really have a good solution in the current version of IKE. There was a discussion of dangling IKE Phase 2 SAs. These are not prohibited in RFC 2401-2409, and some implementations have them. Yet the IPS security draft prohibits them. This text should probably be removed -- delete the section discussion how IKE phase 2 SAs should be deleted on receipt of an IKE phase 1 delete. Bernard took this as an action item. There was a discussion of IKE rekey intervals. The Bellare et al. paper is really about the birthday attack problem. That is, since CBC modes depend on the previous ciphertext block, if two ciphertext blocks are identical and the next plaintext block is also identical then the next ciphertext block is also identical. This allows an attacker to find areas of repetition within the plaintext. A single birthday attack instance is expected to occur in 2^(X/2) blocks, where X is the block size in bits. Probabilities for birthday attack occurrence are easily calculated via combinatorics. The current draft text is extremely conservative in that it requests that rekey occur in considerably less than 2^(X/2) blocks. This seems excessive in that even a single birthday attack instance doesn't leak much information -- you just know that two plaintext blocks are the same. To get more information you'd need quite a few birthday attack instances, which is very unlikely in just 2^(X/2) blocks. So the proposal is to redo the calculations using the 2^(X/2) formula. David Black requested some explanation of the issue as well. We also talked about the status of ESPv3. This is currently non-normative (not required by IP Storage protocols), and David Black requested that it stay that way unless it was in IPsec WG last call by IETF 54 in Yokahama, Japan. We talked about iSNS security policy. The goal of the IPS security document is to specify IPsec parameters well enough so that implementations will be able to negotiate things and interoperate off the bat. As a result, the minimum piece of configuration required is whether an IPS endpoint requires IPsec or cleartext. This can't be determined from IKE alone without risking a long timeout, something undesirable for a disk access protocol. The information can be configured manually, or can be supplied via iSNS. If an Initiator can obtain IPsec security policy from other means (manually, via IPsec security policy functionality) then it need not query the iSNS server for this information. However, if it doesn't have the information, it can use iSNS to obtain an IKE proposal payload for a particular Target. The question was asked about what security configuration information could/should be provided by SLPv2. The minimum configuration would be an SLPv2 attribute describing whether a Target supports IPsec. It was noted that if iSNS or SLPv2 is used to determine security policy or configuration, then these protocols MUST be secured. Otherwise, an attacker could provide bogus security policy to convince a host to connect to it in cleartext. Authorization is important too, or else an attacker who had an IPsec certificate could masquerade as an iSNS server or SLPv2 DA and provide bogus information. We then got into a discussion of tunnel mode vs. transport mode. David Black noted that in many situations, IPS gateways are not functioning as IPsec gateways or an IP router. Thus, the IPS gateway will not routing packets through it -- both the inner and outer tunnel addresses will be consumed by the IPS gateway. As a result, the IPS gateway will not need to assign addresses for use with IPsec tunnel mode. This simplifies things considerably. It was resolved that Bernard would put together text explaining the various configurations and the implications, based on David's original message on the subject. With respect to the IPsec tunnel mode vs. transport mode debate, David proposed the following: IPsec tunnel mode is a MUST implement for both Initiators and Targets; IPsec transport mode is also required where RFC2401 says it is required. RFC 2401 requires Transport mode for everything but IPsec gateways. The end result of this is that a Target might be able to just implement Tunnel mode if it were to act as an IPsec gateway; however, if it is not a gateway, then it MUST implement transport mode. For the specific case of an iSCSI initiator, only tunnel mode would be "MUST implement", as that is the minimum requirement for interoperability. If an initiator's IPsec implementation is an IPsec gateway (as RFC 2401 defines and uses that term), then it would not be required to implement transport mode. The question was raised of whether having to do both transport and tunnel mode was excessive. Would this be a problem for hardware vendors? David Black felt that this approach seemed like the only way to satisfy both those vendors who want to enable separate gateway boxes as well as those who prefer the efficiency and end to end approach of IPsec transport mode. Existing IPsec implementations conform to RFC 2401, and hence this requirement (transport mode required where RFC 2401 says it is required) should not cause problems for use of such implementations. Finally, David felt that not only was adhering to this aspect of the IPsec architecture a good thing to do in principle, but in practice it should also help avoid Last Call objections that iSCSI is misusing IPsec by departing from the architecture. In connection with the latter point, a question was raised about whether not requiring AH could cause difficulties. It will not, because the ipsec WG is in the process of revising RFC 2401 to (among other things) remove the current requirement for AH. Sorry for the delay in getting these out. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Jan 31 22:12: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 WAA19383 for ; Thu, 31 Jan 2002 22:12:56 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g112JQ614653 for ips-outgoing; Thu, 31 Jan 2002 21:19:26 -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 g112JOj14648 for ; Thu, 31 Jan 2002 21:19:24 -0500 (EST) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 21:22:06 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029373F2@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: DHCP and IPsec transport/tunnel mode Date: Thu, 31 Jan 2002 21:05: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 Here's the promised message on why IP Storage protocols differ from remote access in not generally needing to allocate IP addresses through IPsec tunnels (which requires an IPsec extension to run DHCP through an IPsec tunnel). This is the rationale behind the proposal to REQUIRE tunnel mode without worrying about DHCP complications; sorry for the length, but this stuff is not simple ... I've spent some time thinking about this (wasn't possible before Salt Lake City, sorry) and am coming to the conclusion that I want to question the following requirement from Section 5.1 (p.29) of the -06 IPS Security draft: [2] Dynamic address assignment and configuration. Where IP addresses are dynamically assigned (such as with dynamically addressed hosts implementing iSCSI), it is necessary to support address assignment and configuration within IPsec tunnel mode. The use of DHCP within IPsec tunnel mode has been proposed for this, as described in [55]. However, this mechanism is not yet widely deployed within IPsec security gateways. Existing IPsec tunnel mode servers typically implement the desired functionality via proprietary extensions to IKE. [55] is a reference to draft-ietf-ipsec-dhcp-13.txt in the ipsra WG, which has recently been approved for publication as a Proposed Standard (IIRC). For a remote access situation, I agree with [2] above, the problem I'm having is that iSCSI usage doesn't seem to fit the remote access scenario. I think the same is also true for FCIP and iFCP, but I'll stick to iSCSI in the discussion for clarity. Here's the key diagram from Section 3 (p.5) of draft-ietf-ipsec-dhcp-13.txt: corporate net +------------------+ | | externally | +--------+ | !~~~~~~~~~~! |+-------+ visible | | | | ! rmt host ! ||virtual| host | |security| |---! virtual ! || host | |--------|gateway/| | ! presence ! || |<================>| DHCP |----| !~~~~~~~~~~! |+-------+ |--------| Relay | | +------------------+ ^ +--------+ | +--------+ | |---| DHCPv4 | IPsec tunnel | | server | with encapsulated | +--------+ traffic inside In iSCSI terms the IPsec tunnel would connect the Initiator to the Target. The remote access requirement that "the the remote host appear to be present on the local corporate network" doesn't seem to apply - the "corporate net" would be the private connection from the security gateway to the iSCSI Target, and the combination of doing address allocation separately for it and requiring Initiators to participate in that allocation seems worse than pointless, as it introduces complexity ... For ease of explanation, lets assume that both the Initiator and Target are on the same corporate network. If DHCP is being used on that network, then any dynamic address allocation wants to participate in that DHCP infrastructure, as opposed to defining something separate. One way to see this is to visualize an Initiator that wants to talk to half a dozen different Targets built in the above fashion - asking the Initiator to remember half a dozen different IP addresses (one per Target, because each Target did its own DHCP allocation for the Initiator) looks very wrong. What's actually going on is that the position of the corporate net moves in the above diagram for iSCSI to: corporate net iSCSI internal net +------------------+ | | | externally | | +--------+ | !~~~~~~~~~~! |+-------+ visible | | | | | ! rmt host ! ||virtual| host | | |security| |---! virtual ! || host | |--------|gateway/| | ! presence ! || |<================>| DHCP |----| !~~~~~~~~~~! |+-------+ |--------| Relay | | +------------------+ ^ +--------+ | +---------+ | |---| DHCPv4 | IPsec tunnel | | server??| with encapsulated | +---------+ traffic inside The next step in this journey is to observe that for the situation of interest, the iSCSI Initiator on the left hand side doesn't even need two IP addresses - the left hand side implementation in the above diagram is host-based, and hence should be able to use the same IP address for both the inner and outer header of the tunnel-mode IPsec packets. If that address has to be dynamic, it can be obtained from DHCP on the LAN in the usual fashion (in essence, the externally visible host uses DHCP to get an IP address that is used by both it and the virtual host). Ok, but what about iSCSI implementations that use a security gateway in a fashion that the inner and outer IP addresses have to be different (e.g., because the gateway "knows" that all traffic destined for its IP address is for the gateway and won't pass it on to iSCSI)? One example is the right hand side of the above diagram, and lets stick with it for consistency, even though it's a Target and dynamic addresses for Targets cause some configuration complications (an indirection through DNS is one way to address these). I suggest that the above observation about DHCP on the corporate network still applies: If DHCP is being used on that network, then any dynamic address allocation wants to participate in that DHCP infrastructure, as opposed to defining something separate. One way of doing this is to take the box labeled "DHCPv4 server??" in the above diagram and make it a DHCP proxy/relay that connects to the corporate network on the other side of the security gateway (and take out the DHCP relay in the gateway): corporate net |-----------------------------------+ | | | iSCSI internal | +------------------+ | | | | externally | | +--------+ | !~~~~~~~~~~! | |+-------+ visible | | | | | ! rmt host ! | ||virtual| host | | |security| |---! virtual ! | || host | |--------|gateway/| | ! presence ! | || |<================>| |----| !~~~~~~~~~~! | |+-------+ |--------| | | | +------------------+ ^ +--------+ | +---------+ | | |---| DHCPv4 |---+ IPsec tunnel | | Relay | with encapsulated | +---------+ traffic inside The actual DHCPv4 server would be somewhere out on the corporate net. This will strike some folks as a bit peculiar, as it's something that one would NEVER do in a remote access situation, because the security domains on the two sides of the gateway are very different (one has to protect the corporate net from the wild Internet on the other side of the gateway). I think that the situation is less extreme for iSCSI, in that its ok to rely on the corporate net for DHCP services even while we want to use IPsec to protect iSCSI traffic flowing over it. OTOH, the above diagram is not exactly the preferred way of doing things - I could easily see the resulting situation favoring static IP address allocation when the DHCP relay is physically separate, but it may be viable if the DHCP relay is software collocated with the security gateway (software). Comments/reactions/etc. please? 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 ---------------------------------------------------