RE: iSCSI Requirements Draft - Informal WG Last Call - A few c oncerns about the document.

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

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

Seems reasonable, but I'm having a hard time seeing where this fits and what
to say, and I have this nagging notion that this is already obliquely
mentioned in one of the sections.  I'll work on this.

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

I don't see how these comments require any change to the text already
included.  The text doesn't mention sessions, but when it was written, the
details of session and connection relationships weren't fully explored.  The
details of the relationship between session, connection, command allegience
and the mapping of an I_T_L nexus are covered in the other docs.

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

The term "active" and "passive" attacks are commonly used in discussions of
Denial of Service attacks.  I didn't feel it was appropriate to provide
background information since there are plenty of other sources of
information about DOS available.  The requirement specifically mentions
passive attacks since it is nearly impossible to imagine/protect against
active attacks.
 
> 4)  REMOVE SALES/MARKETING FLUFF
> 
..snip..
> 	Other similar text is sprinkled throughout the document and 
> 	should be deleted.

I disagree.  This is an informational document - part of the intent of this
document is to discuss the implications and possibilities that iSCSI
technology development provides.  There are countless examples of this type
of discussion in other informational RFCs.

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

I see your point, I'll work on that wording.

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

This text was added to satisfy a specific request.  The intent was to
summarize an approach that was already considered and discarded.  The hope
is that newcomers to the iSCSI discussion could review this document and we
might avoid revisiting this idea.

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

How about  
"In the interest of simplicity, iSCSI SHOULD minimize optional features.
When optional features are deemed necessary, the protocol MUST allow for
feature negotiation at session establishment (login).  This also implies
iSCSI MUST operate correctly when no optional features are negotiated, and
when any individual option negotiation is unsuccessful."

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

You must have missed an early discussion that future technology developments
may make it necessary to re-evaluate our digest calculation (witness the TCP
checksum debate).  The intent isn't to allow negotiation of digest formats,
but to recognize that in the future it may be necessary to change the
protocol to update the digest algorithm.

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

I like it.  Done.

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

See separate email to group.

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

The first requirement is mandated by the IETF for new IP protocols and is
satisfied by our selection of TCP.  I think that's said in several
paragraphs in the document.

Thanks for your review!

Marj