Re: iSCSI Requirements Draft - Informal WG Last Call - A few concerns about the document.

[Robert Snively <rsnively@Brocade.COM>]

Having reviewed the iSCSI requirements draft, I have identified the
following issues.  Where possible, I have proposed corrections.

1)  MISSING REQUIREMENT FOR AVOIDING LUN BLOCKING

	At present, there does not appear to be any text
	referencing the problems of hanging up all logical units
	on a target because one command to one logical unit
	was stalled.  This should be addressed explicitly, 
	probably in section 4.2.

2)  ORDERING OF COMMANDS

	In section 2.4, the following text is given:
    
   MUST provide a FIFO transport of SCSI commands, even when commands 
   are sent along different paths. This command ordering mechanism 
   SHOULD seek to minimize the amount of communication necessary across 
   multiple adapters doing transport off-load. 
    
	This was heavily discussed already.  Related to point 1, the
	issue should actually be the FIFO transport of SCSI commands
	for a particular I_T_L nexus.  If the commands are going to
	different logical units or crossing different I_T nexi, the
	requirement should not be present.  I would propose changing
	the MUST to apply only to an I_T_L nexus, allowing other
	relationships to have an un-ordered relationship.  This will
	be especially useful for recovery on systems that install
	a lower level framing capability.

3)  CLARIFY AN UNCLEAR SECURITY REQUIREMENT  

Section 6.2 provides a requirement that uses the oxymoron 
"passive attack".  If it is an attack, there is an intent and
it is active.  I would propose deleting the word "passive" in
the following requirement:
    
   iSCSI authenticated login MUST be resilient against >passive< attacks. 
  
4)  REMOVE SALES/MARKETING FLUFF

	Certain sections are filled with opinions that have no
	relevance to the standards activities upon which these
	requirements are being placed.  The wording may or may
	not be correct and is often improvable.  Such wording
	should be deleted from this document.  The more
	egregious examples, but not the only examples, of text
	that should be deleted include:

	In section 2.1: 

   "The IP infrastructure offers compelling advantages for volume/block-
   oriented storage attachment compared to current approaches.  It 
   offers the opportunity to take advantage of the performance/cost 
   benefits provided by competition in the internet marketplace. This 
   reduces the cost of storage infrastructure by: 
    
    -- Increasing performance (market driven by networking demand) 
    -- Offers richer array of management, security and QoS solutions 
    -- Economies arising from the need to install and operate only 
       single type of network 
    
   In addition, mapping SCSI over IP provides: 
    
    -- Extended distance ranges 
    -- Connectivity to "carrier class" services that support IP"

	While an intriguing marketing statement, there is absolutely
	no objective information that indicates what is the standard of 	comparison and whether or not any of this is true.  This text
	should be deleted.

	On page 7:

   "Products could initially be offered for Gigabit Ethernet attachment, 
   with rapid migration to 10 GbE.  For performance competitive with 
   alternative SCSI transports, it will be necessary to implement the 
   performance path of the full protocol stack in hardware.  These new 
   storage NICs might perform full-stack processing of a complete SCSI 
   task, analogous to today's SCSI and Fibre Channel HBAs, and might 
   also support all host protocols that use TCP (NFS, CIFS, HTTP, etc)."

	All these statements depend on what market is being approached
	by the implementation.  For any particular market, any or all
	of this information may be incorrect.  This text should be deleted.

	Other similar text is sprinkled throughout the document and 
	should be deleted.

5)  CORRECT TEXT ASSOCIATED WITH DIRECT DATA PLACEMENT

	The text associated with direct data placement in section 2.2
	is largely associated with routing buffering and framing, not
	the requirements for zero-copy.  The text at present is:

   Direct data placement (zero-copy iSCSI): 
    
   This is an important implementation goal.  In an iSCSI system, each 
   of the end nodes (for example host computer and storage controller) 
   has ample memory; but the intervening nodes (NIC, switches) do not.  
   Assume a WAN-scale retransmission requirement of 25 MB (1 Gbps) or 
   250 MB (10 Gbps, see Framing discussion).  Therefore, intervening 
   nodes MUST NOT be required to buffer data. 

	It should be rewritten to say:

   Direct data placement (zero-copy iSCSI): 
    
   Direct data placement allows iSCSI data to be moved directly
   to the required memory locations in memory with no requirement
   to recopy the incoming information.  Direct data placement 
   significantly reduces the memory bus and I/O bus loading in
   the end-point systems, allowing improved performance.
   
6)  ALTERNATE CONNECTION BINDING

	The section in 2.4 discussing an alternate mechanism for
	connection binding merely serves to weaken the stand
	in favor of the selected binding relationship.  The following
	text should be deleted:

   "An alternate approach that was extensively discussed involved 
   sending all commands on a single connection and the associated data 
   and status on a different connection (asymetric approach). In this 
   scheme, the transport ensures the commands arrive in order. The 
   protocol on the data and status connections is simpler, perhaps 
   lending itself to a simpler realization in hardware.  One 
   disadvantage of this approach is that the recovery procedure is 
   different if a command connection fails vs. a data connection. Some 
   argued that this approach would require greater inter-processor 
   communication when connections are spread across processors.   
   The reader may reference the mail archives of the IPS mailing list 
   between June and September of 2000 for extensive discussions on 
   symmetric vs asymmetric connection models." 

7)  OPTIONAL BEHAVIOR

	In clause 2.4, wording about the desirability of minimizing
	optional features is discussed.  However, it reaches the 
	mistaken conclusion that there is only one time at which
	options may be negotiated and that rejection is required if
	the options are not supported.  The following text should 
	be changed from:

   "In the interest of simplicity, iSCSI SHOULD minimize optional 
   features.  When features are deemed necessary, the protocol SHOULD 
   allow for feature negotiation at session establishment (login) and 
   provide for rejection when an implementation does not support a 
   requested feature."

	to:

   "iSCSI SHOULD minimize optional features.  When features are
   deemed necessary, the protocol SHALL provide for negotiation of
   the use of those features.  iSCSI SHALL operate correctly whether
   an optional feature is negotiated to be used or is 
   negotiated not to be used."

8)  REMOVE OPTIONAL EXTENSIONS

	In section 4.1, the text suggests that various digest
	implementations may be used.  This is an option that has
	no reason to be allowed, since we will choose the proper
	digest calculation method after due study and no other
	calculation method should be allowed.  The following
	text should be deleted.
 
   "The iSCSI header format SHOULD be extensible to include other digest 
   calculation methods."

9)  SOFTEN REQUIREMENT TO IMPLEMENT STRANGE SAM-2 FUNCTIONS

	In section 5.2, the following text suggests that any
	feature in SAM-2 requires a valid transport mapping.  However,
	it further suggests making such functions recommended or
	required to implement, even if they are rarely used or 
	used only in contexts different from iSCSI.  The following
	text:    

   "In order to be considered a SCSI transport, the iSCSI standard must 
   comply with the requirements of the SCSI Architecture Model [SAM2] 
   for a SCSI transport.  Any feature SAM2 requires in a valid 
   transport mapping MUST be specified by iSCSI and the specification 
   SHOULD make such a feature either RECOMMENDED or REQUIRED in 
   implementations."

	should be changed to read:

  "In order to be considered a SCSI transport, the iSCSI standard SHALL 
   comply with the requirements of the SCSI Architecture Model [SAM2] 
   for a SCSI transport.  Any feature SAM2 requires in a valid 
   transport mapping SHALL be specified by iSCSI.  The iSCSI document 
   SHALL specify for each feature whether it is OPTIONAL, RECOMMENDED,
   or REQUIRED to implement and/or use."

10)  INCORRECT REQUIREMENT FOR BRIDGES/ROUTERS  

	In section 5.2, there is a paragraph treating gateways.
	I contend that all present SCSI transports are easily bridged
	BECAUSE they have chosen a very similar encapsulation format.
	The similar encapsulation format is that used by FCP, FCP-2,
	SBP-2, Packetized Parallel, and SSA.  The structure of 
	iSCSI packets and the protocol for transmitting them should
	be similar to the encapsulation formats used by those
	protocols.  Using this as a guideline, the following
	requirement is incorrect:

   "The iSCSI protocol MUST allow for the construction of gateways to 
   other SCSI transports, including parallel SCSI [SPI-X] and to SCSI-
   FCP[FCP, FCP-2].  It MUST be possible to construct "translating" 
   gateways so that iSCSI hosts can interoperate with SCSI-X devices; 
   so that SCSI-X devices can communicate over an iSCSI network; and so 
   that SCSI-X hosts can use iSCSI targets (where SCSI-X refers to 
   parallel SCSI, SCSI-FCP, or SCSI over any other transport).  This 
   requirement is implied by support for SAM-2, but is worthy of 
   emphasis. These are true application protocol gateways, and not just 
   bridge/routers.  The different standards have only the SCSI-3 
   command set layer in common.  These gateways are not mere packet 
   forwarders."

	That paragraph should be reworded as follows:

   "The iSCSI protocol MUST allow for the construction of simple
   gateways to other SCSI transports, including parallel SCSI and
   packetized parallel SCSI as specified by SPI-4, and Fibre
   Channel Protocol for SCSI as specified by FCP and FCP-2.
   It MUST be possible to construct  
   gateways so that iSCSI devices can use SCSI commands to communicate with
   devices using other protocols.  This 
   requirement is implied by support for SAM-2, but is worthy of 
   emphasis. iSCSI SHALL use packet formats similar to the common
   packet formats used by other packetized SCSI protocols where
   possible to allow both simple bridging gateways and more
   sophisticated translating gateways."

11) CLARIFY CONGESTION QUESTION

	Section 8.3 considers congestion in a rather strange way.
	It was my impression that a well-behaved TCP/IP connection
	provided appropriate congestion management, regardless of
	the information passed across it.  As a result, the following
	text in 8.3 should be removed:

   "The iSCSI protocol MUST be a good network citizen with proven 
   congestion control (as defined in RFC 2309). In addition, iSCSI 
   implementations MUST NOT use multiple connections as a means to 
   avoid transport-layer congestion control."

	and replaced with:

   "iSCSI implementations MUST NOT use multiple connections as a means to 
   avoid transport-layer congestion control.  Standard TCP/IP 
   congestion management mechanisms operate normally while transporting
   iSCSI information."