Comments on the current iSCSI draft

["harwood, jack" <harwood_jack@emc.com>]

Comments on the internet-SCSI (iSCSI) Document 3/7/00
------------------------------------------------------------
The following are comments compiled from EMC engineering with respect to the
internet-SCSI document drafted by IBM and Cisco.  In general this document
has provided a good start to mapping SCSI over TCP, in particular with
mapping to TCP and not UDP.  Specifically the comments cover 

* Architecture - Issues with the overall document that appear to pose
obstacles to widespread deployment.
* Conceptual - Issues with document that need addressing to enable effective
implementations.
* Specifics - Issues with bits and bytes in the command descriptions
* Questions - Questions about decisions made.

Architectural
-------------
* There is an issue with the separation of the Control and Data Channel. NAT
(address translation), firewall, or load balancing products will not support
iSCSI without changes which in turn is a barrier to adoption for large
networks.  If the goal is to provide interleaving of control commands with
large data transfers we feel this can be accomplished in other ways.
	- Use smaller data frames to allow better interleaving of control
and 
	data on a single connection
	- Use multiple connections between the same source and destination
pair 
	where each connection is independent of other connections 
	(i.e., data/control are combined on each connection).
Separation of control and data also adds new failure modes where one channel
closes but the other does not.

* The use of DNS addressing in the protocol as described in sections 3.13,
Open Data Connection, and section 3.17, Third Party Copy, will force all
parties to depend on DNS in order for the protocol to work. While system and
network administrators should be free to make this choice (and invest the
effort in making DNS suitably robust), this protocol design should NOT be
based on the assumption that DNS is a robust highly available service.  The
protocol should be based on IP addresses.


Conceptual
----------
* The iSCSI protocol requires a strong authentication mechanism. In its
current form, without an implementation and corresponding specification, it
is impossible to write an interoperable authentication implementation from
the document as it stands, hence at least one strong authentication
mechanism must be mapped onto the protocol, possibly in a separate document
or documents.

* The parameter negotiation, described in sections 3.9-12, is very general.
The free-form text/value format will cost code to parse and may not be
justified.

* The action of killing all outstanding IOs on a login or operation timeout
seems too severe for this process and provides an opening for a denial of
service attack.  Also there is no other rationale in the document as to why
this semantic is useful.

* A general mapping of error recovery for iSCSI is needed, i.e. what parts
need definition versus what will use TCP error recovery mechanisms.  

* In section 3.17, Third party copy needs a much better explanation about
authentication, login and how the entire process works.  


Specifics
---------
* It should be stated specifically in sections 2.4 and 3.8 that iSCSI data
segments cannot overlap.

* The expected data length and flags, i.e. command direction, should be
described in the SCB itself and not as separate fields in the SCSI command,
see section 3.3.

* Using the task tag and TCP connection 4-tuple (source and destination IP
addresses and ports) we should have a fully qualified identifier and should
not need LUN number in the response and task management response, see
section 3.3 and 3.6.

* The LUN number should be embedded in the data for the AEN, see section
3.4.
 
* In section 5.1 a recommendation is made to use 8k as the upper limit for
small TCP segments.  Depending on the MTU size this recommendation may cause
fragmentation.  More detail and analysis are needed to justify this
recommendation.

* A standard CRC should be required, see section 6.1.

* The target should not gets its name from the initiator, see section 10.1.

* Section 10.3 needs to provide details on how to prevent reply/reuse.  Also
this text seems to allow passwords in the clear which is not acceptable.

* In section 10.5 it states "Once AllowNoRTT has been set to 'yes', it
cannot be set back to no".  It should clarify this is for the open
connection and closing this connection and opening a new connection will
clear this condition.



Questions
--------
* What value does the ability to do an iSCSI ping add to the existing
ability to do an ICMP ECHO?  If little or none, this should be omitted, see
section 3.15.



TCP-RDMA
--------
Although the premise of TCP acceleration is quite useful the concept of RDMA
does not apply for our application of internet SCSI.  We will handle the
moving of data as implementation specific and not as generic design such as
RDMA.